Refined-github: Versioning, deployment improvements

Created on 8 Jul 2017  路  8Comments  路  Source: sindresorhus/refined-github

I'll preface by saying that the current setup (deploy every push to master) works well for me and I prefer it over manually creating tags/releases.

I do however have two wishes:

  • [x] limit to one release per day
  • [ ] shorter version numbers (17.7.8 instead of 17.7.8.1317)

Travis recently added a daily cronjob feature which we could use to implement daily deployment, but it runs regardless of changes.

These changes are possible but we need two pieces:

  • something that stops Travis as soon as it sees no new commits since the last build (which might not be exactly 24 hours before)
  • something that stores the previous version in Travis' cache (seems possible) as y.m.d and automatically bumps it to y.m.d.1 if multiple builds happen in the same day

Ideas? Have you seen such packages? Know how to do this?

help wanted meta under discussion

All 8 comments

@bfred-it I think we should just go with the daily cronjob right now and we can figure out how to only release when there are new commits later on.

How about using a dedicated CD service (Jenkins etc)? I don't think Travis is the right tool for such a relatively complex deployment scenario

I never used Jenkins, but if it's easier to manage I wouldn't be opposed to it.

I would prefer to use a hosted service unless we really can't. I hate doing DevOps and we have better things to spend our time on than manage a Jenkins instance.

What's the aversion to multi deploys a day? The current solution works and the proposed solutions all appear to overcomplicate the release process.

The problem is that we can't even make readme changes that they're deployed instantly. Or you can't merge something and then make some additional changes before deploy.

I mean no big deal, just a bit annoying.

Deploying once a day was pretty easy really, the 3-point version is a little less easy.

This is the code needed to cache, retrieve, and bump the version:

  • 17.7.12 (first deploy of the day)
  • 17.7.12.1025 (successive deploys, if any)
cache:
  directories:
  - $HOME/.version-store
script:
  - CURR=$(date -u +%y.%-m.%-d)
  - PREV=$(cat $HOME/.version-store/v || true) 
  - if [[ $PREV =~ ^$CURR ]]; then CURR=$(date -u +%y.%-m.%-d.%-H%M); fi;
  - echo $CURR > $HOME/.version-store/v

See tests here: https://travis-ci.org/bfred-it/sandbox/builds/252651771

Except this script can't live in .travis.yml because deployment only accepts one command, so I'll have to transpose it to package.json or a .sh file.

Worth it or not? Should I turn it into its own package? Then it could be used as:

cache:
  directories:
  - $HOME/.version-store
"update-version": "dot-json extension/manifest.json version $(daily-version)"

Edit: published: https://github.com/bfred-it/daily-version

@busches It gives us some time on master before deploying to everyone. Some issues are not apparent right away. Most big projects have nightly builds.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

sindresorhus picture sindresorhus  路  3Comments

hkdobrev picture hkdobrev  路  3Comments

Celthi picture Celthi  路  3Comments

sompylasar picture sompylasar  路  3Comments

Arcanemagus picture Arcanemagus  路  3Comments