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
The idea behind the following pipeline is that each subsequent job updates the body of the same pre-release until the final job does its update and makes that pre-release to become a normal release:
However, it doesn't work as expected. The subsequent jobs don't get the updated body of the release most of the time (depending on cache accessibility/worker used, afaics), which results into a body like this:
this is an update from job2
this is a final update from job4
(in various combinations, but never a complete one from all 4 jobs).
I believe it matches the explanation from #61 (comment):
This is working as expected of the caching semantics. When a resource version changes in-place, there's no way for Concourse to know that that same version is technically different now. I don't think it's an issue specific to this resource, but you could open a general issue to invalidate caches when a put is done to a version; that may be a route we can explore.
Would storing more release metadata in Concourse solve the problem? E.g. not only the id, tag and timestamp, but also body, commit_sha, etc. Or perhaps some extra timestamp/hash value of the result of the last update of a resource by Concourse's put.
Concourse version: 7.6.0, resource version: bundled with Concourse (v1.6.4).
The text was updated successfully, but these errors were encountered:
The idea behind the following pipeline is that each subsequent job updates the body of the same pre-release until the final job does its update and makes that pre-release to become a normal release:
pipeline.yaml
However, it doesn't work as expected. The subsequent jobs don't
get
the updated body of the release most of the time (depending on cache accessibility/worker used, afaics), which results into a body like this:(in various combinations, but never a complete one from all 4 jobs).
I believe it matches the explanation from #61 (comment):
And is also similar to #69.
Would storing more release metadata in Concourse solve the problem? E.g. not only the
id
,tag
andtimestamp
, but alsobody
,commit_sha
, etc. Or perhaps some extra timestamp/hash value of the result of the last update of a resource by Concourse'sput
.Concourse version: 7.6.0, resource version: bundled with Concourse (v1.6.4).
The text was updated successfully, but these errors were encountered: