Roles
- Release Owner: @cintrix84
- Release Engineer: @zhunting
When Ready to Release
Release Owner
-
Request Hammer CLI Katello release from maintainers
-
Request Virt Who Configure release from maintainers
-
Request any other releases as needed from the release owners (consult the
:repos:
section ofconfigs/katello/4.3.yaml
) -
Change Redmine version 4.3.1 state to Closed
-
Do Cherry-picks: Clone tool_belt
-
If any minor versions of Katello have been added to Redmine since the last cherry-pick, make sure to include them in
prior_releases
in configs/katello/4.3.yaml -
Run
./tools.rb setup-environment configs/katello/4.3.yaml
-
Run
./tools.rb cherry-picks --version 4.3.1 configs/katello/4.3.yaml
- Open a PR in Katello release branch. Make sure the PR name starts with [CP] to prevent our automations from adding it to Redmine issues.
-
Using
git cherry-pick -x
as needed, verify tickets in the cherry_picks_4.3.1 file are accounted for, or additionally cherry-pick them. Recommended: Do this in tool_belt’s checkout of Katello, inrepos/katello/4.3.1/katello
. This way when you run cherry-picks again, tool_belt will be aware of any picks already completed. -
For any cherry-picks that are not needed (including Redmine trackers) you can add them to the
:ignores:
section oftool_belt
inconfigs/katello/4.3.yaml
-
If any minor versions of Katello have been added to Redmine since the last cherry-pick, make sure to include them in
-
Check for outdated deprecation warnings in the current and next release with
./tools check-deprecation-warnings configs/katello/4.3.yaml
. Follow the instructions in the output of the command. Don’t forget to create any Redmine issues needed! -
Bump version:
-
Open a PR (or use cherry-pick PR) against the release branch which updates
lib/katello/version.rb
to 4.3.1 -
git pull
to make sure you have the latest changes -
Commit:
git commit -m "Release 4.3.1"
-
Ensure that the commit above is the last commit and there are no commits after it. This is the commit that will get tagged. (Rearrange commits with
git rebase -i
if needed.)
-
Open a PR (or use cherry-pick PR) against the release branch which updates
-
Once the PR is merged, perform the following in the Katello release branch (the real one, not your fork):
-
Tag:
git tag -s -m "Release 4.3.1" 4.3.1
-
Push:
git push --follow-tags
(Must be pushed directly to the release branch, as pull request merges will not preserve tags.) -
Generate source gem:
gem build katello.gemspec
- Ensure you have a working login and password at rubygems.org
-
Push gem:
gem push katello-4.3.1.gem
-
Tag:
-
Inform the delivery team that the gem is published
Once Source is Available
Note it is considered good practice to release on a day when the next day is a working day. This means no releases on Fridays or on the day before a holiday.
Release Engineer
- Update release version similar to here
-
Update
katello
,katello-repos
andrubygem-katello
- Merge packaging PR once job is green
- Wait for Jenkins to build the packages (replace 4.3 with the matching Foreman version)
- Download, sign, upload RPM signatures and upload RPMs
- Kick off the release pipeline by calling release_pipeline
Once release is out
Release Owner
-
Confirm response that the build succeeded (or if necessary, do more cherry-picks and version bumps repeating the steps above)
-
Post a release announcement
-
Create and upload release specific developer stable box