From a167aec1a37552d51a6ba56782a53b2b320054d0 Mon Sep 17 00:00:00 2001 From: Tomas Kopecek Date: Aug 26 2020 09:47:52 +0000 Subject: doc: release process Fixes: https://pagure.io/koji/issue/2444 --- diff --git a/docs/source/writing_koji_code.rst b/docs/source/writing_koji_code.rst index 0c10676..d580518 100644 --- a/docs/source/writing_koji_code.rst +++ b/docs/source/writing_koji_code.rst @@ -564,11 +564,11 @@ The root of the git clone for Koji code contains a ``Makefile`` that has a few targets to make building and deployment a little easier. Among them are: -- tarball: create a bz2 tarball that could be consumed in an rpm build -- rpm: create Koji rpms. The NVRs will be defined by the spec file, +- ``tarball``: create a bz2 tarball that could be consumed in an rpm build +- ``rpm``: create Koji rpms. The NVRs will be defined by the spec file, which is also in the same directory. The results will appear in a ``noarch`` directory. -- test-rpm: like rpm, but append the Release field with a date and time +- ``test-rpm``: like rpm, but append the Release field with a date and time stamp for easy upgrade-deployment Writing Koji plugins @@ -685,3 +685,164 @@ You will need to install the packages below to run the check. * ``python-flake8`` * ``python-flake8-import-order`` + +Release process +=============== + +Merging PRs +----------- + +We're not using pagure's merge button as it doesn't do everything we want. +Instead `pg script `__ is used. + +:: + + pg pr checkout + +will checkout given PR and it can be reviewed locally. It can be rebased in this +time or it can be done automatically in the moment of merging: + +:: + + pg pr merge -r + +This will merge the changes, fetch info from pagure, and show you the current +git changelog. The changelog should be looked over for any issues, and it will +require special formatting so pagure will close out the release notes pull +request automatically. + +For example, you'll want the 'Merges' and 'Fixes' lines. + +The unit tests should be run before pushing if there were any new code changes +since the last tests. After that, it will be ready to push. Test with ``git push +-n`` first before the push to make sure it's correct. + + +Release Notes +------------- + +There should be separate PR with release notes (and version bumps) for every +release. + +Pushing the Code +---------------- + +Once Koji is ready to release, double check that the release notes are the only +open pull request. If that's the case, the release notes are ready to merge. + +Once the code is pushed, make sure all the PRs in the release roadmap are +closed, including the release notes PR. + +Now the release should be tagged. All Koji releases have been signed, using this +command: + +:: + + git tag -a -s -m 'Koji 1.18.0' koji-1.18.0 + +Then the tag must be pushed: + +:: + + git push origin refs/tags/koji-1.18.0 + +To create the tarball, run ``make tarball`` from the base koji directory. You +should then copy the tarball to some other directory, just to have a backup. The +tarball should be uploaded through the pagure interface, though the upload can +also be done via ssh. + +Once it's uploaded, download it and check the shasum against your local tarball. +If there are no issues, Koji's code release is complete. + +Updating the Site +----------------- + +The next step is to update the Koji site with the new docs and release notes. +This content is based in a separate repo from the Koji one. + +Simple bash script for this repo could be used, ``kdoc``. Using ``kdoc``, run +these commands in the docs repo: + +:: + + kdoc release-1.18.0:test + kdoc + +``kdoc`` checks out the master branch of the koji git repo, constructs docs from +that, and copies those changes into the doc repo. Once the changes are in place, +commit them and push them to your fork: + +:: + + git commit -m 'koji 1.18.0 release' + git diff --stat test + git push mikem + +Check your fork to make sure everything looks good (for example, check against a +previous release), then push the changes with 'git push.' + +:: + + #!/bin/bash + + # kdoc shell script + + set -x + set -e + + # TODO more sanity checks + + KDIR=~/cvs/koji + DOCDIR=~/cvs/koji-docs + DBRANCH=master + SBRANCH=master + + branches=$1 + if test -n "$branches"; then + dst=${branches#*:} + src=${branches%:*} + test -n "$src" && SBRANCH=$src + test -n "$dst" && DBRANCH=$dst + fi + + cd "$KDIR/docs" + test -n "$SBRANCH" && git checkout $SBRANCH + make dirhtml + + cd "$DOCDIR" + test -n "$DBRANCH" && git checkout $DBRANCH + rsync -avPH --delete --exclude .git "$KDIR/docs/build/dirhtml/" "$DOCDIR/" + git status + + echo "Docdir is: $DOCDIR" + +Pushing to PyPi +--------------- + +All releases should also go to PyPi repository, even if we've not publicly +announced, that it is the supported delivery channel. + +:: + + dnf install twine + make pypi + make pypi-upload + +Release Email +------------- + +The last step is to send out an email to koji-devel@lists.fedorahosted.org. See +previous release emails for how to format the message. + +Generally the email should include a link to the release notes, list some +highlights from the release, links to the release roadmap and current roadmap, +and a link to the download. + +Required Permissions +-------------------- + +* Merge permissions for the koji repo +* Merge permissions / access to the docs repo +* Key for signing + +