Setting tag at deployment time results in double build + different configurations for same deployment provider

Deployment
, ,
1

My build is a Java/Maven build. I would like to achieve the following:

  • tagged commits are deployed to the corresponding GitHub release as a draft. Those are supposedly releases or release candidates
  • untagged commits are deployed to a GitHub release named after the Maven project version. Those are supposedly snapshots and may be overridden many times

Here’s what I have come up with:

before_deploy:
- if [[ -z "$TRAVIS_TAG" ]]; then export TRAVIS_TAG=$(mvn help:evaluate -Dexpression=project.version -q -DforceStdout); git tag -f $TRAVIS_TAG; fi
deploy:
  provider: releases
  draft: false
  overwrite: true
  api_key:
    secure: ...
  skip_cleanup: true
  file: ...

It seems to work but I’m not quite happy yet:

  • tagging the untagged commit triggers a double build… is there a way to avoid that? Also, since the second build is a tagged build I was expecting it to trigger a deploy again, but it doesn’t, it says “Skipping a deployment with the releases provider because this branch is not permitted: 1.0-SNAPSHOT”
  • I would like my “real” tagged commits to be deployed as draft releases, because they might need to be edited before being published. On the other hand, snapshots can be published right away. How can I use the same provider but configure it differently depending if I’m deploying a snapshot or not? I tried to duplicate the Github releases provider and add conditions like condition: "$TRAVIS_TAG" =~ -SNAPSHOT$ but Travis complained that it could not parse the file…

Any help appreciated!

2

So it’s not exactly as I thought… The double build is triggered only the first time the tag is set, so that’s not so bad.
However I’m still struggling with the double deploy configuration. Contrary to what I thought, it seems the before_deploy section is executed after conditions have been evaluated for each provider, so the value of TRAVIS_TAG set in before_script can’t be used in a condition clause…

3

This is true. You’d probably want to use after_script for that.

4

I just found that this is specified at the very bottom of the page…

Note that before_deploy and after_deploy are run before and after every deploy provider, so they will run multiple times, if there are multiple providers.

Maybe this should be moved next to the full lifecycle, in other words steps 9-10-11 are repeated for each provider.

You’d probably want to use after_script for that.

You mean after_success? Otherwise I don’t see how it could affect deployment.
It remains unclear to me when exactly the deployment conditions are evaluated. Is it between after_success/failure and before before_deploy ?

5

You can suggest an improvement to a documentation page by using “improve this page at Github” link at the top of it.

1 Like