OTA-1991: feat(cincinnati): Use upstream Dockerfile for testing#79424
Conversation
|
Skipping CI for Draft Pull Request. |
|
/test all |
WalkthroughExternalizes the deploy Dockerfile to ChangesDeploy Image Dockerfile Migration
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes 🚥 Pre-merge checks | ✅ 12✅ Passed checks (12 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
|
/pj-rehearse more |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
This will allow us to immediately run the CI testing on any proposed changes to the Dockerfile, which is used for the cincinnati as: - a layered product [1] - a SaaS [2] Otherwise, the used Dockerfile is only used for verifying whether a container image can be built, and no regression testing is run on it in this stage. [1]: https://gitlab.cee.redhat.com/ota/cincinnati/-/blob/da1724d8c3681c1f024e250ac5e7d09feb08fa31/.tekton/osus-operand-push.yaml#L27 [2]: https://gitlab.cee.redhat.com/service/app-interface/-/blob/c49fa3016addc8efbf7460ca5ea24fbccd9b0b06/data/services/cincinnati/cicd/ci-int/jobs.yaml
c188c6f to
a24e0cb
Compare
|
@DavidHurta: This pull request references OTA-1991 which is a valid jira issue. Warning: The referenced jira issue has an invalid target version for the target branch this PR targets: expected the story to target the "5.0.0" version, but no target version was set. DetailsIn response to this:
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the openshift-eng/jira-lifecycle-plugin repository. |
|
[REHEARSALNOTIFIER]
Interacting with pj-rehearseComment: Once you are satisfied with the results of the rehearsals, comment: |
|
@DavidHurta: all tests passed! Full PR test history. Your PR dashboard. DetailsInstructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository. I understand the commands that are listed here. |
|
@DavidHurta: now processing your pj-rehearse request. Please allow up to 10 minutes for jobs to trigger or cancel. |
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: DavidHurta, wking The full list of commands accepted by this bot can be found here. The pull request process is described here DetailsNeeds approval from an approver in each of these files:
Approvers can indicate their approval by writing |
openshift#1067 uses the ubi-minimal images. > We do not need to update the base image in the build stage, but I do not see a reason why we should not use the minimal for all stages while we are at it. This pull gives a reason: It saves the dependency installation in each CI build. The build base is used in CI already as the build root [1] (and it is open to the public which should cause no troubles to the Flux build). We should keep the CI build and the production build as close as possible if not identical [2]. Cincinnati is not an OCP product but the theory there can be applied. The builder image is currently not based from ubi-minimal [3]. We could switch to it, e.g., when making the next build root image for a new Rust version. In addition, the recipe `just build --release` is used to build the binaries, to keep doing things in a consistent way. Basically this pull tries to reduce the change on CI from openshift/release#79424. [1]. https://github.com/openshift/release/blob/76d0cff0192e04c1d90a535d72106bffab91e79a/ci-operator/config/openshift/cincinnati/openshift-cincinnati-master.yaml#L18-L22 [2]. https://docs.ci.openshift.org/architecture/images/ [3]. https://github.com/openshift/release/blob/76d0cff0192e04c1d90a535d72106bffab91e79a/ci-operator/config/openshift/cincinnati/openshift-cincinnati-master.yaml#L26
openshift#1067 uses the ubi-minimal images. > We do not need to update the base image in the build stage, but I do not see a reason why we should not use the minimal for all stages while we are at it. This pull gives a reason: It saves the dependency installation in each CI build. The build base is used in CI already as the build root [1] (and it is open to the public which should cause no troubles to the Flux build). We should keep the CI build and the production build as close as possible if not identical [2]. Cincinnati is not an OCP product but the theory there can be applied. The builder image is currently not based from ubi-minimal [3]. We could switch to it, e.g., when making the next build root image for a new Rust version. In addition, the recipe `just build --release` is used to build the binaries, to keep doing things in a consistent way. Basically this pull tries to reduce the changes on CI from openshift/release#79424. [1]. https://github.com/openshift/release/blob/76d0cff0192e04c1d90a535d72106bffab91e79a/ci-operator/config/openshift/cincinnati/openshift-cincinnati-master.yaml#L18-L22 [2]. https://docs.ci.openshift.org/architecture/images/ [3]. https://github.com/openshift/release/blob/76d0cff0192e04c1d90a535d72106bffab91e79a/ci-operator/config/openshift/cincinnati/openshift-cincinnati-master.yaml#L26
This will allow us to immediately run the CI testing on any proposed changes to the Dockerfile, which is used for the cincinnati as: - a layered product [1] - a SaaS [2] Otherwise, the used Dockerfile is only used for verifying whether a container image can be built, and no regression testing is run on it in this stage. [1]: https://gitlab.cee.redhat.com/ota/cincinnati/-/blob/da1724d8c3681c1f024e250ac5e7d09feb08fa31/.tekton/osus-operand-push.yaml#L27 [2]: https://gitlab.cee.redhat.com/service/app-interface/-/blob/c49fa3016addc8efbf7460ca5ea24fbccd9b0b06/data/services/cincinnati/cicd/ci-int/jobs.yaml
This PR updates the CI configuration for the openshift/cincinnati repository's master branch to use Cincinnati's upstream Dockerfile for testing and to simplify image handling in the pipeline.
What changed practically
Why this matters