Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-14917

Build is not triggered for new tag (without new commit)

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Reopened (View Workflow)
    • Priority: Major
    • Resolution: Unresolved
    • Component/s: git-plugin
    • Labels:
      None
    • Similar Issues:

      Description

      In our company we have always 2 build jobs for each project. One job is working on the HEAD of the repository to trigger e-mails on broken builds and the second job is to publish released versions(tags).

      The second job is just checking the repository for tags and publishs the tag builds to the QM department. I have setup this job to watch nightly to the repository and start the job if there is something new. If there is a new commit (+ tag) in the repo, everything works fine. But if there is only a new tag (on a commit which was already built), the job is not started automatically (but only for the next commit).

      I tried to setup the refspec to "+refs/heads/:refs/remotes/origin/" or "+refs/heads/:refs/remotes/origin/" but both doesn't work.

      Steps to reproduce:
      1. set built-trigger to request version control at: * * * * * (to trigger each minute)
      2. in git: commit, create a tag, push -> built is started within the next minute -> OK
      3. in git: create a tag (on last commit), push -> built is not triggered (expected result: build job should start within the next minute) -> not OK

      I'm not sure if this is a bug or something wrong in my configuration.

        Attachments

          Issue Links

            Activity

            Hide
            gandalf Dell Green added a comment -

            I have the same problem, i need the creation of a new tag with no new commit to also trigger a build as the tag is built into my artifacts as part of the release

            Show
            gandalf Dell Green added a comment - I have the same problem, i need the creation of a new tag with no new commit to also trigger a build as the tag is built into my artifacts as part of the release
            Hide
            sschuberth Sebastian Schuberth added a comment -

            I'd rather say this is a missing feature instead of a bug. In fact, even if setting up the refspec worked that way, it would also trigger builds if some long past commit was tagged that precedes an existing tag in history. But what you usually want is to trigger a build if a new most recent tag with a certain name pattern appears on some branch. The bad news is that "git tag --list" lists tags alphabetically, not in (reverse) chronological order. The good news is that you can use "git log --tags" in conjunction with a special trigger job to achieve the desired effect. I've outlined the details of this approach as part of this answer on StackOverflow.

            Show
            sschuberth Sebastian Schuberth added a comment - I'd rather say this is a missing feature instead of a bug. In fact, even if setting up the refspec worked that way, it would also trigger builds if some long past commit was tagged that precedes an existing tag in history. But what you usually want is to trigger a build if a new most recent tag with a certain name pattern appears on some branch. The bad news is that "git tag --list" lists tags alphabetically, not in (reverse) chronological order. The good news is that you can use "git log --tags" in conjunction with a special trigger job to achieve the desired effect. I've outlined the details of this approach as part of this answer on StackOverflow .
            Hide
            efredlo Fredric Lonngren added a comment -

            This is actually possible (or rather was, it has regressed now) by setting up a job refering to refs/tags.
            We have special "ReadyForIntegration" tags "RFI_whatever" that we use to kick some of our system integration pipelines in Jenkins:

            Refspec: +refs/tags/RFI_foo_clients/:refs/remotes/origin/tags/RFI_foo_clients/
            Branch specifier: /tags/RFI_foo_clients/*

            that let the teams set tags like "RFI_foo_clients/R16/drop_1.0" and the integration-jobs distributes them according to the name-spaces in the tag.
            If you trigg in refs/tags each annotated tag is it's own reference so each should build using the tag-reference, even if they dereference to the same commit. This used to work up until recently when only the first tag on a commit builds.
            I'm attaching Jenkins-tag-trigger-bug.pdf with background-data from one of our jobs with four commits (of total 33) that has double tags on them, where two earlier works and the two later ones does not.
            It may be due to the same cause with wildcard branches in JENKINS-20767 ?

            Show
            efredlo Fredric Lonngren added a comment - This is actually possible (or rather was, it has regressed now) by setting up a job refering to refs/tags. We have special "ReadyForIntegration" tags "RFI_whatever" that we use to kick some of our system integration pipelines in Jenkins: Refspec: +refs/tags/RFI_foo_clients/ :refs/remotes/origin/tags/RFI_foo_clients/ Branch specifier: /tags/RFI_foo_clients/ * that let the teams set tags like "RFI_foo_clients/R16/drop_1.0" and the integration-jobs distributes them according to the name-spaces in the tag. If you trigg in refs/tags each annotated tag is it's own reference so each should build using the tag-reference, even if they dereference to the same commit. This used to work up until recently when only the first tag on a commit builds. I'm attaching Jenkins-tag-trigger-bug.pdf with background-data from one of our jobs with four commits (of total 33) that has double tags on them, where two earlier works and the two later ones does not. It may be due to the same cause with wildcard branches in JENKINS-20767 ?
            Hide
            efredlo Fredric Lonngren added a comment - - edited

            Attaching example of regression in tag-trigging.

            Show
            efredlo Fredric Lonngren added a comment - - edited Attaching example of regression in tag-trigging.
            Show
            jbq jbq added a comment - https://github.com/jenkinsci/git-plugin/pull/340
            Hide
            jodiug Guido Josquin added a comment - - edited

            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?

            Show
            jodiug Guido Josquin added a comment - - edited 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?
            Hide
            jbq jbq added a comment -

            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.

            Show
            jbq jbq added a comment - 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.
            Hide
            4mg0ldst79 Andy Goldstein added a comment - - edited

            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.

            Show
            4mg0ldst79 Andy Goldstein added a comment - - edited 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.

              People

              • Assignee:
                Unassigned
                Reporter:
                clubby2010 Oliver Bee
              • Votes:
                11 Vote for this issue
                Watchers:
                17 Start watching this issue

                Dates

                • Created:
                  Updated: