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
Right now our docker image GitHub workflows have a problem where if we release a 1.2.x patch release after a 1.3.0, the 1.2.x release will get tagged as latest which will potentially "downgrade" people if they try to pull latest. I think most people would expect 1.3.0 to remain the latest in this case.
Right now our docker image GitHub workflows have a problem where if we release a 1.2.x patch release after a 1.3.0, the 1.2.x release will get tagged as
latest
which will potentially "downgrade" people if they try to pull latest. I think most people would expect 1.3.0 to remain the latest in this case.I wrote a new way of determining whether a workflow is running as the result of being the latest release, or just some other release and it's part of the docs site build here: https://github.com/hyperledger/firefly/blob/main/.github/workflows/docs.yml#L26-L48
We should port this code into the docker release job as well: https://github.com/hyperledger/firefly/blob/main/.github/workflows/docker_release.yml
This definitely needs to happen before we do a 1.2.3 patch release or we will need to manually fix Docker tags as we have in the past.
The text was updated successfully, but these errors were encountered: