Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Get behaviour does not match README #31

Open
theozaurus opened this issue Nov 21, 2017 · 1 comment
Open

Get behaviour does not match README #31

theozaurus opened this issue Nov 21, 2017 · 1 comment
Labels

Comments

@theozaurus
Copy link

Using Concourse 3.5.0 and the pool-resource we expected a 'get' to only return when an acquired lock was available. However, the behavior we see is that we are returned the latest resource version for the git repo backing the pool, regardless of a locks state.

The README for this resource states: in: Fetch an acquired lock.

Should the get behavior be to only get acquired locks, or get any lock?

@XenoPhex
Copy link
Contributor

XenoPhex commented Apr 4, 2018

We're also seeing the same issue out pipelines.

Situation: Pipeline 1 claims a specified lock in Job 1 and tries to releases it in Job 2. Between job runs, Pipeline 2, performs any actions on the same pool for any unclaimed locks. When Job 2 tries to release the lock, the pool resource claims that the lock cannot be found.

The root cause of this is the assets/in#73 script is only creating a name and metadata file based on the latest commit to the pool. Instead, a parameter probably needs to be passed to the in script to specify a given lock that's been claimed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants