-
Notifications
You must be signed in to change notification settings - Fork 41
Pipeline resource fly version must match Concourse deployment #55
Comments
it almost looks like there is some behavior to perform a concourse-pipeline-resource/fly/fly.go Line 72 in 45fa8ca
maybe there's a bug in that behavior? |
It looks like the sync is done after login instead of before. No option is also specified for the sync ( |
Currently, What will need to be implemented is a pre-check if there is a discrepancy between the target's major version and the current fly cli's major version, and "sync" if there is via the api. If needed, I have implemented the feature in my fork. I'm not very good at unit tests with golang, and I'm currently not submitting a PR until I can get some testing in first. However, you can still build the container, push it into a private registry, and have concourse reference that. |
FWIW I'm intending to fix this problem by just introducing a native Ultimately I would much rather deprecate this resource type. It's too awkward to support. Once we've far enough along on our Core roadmap I suspect most people won't need it anymore. |
@hstenzel how did you manage to specify the resource type? We are running into the same issue when setting some pipelines on a Concourse v4.X.X.
but the resource still comes up with the latest version of |
Sorry, I'm in a different position and can't check that detail. |
@irbekrm Hi. I realise you posted your question a while ago. I struggled with the same problem today but eventually got it to work by calling Thought I'd post this if you still needed help or someone else with a similar issue sees this. |
Thanks @ZiadSalah ! We don't have a need to pin the resource anymore, but this might become useful at another time. |
Since the
concourse-pipeline-resource
image contains thefly
binary and does notfly sync
, this leads to a failure of the resource when either the resource's fly version is ahead of the Concourse deployment or whenever the Concourse deployment is ahead of theconcourse-pipeline-resource
.The workaround for this is to use a specific version of the resource by specifying the docker tag, but then the pipeline configuration is required to be changed just because the Concourse version is upgraded.
It would be better if the resource did a
fly sync
internally to be sure that it is using the correct version offly
for the Concourse deployment. Even better if the resource could just have a number of versions of fly internally & call an api to determine which it should use.The text was updated successfully, but these errors were encountered: