MDBF-770 - GitHub Reusable Workflows #535
Conversation
The core idea is to use GitHub reusable workflows to divide image builds into groups of parent workflows. Based on the "matrix" in bbw_build_container.yml, parent workflows were created to reflect Dockerfile usage. Each workflow monitors changes in the corresponding Dockerfile, allowing for more granular control over which images are built. A master workflow, "build-workflow-dispatcher," is available to trigger all the child workflows manually or when the template is changed. Rollout Plan: - In bbw_build_container_template.yml, the PUSH to QUAY/GHCR is commented out so we can push this commit and perform regression tests against the current bbw_build_container workflow. - All pending contributions to bbw_build_container should be rebased and adapted to this new workflow by either changing the template file or the corresponding parent workflow. - Our forks should be synced after this is merged. - when we are ready to activate PUSH to registries, we uncomment QUAY/GHCR blocks of code in the template file and disable the old workflow - the old workflow should stay disable for a while in case of a rollback
|
Right now there's a lot of noise in the checks section of this Pull Request. |
There was a problem hiding this comment.
Happy to get this done and merged use.
Rebasing existing work on this can occur afterwards.
Could enable GHCR as the first proof to have some images to test from the build, leaving QUAY for afterwards.
In favour of a quick cleanup. Things are in code history for reverting, if they are maintained for possible revert it tends to linger.
@grooverdan I would keep bbw_build_container.yml for a while, not very much, until we enable QUAY also on these workflows.
How does it sound? |
|
@grooverdan So, I've enabled push to GHCR: I will double check everything to see if I have the right images, tags, platforms, and other parameters right. @fauust If it's ok for you, that OpenSuse/SLES logic for moving files to be available for any container, I would provide it in a different patch as there are already many things to test. --> solved in: acffa3e |
- avoid race conditions and building from different commits when both Dockerfiles and the template file are modified. - define input for the user for the dispatcher workflow
|
One commit to address conditions on which dispatcher runs in parallel with other workflows (Triggered by docker files). |
|
For the failures reported in
|
@grooverdan @fauust @vladbogo .
The core idea is to use GitHub reusable workflows to divide image builds into groups of parent workflows.
Based on the "matrix" in bbw_build_container.yml, parent workflows were created to reflect Dockerfile usage. Each workflow monitors changes in the corresponding Dockerfile, allowing for more granular control over which images are built.
A master workflow, "build-workflow-dispatcher," is available to trigger all the child workflows manually or when the template is changed.
Rollout Plan:
Pending contributions that should be adapted:
If I'm missing something please let me know.