Build on tag


#1

Hello

we switch our project to CCI2.0 and its working fine :slight_smile: however in the previous version of CCI when we push a new tag it trigger a build for us, in the new version looks like it not working.

How can I build from tag?

thanks


#2

Tags are not yet fully supported in the same way as 1.0. The current workaround I’ve been recommending is to use git describe with some logic.


#3

:frowning:


#4

I moved this into a feature request so that we can keep better track of this. I agree that this should work the same way as it did in 1.0.


#5

If you have a chance, could you share an example of what this would look like for other folks that might run into this issue?


#6

A nice, simple example looking for deploy in the tag on HEAD.

if [[ `git describe 2>/dev/null` == *"deploy"* ]] ; then echo "success" ; fi


#7

I want to be able to push a docker image for each tag when a tag is pushed.

So for example if I push a tag 0.3.4 then I would want to tigger a build and if it succeeds then do a docker build and push to a docker registry against that tag.


#8

Any updates on this or ETA?


#9

How can I trigger build/deploy for pushing tag (not new commit)?

For example:

  1. push commit

     #edit something
     git commit -a -m "new feature"
     git push origin master
    
  2. push tag

     git tag v1.0.0
     git push origin v1.0.0
    

expectation: trigger build and deploy v1.0.0
actual: don’t trigger build


#10

As of now, without using a bash workaround like the one I posted, this is unsupported. We will support it, but there is no ETA at this time.


#11

Thank you for your reply!

Our deployment depends on the tag feature so
I can’t wait to support it!


#13

What MTSMFM seems to be saying is that the build isn’t triggered when a tag is pushed - so even if we have the “bash workaround” in place, no build is triggered.

For now I’ve just been manually “restarting” a build - which pulls down the new git state and the “bash workaround” sees the new tag. It would be nice to not have to have this manual step however.


#14

Our tagged releases also have a version number in the commit message, e.g. 1.5.0. Here’s an example we use that checks for last commit message and if it matches a version release, we build the Docker image.

- type: setup-docker-engine

- type: shell
  name: Build docker image
  command: |
    if git log -1 --pretty=%B | grep "^[0-9]\+\.[0-9]\+\.[0-9]\+$";
    then
      version=$(git log -1 --pretty=%B)
      docker build -t foo/bar:$version .
    else
      echo "Not a release, skipping build"
    fi

#15

It looks like this code doesn’t actually trigger a publish so maybe this isn’t an issue for you, but since this logic doesn’t check for the current branch and always just checks the last commit message, I believe it may execute multiple times – for example, if multiple people push a feature branch with a single new commit on top of the release, all of the builds for those branches will run this “publish” logic since the last commit will have the matching commit message.


#16

We currently use a similar work-around of “use bash script to see if current commit is tagged, and if so run release”. The logic looks like the following:

- type: deploy
  name: "Publish on release tags"
  command: |
    set -eu
    TAG=$(git describe --tags)
    if [[ $TAG =~ ^[0-9]+(\.[0-9]+)+(-rc[0-9]+)?(-alpha[0-9]+)?$ ]]; then
      # run publish logic
    fi

We typically tag commits that have already built as releases, so the current workflow is to wait for the build to finish, tag the commit, push the tag, and then re-trigger the build that had the commit that we tagged – the rebuild will then see the tag and attempt to execute it.

However, this is definitely not as straightforward/clean as in CircleCI 1.0, where pushing the tag would kick off a build automatically based on the circle.yml contents and tag builds could be easily distinguished in the CircleCI UI (the build itself would have the name of the tag instead of just being another build on “develop” or “master” or wherever else).


#17

FWIW, this is also a blocker for us switching over (which is a shame, we’ve managed to get things much faster on Circle 2.0 with custom Docker base images etc!)

We normally create a release through the GitHub UI - which creates a Git tag. In our existing workflow, this builds and packages up a version and deploys it to the staging environmment with no more actions required. Without a fresh build being started on a new tag, we’d need an additional step to kick off this build.


#18

Same here… got excited to start the switch, but we use tags for automatic deploys on all of our repos.


#19

$CIRCLE_TAG is now available within builds! The functionality is exactly the same as 1.0.


#20

Great news! However, to confirm, you still can’t trigger builds on new tags? Or you can but there’s some configuration required to enable it?


#21

I’d give it a try.