-
Story
-
Resolution: Done
-
Critical
-
None
-
None
-
None
-
8
-
False
-
None
-
False
-
SECFLOWOTL-190 - OpenShift GitOps Konflux Enablement
-
-
-
GitOps Crimson - Sprint 3261, GitOps Crimson - Sprint 3262
Story (Required)
As a user of gitops on konflux I want all my applications and components onboarded.
Background (Required)
Konflux documentation for this procedure can be found here: https://konflux-ci.dev/docs/how-tos/creating/
Out of scope
- Adding secrets
- customizing the build pipeline
- adding integration tests
- testing out full release
Approach (Required)
All of the components that we currently define in cpaas (here: https://gitlab.cee.redhat.com/gitops-cpaas-midstream/gitops-midstream-repos/-/blob/gitops-1.13-rhel-8/upstream_sources.yaml?ref_type=heads) should also be created as components for the GitOps Operator application in konflux.
We should start with onboarding one component at a time, try to start with something easy the first time- something like gitops console plugin/something that doesn't have other dependencies. Some components (like Argo CD upstream) might require subgraphs since it's a component that needs other components built before it (like helm and kustomize).
We should be able to keep our configuration in gitlab like we currently do for cpaas, we might be okay just creating a new branch in the midstream repos gitlab (https://gitlab.cee.redhat.com/gitops-cpaas-midstream/gitops-midstream-repos) rather than creating a whole new repo.
Dependencies
Might depend on https://issues.redhat.com/browse/GITOPS-5053 (creating secrets in konflux) in order to have konflux pull from the repo
Acceptance Criteria (Mandatory)
- Have an application in konflux for openshift gitops that contains all of our components
INVEST Checklist
Dependencies identified
Blockers noted and expected delivery timelines set
Design is implementable
Acceptance criteria agreed upon
Story estimated
Legend
Unknown
Verified
Unsatisfied
Done Checklist
- Code is completed, reviewed, documented and checked in
- Unit and integration test automation have been delivered and running cleanly in continuous integration/staging/canary environment
- Continuous Delivery pipeline(s) is able to proceed with new code included
- Customer facing documentation, API docs etc. are produced/updated, reviewed and published
- Acceptance criteria are met