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)

          Oliver Bee created issue -

          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
          Dell Green made changes -
          Status Original: Open [ 1 ] New: In Progress [ 3 ]

          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 .
          Sebastian Schuberth made changes -
          Link New: This issue is duplicated by JENKINS-17898 [ JENKINS-17898 ]

          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.
          Fredric Lonngren made changes -
          Attachment New: Jenkins-tag-trigger-bug.pdf [ 25721 ]
          Mark Waite made changes -
          Status Original: In Progress [ 3 ] New: Open [ 1 ]
          R. Tyler Croy made changes -
          Workflow Original: JNJira [ 145618 ] New: JNJira + In-Review [ 176410 ]

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

              Created:
              Updated: