(this is a followup to my previous post)
I would like my untagged commit builds to deploy to a GitHib release named like the Maven version. The idea is that the latest snapshot build is always available as a GitHub release, say 1.0-SNAPSHOT. This means the release might already exist.
I have used the indications there to set the TRAVIS_TAG to the Maven version. It worked one time, but failed the subsequent times.
If I add a unique suffix, like this:
- export VERSION=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout)
- export TRAVIS_TAG=${TRAVIS_TAG:-$VERSION-$(git log --format=%h -1)}
it works but a new release is created on each build. I would like the existing release to be updated, if it exists.
Is there a way to UPDATE an existing GitHub release? I suppose I might need to move the tag, if it exists, to the current commit ?
Thanks
Thanks for pointing me to this discussion about “nightly” release, very helpful.
So my idea to avoid infinite loop is:
- set the deployment to
on: tags
- when building an untagged commit, move the “latest” tag with
git tag -f and push, but don’t set TRAVIS_TAG; this will prevent the current build from being deployed (because of on: tags)
-the tagging should trigger a new tagged commit build, which will have TRAVIS_TAG set and hence trigger a normal deploy
Does that sound viable?
PS: it’s not exactly true that a Github release must be associated with a Git tag, you can actually create a GitHub release without a tag in draft mode, but you can’t publish it unless it is associated with a tag.
Yes, this is the easiest way, and would allow you to build both automatic and manually created tags in a uniform manner.
I’m reviving this old thread, the solution is still working fine but there’s a minor annoyance: even though the draft release is correctly updated in github, it still bears the original creation date… Is it possible to update the release date ? Or do I need to delete the existing release ?