Deploy to PyPI from Travis CI #106

hugovk · 2019-11-14T10:19:29Z

This should help make releasing easier.

Deploy non-tagged builds to Test PyPI
Deploy tagged builds to live PyPI

Will only trigger when run from the SethMMorton/natsort repo, on master, so not for forks or PRs.

The on: section shows the conditions for triggering an upload. This should be set up so only a single build job qualifies.

Right now, there's only a single Python 3.8 job, so select on python: 3.8. If 3.7 and 3.8 are switched, this can also so there's only a single 3.7. It's possible to select on other conditions too:

https://docs.travis-ci.com/user/deployment/#conditional-releases-with-on

skip_existing: true should in any case prevent trying to re-upload existing ones.

TODO:

Add an API token called (say) natsort-ci at https://test.pypi.org/manage/account/token/
On the command line, install the Travis Client
Run travis encrypt
Paste in the token from step 1, it begins pypi-
Ctrl-D to end
Add the encrypted value as the first password: secure: "TODO" value
Repeat for production PyPI, put the encrypted value as the second "TODO"

More info on PyPI API tokens: https://pypi.org/help/#apitoken

hugovk · 2019-11-14T10:25:24Z

#104 (comment):

I would feel more comfortable if there were some sort of button I had to press in the CI to actually enact the deployment, because I am always afraid of accidentally releasing something broken.

One option is to only have the Test PyPI stuff uploaded automatically. There's definitely value in testing a package can be built (checks those Twine/manifest errors) and uploaded successfully (PyPI doesn't reject anything). And then production releases are still done manually.

Another option: instead of uploads to Test PyPI for merges and uploads to production on tags, have both uploaded to Test PyPI. You can then download and check the packages, and/or install directly from Test PyPI, and if good, upload them manually to production PyPI.

hugovk · 2019-11-14T10:29:19Z

Looking at this PR build from my fork:

https://travis-ci.org/hugovk/natsort/jobs/611795507

Python 3.5 build. At the end of the log it shows all the reasons why it didn't attempt deploy to Test PyPI or production PyPI, ie. because I'm on a fork, it's not master, not tagged, and not 3.8:

Skipping a deployment with the pypi provider because this repo's name does not match one specified in .travis.yml's deploy.on.repo: SethMMorton/natsort
Skipping a deployment with the pypi provider because this branch is not permitted: deploy-to-pypi
Skipping a deployment with the pypi provider because this is not on the required runtime
Skipping a deployment with the pypi provider because this repo's name does not match one specified in .travis.yml's deploy.on.repo: SethMMorton/natsort
Skipping a deployment with the pypi provider because this is not on the required runtime
Skipping a deployment with the pypi provider because this is not a tagged commit

https://travis-ci.org/hugovk/natsort/jobs/611795510

Python 3.8 build. Skipped due to fork, not master, not tagged:

Skipping a deployment with the pypi provider because this repo's name does not match one specified in .travis.yml's deploy.on.repo: SethMMorton/natsort
Skipping a deployment with the pypi provider because this branch is not permitted: deploy-to-pypi
Skipping a deployment with the pypi provider because this repo's name does not match one specified in .travis.yml's deploy.on.repo: SethMMorton/natsort
Skipping a deployment with the pypi provider because this is not a tagged commit

This one doesn't complain about the runtime, ie. 3.8 is good.

codecov · 2019-11-14T10:29:31Z

Codecov Report

Merging #106 into master will increase coverage by 0.24%.
The diff coverage is n/a.

@@            Coverage Diff             @@
##           master     #106      +/-   ##
==========================================
+ Coverage   99.29%   99.53%   +0.24%     
==========================================
  Files          12       10       -2     
  Lines         568      432     -136     
==========================================
- Hits          564      430     -134     
+ Misses          4        2       -2

Impacted Files	Coverage Δ
natsort/compat/locale.py	`95.23% <0%> (-4.77%)`	⬇️
natsort/utils.py	`100% <0%> (ø)`	⬆️
natsort/compat/fastnumbers.py	`100% <0%> (ø)`	⬆️
natsort/ns_enum.py	`100% <0%> (ø)`	⬆️
natsort/natsort.py	`100% <0%> (ø)`	⬆️
natsort/unicode_numbers.py	`100% <0%> (ø)`	⬆️
natsort/__main__.py	`100% <0%> (ø)`	⬆️
natsort/compat/fake_fastnumbers.py	`100% <0%> (ø)`	⬆️
natsort/__init__.py	`100% <0%> (ø)`	⬆️
natsort/compat/pathlib.py
... and 1 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 60b86c3...f65e59d. Read the comment docs.

hugovk · 2019-11-14T10:36:57Z

Here's an example deploy to Test PyPI from one of my projects for a merge to master:

https://travis-ci.org/hugovk/pypistats/jobs/611462790#L328

And a tagged release to production PyPI:

https://travis-ci.org/hugovk/pypistats/jobs/611801885#L345

This is the release checklist:

https://github.com/hugovk/pypistats/blob/master/RELEASING.md

SethMMorton · 2019-11-14T17:16:25Z

I am definitely intrigued. I have a few questions.

This is the first I have heard about uploading to the test PyPI. Can you explain some of the benefits of doing so?
What is the benefit of making a GitHub release as well as uploading to PyPI?
I note in your checklist you mention GitHub actions. What actions do you have set up?

hugovk · 2019-11-15T07:14:28Z

This is the first I have heard about uploading to the test PyPI. Can you explain some of the benefits of doing so?

TestPyPI is:

a separate instance of the Python Package Index that allows you to try distribution tools and processes without affecting the real index

By successfully deploying there during the development cycle, you have more confidence that when it comes to actually releasing, your code can be successfully package and uploaded. It helps avoid things like MANIFEST.in errors, tests that setup.py works (normal unit testing omits this crucial file).

It also possible to install your test package from TestPyPI:

$ pip install --index-url https://test.pypi.org/simple/ your-package
# or to pull dependencies from PyPI:
$ pip install --index-url https://test.pypi.org/simple/ --extra-index-url https://pypi.org/simple your-package

https://packaging.python.org/guides/using-testpypi/#using-testpypi-with-pip

This can be useful for additional testing of your package, that it works from end-to-end (build, upload, download, install, run).

Also, occasionally someone may wish to try a fix or new feature that's in master but not yet released. This would give them something to try without installing from source. (Although pip install -U git+https://github.com/org/repo also works (but can be problematic on Windows if C extensions need compiling).)

hugovk · 2019-11-15T07:14:41Z

What is the benefit of making a GitHub release as well as uploading to PyPI?

There's not a huge benefit in doing so. I don't upload any binaries to GitHub, PyPI is enough. Basically I only mark a tag as a release and sometimes put some basic release notes there (eg. https://github.com/hugovk/pypistats/releases) but you could easily skip it as the tag list is pretty much the same (eg. https://github.com/SethMMorton/natsort/releases).

hugovk · 2019-11-15T07:15:24Z

I note in your checklist you mention GitHub actions. What actions do you have set up?

I'm using it as a CI. I have two workflows, for lint and unit tests:

https://github.com/hugovk/pypistats/tree/master/.github/workflows

Pretty much the same as Travis CI does, except unit tests on GHA are also tested on macOS and Windows, and also testing two Ubuntu versions (I have Travis only testing Linux, with a single Ubuntu version). You get 5 parallel jobs and 20 with GHA, so they run quickly.

SethMMorton · 2019-11-15T17:45:31Z

Thanks for all that. I was asking about the GitHub releases because it was mentioned it the checklist you linked to.

SethMMorton · 2019-11-15T17:48:19Z

Looking at the GitHub actions files... I wonder why I would bother with Travis-CI going forward. It seems like GitHub actions has the following advantages over Travis

Integrated into GitHub
More control over how your actions are performed (I see versioning of actions and containers, and more modularity into what is actually done)
First-class support for Linux, macos, and Window (whereas in Travis macos and Windows still feel like afterthoughts)
More concurrent runners

Am I missing something?

SethMMorton · 2019-11-16T01:10:24Z

@hugovk Despite all the things I said about GitHub actions, I plan to accept this PR. One think I liked about the project you showed me was your release checklist - if you were to update this PR to include one of those (minus the GitHub releases thing) I will merge.

So long as you don't mind if I tweak the release checklist after-the-fact as I settle on this more automated release method 😺

hugovk · 2019-11-16T08:22:54Z

Looking at the GitHub actions files... I wonder why I would bother with Travis-CI going forward. It seems like GitHub actions has the following advantages over Travis

Integrated into GitHub

More control over how your actions are performed (I see versioning of actions and containers, and more modularity into what is actually done)

First-class support for Linux, macos, and Window (whereas in Travis macos and Windows still feel like afterthoughts)

More concurrent runners

Am I missing something?

All very good points, and I may well ditch Travis in the future. Reasons for keeping it a bit longer:

GitHub Actions only came out of beta last week.
Some things like caching are very new and not as straightforward (but you get lots of control) or as fully supported as with Travis CI.
I haven't fully worked out how to best use Codecov for code coverage with GitHub Actions, especially for forks
Travis CI is more widely known
Travis added support for Python 3.8 within a day of its release, GHA took about 24 days
Travis has nightly and dev versions of Python available
Travis are adding different architectures
GHA had removed some Windows version support with short notice, suddenly breaking builds. This was during the beta so hopefully things will settle now.

I can definitely see using only GHA or doing most testing on GHA in the future.

Over at Pillow we're in the process of moving testing from Travis (5 parallel jobs) and AppVeyor (1 serial job) to GHA (20). I expect we'll still keep some basic testing on Travis and AppVeyor, maybe a recent Python version and things which are unique to those platforms.

hugovk · 2019-11-16T08:27:43Z

@hugovk Despite all the things I said about GitHub actions, I plan to accept this PR. One think I liked about the project you showed me was your release checklist - if you were to update this PR to include one of those (minus the GitHub releases thing) I will merge.

So long as you don't mind if I tweak the release checklist after-the-fact as I settle on this more automated release method 😺

Added!

I definitely recommend a checklist, it's handy to refer to something when releasing, and useful if someone else does a release. Sure, please do tweak and change it to fit your needs!

SethMMorton · 2019-11-18T06:07:24Z

@hugovk So I am finally getting around to creating the API token, and I am being bitten by travis-ci/travis.rb#221 (which I see by the thumbs-up on various comments you are aware of). FWIW, I just migrated my .org accounts to .com...

Any suggestions on working around this?

hugovk · 2019-11-18T08:11:44Z

Oh, that's a pain... Travis The workaround is to use your own username and encrypted password, like this:

https://github.com/hugovk/osmviz/blob/master/.travis.yml#L41-L43

(If you wanted to limit it to a single package, I suppose you could create a new user and add it to just natsort.)

SethMMorton · 2019-11-20T03:51:31Z

Thank you so much for your help! As an FYI, I ended up modifying your code slightly so that the deploy: was its own stage.

hugovk · 2019-11-20T07:09:35Z

You're very welcome, thank you for natsort! Good idea about the extra stage.

Deploy to PyPI from Travis CI

7690c3f

hugovk mentioned this pull request Nov 14, 2019

Add support for Python 3.8 #104

Merged

Add release checklist

f65e59d

hugovk mentioned this pull request Nov 18, 2019

Encrypt failed: data too large for key size travis-ci/travis.rb#221

Closed

SethMMorton merged commit ea10acc into SethMMorton:master Nov 19, 2019

hugovk deleted the deploy-to-pypi branch November 19, 2019 21:01

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Deploy to PyPI from Travis CI #106

Deploy to PyPI from Travis CI #106

hugovk commented Nov 14, 2019

hugovk commented Nov 14, 2019

hugovk commented Nov 14, 2019

codecov bot commented Nov 14, 2019 •

edited

hugovk commented Nov 14, 2019

SethMMorton commented Nov 14, 2019

hugovk commented Nov 15, 2019

hugovk commented Nov 15, 2019

hugovk commented Nov 15, 2019

SethMMorton commented Nov 15, 2019

SethMMorton commented Nov 15, 2019

SethMMorton commented Nov 16, 2019

hugovk commented Nov 16, 2019

hugovk commented Nov 16, 2019

SethMMorton commented Nov 18, 2019

hugovk commented Nov 18, 2019

SethMMorton commented Nov 20, 2019

hugovk commented Nov 20, 2019

Deploy to PyPI from Travis CI #106

Deploy to PyPI from Travis CI #106

Conversation

hugovk commented Nov 14, 2019

hugovk commented Nov 14, 2019

hugovk commented Nov 14, 2019

codecov bot commented Nov 14, 2019 • edited

Codecov Report

hugovk commented Nov 14, 2019

SethMMorton commented Nov 14, 2019

hugovk commented Nov 15, 2019

hugovk commented Nov 15, 2019

hugovk commented Nov 15, 2019

SethMMorton commented Nov 15, 2019

SethMMorton commented Nov 15, 2019

SethMMorton commented Nov 16, 2019

hugovk commented Nov 16, 2019

hugovk commented Nov 16, 2019

SethMMorton commented Nov 18, 2019

hugovk commented Nov 18, 2019

SethMMorton commented Nov 20, 2019

hugovk commented Nov 20, 2019

codecov bot commented Nov 14, 2019 •

edited