CI: Run different workflow if new image needs to be built.#44
Merged
Conversation
59f8ca5 to
060edfe
Compare
04e5880 to
f625f3c
Compare
218ff43 to
bf5663c
Compare
bf5663c to
695bb67
Compare
If the Dockerfile's have been changed, we need to rebuild the CI image. Else, we can skip this step and just re-use the latest image in-sync with main. Currently there is a workaround regarding how we pass the new CI image name should it need to be built. This is a limitation with how GitHub handles matrix job's with outputs. Because our image tag is based on a constant, the jobs within the matrix will all provide the same value at least. Ideally we would provide the full image name and tag. We can look at refactoring the workflow to avoid this situation. If a new image needs to be built, it will also attempt to push this image to the docker registry. This means any changes to the Dockerfile will require a PR to be opened directly in hipFile instead of a fork. Given that the Dockerfile is expected to rarely change, this should be an acceptable trade-off.
This cache will only be used by the same PR if it gets updated for whatever reason. This way people won't be sad if a particular distro takes 20 minutes to download packages for if they need to change the PR. Intentionally not caching from 'latest' to have a relatively up-to-date image. Open to discuss about this.
695bb67 to
58bfd98
Compare
This will keep our CI image up-to-date, even if we aren't making any changes to the Dockerfile. This will only run if a PR has been accepted and merged.
58bfd98 to
b6cec82
Compare
37608da to
a91e6bd
Compare
a91e6bd to
07099ec
Compare
Collaborator
Author
|
Will need to reconfigure the "Required" CI Checks if this PR is accepted. |
1 task
kurtmcmillan
approved these changes
Nov 13, 2025
derobins
approved these changes
Nov 13, 2025
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
We would like to enable a fork-based development process. Our current CI does not allow this due to us building and pushing a new "development" CI image for every PR. Pushing this image to GHCR is a privileged action and is not enabled by default from external PRs. Using build artifacts instead is another solution that does not require these privileges but loses certain performance qualities like caching. In addition, we found that certain machines could take 30-60 minutes to download the CI image via build artifacts.
This approach uses GHCR but limits when we choose to build and push a new development CI image. This will only be triggered if the Dockerfile has been changed. The rest of the CI process will then use this new development image when building and testing. Since pushing to GHCR is a privileged action, any changes to the Dockerfile must be submitted internally within the repo.
If the Dockerfile's have not been changed, no image will be built and will use the latest CI image that is kept in sync with the develop branch.
Whenever a PR is accepted & merged into develop, a new 'latest' CI image will be built and published.