Release Pants as a pex. #6014
Release Pants as a pex. #6014
Conversation
This adds release automation of a Pants pex to our Travis CI job when run against a release_* tag. There is more to be done to consume the pex in the setup script we point users to, but the actual release should now be covered. Fixes pantsbuild#4896
| file: dist/deploy/pex/* | ||
| skip_cleanup: true | ||
| on: | ||
| # We only release a pex for Pants releases, which are tagged. |
There was a problem hiding this comment.
So, while only building pexes for tags should reduce storage costs, Twitter does currently rely on the fact that travis publishes wheels for "all origin branch shas", in that we consume nightly/master wheels for a nightly smoketest.
I think that the storage costs for pexes should be relatively small, and that most of the cost would be from people actually fetching them. @benjyw : does that sound right?
If so, it would be good to ship pexes for all branches (but not PRs).
There was a problem hiding this comment.
2 things:
- This deploys using github releases which only work for tags. I think this is a good thing for our public releases - pypi and github releases are standard discoverable things, an s3 bucket isn't as much.
- Cache ./pants bootstrapping in CI using stages #6016 will require storing pexes for all shas temporarily in S3. This will need a new bucket with a TTL attached to auto-purge. Wheels can get moved there too.
I'd like to defer the per-branch bit until work on point 2.
There was a problem hiding this comment.
Ok, works for me. Thanks.
As long as the -p flag continues to work, Twitter can wait to migrate to the new mechanism.
There was a problem hiding this comment.
It is true that our costs are 99% bandwidth, not storage.
This adds release automation of a Pants pex to our Travis CI job when
run against a release_* tag. There is more to be done to consume the pex
in the setup script we point users to, but the actual release should now
be covered.
Fixes #4896