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
I think you're suggesting that PRs have an automated build and push to a public image registry, which can be reachable by any reviewer. It's a good idea but with large scale open source repos, that image registry could swell substantially and someone would need to manage that container registry. Some things to consider about:
Creating/managing the github action to build and push
It's possible to tag the image with only the branch name associated with the PR to apply a limit to images associated with a PR (in contrast to commit sha based tagging)
Managing and securing remote image registry
I do something in my organization's fork which allows us to include linting and CVE scanning using trivy, as well as making the image available.
Hey @Souheil-Yazji, what I 'm suggesting is not to publishd to a public registry but rather push them as artifacts in the CI's run. This way, they are also scoped in the PR rather than a public registry, which could also imply that they are published for use there. An example can be seen in this PR's runs https://github.com/canonical/pipelines-rocks/actions/runs/11816173378 where visualization-server artifact represents the oci-image built from the PR.
On pull requests, workflows should upload the built images as artifacts. This way,
This is not a dashboard-specific thing, but I didn't know where to open this.
The text was updated successfully, but these errors were encountered: