[JIRA] (JENKINS-14917) Build is not triggered for new tag (without new commit)

1 view
Skip to first unread message

jbq@caraldi.com (JIRA)

unread,
Mar 8, 2017, 10:20:37 AM3/8/17
to jenkinsc...@googlegroups.com
jbq resolved as Fixed
 

https://github.com/jenkinsci/git-plugin/pull/340

Jenkins / Bug JENKINS-14917
Build is not triggered for new tag (without new commit)
Change By: jbq
Status: Open Resolved
Assignee: Nicolas De Loof jbq
Resolution: Fixed
Add Comment Add Comment
 
This message was sent by Atlassian JIRA (v7.3.0#73011-sha1:3c73d0e)
Atlassian logo

g.josquin+jenkins@gmail.com (JIRA)

unread,
Jun 12, 2018, 6:17:03 AM6/12/18
to jenkinsc...@googlegroups.com
Guido Josquin reopened an issue
 

This is still not working for me, so I am reopening the issue.

Description:

https://stackoverflow.com/questions/50778526/trigger-a-jenkins-pipeline-by-tagging-an-existing-commit

Change By: Guido Josquin
Resolution: Fixed
Status: Resolved Reopened
Assignee: jbq

g.josquin+jenkins@gmail.com (JIRA)

unread,
Jun 18, 2018, 8:35:02 AM6/18/18
to jenkinsc...@googlegroups.com
This is still not working for me, so I am reopening the issue.

Description:

[ https://stackoverflow.com/questions/50778526/trigger-a-jenkins-pipeline-by-tagging-an-existing-commit ]

 

Perhaps you might be able to help, [~jbq] - is tag-triggered building currently supported?

jbq@caraldi.com (JIRA)

unread,
Jun 18, 2018, 8:59:02 AM6/18/18
to jenkinsc...@googlegroups.com
jbq commented on Bug JENKINS-14917

Hi Guido, I made my work, reviewed, tested and pushed the proposed changes on march 2017.  Now there it is likely that a regression has popped in since then.  Unfortunately I'm not working on Jenkins ATM and can't offer help on this.

andy.goldstein@gmail.com (JIRA)

unread,
Aug 15, 2018, 12:07:05 PM8/15/18
to jenkinsc...@googlegroups.com

As best I can determine, the git plugin filters out "non-tip" revisions, leading to this situation. For example, imagine this flow:

  1. Push to master, commit d0253f44158313c249a7db9892f984fd0e8596b2
  2. Jenkins builds that branch/commit
  3. Tag master as v1.2.3, which becomes commit 8f0a0c31a89b6a594eeb1e8db6a2fcc4e1923890
  4. Jenkins shows the following (if you enable verbose git output)

After branch filtering: [Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master), Revision 8f0a0c31a89b6a594eeb1e8db6a2fcc4e1923890 (origin/tags/v1.2.3)]
After non-tip filtering: [Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master)]
Removing what's already been built: {origin/master=Build #5 of Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master)}
After filtering out what's already been built: []
Nothing seems worth building, so falling back to the previously built revision: Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master)
The only way I can think of to build branches vs tags is to have separate jobs for each, which isn't ideal.

This message was sent by Atlassian JIRA (v7.10.1#710002-sha1:6efc396)

andy.goldstein@gmail.com (JIRA)

unread,
Aug 15, 2018, 12:07:06 PM8/15/18
to jenkinsc...@googlegroups.com
Andy Goldstein edited a comment on Bug JENKINS-14917
As best I can determine, the git plugin filters out "non-tip" revisions, leading to this situation. For example, imagine this flow:
# Push to master, commit d0253f44158313c249a7db9892f984fd0e8596b2
# Jenkins builds that branch/commit
# Tag master as v1.2.3, which becomes commit 8f0a0c31a89b6a594eeb1e8db6a2fcc4e1923890
# Jenkins shows the following (if you enable verbose git output)

{{ After branch filtering: [Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master), Revision 8f0a0c31a89b6a594eeb1e8db6a2fcc4e1923890 (origin/tags/v1.2.3)] }}
{{ After non-tip filtering: [Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master)] }}
{{ Removing what's already been built: \{origin/master=Build #5 of Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master)} }}
{{ After filtering out what's already been built: [] }}
{{ Nothing seems worth building, so falling back to the previously built revision: Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master) }}


The only way I can think of to build branches vs tags is to have separate jobs for each, which isn't ideal.

andy.goldstein@gmail.com (JIRA)

unread,
Aug 15, 2018, 12:08:02 PM8/15/18
to jenkinsc...@googlegroups.com
Andy Goldstein edited a comment on Bug JENKINS-14917
As best I can determine, the git plugin filters out "non-tip" revisions, leading to this situation. For example, imagine this flow:
# Push to master, commit d0253f44158313c249a7db9892f984fd0e8596b2
# Jenkins builds that branch/commit
# Tag master as v1.2.3, which becomes commit 8f0a0c31a89b6a594eeb1e8db6a2fcc4e1923890
# Jenkins shows the following (if you enable verbose git output)

{ { noformat}
After branch filtering: [Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master), Revision 8f0a0c31a89b6a594eeb1e8db6a2fcc4e1923890 (origin/tags/v1.2.3)] }}
{{ After non-tip filtering: [Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master)]}}
{{ Removing what's already been built:
\
{origin/master=Build #5 of Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master)}}}

{{ After filtering out what's already been built: []}}
{{ Nothing seems worth building, so falling back to the previously built revision: Revision d0253f44158313c249a7db9892f984fd0e8596b2 (origin/master)}} {noformat}


The only way I can think of to build branches vs tags is to have separate jobs for each, which isn't ideal.

andy.goldstein@gmail.com (JIRA)

unread,
Aug 15, 2018, 12:09:02 PM8/15/18
to jenkinsc...@googlegroups.com

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

unread,
Jan 13, 2020, 7:48:10 PM1/13/20
to jenkinsc...@googlegroups.com
Change By: Mark Waite
Status: Reopened Open
This message was sent by Atlassian Jira (v7.13.6#713006-sha1:cc4451f)
Atlassian logo
Reply all
Reply to author
Forward
0 new messages