Details
-
Improvement
-
Status: Open (View Workflow)
-
Major
-
Resolution: Unresolved
-
None
-
LTS 2.73.1 (2017-09-13)
Description
Hello,
I'm the maintainer of a maven-plugin (https://github.com/ktoso/maven-git-commit-id-plugin ) that exposes certain repository information as properties into the build. A user of of this plugin reported that the branch name is not available with a single branch pipeline build under jenkins. From the plugin perspective we rely (especially for the branch identifier) on the environment properties that are being exposed by the [Git Plugin|https://github.com/ktoso/maven-git-commit-id-plugin ]. In particular we use the GIT_LOCAL_BRANCH or GIT_BRANCH . Unfortunately with Jenkins LTS 2.73.1 (2017-09-13) those environment variables are not available and thus making it impossible to retrieve the branch name.
Thank you for your time.
Note:
During my initial debugging I noticed that a user could this get to work when using a parameterized build which is not really beautiful since the parameter used need to be set to GIT_LOCAL_BRANCH or GIT_BRANCH since its then automatically exposed as environment variable (would consider this a dirty hack)...
pipeline {
agent any
parameters {
string(defaultValue: 'master', description: 'branch', name: 'GIT_BRANCH')
}
stages {
stage('Clone sources') {
steps {
git branch: "${params.GIT_BRANCH}", url: 'https://github.com/ktoso/maven-git-commit-id-plugin.git'
}
}
stage('Build printenv'){
steps {
sh 'printenv'
}
}
}
}
Original issue: https://github.com/ktoso/maven-git-commit-id-plugin/issues/325
Attachments
Issue Links
- is related to
-
-
- Resolved
-
-
-
- Resolved
-
Activity
I have used following workaround in my pom.xml for maven
<properties>
<branch>${git.branch}</branch>
</properties>
From jenkins pipeline I call then follwing step
steps {
sh 'mvn clean verify -Dbranch=$BRANCH_NAME'
}
In my development environment I call mvn without -DBranch, as there maven-git-commit-id-plugin works fine.
Michael Behrns-Miller
added a comment - Ability to build and deploy a specific dockerized branch is seriously crippled by the lack of a branch name variable in Pipeline's Jenkinsfile.
Instead, you have to hardcode the branch name in the Jenkinsfile for a given branch, and end up with a bunch of branch merging confusion.
An alternative is to move to multibranch pipeline, but that has different keys, different commit triggers, etc. which is just too much.
If this variable was available it would definitely simplify our CI.
Thanks!
Michael Behrns-Miller
added a comment - Ability to build and deploy a specific dockerized branch is seriously crippled by the lack of a branch name variable in Pipeline's Jenkinsfile.
Instead, you have to hardcode the branch name in the Jenkinsfile for a given branch, and end up with a bunch of branch merging confusion.
An alternative is to move to multibranch pipeline, but that has different keys, different commit triggers, etc. which is just too much.
If this variable was available it would definitely simplify our CI.
Thanks! Removing myself as assignee. My current work assignments do not provide sufficient bandwidth to review these issues and in the majority of cases I am only assigned by virtue of being the default assignee. For the credentials-api and scm-api related plugins I have permission to allocate time reviewing changes to these APIs themselves to ensure these APIs remain cohesive, but that can be handled through PR reviews rather than assigning issues in JIRA
Seeing the same in multi-branch pipelines.
Settled for making an explicit parameter that I pass in from all parent jobs.
if ( ! env.BRANCH_NAME ) { println("Warning: Missing env.BRANCH_NAME, use MBPL_BRANCH (${params.MBPL_BRANCH})") if ( ! params.MBPL_BRANCH ) { error("Warning: Missing env.BRANCH_NAME, requires MPL_BRANCH, also unset, can't continue") } env.BRANCH_NAME = params.MBPL_BRANCH }
pretty annoying though.
Seems to happen most often from a jobs that spins up multiple child jobs. Usually only one of the child jobs (with a common parent) will have this problem.
Bruce
added a comment - - edited Seeing the same in multi-branch pipelines.
Settled for making an explicit parameter that I pass in from all parent jobs.
if ( ! env.BRANCH_NAME ) {
println( "Warning: Missing env.BRANCH_NAME, use MBPL_BRANCH (${params.MBPL_BRANCH})" )
if ( ! params.MBPL_BRANCH ) {
error( "Warning: Missing env.BRANCH_NAME, requires MPL_BRANCH, also unset, can't continue " )
}
env.BRANCH_NAME = params.MBPL_BRANCH
}
pretty annoying though.
Seems to happen most often from a jobs that spins up multiple child jobs. Usually only one of the child jobs (with a common parent) will have this problem. 
Hitting us, too. Workaround: In Multi Branch Pipeline, you can use
withEnv(["GIT_BRANCH=$BRANCH_NAME"]) {
//do something with GIT_BRANCH
}
around it.