MycroftAI / adapt

Adapt Intent Parser
Apache License 2.0
710 stars 154 forks source link

Add support for publishing to pypi to github actions #133

Closed forslund closed 3 years ago

forslund commented 3 years ago

Adds stage for publishing when pushed to branch as soon as a release is tagged (tag should begin with release/), this can be changed to as soon as pushed to master but personally I think it's better to do it on a tagged release as each release on Pypi should have a tagged release on github with notes.

Requires secrets to be added to the repo to work: PYPI_USERNAME and PYPI_PASSWORD, maybe @krisgesling could add those if this is something we want.

The method was tested on the repo I'm setting up for combo-lock resulting in test-pypi.

Also these specific changes were tested in my fork of adapt without credentials resulting in this run for a new tag.

forslund commented 3 years ago

I added a job to the master branch to automatically tag the release from the version in setup.py as needed. Would this work for you guys?

forslund commented 3 years ago

The tagging is done here: https://github.com/MycroftAI/adapt/pull/133/commits/08b3e62e4591e39cfbae99828277e135a3931686

forslund commented 3 years ago

I was under the impression that admin access for the repo is needed to even get to the settings part.

forslund commented 3 years ago

Also you should be able to store the secrets in the mycroftai organization and not directly in the repo, which may be better.

krisgesling commented 3 years ago

Alright - token with privileges for the Adapt PyPI project has been added to PYPI_PASSWORD. PYPI_USERNAME can be hardcoded to __token__ seems like GITHUB_TOKEN might be automatically handled by Github Actions. So let's give it a try and see what happens. :crossed_fingers:

forslund commented 3 years ago

Will update to use __token__ as username

krisgesling commented 3 years ago

Didn't work :(

The publish job got skipped, see: https://github.com/MycroftAI/adapt/runs/3113181415?check_suite_focus=true

My first thought is that maybe the conditional used to prevent it from triggering isn't evaluating as we expect

if: contains(github.ref, '/tags/release')

Docs state that github.ref is:

The branch or tag ref that triggered the workflow run. For branches this in the format refs/heads/, and for tags it is refs/tags/.

I'm guessing the trigger for the workflow run in this case is the branch and doesn't contain the tag reference that was added during the job itself.

Do we need to instead base this off the outcome of the tag push?

forslund commented 3 years ago

Hmmm, thought I changed this. That is from triggering the job from creating a release on github.

I can fix it but not until this weekend

forslund commented 3 years ago

Hmm, maybe that is correct...it doesn't seem to have triggered any run at all for the new tag. Looking from my phone so I might have missed it...

krisgesling commented 3 years ago

Yeah, maybe they don't trigger workflows from actions taken by another workflow to prevent an infinite loop?

forslund commented 3 years ago

Maybe, should be fairly simple to move the pypi code to the same stage that creates the tag, I'll do it on friday if none have done it before that