Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Release Responsible #616

Closed
usercont-release-bot opened this issue Aug 16, 2024 · 0 comments
Closed

Release Responsible #616

usercont-release-bot opened this issue Aug 16, 2024 · 0 comments
Assignees
Labels

Comments

@usercont-release-bot
Copy link
Collaborator

Check if there are changes worth releasing for all our RPM-packaged projects: packit, ogr, specfile

(packit is used as an example below)

  • Run Prepare a new release workflow via Run workflow button: choose main branch and type the correct version number for the new release. In a while, you should see the action running and creating a pull request in the repository.

  • Review the created PR - you can ask other team members to help you with changelog grammar if needed. You can check out the PR locally, update it and push it back to the PR.

    • If the Check release notes required check doesn't run, do a force-push or edit the PR title or description, that should trigger it.
  • Merge the pull request once you're fine with the content (and there are no pending review requests).

  • The merge of the PR should trigger an action that creates a draft release in the releases list. Edit the release, make sure the content is correct and then publish the release by clicking Publish release.

  • Make sure the package is uploaded to PyPI

  • Check (wait a few minutes) & merge PRs in dist-git created by packit: merge those created by the stage instance via pull_from_upstream (this will automatically close the Bugzilla from Upstream Release Monitoring) and close the ones created by the production instance. (But check that both services proposed the same set of changes.)

  • If you haven't released all 3 packages, make sure to tag the latest builds of those that weren't released into corresponding sidetags; until Implement a command to tag builds of a package into a sidetag group packit-service#2468 is implemented it is necessary to do it manually for each dist-git branch:

    • Determine sidetag name, either from builds of other packages or (if there aren't any) from the sidetags table in the database
    • Run koji latest-build f40-updates python-specfile to get the latest stable NVR
    • Run koji tag-build $SIDETAG_NAME $LATEST_NVR to tag it into the sidetag
  • Wait a few minutes and verify that RPMs are built in Koji

  • Wait a bit and verify that updates have been created in Bodhi

  • Celebrate another release 🚀🎉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
Archived in project
Development

No branches or pull requests

2 participants