feat(RELEASE-2158): Support self-hosted Quay#3148
feat(RELEASE-2158): Support self-hosted Quay#3148querti wants to merge 1 commit intoconforma:mainfrom
Conversation
Add a new e2e test pipeline that checks if push-to-external-registry works with self-hosted Quay. Unlike other e2e tests which use the stage cluster, this one uses ephemeral Kind cluster. The reason is Quay is deployed to the cluster and is used for testing. Two changes were made to the push-to-external-registry pipeline to ensure its compatibility with self-hosted Quay: - Mount the ca-bundle.crt from trusted-ca configmap to /etc/ssl/certs/. This ensures that the self-signed CA cert of the internal Quay instance is known to the 3rd party tools like skopeo and cosign. Without it, the tools would fail with a TLS error. - Update regexes to support a Quay URL with a port number. The regexes assume that only one ":" will be present in the url, which may be wrong. Update them to account for hostnames with port number. Several other changes were made to support this functionality: - Mounting the CA bundle in Conforma task[1] - Support self-hosted Quay deployment in the Kind cluster[2] - Add init-quay task and skip-quay parameter[3] - Add a new Go e2e test for self-hosted quay[4] [1] conforma/cli#3148 [2] konflux-ci/konflux-ci#5689 [3] konflux-ci/tekton-integration-catalog#272 [4] konflux-ci/e2e-tests#1798 Assisted-by: Cursor Signed-off-by: Lubomir Gallovic <lgallovi@redhat.com>
|
This PR adds the cert to other tasks in the push-to-external-registry pipeline: konflux-ci/release-service-catalog#2031 |
Review Summary by QodoSupport self-hosted Quay with trusted CA certificates
WalkthroughsDescription• Add trusted CA certificate mounting for self-hosted Quay support • Mount CA bundle to both /mnt/trusted-ca and /etc/ssl/certs/ca-custom-bundle.crt • Enable Verify Conforma task to work with self-signed certificates Diagramflowchart LR
A["Verify Conforma Task"] -- "mounts CA bundle" --> B["Trusted CA Volume"]
B -- "maps to /mnt/trusted-ca" --> C["CA Bundle Location 1"]
B -- "maps to /etc/ssl/certs/ca-custom-bundle.crt" --> D["CA Bundle Location 2"]
C --> E["Self-hosted Quay Support"]
D --> E
File Changes1. tasks/verify-conforma-konflux-ta/0.1/verify-conforma-konflux-ta.yaml
|
Code Review by Qodo
1. CA mount not consumed
|
ff41ea2 to
febf62f
Compare
|
@simonbaird @joejstuart @st3penta can I request a review? Thanks! |
| - name: trusted-ca | ||
| mountPath: /mnt/trusted-ca | ||
| readOnly: true | ||
| - name: trusted-ca |
There was a problem hiding this comment.
Is it intentional to define two different volume mounts with the same name, trusted-ca?
There was a problem hiding this comment.
I'm mounting the same file in two places. Is this a risk or a bad pattern?
There was a problem hiding this comment.
Oh okay I get it. The name refers to the volume, so that's why it's not unique. Lgtm.
|
In your commit it says "This instance has a self-signed CA cert" which makes me think it was written by Cursor. What instance? Will this change impact Red Hat production Konflux which maybe isn't using a self-signed CA cert? |
Sorry if my original description isn't very clear. We are asked that the release pipeline "push-to-external-registry" should be compatible with self hosted Quay. We will not be using this feature, we will keep using quay.io. This is for our customers who may want to deploy their own quay instance, only available in their intranet. When that is the case, they will have their own CA cert. This CA cert must be mounted in the right place, otherwise tools like skopeo will not trust this instance. This PR mounts the custom CA cert to the right place to ensure that the task works correctly. trusted-ca configmap is generally defined by the cluster admin and should contain the internal CA cert. I'm not referring to any particular self-hosted quay instance, just any that might exist. I hope that makes things a bit clearer! |
Codecov Report✅ All modified and coverable lines are covered by tests.
Flags with carried forward coverage won't be shown. Click here to find out more. 🚀 New features to boost your workflow:
|
Add a new e2e test pipeline that checks if push-to-external-registry works with self-hosted Quay. Unlike other e2e tests which use the stage cluster, this one uses ephemeral Kind cluster. The reason is Quay is deployed to the cluster and is used for testing. Two changes were made to the push-to-external-registry pipeline to ensure its compatibility with self-hosted Quay: - Mount the ca-bundle.crt from trusted-ca configmap to /etc/ssl/certs/. This ensures that the self-signed CA cert of the internal Quay instance is known to the 3rd party tools like skopeo and cosign. Without it, the tools would fail with a TLS error. - Update regexes to support a Quay URL with a port number. The regexes assume that only one ":" will be present in the url, which may be wrong. Update them to account for hostnames with port number. Several other changes were made to support this functionality: - Mounting the CA bundle in Conforma task[1] - Support self-hosted Quay deployment in the Kind cluster[2] - Add init-quay task and skip-quay parameter[3] - Add a new Go e2e test for self-hosted quay[4] [1] conforma/cli#3148 [2] konflux-ci/konflux-ci#5689 [3] konflux-ci/tekton-integration-catalog#272 [4] konflux-ci/e2e-tests#1798 Assisted-by: Cursor Signed-off-by: Lubomir Gallovic <lgallovi@redhat.com>
|
One thing I'm wondering about: There's already a mount here just for the Also, along the lines of what Qodo said, do we need to set SSL_CERT_DIR in the stepTemplate also? |
I asked Claude about this and it said it should be okay. But do you want to also mount
I think it could be done later when/if needed, so maybe not a blocker for this PR. Wdyt? |
|
/ok-to-test |
Verify Conforma task should support images that are in a self-hosted Quay instance. This instance has a self-signed CA cert which is implicitly not trusted by 3rd party tools. This can be fixed by mounting the CA bundle to /etc/ssl/certs/, making it trusted. Mount to /mnt/trusted-ca is added to be consistent with other tasks in the pipeline. Assisted-by: Cursor Signed-off-by: Lubomir Gallovic <lgallovi@redhat.com>
febf62f to
2281228
Compare
|
No actionable comments were generated in the recent review. 🎉 ℹ️ Recent review info⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (1)
📝 WalkthroughWalkthroughThe change adds two new read-only volume mounts to the Task's step template: one at Changes
Estimated code review effort🎯 1 (Trivial) | ⏱️ ~3 minutes 🚥 Pre-merge checks | ✅ 3✅ Passed checks (3 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Tip Try Coding Plans. Let us write the prompt for your AI agent so you can ship faster (with fewer bugs). Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
I don't know what the mount /etc/pki/tls/certs/ca-custom-bundle.crt is used for, I don't want to accidentally break anything by removing it. Would it be OK if we kept the scope of this PR to just adding the new mounts? |
…elf-hosted Quay Add a new e2e test pipeline that validates push-to-external-registry works with self-hosted Quay. Unlike other e2e tests which use the stage cluster, this one uses an ephemeral Kind cluster where Quay is deployed and used for testing. The test runs an inline taskSpec that clones release-service-catalog at the PR's commit SHA and runs a test-kind.sh script directly, keeping e2e test ownership in this repo. The pipeline discovery script is updated so the test triggers alongside push-to-external-registry changes. Two changes were made to the push-to-external-registry pipeline to ensure its compatibility with self-hosted Quay: - Mount the ca-bundle.crt from trusted-ca configmap to /etc/ssl/certs/. This ensures that the self-signed CA cert of the internal Quay instance is known to 3rd party tools like skopeo and cosign. Without it, the tools would fail with a TLS error. - Update regexes to support a Quay URL with a port number. The regexes assumed only one ":" would be present in the url. Several other changes were made to support this functionality: - Mounting the CA bundle in Conforma task[1] - Support self-hosted Quay deployment in the Kind cluster[2] - Add init-quay task and skip-quay parameter[3] [1] conforma/cli#3148 [2] konflux-ci/konflux-ci#5689 [3] konflux-ci/tekton-integration-catalog#272 Assisted-by: Cursor Signed-off-by: Lubomir Gallovic <lgallovi@redhat.com>
Add a new e2e test pipeline that validates push-to-external-registry works with self-hosted Quay. Unlike other e2e tests which use the stage cluster, this one uses an ephemeral Kind cluster where Quay is deployed and used for testing. The test runs an inline taskSpec that clones release-service-catalog at the PR's commit SHA and runs a test-kind.sh script directly, keeping e2e test ownership in this repo. The pipeline discovery script is updated so the test triggers alongside push-to-external-registry changes. Two changes were made to the push-to-external-registry pipeline to ensure its compatibility with self-hosted Quay: - Mount the ca-bundle.crt from trusted-ca configmap to /etc/ssl/certs/. This ensures that the self-signed CA cert of the internal Quay instance is known to 3rd party tools like skopeo and cosign. Without it, the tools would fail with a TLS error. - Update regexes to support a Quay URL with a port number. The regexes assumed only one ":" would be present in the url. Several other changes were made to support this functionality: - Mounting the CA bundle in Conforma task[1] - Support self-hosted Quay deployment in the Kind cluster[2] - Add init-quay task and skip-quay parameter[3] [1] conforma/cli#3148 [2] konflux-ci/konflux-ci#5689 [3] konflux-ci/tekton-integration-catalog#272 Assisted-by: Cursor Signed-off-by: Lubomir Gallovic <lgallovi@redhat.com>
Verify Conforma task should support images that are in a self-hosted Quay instance. This instance has a self-signed CA cert which is implicitly not trusted by 3rd party tools. This can be fixed by mounting the CA bundle to /etc/ssl/certs/, making it trusted. Mount to /mnt/trusted-ca is added to be consistent with other tasks in the pipeline.