forked from confidential-containers/cloud-api-adaptor
-
Notifications
You must be signed in to change notification settings - Fork 0
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
Update README.md #62
Closed
Closed
Update README.md #62
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The podvm_builder, podvm_binaries, and podvm workflows were converted to `workflow_call` so that they can be re-used. Before, on release time, `podvm_builder` were first triggered on a `release` event then the others followed upon finish of the previous. With this change, the `podvm_on_release` workflow was created to be the entry point for the `release` event, so the (now) callable `podvm_builder`, `podvm_binaries`, and `podvm` are directly called. Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Added the `registry` parameter to the builder/binaries/podvm workflows to allow publish the images in an arbitrary registry. Also added login handler if the registry is `ghcr.io`. Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
The current behavior of builder/binaries/podvm workflows is to push images with the `latest` and commit SHA tags. Now that those workflows are callable there is a need to tag those images differently depending on the use case. The approach took here was to used different tags based on the event that triggered the workflow: * on `release` event, tag with `latest` and the commit SHA. Default behavior does not change * on `pull_request` or `pull_request_target` uses the `ci-prN` where `N` is the pull request number. Does not make sense to push `latest` or commit SHA to an image that is transient. Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Added parameters to the `podvm_binaries` and `podvm` workflows to allow overwrite the base images to build the podvm-binaries-* and podvm-* images. This is needed to accomodate the use case of running those workflows on pull request, for instance, suppose a PR 123: * ghcr.io/cloud-adaptor-api/podvm-builder-ubuntu:ci-pr123 is created. * `podvm_binaries` is called with `builder_img_tag=ghcr.io/cloud-adaptor-api/podvm-builder-ubuntu:ci-pr123` which is passed down to the podvm/Dockerfile.binaries in order to use the new builder * Same goes for `podvm`, this time using the built, say, `ghcr.io/cloud-adaptor-api/podvm-binaries-ubuntu-amd64:ci-pr123` image. Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Added the `caa_src_ref` parameter to builder/binaries/podvm workflows so that: * the workflow's `checkout` action will use the passed git ref * the cloud-api-adaptor repository used on the image builds is checked out to ref too Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
The Dockerfile.builder* dockerfiles were changed to allow checking out in an arbitrary git ref, otherwise it will checkout only branches. This make the builder dockerfiles on pair with the other dockerfiles (binaries' and podvm's). Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
When it tries to create the `CAA_SRC_REF` branch and it exists already, it will reset the branch instead of simply fail the checkout operation. That error can happen, for example, if `CAA_SRC_REF` is passed to the builder image then that image is used for the binaries build and you passed the same `CAA_SRC_REF`, i.e., on the builder image the repository is already branched to `CAA_SRC_REF` and in the binary image build it will try to create the branch same again (so failing). The checkout with `-B` will reset the branch instead of fail. Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Until now the `e2e_on_pull` workflow was using built podvm images, where the qcow2 files are extracted and uploaded as artifacts which are picked up by downstream jobs (e.g. `e2e_libvirt`). This changed the workflow to leverage the new `podvm_builder`, `podvm_binaries` and `podvm` workflows so that the podvm images are built from the pull request code, pushed to ghcr.io and the downstream jobs should extract the qcow2 file themselves. Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
No description provided.