-
Notifications
You must be signed in to change notification settings - Fork 94
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
workflows: mksoi: Remove mid-build caching #2198
workflows: mksoi: Remove mid-build caching #2198
Conversation
e6c1128
to
670a9b5
Compare
The e2e tests works with this code in my fork: https://github.com/stevenhorsman/cloud-api-adaptor/actions/runs/12202102693/job/34042019318 so I think it's okay to go. |
@@ -15,10 +15,6 @@ PODVM_IMAGE ?= $(REGISTRY)/podvm-generic-$(PODVM_DISTRO)$(if $(filter $(SE_BOOT) | |||
PODVM_CONTAINER_NAME ?= $(REGISTRY)/podvm-docker-image-$(ARCH) | |||
VERIFY_PROVENANCE ?= no | |||
|
|||
PUSH ?= false |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I suggest to leave this makefile toggle. We never know, in future we might decide to push the builder/binaries. Or developers can still use it to easily push and share with another dev.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
wouldn't a developer who is interested in this just push the image instead of using this toggle? I would generally lean towards removal of dead code, even if it could be useful in the future.
toggles like this incur a cost. coginitive burden for people who want to work on those build-scripts and often we end up propagating them in Dockerfile build-args/envs, workflow inputs, ... (cost of carry)
If we have a use case it should be trivial to re-add.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good points. I'm convinced this may incur in cost unnecessarily. Thanks @mkulke !
if: ${{ inputs.arch == 'amd64' }} | ||
run: nix profile install nixpkgs#crane | ||
|
||
- name: Install crane with go |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we can remove Setup Golang version ${{ env.GO_VERSION }}
step as it was only needed for building crane? Consequently remove the line were it gets the go version from versions.yaml.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good spot; updated now. Thanks!
Remove the push of the builder and binaries during the mkosi build, but just output them to the local directory always to simplify the flow and remove the need to use crane to pull them down. Signed-off-by: stevenhorsman <[email protected]>
670a9b5
to
05c0987
Compare
I've tested this on my fork: https://github.com/stevenhorsman/cloud-api-adaptor/actions/runs/12232882664/job/34119638806 and apart from s390x (which I don't have a runner for, so can't test), it is all passing apart from a single test on cri-o, which I don't think it related to this. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thanks @stevenhorsman !
Remove the push of the builder and binaries during the mkosi build, but just output them to the local directory always to simplify the flow and remove the need to use crane to pull them down.