-
Story
-
Resolution: Unresolved
-
Undefined
-
None
-
1.15.0
-
13
-
False
-
None
-
False
-
SECFLOWOTL-100 - Progressive Delivery CLI Support
-
-
-
GitOps Scarlet - Sprint 7/3266
Story (Required)
See parent epic for high level details. GITOPS-5636 is a prerequisite for this story. See list of helpful additional resources on parent epic.
Background
Once we have Konflux building the Rollouts CLI successfully, we will need to release it as part of Konflux release process.
Defining the overall Konflux OpenShift GitOps release process is likely to be handled by other epics, but this is the part that relates specifically to the CLI.
Within Konflux, all release activities are defined by Konflux release team in the release catalog.
- My understanding is, if you want to do something as part of a release, you will need to find it within the predefined pipelines in the release catalog: https://github.com/konflux-ci/release-service-catalog/tree/development/pipelines
In our case, because we have CLI binaries which we need to push to developers.redhat.com, we need to use the 'push-binaries-to-dev-portal' pipeline in the release catalog.
- This Pipeline will verify, sign, and push the binaries to destination (CDN, then content gateway)
- You can find an example of using this Pipeline, here: https://gitlab.cee.redhat.com/pkhander/push-to-dev-portal-testing/-/blob/main/rpa.yaml?ref_type=heads
Ultimately:
- This is the parent Outcome that is tracking all binary release capabilities: https://issues.redhat.com/browse/KONFLUX-2298
- Our goal is to upload to https://developers.redhat.com/content-gateway/rest/browse/pub/openshift-v4/clients/openshift-gitops/latest/,
- This appears to be exactly covered by KONFLUX-321 design doc.
- Windows/Mac binaries may not be available, it's unclear, but in case, this is the tracking item: KONFLUX-2731
Sketch of work
1) Define a ReleasePlan to enable release of Rollouts kubectl plugin
- Described here https://konflux-ci.dev/docs/advanced-how-tos/releasing/create-release-plan/
- And see https://gitlab.cee.redhat.com/releng/konflux-release-data/ for plenty of examples from other teams.
2) Define a ReleasePlanAdmission which provides 'exodus/contentGateway' data in .data, references the standard ec policy, and has a pipeline ref to push binaries
A ReleasePlanAdmission is defined which looks a bit like this:
apiVersion: appstudio.redhat.com/v1alpha1 kind: ReleasePlanAdmission metadata: labels: release.appstudio.openshift.io/auto-release: "false" # (this was true in the example I copied it from) name: rpa namespace: default spec: applications: [list,of,applications] origin: origin-tenant policy: some-policy data: # Start of data needed for push-to-dev-portal-pipeline exodus: env: "cdn-live" contentGateway: productName: "Konflux test product" productCode: "K-Test-Product" productVersionName: "KTestProduct 1" components: - name: test-component description: "Red Hat OpenShift Local Sandbox Test" label: "Checksum File Sandbox Test" # End of data needed for push-to-dev-portal-pipeline pipeline: pipelineRef: resolver: git params: - name: url value: "https://github.com/konflux-ci/release-service-catalog.git" - name: revision value: production - name: pathInRepo value: "pipelines/push-binaries-to-dev-portal/push-binaries-to-dev-portal.yaml"
(this is from the gitlab link above)
3) Determine how we can verify that the release is defined correctly, for example, running a test release.
As per Konflux docs, ensure this is true: "When a ReleasePlanAdmission is correctly configured to be paired with a ReleasePlan, its Status will display as being Matched."
Acceptance Criteria
- ReleasePlan is defined in the openshift gitops operator konflux workspace
- ReleasePlanAdmission is defined in that workspace
- We have determined what data we need to provide in the .spec.data field of ReleasePlanAdmission, in order to make this work successfully.
- ReleasePlanAdmission successfully configures 'push-binaries-to-dev-portal' task
- ReleasePlanAdmission has status of matched, indicating it is correcting matching to ReleasePlan
- Investigate how we can test this: for example, can do a 'test' release, to make sure these are correct?
- is blocked by
-
GITOPS-5636 Rollouts CLI on Konflux: 2) Enable hermetic build to Rollouts Kubectl build, and integrate with existing OpenShift GitOps Konflux build
- Review