My Ant build.xml script starts with
GIT_BRANCH = ${env.GIT_BRANCH}PWD = ${env.PWD}
Hudson CI is setup to build when any branch changes. Console output is...
Commencing build of Revision 90906a63929e9074035eb5b10c71ee055ad3e13c (origin/DPM-48) GitAPI created Checking out Revision 90906a63929e9074035eb5b10c71ee055ad3e13c (origin/DPM-48) [workspace] $ git.exe checkout -f 90906a63929e9074035eb5b10c71ee055ad3e13c [workspace] $ cmd.exe /C '"C:\Program Files\WinAnt\bin\ant.bat" -file build.xml ...' [echo] GIT_BRANCH = ${env.GIT_BRANCH} [echo] PWD = /cygdrive/d/.hudson
From the console output, Hudson knows it is building topic branch DPM-48 but environment variable GIT_BRANCH is not set and 'git branch' returns that git is at a 'detached HEAD' state
* (no branch) master DPM-48
What I want to know is which branch I'm building on hudson. There must be a way to do this.
RESOLVED
After seeing the comment by abayer in Hudson bug 6856, I took the following steps:
- Using the Hudson Plugin Manager, I updated my Hudson Git Plugin version 1.1) to get abayer's fix.
- Using the Hudson Job Configuration, I clicked the "Advanced" button under "Source Code Management" -> "Branches to Build". I then changed the "Local branch to use" to something to use for a name. It doesn't matter what.
- Then I clicked the "Save" button and started a build with "Build Now"
The build log shows
[workspace] $ git.exe checkout -b ChangeTester d6caef27759495c5714923c1ddf19551a70d6083
Instead of
[workspace] $ git.exe checkout -f d6caef27759495c5714923c1ddf19551a70d6083
Which means that I am not in a 'detached head' state and can therefore do commits, create tags, and push.
I can use 'git rev-parse HEAD' to get the commit hash and find that in the output of 'git show-ref' to find the real name of the branch if I need it.
I'm now able to push successful build tags to my git repo.
Note: the OP milkplus's comment refers to recent Hudson bug 6856 (June 2010), which mentions:
Git builds with detached head no matter what
While it is unclear if that particular issue will be solved (answers suggest it might actually "work as designed"!), it also refers to this version of hudson Git Plugin, allowing to checkout a local branch.
You are in a DETACHED HEAD because, as the git plugin is working right now, it did checkout directly a commit SHA1, and not a branch HEAD.
The state you are in while your HEAD is detached is not recorded by any branch (which is natural --- you are not on any branch). What this means is that you can discard your temporary commits and merges by switching back to an existing branch.
Your building script could first try to find what branch the relevant commit is coming from.
As the OP milkplus realized by looking at the source code of the Hudson Git Plugin:
public void buildEnvVars(AbstractBuild build, java.util.Map env) { super.buildEnvVars(build, env); String branch = getSingleBranch(build); if(branch != null){ env.put(GIT_BRANCH, branch); } }
An environment variable GIT_BRANCH is set, but it doesn't appear to have any value in the xml build script:
GIT_BRANCH = ${env.GIT_BRANCH}
If that is the case, it may be because of issue 7554:
GIT_BRANCH not set when multiple branches are selected for build
When trying to identify what branch the current build are on, I found that the GIT_BRANCH environment variable is not set when more then a single branch is selected to be built.
This isn't really a bug so much as a feature request, I think - the GIT_BRANCH env var is only set if there's a single branch, so as such, it's not relevant if/when there are multiple branches. I'm not sure how we'd format an env var for multiple branches in this context.
I thought that GIT_BRANCH shall be set to the branch that is currently building. Like if the build is on master it will contain the master.
That would help to for example push to another remote that branch that was built during this build. Or Triggering another Build with the correct branch set to be built.
Kind of mirror the NPE described here
For some reason Git plugin started to pass null value for GIT_BRANCH environment variable.
This caused Maven plugin to fail in System.getProperties().putAll(systemProps) call.
The solution was to use "master" as default Git branch instead of "**" or empty String.
Thank you, very much for sharing this solution!
I had some trouble to find this optional dialog to set the local branch - and to show others that this is also still the current approach also in year 2015 I would to attach some screenshot of the current gui dialogs of jenkins.
