Story (Required)

As a release engineer, trying to release OpenShift GitOps 1.16.0, I want to tag the upstream and midstream sources that was included in the downstream build so that, there is trackability for future maintenance.

Background (Required)

Every release artificat should be tagged for the exact commit id that was released. For GitOps Operator, Upstream and midstream repos have to be tagged.

Out of scope

Only operator code base is considered here (argocd-operator and gitops-operator). Other community projects are already tagged and are not covered in this story.

Approach (Required)

• Identify the upstream commit id that was used for the release from the upstream_sources.yaml file in midstream repo.
  For eg: 1.16.0 release -> https://gitlab.cee.redhat.com/gitops-cpaas-midstream/gitops-midstream-repos/-/blob/gitops-1.16-rhel-8/upstream_sources.yaml?ref_type=heads
• Tag the upstream gitops-operator code and push it.
  1. Go to : https://github.com/redhat-developer/gitops-operator/releases
  2. Click Draft a new Release
  3. Provide the tag name as v1.16.0
  4. Provide the release title as v1.16.0
• Tag the midstream repo for RHEL 8
  1. Go to : https://gitlab.cee.redhat.com/gitops-cpaas-midstream/gitops-midstream-repos/-/tags
  2. Click New tag
  3. Provide the tag name as v1.16.0-rhel-8
  4. Provide the Create from field value as gitops-1.16-rhel-8
  5. Provide the message as Release tag for OpenShift GitOps 1.16.0 RHEL8
• Tag the midstream repo for RHEL 9
  1. Go to : https://gitlab.cee.redhat.com/gitops-cpaas-midstream/gitops-midstream-repos/-/tags
  2. Click New tag
  3. Provide the tag name as v1.16.0-rhel-9
  4. Provide the Create from field value as gitops-1.16-rhel-9
  5. Provide the message as Release tag for OpenShift GitOps 1.16.0 RHEL9

  Dependencies

Release is already done and the errata is in SHIPPED_LIVE state.

Acceptance Criteria (Mandatory)

• upstream gitops-operator and midstream code bases are tagged with the correct commit ids that were released.

<Provides a required and minimum list of acceptance tests for this story. More is expected as the engineer implements this story>

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