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
The ref-implementation includes argo workflows. The idpbuilder core includes gitea with an OCI compliant registry. We should add a stack that can be used in conjunction with the ref-implementation that creates an example workflow that can build docker images and push them to the gitea registry. This would allow folks to rapidly ideate on container images within the idpbuilder ecosystem. A great example of this is when we would like to make changes to the cnoe/backstage-app container image and see those changes without having to push to github and build the container.
Then we could wire up a way for gitea to trigger the workflow on commit/push of the dockerfile. This might be able to be done with webhooks that trigger an argo event. See: argoproj/argo-events#1431 (comment)
Finally as an added bonus, maybe we can wire up argocd to watch the container image tags and then re-trigger the deploy of the backstage app when the tag changes somehow:
Have you searched for this feature request?
Problem Statement
The ref-implementation includes argo workflows. The idpbuilder core includes gitea with an OCI compliant registry. We should add a stack that can be used in conjunction with the ref-implementation that creates an example workflow that can build docker images and push them to the gitea registry. This would allow folks to rapidly ideate on container images within the idpbuilder ecosystem. A great example of this is when we would like to make changes to the cnoe/backstage-app container image and see those changes without having to push to github and build the container.
Possible Solution
We could proabably make use of this workflows buildkit template: https://github.com/argoproj/argo-workflows/blob/main/examples/buildkit-template.yaml and just load the "giteaAdmin:password"|base64 into the secret used to create the .docker/config.json for the push container. We can also tune the buildkit to push to our local gitea registry using the flags as explained here: https://github.com/moby/buildkit?tab=readme-ov-file#imageregistry
swapping out the docker.io with our gitea registry info like shown in this example from artifactory: https://jfrog.com/help/r/jfrog-artifactory-documentation/configure-buildkit/buildctl-to-work-with-artifactory#UUID-746f0697-8562-16d3-f06d-763bb55cace3_bridgehead-idm4570299324803233722417853409
Then we could wire up a way for gitea to trigger the workflow on commit/push of the dockerfile. This might be able to be done with webhooks that trigger an argo event. See: argoproj/argo-events#1431 (comment)
Apparently argo event webhooks support's "gogs" another self hosted git server ( https://argo-cd.readthedocs.io/en/stable/operator-manual/webhook/ ), so maybe there is something there we can use.
I believe the foundations for this in gitea are now available: go-gitea/gitea#29145 which means that this can move forward: go-gitea/gitea#1089
Finally as an added bonus, maybe we can wire up argocd to watch the container image tags and then re-trigger the deploy of the backstage app when the tag changes somehow:
https://argocd-image-updater.readthedocs.io/en/stable/
Or using some gitea action (https://docs.gitea.com/usage/actions/overview) magic, replacing the github actions steps in the following:
https://arshsharma.com/posts/2023-10-14-argocd-github-actions-getting-started/
Alternatives Considered
Using gitea actions all together rather than argo workflows to build images: https://tobru.ch/gitea-actions-container-builds/
The text was updated successfully, but these errors were encountered: