Pulp

Copying the steps here:

1. Build the changelog with the towncrier --version x.y.z --draft command. If it looks good rebuild with towncrier --version x.y.z. This will stage git changes for you.

2. Commit the changelog by itself. (first commit)

3. Increment the versions in setup.py and pulpcore/__init__.py to the release versions. e.g. 3.0.1

4. Commit the version bump (second commit). Note the hash of this commit.

5. Increment the versions in setup.py and pulpcore/__init__.py to the next, unreleased version for that branch. For a y-release of 3.1.0 on 'master' would be 3.2.0.dev. For a z-release 3.0.1 on the 3.0 branch, the next unreleased version would be 3.0.2.dev. If you're making a new y-release, also bump the value for stable_branch in template_config.yml.

6. Commit the version bump (third commit).

What defines " If it looks good" from the first step and how can we automate it?

What can be used to trigger these steps?

• I thought about opening an issue on pulp-ci, and then it will have a job for parsing the issue with pygithub and execute the steps, making pulpbot to open a PR

What defines " If it looks good" from the first step and how can we automate it?

Great question. What if the release nanny runs towncrier --version x.y.z --draft locally before kicking off the release process?

What can be used to trigger these steps? I thought about opening an issue on pulp-ci, and then it will have a job for parsing the issue with pygithub and execute the steps, making pulpbot to open a PR

My thought was that this script would initially be triggered by a user (ie the release nanny). Then later we could move it to a CI environment. Thoughts?

Creating PRs from CLI: https://github.com/github/hub#installation https://github.com/github/hub/issues/1219#issuecomment-238089588

PR: https://github.com/pulp/pulp_file/pull/390