Add GH Action GitHub + PyPI release automation on git version tag pushes

[chrissimpkins]

Adds a new GitHub Action configuration that prepares and pushes a GitHub release and PyPI source dist + wheel release when a v prefixed version git tag is pushed. It can live side-by-side with the Travis CI unit testing / type checking configuration.

@m4rc1e you will need to add the following data to the repository "Secrets" settings:

• PyPI username as PYPI_USERNAME
• PyPI password as PYPI_PASSWORD

If those data are missing when you push a version tag, you'll get a GH release but the PyPI push will fail.

This Action automatically adds the following to the body of every release:

Please see the root of the repository for the CHANGELOG.md

You'll need to change this line to something that is appropriate here.

[m4rc1e]

This is great!

I'm not such a fan of the body placeholder text. I wonder if it's possible to instead use the content from an annotated tag?

[m4rc1e]

I see actions/create-release@v1 provides an optional arg called body_path which can be used instead of body. We could extract the annotated tagged release text and save it as an .md file, then load it using the body_path command. Let me try this out.

[anthrotype]

have you seen this actions/create-release#11

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[google-cla]

All (the pull request submitter and all commit authors) CLAs are signed, but one or more commits were authored or co-authored by someone other than the pull request submitter.

We need to confirm that all authors are ok with their commits being contributed to this project. Please have them confirm that by leaving a comment that contains only @googlebot I consent. in this pull request.

Note to project maintainer: There may be cases where the author cannot leave a comment, or the comment is not properly detected as consent. In those cases, you can manually confirm consent of the commit author(s), and set the cla label to yes (if enabled on your project).

ℹ️ Googlers: Go here for more info.

[m4rc1e]

Cosimo, thank you. After reading the thread, I noticed I don't need to use the body_path arg. Instead I've opted to get the release notes in a separate step, then just import them into the body arg.

@chrissimpkins I've updated the PR. Could you take a look before I merge?

[m4rc1e]

@googlebot I consent.

[m4rc1e]

We can't merge this until I add the PyPi credentials.

@davelab6 can I get full permissions for this repo please? I'm currently not able to add secrets to this repo.

[madig]

You can probably get rid of matrix and just use python-version: "3.x" here?

[chrissimpkins]

yep definitely. sorry this was copy/pasted from blocks of my ci templates. ty!

[chrissimpkins]

@m4rc1e Please let me know if you want this change and want me to make the edit.

[m4rc1e]

I tested this PR on my own branch. It produces releases which have the following appearance:

It looks fine to me. It's a whole lot better than the non-existent releases we so far have. One slight complaint is the body text isn't formatted as markdown.

---

In order to push future releases, one can do the following:

• Create a new annotated tag which has the same version number as the version number found in setup.py e.g `git tag -a v0.5.0'
• Vim/nano will be opened so you can write your release notes. I'd like us to simply specify what has changed in the new release. One could argue that we could just use the commit messages. However, the commit messages are perhaps too granular in this repo. I'd prefer some human intervention here.
• Push the tags git push --tags upstream

This should take care of the repo's tagged release and pushing the package to PyPi.

@chrissimpkins thanks for your work on this! I may adopt this for our other tools as well since the workflow is very nice.

[anthrotype]

@m4rc1e cool! will GH format the tag message as markdown?

[chrissimpkins]

One could argue that we could just use the commit messages. However, the commit messages are perhaps too granular in this repo. I'd prefer some human intervention here.

100% agree. A maintained, human distilled changelog is a feature for users who do not closely follow/develop a project IMO. The ends of the spectrum from "We're always making changes to make the best product for you" to "here are every single one of the commits that were made since we last released, parse it yourself and figure out what we did" tend to be less useful to the average user who just needs to know what happened between release X and Y.

[m4rc1e]

@m4rc1e cool! will GH format the tag message as markdown?

@anthrotype, This non-markdown issue seems to be my fault. As a test, I've removed my heuristic to dynamically fetch the release notes from the annotated tag and instead I've just hardcoded an md list. Well well, the hardcoded list works just fine.

I'll look into this a bit more.

[chrissimpkins]

Well well, the hardcoded list works just fine.

I imagine this means that it will support automated PR / IR linking with URL/issue numbers in the text too? That would be nice

[chrissimpkins]

Marc, are you working on this in a fork on your personal account? I can't find https://github.com/m4rc1e/gftools

Found it at https://github.com/m4rc1e/tools

[anthrotype]

@m4rc1e maybe add a comment explaining why you have to escape all the newlines and the link to the original actions/create-release#11 (comment)

[m4rc1e]

Ok, we can now fetch the annotated tag's message and the output is now markdown.

This nearly killed me so here are some notes:

• Include body parameter for release actions/create-release#11 Isn't in production yet so you must use the master instead, uses: actions/checkout@master, not uses: actions/checkout@v1
• actions/checkout will only fetch a single commit by default. Includingfetch-depth: 0 will fetch all branches and tags. However, annotated tag messages are not included. To include them, include git fetch --tags --force in a run cmd, Preserve tag annotations actions/checkout#290
• Getting the version tag name required some string manipulation.

@anthrotype I will. Apologies for all the mess in this PR. I've spent a decent amount of time getting it to work. I plan to go back and tidy.

[anthrotype]

thanks Marc for cracking this out. I've been wanting to get a MD-formatted GH release out of a git annotated tag for long time, never got around to solve this 👍
we'll use this approach in all the other font tooling projects (/cc @madig)

[m4rc1e]

Right, I'm done with this. I've added comments for the parts which need explaining. If anyone would like to review, feel free.

[chrissimpkins]

LGTM. Thanks for all of the edits here Marc.

[m4rc1e]

I've added my PyPI credentials to this repo so we can merge this.

Thanks everyone for your reviews and a shout out to Chris for starting this pr.

[chrissimpkins]

My pleasure. Hope that this is helpful with your releases!

[madig]

You didn't delete .travis.yml 😬

Edit: oh wait this is not for testing, nevermind

[davelab6]

I love to see it