build docker base images in CI #322
Conversation
abe-winter
requested review from
stuqdog and
jckras
and removed request for
a team
abe-winter
changed the title
| type: boolean | ||
| default: false | ||
| push: | ||
| description: "whether to push the images after building them" |
There was a problem hiding this comment.
just for my own understanding, In what cases would we run this workflow without pushing images to GHCR? why do we have the option to disable pushing inputs.push here?
There was a problem hiding this comment.
push=false for testing only; for commands with a big side effect (in this case overwriting a public image), I like to have a 'dry run' option
| file: etc/docker/base-images/${{ inputs.dockerfile }} | ||
| labels: ${{ steps.base-meta.output.labels }} | ||
|
|
||
| # build sdk (if inputs.build-sdk) |
There was a problem hiding this comment.
Can you explain the purpose of separating build-base and build-sdk into two separate steps? are there times where only one would be built?
There was a problem hiding this comment.
I did this because the instructions in the readme were already two-step
but in general the purpose of 'base images' is to save time on the constant part of the build
here specifically, could imagine us rebuilding the base images weekly or monthly, and rebuilding the sdk image on every release or on main branch update
What changed
Why
Allow people to use these without having to build them on-laptop
Note
Github CI requires a workflow to be on the main branch before it can be tested; this hasn't been tested and may require another PR. (Once the workflow has ever been on the main branch, it can then be run from other branches).