Update release process and mark unit tests as executable #1163
Conversation
It's convenient to be able to run unit test scripts directly, rather than having to pass them as arguments to Python. This is already possible for several of our unit tests, make it possible for all by setting the execute bit. Signed-off-by: Joshua Lock <jlock@vmware.com>
* Strongly encourage the reader to use Python 3 for creating release artefacts * Recommend cleaning the tuf directory before creating the release Signed-off-by: Joshua Lock <jlock@vmware.com>
| @@ -1,12 +1,16 @@ | |||
| # Release process | |||
|
|
|||
| * Ensure you have a backup of all working files and then remove files not tracked by git | |||
| `git clean -xdf`. **NOTE**: this will delete all files in the tuf tree that aren't | |||
There was a problem hiding this comment.
Does this mean that if I am to release something, this will have to delete all my venvs in the current directory (which of course are not tracked by git) if I don't back them up?
There was a problem hiding this comment.
Yes, it does. The theory is that it's better to ensure the directory is clean and matches the git tree, so that we don't accidentally end up packaging things we don't intend to ship.
There was a problem hiding this comment.
Yes, it makes sense.
Just wanted to make sure I understand it right.
There was a problem hiding this comment.
@MVrachev the alternative I've used is that I never do releases from my development directory: I make a new git clone for every release. This ensures two things
- all files required for the release actually are in git
- no files from outside of git end up in the release
| * Ensure `docs/CHANGELOG.md` contains a one-line summary of each [notable | ||
| change](https://keepachangelog.com/) since the prior release | ||
| * Update `setup.py` and `tuf/__init__.py` to the new version number vA.B.C | ||
| * Test packaging, uploading to Test PyPI and installing from a virtual environment | ||
| (ensure commands invoking `python` below are using Python 3) |
There was a problem hiding this comment.
I'm not sure we need this note (here and below) if the commands also say python3
There was a problem hiding this comment.
I think it's okay to be very clear about it. But I'm fine either way.
There was a problem hiding this comment.
I opted to be very clear, just in case readers are not diligently reading each step
| * Ensure `docs/CHANGELOG.md` contains a one-line summary of each [notable | ||
| change](https://keepachangelog.com/) since the prior release | ||
| * Update `setup.py` and `tuf/__init__.py` to the new version number vA.B.C | ||
| * Test packaging, uploading to Test PyPI and installing from a virtual environment | ||
| (ensure commands invoking `python` below are using Python 3) |
There was a problem hiding this comment.
I think it's okay to be very clear about it. But I'm fine either way.
|
Haven't read everything, but is it possible to codify the release process in a Python script? Would make it a lot more automatic and less error-prone... |
That's a great idea, @trishankatdatadog! Mind creating a ticket? I think it's out of the scope of this PR, because it needs some tinkering in regards to non-automatable (e.g. "update the changelog", ...), or slightly harder to automate ("check test.pypi.org", "create release on GitHub", ...) steps. Speaking of steps, as follow-up work we might want to consider creating and publishing in-toto link metadata for all of these and a corresponding layout too. (see in-toto/in-toto#278 for some thoughts about doing this for the very similar release process of in-toto itself). |
Absolutely. That is one of several tasks I've been wanting to get around to for some time. |
Fixes issue #: N/A
Description of the changes being introduced by the pull request: Following some discussion around #1160 this PR updates the release docs to recommend explicitly using Python3 for distribution generation and cleaning the tuf tree before making a release.
I've also included a patch that adds the executable bit to some of our unit tests that didn't already have it.
Please verify and check that the pull request fulfills the following
requirements: