Skip to content
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: Enhance s390x mkosi workflow #2019

Draft
wants to merge 25 commits into
base: main
Choose a base branch
from

Conversation

stevenhorsman
Copy link
Member

Try and make the s390x mkosi workflow more like the packer one, so we that could lift and shift it into the e2e/podvm build pipelines in future:

  • Add a ubuntu-22.04 runner for amd64 image build
  • Add input parameters to allow the option to override the registry, tag and git-ref
  • Make the intermediate builder and binary images be pushed to the registry

@stevenhorsman stevenhorsman force-pushed the mkosi-workflow-multi-arch branch 2 times, most recently from 1765e5c to 71c9664 Compare August 28, 2024 13:20
@stevenhorsman
Copy link
Member Author

FYI, I've moved on a lot from this approach to try and build on top of #1965. I'm missed about the best strategy and whether it's worth the complexity to keep separate workflows for the podvm's builder, binaries and image stage, so I've posted on slack to see if others have thoughts.

@stevenhorsman
Copy link
Member Author

Ok, I've re-worked this to have a single mkosi workflow and not interlink with the separate stages. It's still WIP though and in test!

@stevenhorsman stevenhorsman force-pushed the mkosi-workflow-multi-arch branch 9 times, most recently from d9688b1 to e8d62a2 Compare September 16, 2024 12:48
@stevenhorsman stevenhorsman force-pushed the mkosi-workflow-multi-arch branch 15 times, most recently from 8399619 to 6bbe745 Compare September 23, 2024 16:11
@stevenhorsman stevenhorsman force-pushed the mkosi-workflow-multi-arch branch 4 times, most recently from 6ac46de to 334cd80 Compare October 30, 2024 12:43
wainersm and others added 23 commits October 30, 2024 15:58
So that the podvm_mkosi.yaml workflow can be reused in podvm.yaml
to build mkosi artifacts.

Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
- Remove seperate s390x workflow
- Pin runner version
- Add inputs required to plug this into the e2e workflows
- Add check for if builder and binaries image already exist
- Add s390x mkosi install
- bump github actions to latest versions

Signed-off-by: stevenhorsman <[email protected]>
- Update image names to match the existing naming scheme
- Add debug suffix to the container image name for clarity
- Add push/load switch based on the PUSH env

Signed-off-by: stevenhorsman <[email protected]>
- Rename the docker provider's podvm Dockerfile
to Dockerfile.podvm_docker_provider for more clarity and to enable us
to use Dockerfile.podvm for the "main" version of the podvm in future
- Add arch awareness, so we can build images for multiple architectures.

Signed-off-by: stevenhorsman <[email protected]>
- Add calls to build the podvm-mkosi image
in the same places we build the current podvm image

Signed-off-by: stevenhorsman <[email protected]>
Now we switched to docker buildx we are seeing permissions
problems in the s390x workflow

Signed-off-by: Hyounggyu Choi <[email protected]>
- Add input option to select between the debug and non-debug mkosi image build
- Initially use the debug build for e2e tests and non-debug for
release and image publish

Signed-off-by: stevenhorsman <[email protected]>
- Re-use the resources/binaries-tree binaries already fetched in
the podvm_mkosi.yaml to build the podvm image for the docker provider.
- We also need to clean up the image build artifacts to stop the
runner going out of space

Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Signed-off-by: stevenhorsman <[email protected]>
Add a callable workflow that run the e2e tests for the docker provider. This
workflow is similar to e2e_libvirt.yaml.

Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Signed-off-by: stevenhorsman <[email protected]>
This will make the e2e tests for docker to run. Initially it's disabled
on pull requests, so only running with the nightly and manual triggers.

Notice that's set continue-on-error so that the e2e_run_all workflow
exit status won't change, i.e. any failure on e2e_docker is disregarded.

Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Add fedora-like OS support for cross-build-extras

Signed-off-by: stevenhorsman <[email protected]>
- Convert the mkosi image to a qcow2 file
and upload it via oras CLI, so we
can use it for libvirt testing
- Run as sudo to avoid permissions error
- It used to be that the fedora se image was the only
image that was built on s390x, but now with the other
mkosi builds, it feels better to make the s390x ubuntu
podvm image which is arguably set-up incorrectly the
special case. When we drop packer support we can
remove this code.

Signed-off-by: stevenhorsman <[email protected]>
Add runner as an input parameter to e2e_libvirt
tests, so we can control it from calling workflow

Signed-off-by: stevenhorsman <[email protected]>
Publish the podvm qcow2 files with oras

Signed-off-by: stevenhorsman <[email protected]>
In the workflow output the qcow2 oras image location,
so that we can use this in the e2e testing step

Signed-off-by: stevenhorsman <[email protected]>
In the workflow output the docker provider oci image location,
so that we can use this in the e2e testing step

Signed-off-by: stevenhorsman <[email protected]>
In the mkosi flow we publish the podvm qcow2 image
with oras, so add support to pull this down in e2e testing

Signed-off-by: stevenhorsman <[email protected]>
- Added two new decoupled jobs that depends on the
amd64 and s390x mkosi podvm builds to test each
of those images with libvirt
- Added the option of arch specific label triggers in
case of specific testing restrictions

Signed-off-by: stevenhorsman <[email protected]>
We want to run clean up even if previous steps fail,
so try adding `always` to the condition

Signed-off-by: stevenhorsman <[email protected]>
Now that we are testing mutliple archs in the e2e tests
we should use the same workflow that builds the multiarch
CAA image on publish.

Signed-off-by: stevenhorsman <[email protected]>
Use automatic UEFI firmware for VM boot.

Ref: https://libvirt.org/formatdomain.html

Signed-off-by: Pradipta Banerjee <[email protected]>
Try and run the s390x dev build natively on the s390x runner,
so it doesn't run emulated and take a long time.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants