[JIRA] (JENKINS-59206) Environment variables tag name and branch name set incorrectly

18 views
Skip to first unread message

michaelperzel@gmail.com (JIRA)

unread,
Sep 3, 2019, 12:23:02 PM9/3/19
to jenkinsc...@googlegroups.com
MICHAEL PERZEL created an issue
 
Jenkins / Improvement JENKINS-59206
Environment variables tag name and branch name set incorrectly
Issue Type: Improvement Improvement
Assignee: Mark Waite
Components: git-plugin
Created: 2019-09-03 16:22
Environment: Jenkins jenkins-2.187-1.1
Git-plugin 4.0.0-rc
Priority: Minor Minor
Reporter: MICHAEL PERZEL

In a multi-branch pipeline, if you commit to the master branch and print out the values of the environments variables you will see:

BRANCH_NAME = master
GIT_BRANCH = master

If you trigger a build via committing a tag to the same repository and print out the variables (where the tag name is 4.1.0):

BRANCH_NAME = 4.1.0
GIT_BRANCH = 4.1.0
TAG_NAME = 4.1.0

I believe the correct values for the tagged build should be:

BRANCH_NAME = master
GIT_BRANCH = master
TAG_NAME = 4.1.0
Add Comment Add Comment
 
This message was sent by Atlassian Jira (v7.11.2#711002-sha1:fdc329d)

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 1:48:02 PM9/3/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Improvement JENKINS-59206
 
Re: Environment variables tag name and branch name set incorrectly
I disagree.  A tag does not reliably have an association to a branch.  

A tag is a "a pointer to a specific commit".  It identifies a specific commit by providing a simplified name to describe that commit.

A branch is a " lightweight movable pointer".

Depending on the state of the repository, a tag may be on no branch, one branch, or many branches.  Attempting to assign a branch name which is not the name of the tag is hard or impossible to do reliably.

Output from the command {{git log --graph --pretty=oneline --abbrev-commit --decorate}}:

{noformat}
* dd46d51 (HEAD -> master) More information added
* f6db255 Add another date
* dacdad4 (tag: v2.0) Another new change
* c4825db Add comment about v1.1
| * ec23f88 (branch-1.x) Another README change
| * 8c5c32a New change on branch-1.x
| | * a6a83ee (tag: orphan-v1.1) Orphan change, no branch
| |/
| * 1df4892 A newer change on branch-1.x
| * 3990059 (tag: v1.0) A change on branch-1.x
|/
* a693bf7 Add comment about tag
* 183db1f Add README
{noformat}

In that case, the tag {{orphan-1.1}} is not directly associated with any branch, while the tag {{v1.0}} might be associated with {{branch-1x}}.  However, if branch-1.x is merged into master, then the tag {{v1.0}} might be associated with both {{branch-1.x}} and {{master}}.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 1:48:02 PM9/3/19
to jenkinsc...@googlegroups.com

I disagree. A tag does not reliably have an association to a branch.

A tag is a "a pointer to a specific commit". It identifies a specific commit by providing a simplified name to describe that commit.

A branch is a " lightweight movable pointer".

Depending on the state of the repository, a tag may be on no branch, one branch, or many branches. Attempting to assign a branch name which is not the name of the tag is hard or impossible to do reliably.

Output from the command git log --graph --pretty=oneline --abbrev-commit --decorate:

* dd46d51 (HEAD -> master) More information added
* f6db255 Add another date
* dacdad4 (tag: v2.0) Another new change
* c4825db Add comment about v1.1
| * ec23f88 (branch-1.x) Another README change
| * 8c5c32a New change on branch-1.x
| | * a6a83ee (tag: orphan-v1.1) Orphan change, no branch
| |/
| * 1df4892 A newer change on branch-1.x
| * 3990059 (tag: v1.0) A change on branch-1.x
|/
* a693bf7 Add comment about tag
* 183db1f Add README

In that case, the tag orphan-1.1 is not directly associated with any branch, while the tag v1.0 might be associated with branch-1x. However, if branch-1.x is merged into master, then the tag v1.0 might be associated with both branch-1.x and master.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 1:49:01 PM9/3/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Improvement JENKINS-59206
I disagree.  A tag does not reliably have an association to a branch.  

A tag is a "a pointer to a specific commit".  It identifies a specific commit by providing a simplified name to describe that commit.

A branch is a " lightweight movable pointer".

Depending on the state of the repository, a tag may be on no branch, one branch, or many branches.  Attempting to assign a branch name which is not the name of the tag is hard or impossible to do reliably.

Output from {{git log --graph --pretty=oneline --abbrev-commit --decorate}}:

{noformat}

* dd46d51 (HEAD -> master) More information added
* f6db255 Add another date
* dacdad4 (tag: v2.0) Another new change
* c4825db Add comment about v1.1
| * ec23f88 (branch-1.x) Another README change
| * 8c5c32a New change on branch-1.x
| | * a6a83ee (tag: orphan-v1.1) Orphan change, no branch
| |/
| * 1df4892 A newer change on branch-1.x
| * 3990059 (tag: v1.0) A change on branch-1.x
|/
* a693bf7 Add comment about tag
* 183db1f Add README
{noformat}

In that case, the tag {{orphan-1.1}} is not directly associated with any branch, while the tag {{v1.0}} might be associated with {{branch- 1x 1.x }}.  However, if branch-1.x is merged into master, then the tag {{v1.0}} might be associated with both {{branch-1.x}} and {{master}}.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 1:51:02 PM9/3/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Improvement JENKINS-59206
I disagree.  A tag does not reliably have an association to a branch.  

A tag is a "a pointer to a specific commit".  It identifies a specific commit by providing a simplified name to describe that commit.

A branch is a " lightweight movable pointer".

Depending on the state of the repository, a tag may be on no branch, one branch, or many branches.  Attempting to assign a branch name which is not the name of the tag is hard or impossible to do reliably.

Output from {{git log --graph --pretty=oneline --abbrev-commit --decorate}}:

{noformat}
* dd46d51 (HEAD -> master) More information added
* f6db255 Add another date
* dacdad4 (tag: v2.0) Another new change
* c4825db Add comment about v1.1
| * ec23f88 (branch-1.x) Another README change
| * 8c5c32a New change on branch-1.x
| | * a6a83ee (tag: orphan-v1.1) Orphan change, no branch
| |/
| * 1df4892 A newer change on branch-1.x
| * 3990059 (tag: v1.0) A change on branch-1.x
|/
* a693bf7 Add comment about tag
* 183db1f Add README
{noformat}

In that case, the tag {{orphan-1.1}} is not directly associated with any branch, while the tag {{v1.0}} might be associated with {{branch-1.x}}.  However, if branch-1.x is merged into master, then the tag {{v1.0}} might be associated with both {{branch-1.x}} and {{master}}.

After merging branch-1.x into master:

{noformat}
*   7a7ce4d (HEAD -> master) Merge branch 'branch-1.x'
|\

| * ec23f88 (branch-1.x) Another README change
| * 8c5c32a New change on branch-1.x
* | dd46d51 More information added

* | f6db255 Add another date
* | dacdad4 (tag: v2.0) Another new change
* | c4825db Add comment about v1.1
| | * a6a83ee (tag: orphan-v1.1) Orphan change, no branch
| |/
| * 1df4892 A newer change on branch-1.x
| * 3990059 (tag: v1.0) A change on branch-1.x
|/
* a693bf7 Add comment about tag
* 183db1f Add README
{noformat}

michaelperzel@gmail.com (JIRA)

unread,
Sep 3, 2019, 3:10:02 PM9/3/19
to jenkinsc...@googlegroups.com

Okay, I agree with your explanation. With that in mind should git_branch and branch_name be set to the tag name when the build was triggered by a tag commit?

 

I'm trying to accomplish being able to differentiate between builds triggered from a commit to a branch and from tagging a commit.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 3:14:02 PM9/3/19
to jenkinsc...@googlegroups.com
Mark Waite edited a comment on Improvement JENKINS-59206


In this case, after merging, the tag {{v1.0}} is now on both branch-1.x and on master.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 3, 2019, 3:19:01 PM9/3/19
to jenkinsc...@googlegroups.com

In declarative Pipeline, there is the condition (see Pipeline syntax)

when buildingTag

A stage with that directive will only be built when a tag is being built.

I suspect something similar could be done with scripted Pipeline, checking for the existence or non-existence of the environment variable TAG_NAME.

I don't know of a way to do anything like that in Freestyle, Maven, or Matrix job types.

michaelperzel@gmail.com (JIRA)

unread,
Sep 4, 2019, 12:40:01 PM9/4/19
to jenkinsc...@googlegroups.com

Thanks, that's exactly what i need.

 

I do think it's unclear why git_branch is set to the the tag name but I no longer have a need for this environment variable.

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 4, 2019, 12:42:02 PM9/4/19
to jenkinsc...@googlegroups.com
Change By: Mark Waite
Status: Open Fixed but Unreleased
Resolution: Not A Defect

mark.earl.waite@gmail.com (JIRA)

unread,
Sep 4, 2019, 12:42:03 PM9/4/19
to jenkinsc...@googlegroups.com
Change By: Mark Waite
Status: Fixed but Unreleased Closed
Reply all
Reply to author
Forward
0 new messages