Jenkins: Build when a branch is tagged

Question

(Git newcomer here) I'm trying to implement a system whereby a Jenkins build is triggered when a tag is pushed to a specific branch. Currently, my supervisor has installed a simple PoC where, on our API servers (which run node.js), a cron job is ran every 5 minutes that runs:

git checkout production
git pull
git checkout `git describe --abbrev=0 --tags`

So when a developer wants to push a change to production, they simply run npm version patch which tags the latest commit with a new version number, then pushes the change using git push origin --tags . Then, they run a script via Jenkins that restarts all API services on API boxes.

So, to emulate this and fully automate it, I want to have a Jenkins job that does all of this (plus some extras) when it detects our production branch has been tagged with a new version.

Is this possible? Most documentation I've found involves triggering a build on ANY tag pushed to a repo. I want to trigger on a tag pointing to a commit to a specific repo.

I'm fairly certain this is an advanced case, and I could write some script to do it instead, but I'm attempting to learn best practices for Jenkins and git, and I don't want to end up adhering to some anti-pattern.

Answer 1

I have no clue how Jenkins actually gets used, so this answer may be quite useless.

In Git, however, if you plan to use a detached HEAD like this, all you need is to run git describe twice, once before fetching, and once after:

otag=$(git describe --tags --abbrev=0 origin/production) ||
    die "help, no initial tag"
git fetch origin
ntag=$(git describe --tags --abbrev=0 origin/production) ||
    die "help, no new tag"
if [ "$otag" = "$ntag" ]; then
    echo the tag we would check out now is the same as the one
    echo we checked out last time, so we do nothing
else
    echo moving from tag: $otag to tag: $ntag
    git checkout $ntag
    ... build ...
fi

git describe allows you to specify the commit you want described, so there is no need to check out a branch, fetch, and merge-and-hope-it's-a-fast-forward.

Note that this allows the local branch production to get progressively more and more out of date, or even simply to not exist at all, because the local branch is never really used . The only thing it is giving you in your example code is its upstream setting.