4

I have a build promotion process modeled after this discussion (using promoted builds plugin.) In general, it works great. However, for a few "flavors" of the promotion process (not all) I'd like to push a git tag. I implemented this with an "execute shell" step as one of the promotion actions. This has been working well, and then today failed with the error below. I suspect I landed on a build slave where the workspace wasn't already initialized for git - and that I've been getting lucky in the past (using Cloudbees - where the build slaves are dynamically allocated.)

I've tried the "git publisher", but it seems to expect that you are in a setting where the git source plugin has already done its job. Has anyone been able reliably push a tag from a build promotion step ?

+ git checkout develop
fatal: Not a git repository (or any of the parent directories): .git
Community
  • 1
  • 1
scolestock
  • 717
  • 6
  • 17
  • I would say to tie the promotion to the same master/slave as the job... but you mentioned that your slaves are dynamically allocated. – Slav Apr 08 '14 at 13:27

2 Answers2

2

This has worked so far for me:

git tag MYTAG ${PROMOTED_GIT_COMMIT}
git push --tags

I am not sure if I simplify the issue, in my environment the promotion seems to be executed on master where the archived artifacts are.

diidu
  • 2,823
  • 17
  • 32
  • Though presumably you also need to checkout the git repo? – Andy Smith Jun 04 '15 at 16:57
  • In my case no, the clone is archived and the tag command sets the tag to correct version. But it might be necessary in some other situation. – diidu Jun 09 '15 at 15:19
  • Ah OK, we have multiple jenkins slaves which means we can't guarantee that the git checkout is where we run the command – Andy Smith Jun 09 '15 at 15:26
  • We have multiple slaves too. As far as I understand the promotion -- that can be executed days after the build it is related to -- is always executed at master where the archived artifacts and corresponding clone are. At least it works :) – diidu Jun 15 '15 at 06:44
  • 1
    I learned more on this. I was wrong about promotion being always executed at master. It seems to be executed at the machine where the build is made. This of course makes things more complex if you want to promote something else than the latest build. The latest build should be fine though, as long as you make sure the workspace is not deleted before another version is built. – diidu Sep 03 '15 at 07:06
0

Disclaimer: I know nothing about Git.

You should never rely on files under ${WORKSPACE} when executing promotions. At best, they may be newer than the job run promotion that you are executing, and at worst the workspace could be empty while doing a new checkout (or non-existent as in your case). That's why in the discussion that you linked, I am using Copy Artifacts step. Note that that step copies from archived artifacts, not from job workspace, which should always be considered temporary and transient.

If you need to rely on an SCM checkout for your promotion process, you have to either:

  • Perform command line checkout (it will not be tracked by Jenkins), or
  • Run another job with SCM checkout (all the benefits of Jenkins tracking).

In both cases, I would assume you want to pass an SCM revision number to the promotion process (to use in command line checkout, or as parameter for calling another job). The "Trigger/Call builds" step has an option to pass parent SVN revision, but I don't know if it has the same option for Git. In worst case, on your "build" job execution, store the Git revision to a file and archive that file with the rest of the artifacts. In your promotion process, retrieve the saved file with "Copy Artifacts" step, and then extract the Git revision from that file. You can use EnvInject plugin to help with all that and make the extracted Git revision available as an Environment Variable for the promotion process.

My recommendation would be a second "Trigger/Call Builds" step in your promotion process that triggers a job dedicated to what you want, passing it a Git revision parameter.

Community
  • 1
  • 1
Slav
  • 27,057
  • 11
  • 80
  • 104
  • 1
    Thanks for the reply. I am indeed using "copy artifacts" in the promotion process - and I have access already to the git commit via $PROMOTED_GIT_COMMIT (and $PROMOTED_GIT_BRANCH). So I have much of what I need - just not a workspace that has been properly initialized - which as you point out is my own job to do. I will look at triggering another (parameterized) build so I have benefit of the git scm plugin doing its standard work, though it seems heavy for this task. thanks! – scolestock Apr 09 '14 at 14:07