Trigger canary release on successful PR build #246
Conversation
.travis.yml
Outdated
| @@ -2,6 +2,8 @@ language: node_js | |||
| node_js: | |||
| - '7' | |||
| env: | |||
| global: | |||
| - COMMIT=${TRAVIS_COMMIT::8} | |||
There was a problem hiding this comment.
Hrm, does this modify the build matrix? If so, maybe we just do this when we generate the prerelease id.
There was a problem hiding this comment.
I don't think it changed the matrix, https://travis-ci.org/primer/primer-css/builds/251305487
Looks like it just included a $COMMIT variable in all the builds
| "force": "lerna publish --force-publish=*" | ||
| "updated": "lerna updated", | ||
| "release": "lerna publish", | ||
| "release-candidate": "lerna publish --npm-tag=rc", |
There was a problem hiding this comment.
FYI keeping the --skip-git on release-candidate keeps the version changes locally but doesn't publish them, so when you go from release candidate to a release you don't have to force publish. If we don't do this then we'll need to add a force publish option to the scripts which I'm also not sure why you've removed in this pr. It also means we have more force publish options to consider as right now the forma script publishes every single package which we might not want to do.
There was a problem hiding this comment.
Sorry, my thinking was that we don't need --skip-git because these commands will be run on Travis, from whence we we won't commit changes or push tags.
| "rc": "lerna publish --npm-tag=rc --skip-git", | ||
| "force": "lerna publish --force-publish=*" | ||
| "updated": "lerna updated", | ||
| "release": "lerna publish", |
There was a problem hiding this comment.
So a release will be lerna publish --yes
How does that resolve versions?
e.g.
a@1.1.0
b@2.0.0 depends on a@^1.1.0
c@3.0.0 depends on a@^1.1.0
d@4.0.0
If you merged changes to master that constitute a minor bump of:
a@1.1.0 to a@1.2.0
- causes
b@2.0.0to becomeb@2.0.1 - causes
c@3.0.0to becomec@3.0.1
and a major of:
d@4.0.0 to d@5.0.0
as well as a small change of:
c@3.0.0 to c@3.0.1
How would that all get resolved non interactively?
The result needs to be:
a@1.2.0
b@2.0.1
c@3.0.1
d@5.0.0
There was a problem hiding this comment.
Thanks for weighing in, @bradbarrow. My hope – perhaps based on bad assumptions, which I'm more than happy to reassess – was that we could do the version resolution with lerna publish --no-npm and file a PR with the resulting versions, then have those versions published without any incrementing or prompting when the PR merges. I haven't tested this out yet, but I plan to today.
|
@jonrohan @broccolini How would you all feel about scoping this down to publish canary releases whenever a PR build succeeds? Then we could at least test that feature on this PR before merging. |
|
Status update: I cherry-picked 871d806 so the tests would pass, and this build succeeded... but then failed because npm failed to authenticate. So I replaced the |
|
Welp, that failed. I think I can get it to work by removing the |
|
Hey, it worked! The PR build published the merge commit a7f1f71 as |
I'm okay with that. |
|
Sweet, so I'll merge this, then we can do the commit status updates in another PR! ✨ |
| # merges to dev build a release candidate | ||
| elif [[ $TRAVIS_BRANCH = dev ]]; then | ||
| echo "👌 Publishing release candidate..." | ||
| echo npm run release-candidate -- ${args} |
There was a problem hiding this comment.
Note the echo here and on line 19 will just output the command rather than run it. We'll need to remove those as we're ready to test those release stages.
shawnbot
changed the title
Update from @shawnbot
This PR adds some travis-ci config options that will run
script/cibuildafter the build succeeds. If this is a PR build (whenTRAVIS_EVENT_TYPE = pull_request), then we publish a canary release to thecanarynpm dist-tag.We've stubbed out publish commands for release candidates and final releases, but for now those commands are just echoed rather than executed.
We've also eliminated our per-module build matrix and now run the tests for all modules in one go, which should speed up testing time significantly.