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

Update README.md #62

Closed
wants to merge 11 commits into from
Closed

Update README.md #62

wants to merge 11 commits into from

Conversation

wainersm
Copy link
Owner

No description provided.

wainersm and others added 11 commits September 12, 2023 18:00
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
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant