Publish Docker images to Docker Hub and GHCR #231
Conversation
Signed-off-by: Andy Bavier <andybavier@gmail.com>
Signed-off-by: Andy Bavier <andybavier@gmail.com>
Signed-off-by: Andy Bavier <andybavier@gmail.com>
gab-arrobo
left a comment
gab-arrobo
left a comment
There was a problem hiding this comment.
LGTM. However, note that #230 replaces the local GHAs with reusable workflows from onosproject/.github, which I think is the most appropriate way to proceed with this (make change only once in onosproject/.github are reuse it everywhere in the onosproject organization. I strongly recommend review/merge that PR first and convert the jobs from this push.yml into reusable workflows
SeanCondon
left a comment
SeanCondon
left a comment
There was a problem hiding this comment.
See comment from Gemini - might be worth doing
| secrets: inherit | ||
|
|
||
| update-version: | ||
| needs: tag-github |
There was a problem hiding this comment.
Gemini highlighted a "Parallel Execution" Risk
Currently, release-image and update-version run in parallel because they both only depend on tag-github.
The Problem: If release-image fails (e.g., Docker registry is down, build error), update-version might still succeed. The Result: Your repository will bump the version (e.g., to 1.2.4-SNAPSHOT), but the artifact for 1.2.3 was never published. You end up in a "zombie state" where the git history says the release is done, but the container registry is empty.
The Fix: Make update-version depend on the success of release-image.
There was a problem hiding this comment.
I partially agree with this comment/suggestion. What happens if the release-image fail? Image is not published and VERSION is NOT updated (update-version does not run). So, you have to manually (re)trigger the release-image action again until it is successful and then you need to manually trigger the update-version action.
On the other hand, if we leave the parallelism there, update-version will always run (based on tag-github) and you have to manually (re)trigger the release-image action if needed, which is the approach we took for the sd-core
There was a problem hiding this comment.
As @gab-arrobo points out, it's not entirely clear what is the ideal behavior if the release_image job fails. It sounds like leaving as-is will at least keep the behavior consistent with sd-core so I'm inclined to do that.
@gab-arrobo Let me know if this PR is what you are looking for: onosproject/.github#14 |
Hi @andybavier, |
3 participants
Add a GitHub workflow for publishing Docker images to Docker Hub and GHCR when the VERSION is updated.