search

marceloprates / prettymaps

A small set of Python functions to draw pretty maps from OpenStreetMap data. Based on osmnx, matplotlib and shapely libraries.
GNU Affero General Public License v3.0
11.12k stars 522 forks source link

ci: Add publishing workflow with GitHub Actions #69

Closed matthewfeickert closed 3 years ago

matthewfeickert commented 3 years ago

Resolves #67

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

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

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
matthewfeickert commented 3 years ago

@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. :+1:

matthewfeickert commented 3 years ago

cc @thewchan given this comment RE: Conda-forge https://github.com/marceloprates/prettymaps/pull/68#issuecomment-934385821

marceloprates commented 3 years ago

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 commented 3 years ago

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

  1. $ git push --tags

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

git push origin main --tags

https://github.com/marceloprates/prettymaps/blob/9091bd405e51e55a43036c84b9dd1e96f3731523/.github/workflows/publish-package.yml#L51-L53

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 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 commented 3 years ago

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 commented 2 years ago

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 commented 2 years ago

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

matthewfeickert commented 2 years ago

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

https://github.com/marceloprates/prettymaps/blob/d03fb1cf4e5bb624d0d97673e0c51bc6e53e086c/.github/workflows/publish-package.yml#L56

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. :+1: Also sorry that this hasn't been quite as smoothed as I had hoped.

marceloprates commented 2 years ago

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 commented 2 years ago

I believe everything went well!

Indeed! Looks great. :)

pypi

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. https://github.com/recast-hep/recast-atlas/pull/68). So automating away even more of the boring stuff. :)