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

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

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None

      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.

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

          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

          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

          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.

          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 .

          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 ?

          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 ?

          Fredric Lonngren added a comment - - edited

          Attaching example of regression in tag-trigging.

          Fredric Lonngren added a comment - - edited Attaching example of regression in tag-trigging.

          jbq added a comment -

          jbq added a comment - https://github.com/jenkinsci/git-plugin/pull/340

          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?

          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?

          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.

          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.

          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.

          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.

            Unassigned Unassigned
            clubby2010 Oliver Bee
            Votes:
            15 Vote for this issue
            Watchers:
            21 Start watching this issue

              Created:
              Updated: