Release process for Pipelines-as-Code #

• Clear out the PR needed to be merged.

• Wait that CI is connected.

• Verify PAC CI cluster is up.

• Verify that you have gpg signing setup for your commits.

• Prepare to tag the release with a version, you need to choose between a major release/minor or patch release.

• If for example you choose to do the release 1.2.3 you tag it locally :

git tag v1.2.3

• And pushing it directly to the repo (you need access) :

% git push --no-verify git@github.com:openshift-pipelines/pipelines-as-code refs/tags/1.2.3

• When it started you can follow it on the pac cluster :

tkn pr logs -n pipelines-as-code-ci -Lf

• After a while (gorelease takes sometime) If everything is fine you should have the new version set as pre-release inside:

  https://github.com/openshift-pipelines/pipelines-as-code/releases

• Edit the release like the other releases has been done with a snippet of the highlight of the release.

• If you use AI:

  • make sure to verify the content as it may contains some mistakes.
  • don’t make it overusing emojis, let’s make it professional.
  • make sure to categorize the changes properly. sometime it would expose internal changes as major features.

• Announce it on Slack (upstream/downstream) and twitter.

Packages #

• Sometimes, there may be some issues with system or others. If you need to re-kick the release process you need to :

   git tag --force v1.2.3
   git push --force git@github.com:openshift-pipelines/pipelines-as-code v1.2.3

• Some issues may be with the GitHub token which may be expired or badly generated with a \n.
• Some other issues if you didn’t do a git fetch -a origin before tagging so, you don’t have the latest commits from origin/main