2

I wanted to test Github releases for our OSS. The first problem I encountered is, that travis seems to be unable to merge Github releases from different build-configs of the same build (e.g. create a OSX and a linux version and upload both at the end of the build process), see https://github.com/travis-ci/travis-ci/issues/8053

Is there any solution to this for now? As mentioned using some separate space like AWS S3 is not acceptable as it incurs costs.

Secondly: Is there (now) a solution for nightly builds? In this case I want the same artefacts but for each commit to the develop branch. So it doesn't need to be "nightly", just "latest dev". I'm not really a fan of creating a tag for each of those, but it seems there is no other solution, is there?

Finally: How to synchronize these builds? E.g. some run on appveyor (windows), some on travis (linux, OSX) but all should be released with the same release/tag w/o doing it (e.g. creating the tag) manually. I fear a race condition there even when using e.g. the date (build starts just before midnight but some finish before, some after)

The project is a C/C++ project creating OS-specific binaries.

Collin Barrett
  • 2,441
  • 5
  • 32
  • 53
Flamefire
  • 5,313
  • 3
  • 35
  • 70

1 Answers1

0

Don't know if it's too late (probably) but I had the same needs and managed to make it work.

The "merge releases from multiple jobs" must have been fixed since then, as I have a build that runs 3 jobs (Linux, OSX, Windows) and each of them contributes different files to the same release.

The solution I've found for "nightly" or "latest" release is as follows:

  • set the deployment to on tags: true
  • when building an untagged commit (TRAVIS_TAG not set), move the “latest” tag to the current commit with git tag -f and push it with git push --tags -f, but don’t set TRAVIS_TAG; this will prevent the current build from being deployed (because of on tags: true)
  • the tagging should trigger a new tagged commit build, which will have TRAVIS_TAG set to "latest" and hence trigger a normal deploy to a release named "latest". If the release already exists, it will be updated.

Note that to be able to push from the Travis build, you will need to pass an authentication token. This is described in many places, for example there.

The synchronisation works because each job does the same tagging operation. The first one to push actually moves the "latest" tag on the Github repo, the next ones get "Everything up-to-date". You just need to use the same tag for all jobs.

Here's my script to handle this:

#!/usr/bin/env bash

set -ev

# If we don't have a tag, use the Maven project version to set/update a tag and push.
# Don't set TRAVIS_TAG so that this build will not be deployed.
# The new build that will be triggered by the push will be tagged and deployed as usual.
if [ -z "$TRAVIS_TAG" ] ; then
  VERSION=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)
  git config --local user.name "Olivier"
  git config --local user.email "ogerardin@yahoo.com"
  git tag -f "$VERSION"
  git push --tags -f https://${GH_TOKEN}@github.com/ogerardin/xpman.git
fi

Note that I don't use a fixed tag but I extract the Maven project version, but you could use anything for VERSION as long as it's the same for all jobs (platforms).

Also: you should not call this script from before_deploy, because before_deploy is only executed if the deployment applies to the current build, and if you have on tags: true it means it will not be called for untagged builds. I use after_success.

Olivier Gérardin
  • 1,113
  • 14
  • 27