Repository navigation
ci: newflow prepare build release merge - #164
vibhoraggarwal wants to merge 6 commits into
Conversation
vibhoraggarwal
changed the title
AlexanderLanin
changed the title
cdc8fd2 to
e1a3856
Compare
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Release preparation lacks required permissions, while rebuild inputs permit command injection and can incorrectly roll back latest.
Review effort: Balanced
Findings: 2
Open (3)
What changed in this PR
Introduces a staged container release workflow and manual tag rebuilding.
Changes:
- Adds prepare, build, release, promote, and merge stages.
- Builds SHA-tagged images before publishing releases.
- Adds manual rebuilding of existing release tags.
| File | Description |
|---|---|
.github/workflows/release-and-publish.yaml |
Implements staged releases and tag rebuilds. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
| with: | ||
| ref: ${{ needs.release.outputs.tag_name }} |
There was a problem hiding this comment.
Why did you remove this? Now this action checks it the latest revision from main instead of a fixed one. This workflow now might validate a revision and release a different one, if during building and testing the devcontainer a pull request got merged.
| fi | ||
| # Create the GitHub release only after all validation builds succeed. | ||
| release: | ||
| needs: [build] |
There was a problem hiding this comment.
I guess here is a misconception. Each and every pull request merged to main must build and pass the same tests as executed in this workflow. IMHO there are two reasons this workflow might fail:
- Github network issues (the cause in the linked build failure: https://github.com/eclipse-score/devcontainer/actions/runs/35547146350/job/106175142681#step:5:4095) and this is most often the root cause of build failures
- Ubuntu replaced a package with a newer one (outdated packages with security fixes are removed)
Do we have a better solution to handle the network issues? At builds using bazel we now facilitate the Github Actions Cache to minimize issues caused by Githubs unstable internet connection. At pull requests of the devcontainer we also see a lot of time failed builds due to network issues. I prefer a solution, which makes the workflows for pull requests and releases more stable.
| echo "${{ secrets.GITHUB_TOKEN }}" | docker login ghcr.io -u ${{ github.actor }} --password-stdin | ||
| ./scripts/publish.sh --${{ matrix.os }} "$REBUILD_TAG" | ||
| # Merge the architecture images for an existing rebuilt release. | ||
| rebuild-merge: |
There was a problem hiding this comment.
I am confused about the rebuild and rebuild-merge jobs. To me it looks like this PR tries to only create a new release, after build and test of the devcontainer have been successful. Thus if building the devcontainer fails, there is no tag which could be rebuild, because it was never created.
If needed, these steps could be easily moved into a separate workflow, because they do not depend on anything else and nothing depends on them. However then there is still the issue that they look duplicated to the build and merge steps.
| needs: [prepare] | ||
| if: needs.prepare.outputs.release_needed == 'true' |
There was a problem hiding this comment.
Could you not avoid lots of the code, if you skip the release job, when inputs.rebuild_tag is not empty, but use then inputs.rebuild_tag as input for this job?
Thus the build job would get the tag either from release or from inputs.rebuild_tag.
|
Another way to deal with this could be a command like |
|
@lurtz thanks for the comments. I will be on leave for the next two weeks. I will come back and solve the comments. |
|
FYI I deleted and recreated the 1.11.1 release. I thought it is an easy fix, but this caused a lot of problems. We should talk when you are back |
resolves #162