Katello 4.1.4 Release Process

Development Releases
1

Make this post a wiki

Roles

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 of configs/katello/4.1.yaml)

  • Change Redmine version 4.1.4 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.1.yaml
    • Run ./tools.rb setup-environment configs/katello/4.1.yaml
    • Run ./tools.rb cherry-picks --version 4.1.4 configs/katello/4.1.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.1.4 file are accounted for, or additionally cherry-pick them. Recommended: Do this in tool_belt’s checkout of Katello, in repos/katello/4.1.4/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 of tool_belt in configs/katello/4.1.yaml

  • Check for outdated deprecation warnings in the current and next release with ./tools check-deprecation-warnings configs/katello/4.1.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.1.4
    • git pull to make sure you have the latest changes
    • Commit: git commit -m "Release 4.1.4"
    • 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.)

  • 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.1.4" 4.1.4
    • 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.1.4.gem

  • 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

Once release is out

Release Owner

2

@jeremylenz @Zhunting I was just informed about a new candlepin build available which fixes a potential stack overflow problem. I’m working on getting it built. I’d like to tag it in for this 4.1 release - any objections?

3

Here are the builds ready for tagging in:

4

Hold off on tagging in. I’m testing the equivalent 4.1 build for nightly and might be running into an issue. Will update when I know more!

1 Like
5

My update now is that this probably isn’t worth fixing in 4.1 as there’s a workaround, but we’ll get the new candlepin build in nightly + 4.2 when available

1 Like
6

Continuing my hijack of this thread :wink:

We’ve got a fixed Candlepin build that I tagged into nightly. I recommend tagging for 4.1

el7 → build (katello-thirdparty-candlepin-rhel7, candlepin-4.0.9-1.el7sat.src.rpm) | Task Info | koji
el8 → build (katello-candlepin-nightly-el8, candlepin-4.0.9-1.el8sat.src.rpm) | Task Info | koji

2 Likes
7

Release pipeline is running now, with the newer Candlepin versions :slight_smile:

1 Like