You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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.
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?
The text was updated successfully, but these errors were encountered: