Deploying new releases of your open source libraries should be automated so that you deploy as often as possible. The more work for you, the less often you will do it.
Firstly you need to add your CocoaPods trunk token as a secret token for Travis to expose to the environment of your CI process. You can do this in the repository’s settings. Your token is stored in
Now generate a new one for your computer.
Next I suggest adapting your
.travis.yml to use the new(er) Travis Build Stages format. This will allow you to add a specific
Which will be something like so:
Travis times out if there is not enough output within 8 minutes. So we need to specify
However this will likely cause Travis to cancel the build due to too much output! Thus we need to do a trick:
This little one-liner Ruby script converts every line of output into a single
. of output. Obviously this means your travis deploy log is useless, so an ideal solution might save the log using
PromiseKit’s deploy takes 25 minutes so these tricks were absolutely required.
Only Deploying On New Tags
We don’t want to waste Travis’s free resources by deploying every commit (the deploy would fail due to lack of an updated version, however CocoaPods will still do the full lint before failing), so we need to configure our YAML to only add the deploy job when you add new version tags, this proved quite difficult to get right, so here is the fruits of many hours of my labor:
Put this at the top.
Unfortunately this means Travis will run CI for master and your tag, two builds for the same git SHA. I couldn’t figure out how to prevent this. Frankly it seems like Travis should automatically prevent this, after all, they are the same SHA!
I’m Max Howell and I want to be full-time making, writing and being all about open source. I’ve been doing open source for more than 15 years, and you probably already use some of it (Homebrew anyone?). I need your help to continue, any contribution is most welcome. Thanks so much.