ci: Add publishing workflow with GitHub Actions

[matthewfeickert]

Resolves #67

Add GHA based workflow to release a sdist and wheel to:

• TestPyPI on tags
• PyPI on GitHub releases

---

Things that @marceloprates would need to do for this PR to work:

• Get API tokens for TestPyPI and PyPI
• Save them respectively as GitHub secrets for this repo named test_pypi_password and pypi_password

---

Example resulting release workflow:

Locally on main run:

$ git checkout main && git pull # verify that you're on main and synced with GitHub
$ <whatever you need to do to bump the release number>  # Matthew uses bump2version on most of his projects, but whatever works here
$ git push origin main --tags # push the commit and the tag to GitHub, causing TestPyPI to publish

• Got to TestPyPI (https://test.pypi.org/project/prettymaps/) to look if the release looks okay
• Then on GitHub:
  1. Go to releases: https://github.com/marceloprates/prettymaps/releases
  2. Click "Draft a new release"
  3. On the new page enter the tag you just pushed (e.g. v0.1.0) in the "Tag version" box and the "Release title" box (to make it easy unless you really want to get descriptive)
  4. Enter any release notes and click "Publish release"
• This then kicks of the publication CD workflow that will use the PyPI API key to publish.

[matthewfeickert]

I'm not also installing check-manifest here as the prune ** strategy from PR #68 (which I like as it is simple and easy to read) doesn't work with check-manifest at this time (c.f. mgedmin/check-manifest#144)

[matthewfeickert]

@marceloprates This is ready for review. I'm more than happy to try to explain anything in here as I realize that I'm just presenting a workflow and CI/CD system that might not be very clear if you've never done something like it before in GitHub Actions. 👍

[matthewfeickert]

cc @thewchan given this comment RE: Conda-forge #68 (comment)

[marceloprates]

Dear Matthew,

First of all, thank you again for the help.

I've merged your PR and followed the instructions:

1. Added github secrets test_pypi_password and pypi_password
2. $ git checkout main && git pull
3. $ bump2version --current-version v0.1.2 patch setup.py
4. $ git add setup.py
5. $ git commit "Updated version"
6. $ git push --tags

However, https://test.pypi.org/project/prettymaps/ does not update to v0.1.3

I figure I'm doing something wrong...do you have an idea of what may it be?

[matthewfeickert]

However, https://test.pypi.org/project/prettymaps/ does not update to v0.1.3

I figure I'm doing something wrong...do you have an idea of what may it be?

Ah sorry. I think this

6. $ git push --tags

should have been (c.f. recast-hep/recast-atlas#63 and I also edited the PR body text for posterity)

git push origin main --tags

prettymaps/.github/workflows/publish-package.yml

Lines 51 to 53 in 9091bd4

	- name: Publish distribution 📦 to Test PyPI
	# publish to TestPyPI on tag events
	if: github.event_name == 'push' && startsWith(github.ref, 'refs/tags/v') && github.repository == 'marceloprates/prettymaps'

is looking for a push event (of commits) that also has a tag associated with it. So when you update the version number to v0.1.3 you're going to want to have that diff be associated with a tag so

git show HEAD

should show you both the number change and the tag.

I'm used to setting up bump2version with a config file and not from running it at the command line with options, so make sure that bump2version is also making a tag when it makes the commit.

Example from one of my projects:

$ git show 7bb9828
commit 7bb98286e2bddce46c18afa88eee88a53e6f4998 (tag: v0.1.8)
Author: Matthew Feickert <matthew.feickert@cern.ch>
Date:   Tue Oct 5 23:27:17 2021 -0500

    Bump version: 0.1.7 → 0.1.8

diff --git a/.bumpversion.cfg b/.bumpversion.cfg
index 547b123..9d59f8c 100644
--- a/.bumpversion.cfg
+++ b/.bumpversion.cfg
@@ -1,5 +1,5 @@
 [bumpversion]
-current_version = 0.1.7
+current_version = 0.1.8
 commit = True
 tag = True
 
diff --git a/setup.cfg b/setup.cfg
index 16071da..e1c96e7 100644
--- a/setup.cfg
+++ b/setup.cfg
@@ -1,6 +1,6 @@
 [metadata]
 name = recast-atlas
-version = 0.1.7
+version = 0.1.8
 description = RECAST for ATLAS at the LHC
 long_description = file: README.md
 long_description_content_type = text/markdown
diff --git a/src/recastatlas/config.py b/src/recastatlas/config.py
index dc4d09f..7e8aacf 100644
--- a/src/recastatlas/config.py
+++ b/src/recastatlas/config.py
@@ -44,7 +44,7 @@ class Config(object):
                     "RECAST_DOCKER_BACKENDSTRING", "multiproc:auto"
                 ),
                 "image": conf_from_env(
-                    "RECAST_DOCKER_IMAGE", "recast/recastatlas:v0.1.7"
+                    "RECAST_DOCKER_IMAGE", "recast/recastatlas:v0.1.8"
                 ),
                 "cvmfs": {"location": "/cvmfs", "propagation": "rprivate"},
                 "reg": {

Let me know if that doesn't make sense though. As I made a recommendation that isn't super smooth I'm happy to try to help make things work.

[matthewfeickert]

I'm used to setting up bump2version with a config file and not from running it at the command line with options, so make sure that bump2version is also making a tag when it makes the commit.

Ah yeah, okay looking at bump2version's CLI API options, to just run at the command line with no config file I think you probably want to roll back the commit history to 77b992e and then run

$ bump2version --commit --tag --current-version v0.1.2 patch setup.py

Here's what I get when I run that on my fork:

$ git reset --hard 77b992e
$ python -m pip install --upgrade bump2version
$ bump2version --commit --tag --current-version v0.1.2 patch setup.py
$ git show HEAD
commit aacd8ca933de3bc1bc042089ee85b07b5d20006e (HEAD -> main, tag: v0.1.3)
Author: Matthew Feickert <matthew.feickert@cern.ch>
Date:   Wed Oct 6 10:06:03 2021 -0500

    Bump version: v0.1.2 → 0.1.3

diff --git a/setup.py b/setup.py
index b9a89c5..3402855 100644
--- a/setup.py
+++ b/setup.py
@@ -5,7 +5,7 @@ parent_dir = Path(__file__).resolve().parent
 
 setup(
     name="prettymaps",
-    version="v0.1.2",
+    version="v0.1.3",
     description="A simple python library to draw pretty maps from OpenStreetMap data",
     long_description=parent_dir.joinpath("README.md").read_text(),
     long_description_content_type="text/markdown",

this followed by

$ git push --force-with-lease origin master --tags

should work to bump off a release to TestPyPI.

[marceloprates]

Hi Matthew,

Sorry for the late reply. I've followed your steps (although I manually changed the setup.py version number instead of rolling back the commit story) and was able to have bump2version make a new tag (also checked with git show HEAD and in here), but test.pypi still does not update :(

[marceloprates]

Apparently it's an issue with the lack of authentication information. Will look into that

[matthewfeickert]

Apparently it's an issue with the lack of authentication information. Will look into that

Ah this looks like the API token for TestPyPI isn't saved in the repo secrets under

prettymaps/.github/workflows/publish-package.yml

Line 56 in d03fb1c

password: ${{ secrets.test_pypi_password }}

correctly. Can you just try to update the value of that secret and then retrigger the same workflow? It should pick up the new credentials and then complete if they are valid.

Idk if you want to preemptively update the API token for PyPI as well, in the event that both were somehow pasted in with something slightly off.

Let me know if you have any questions though. 👍 Also sorry that this hasn't been quite as smoothed as I had hoped.

[marceloprates]

Hey Matthew, no need to apologize, on the contrary. I really appreciate your help and was able to learn a little bit more in the process. Thanks a lot!

I believe everything went well! Don't actually know what went wrong before, maybe I accidentally copied the PyPi password where the Test PyPi password should be...

[matthewfeickert]

I believe everything went well!

Indeed! Looks great. :)

I'll open up another Issue to discuss, but if you're interested I've been experimenting with a GitHub Actions workflow that allows you to be able to generate a new release tag from a button press in GitHub Actions (c.f. recast-hep/recast-atlas#68). So automating away even more of the boring stuff. :)