search

janus-idp / operator

Deprecated - Operator for Backstage, based on the Operator SDK framework - see https://github.com/redhat-developer/rhdh-operator
https://github.com/redhat-developer/rhdh-operator
Apache License 2.0
15 stars 15 forks source link

CI: automated build and push of upstream bundle and catalog images per PR and on main branch #73

Closed rm3l closed 10 months ago

rm3l commented 11 months ago

This could help with testing the operator.

Publish images to https://quay.io/organization/janus-idp

Like for the backstage-showcase image (see workflow), we could have tags per PR number and per PR-number-commit

nickboldt commented 11 months ago

PR generation here:

https://quay.io/repository/janus/operator?tab=tags https://quay.io/repository/janus/operator-bundle?tab=tags https://quay.io/repository/janus/operator-catalog?tab=tags

In the new year we can move these into the /janus-idp/ organization... but I don't have access to that quay org, so I can't push there.

nickboldt commented 11 months ago

Successful PR build: https://github.com/janus-idp/operator/actions/runs/7292457894/job/19873744288 from https://github.com/janus-idp/operator/pull/97#issuecomment-1866844303

nickboldt commented 11 months ago

However I can't start a cluster from the PR build because the images don't match:

image

Sources:

** ./bundle/manifests/backstage-operator.clusterserviceversion.yaml ** 
207-                - name: RELATED_IMAGE_backstage
208-                  value: quay.io/janus-idp/backstage-showcase:next
209:                image: quay.io/rhdh/backstage-operator:v0.0.1

So we need to ensure the CSV is regenerated for each PR and CI build, pointing at the correct PR/SHA.

Fixed with https://github.com/janus-idp/operator/pull/104

image

Next step: implementing the same thing for commits, not PRs...

nickboldt commented 11 months ago

OK, next builds are now being created for each pull request and for each pushed commit.

nickboldt commented 11 months ago

TODO:

rm3l commented 10 months ago

Currently, the pr-docker-build.yaml Workflow does not pass on fork PRs (for security reasons with secrets), which is an issue for such contributions.

But as discussed, I think it can be possible to make it pass securely without sacrificing convenience. We did something similar in the past on odo using the pull_request_target trigger and GitHub environments to prevent unauthorized runs. See https://github.com/redhat-developer/odo/blob/main/.github/workflows/pr-website.yaml (inspired from this blog post).

nickboldt commented 10 months ago

PRs from personal forks now produce PR builds too: https://github.com/janus-idp/operator/pull/115

HOWEVER a non-approver can also push a PR build: https://github.com/janus-idp/operator/pull/117 ... so that seems like a problem. cc: @rm3l

rm3l commented 10 months ago

PRs from personal forks now produce PR builds too: #115

Great - thanks!

HOWEVER a non-approver can also push a PR build: #117 ... so that seems like a problem. cc: @rm3l

For non-approvers, I noticed that the external GH environment did not have the required reviewers protection rule, which is needed to prevent this issue. I've added it: image

Let's check if this solves the issue now..

nickboldt commented 10 months ago

As seen by non-maintainer contributor:

image

image

As seen by maintainer:

image

After approval:

image

nickboldt commented 10 months ago

So the approval flow works, though it requires 4 clicks to approve.

Remaining TODOs (from 3 weeks ago):

nickboldt commented 10 months ago