Reputation: 10868
Scenario:
I'm continuously integrating + deploying a Node web app on every commit to master, e.g. via Travis to Heroku.
(Two options: Travis's deploy hook, or Heroku's GitHub Sync. Importantly, both ways only deploy if CI succeeds / tests pass.)
I have some pieces of this app that I want to maintain as separate, reusable modules, e.g. in their own git repos.
Let's assume everything is public for simplicity.
—
I want to similarly continuously integrate + "deploy" (i.e. make available to the app) these modules, on every commit to their master (or w/e branch):
Every time I update my web app, I want to use the latest stable (i.e. tested) version of these modules.
Importantly, if I accidentally commit a bug to a module, and CI fails, an update to the web app should not pick up this change.
I don't want to manually bump a version, or publish a tag, or etc. on every commit.
—
I've investigated a number of options, but can't find any simple way to achieve all three of these goals!
npm git dependency: I can point my web app's package.json
directly at each module's GitHub repo (e.g. "foo": "git://github.com/alice/foo.git#1.x"
) to get continuous "deployment" (availability) of that module's repo. But if I accidentally commit a bug, apps are broken on their next deploy, even if the module's CI fails.
Travis npm publish: Travis can automatically publish the module to npm after a successful CI, but the npm registry requires a unique version each time, and there's no way to automatically bump the version AFAICT.
Travis GitHub release: I was hoping Travis could automatically update a tag, but it can only do this on tags (it's meant more for publishing build assets), so still manual.
—
Is there any way? Thanks!
Upvotes: 2
Views: 941
Reputation: 10868
One option that comes to mind, though it would need to be manually implemented, would be to update a branch (named e.g. stable
or tested
or w/e) on Travis after_success
(sort of like a manual deploy hook).
Then, you could freely commit to master, but this other branch would only contain commits that passed CI. This'd allow you to point npm at this branch, e.g. foo.git#stable
. And if you updated via a non-force git push
, you're guaranteed that this branch would only contain ffwd commits.
You'd need to make GitHub user creds available to the script, e.g. via secure env vars, but they can be the same ones that Travis itself uses. I'm not sure if there'll be any other gotchas though. E.g. I assume git is available to Travis scripts.
Upvotes: 1