-
Notifications
You must be signed in to change notification settings - Fork 706
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
Publish Kubernetes content container image on each commit #8622
Conversation
|
||
on: | ||
push: | ||
branches: [ 'master' ] |
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 this means we will build content each time a patch is proposed, right [0]?
Should we only be building content when it's merged?
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.
Uhm.... As far as I understand, this will trigger a build each time a patch is pushed to the master
branch. Which means, once it merges to master. Proposing PRs means pushing to a PR-specific branch.
.github/workflows/k8s-content.yaml
Outdated
- name: Install cosign | ||
uses: sigstore/cosign-installer@v2.2.1 | ||
with: | ||
cosign-release: v1.7.2 |
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.
Should we extract this into a variable so that we use the same version of cosign for all actions?
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'd actually be up for removing the with
statement and using whatever cosign release is recommended by the action. what do you think?
branches: [ 'master' ] | ||
|
||
env: | ||
COSIGN_EXPERIMENTAL: 1 |
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.
Do we use this anywhere? It looks like we're specifying COSIGN_EXPERIMENTAL in each step explicitly.
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.
This is used by the cosign actions to dynamically take into use OIDC credentials, request a temporary key from fulcio, and sign. That way, we don't need to handle keys ourselves and pass those to sign the container and SBOM.
This adds a GitHub action that will trigger a container build for each commit merged to the `master` branch. These commits will also be signed with cosign. The registry used is the GitHub Container Registry, which allows us to host containers for open source projects without a fee. Signed-off-by: Juan Antonio Osorio <juan.osoriorobles@eu.equinix.com>
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 for adding this
Description:
This adds a GitHub action that will trigger a container build for each
commit merged to the
master
branch. These commits will also be signedwith cosign. The registry used is the GitHub Container Registry, which
allows us to host containers for open source projects without a fee.
This is needed for the Compliance Operator to get fresh content for OpenShift
and other Kubernetes distributions. This is useful for it to pick up Linux content
as well.
Rationale:
The previous
quay.io
-hosted content became stale and the current developmentteams have no access to its configuration. So let's instead use GitHub's registry
which allows repo owners to have access.
Fixes Staled content image:
quay.io/complianceascode/ocp4:latest
#8495