• Icon: Bug Bug
    • Resolution: Not A Defect
    • Icon: Minor Minor
    • None
    • Jenkins 2.73.2, Git Plugin 3.6.0, Pipeline: Multibranch 2.16

      After upgrading to the Git Plugin 3.6.0 I activated the "Discover Tags" option in a Multibranch Pipeline Job. The tag is also discovered as expected, but no build is triggered.

       

      Checking tags... 
      Checking tag PNR-12345 
      ‘Jenkinsfile’ found 
      Met criteria 
      Changes detected: PNR-12345 (null → d56c6578f5f04403f4bd64bf2647f3dd0f36e826) 
      No automatic builds for PNR-12345
       Processed 1 tags
      

      I expected that a new build is triggered, when a new tag is found. How to achieve this?

       

          [JENKINS-47496] No automatic builds for tags

          stephenconnolly thanks for that plug-in; it's exactly what I needed. No more needing checkboxes in my job asking "Do you really mean it?"

          Aaron D. Marasco added a comment - stephenconnolly thanks for that plug-in; it's exactly what I needed. No more needing checkboxes in my job asking "Do you really mean it?"

          Raphael Reitzig added a comment - - edited

          stephenconnolly, this (non-)behaviour is quite confusing and I find your chain of reasoning unconvincing.

          You could have a build storm if you have 200 tags, they all get discovered and queued for building...

          So? The same happens with branches by default. I have to cancel all builds on old branches manually. Not even the build strategies plugin allows me to suppress builds on stale branches.
          (Maybe it's bad style to have lots of stale branches, but whether they are around in any given project is for none of us to decide.)

          Anyway, this only happens once (after creating the project). The age restriction implemented in the build strategies plugin effectively prevents a "build storm"; why not integrate that functionality into the core?

          and your tags are set up to deploy to production because they are tags...

          That's quite the assumption. The pipeline may do nothing of the kind.

          and jenkins does not guarantee the order in which the tags will be discovered or actually executed...

          If the order matters, the pipeline author needs to take care of undesired effects, anyway.

          you have to explicitly configure it

          Without the build strategies plugin, how do you even do so?

          You seem to have a certain set of use cases in mind, which kind of contradicts how Jenkins (as a whole) is advertised as a general-purpose tool. While that's certainly your prerogative as an open-source maintainer , but you should maybe consider whether your perspective covers as many of your users as you'd like.

          Raphael Reitzig added a comment - - edited stephenconnolly , this (non-)behaviour is quite confusing and I find your chain of reasoning unconvincing. You could have a build storm if you have 200 tags, they all get discovered and queued for building... So? The same happens with branches by default . I have to cancel all builds on old branches manually. Not even the build strategies plugin allows me to suppress builds on stale branches. (Maybe it's bad style to have lots of stale branches, but whether they are around in any given project is for none of us to decide.) Anyway, this only happens once (after creating the project). The age restriction implemented in the build strategies plugin effectively prevents a "build storm"; why not integrate that functionality into the core? and your tags are set up to deploy to production because they are tags... That's quite the assumption. The pipeline may do nothing of the kind. and jenkins does not guarantee the order in which the tags will be discovered or actually executed... If the order matters, the pipeline author needs to take care of undesired effects, anyway. you have to explicitly configure it Without the build strategies plugin, how do you even do so? You seem to have a certain set of use cases in mind, which kind of contradicts how Jenkins (as a whole) is advertised as a general-purpose tool. While that's certainly your prerogative as an open-source maintainer , but you should maybe consider whether your perspective covers as many of your users as you'd like.

          Mark F added a comment -

          Here is the workaround to add tag discovery for multibranch pipelines in JobDSL:

           multibranchPipelineJob('my_repo') {
              branchSources { branchSource { source { git {
                      remote(git_url)
                      credentialsId('my_credential_id')
                      traits {
                          gitBranchDiscovery()
                          gitTagDiscovery()  // be careful you don't create a build storm!
                          headWildcardFilter {
                              includes('my_branch1 my_branches* my_tags* )
                              excludes('')
                          }
                      }
              } } } }
              ...
          }
          

          Mark F added a comment - Here is the workaround to add tag discovery for multibranch pipelines in JobDSL: multibranchPipelineJob( 'my_repo' ) { branchSources { branchSource { source { git { remote(git_url) credentialsId( 'my_credential_id' ) traits { gitBranchDiscovery() gitTagDiscovery() // be careful you don't create a build storm! headWildcardFilter { includes('my_branch1 my_branches* my_tags* ) excludes('') } } } } } } ... }

          Jay Ache added a comment - - edited

          I found that adding a Basic Branch Build Strategy to automatically build tags interfered with the rest of the multibranch pipeline builds automatically triggered by GitHub. They were working fine, then I added a Basic Branch Build Strategy to automatically build a tag, added a new tag, the new tag was automatically discovered and it attempted to build it (but failed with a NullPtrException; I had to manually schedule the tag build again before it successfully built, but that's an unrelated issue, probably because of this: https://issues.jenkins-ci.org/browse/JENKINS-50715). However, subsequent pushes to branches didn't re-trigger builds as expected. Simply removing the Basic Branch Build Strategy fixed it, and builds/pull-requests were again automatically built whenever pushes happened.

           

          I'll try Mark F's JobDSL workaround next.

          Jay Ache added a comment - - edited I found that adding a Basic Branch Build Strategy to automatically build tags interfered with the rest of the multibranch pipeline builds automatically triggered by GitHub. They were working fine, then I added a Basic Branch Build Strategy to automatically build a tag, added a new tag, the new tag was automatically discovered and it attempted to build it (but failed with a NullPtrException; I had to manually schedule the tag build again before it successfully built, but that's an unrelated issue, probably because of this: https://issues.jenkins-ci.org/browse/JENKINS-50715 ). However, subsequent pushes to branches didn't re-trigger builds as expected. Simply removing the Basic Branch Build Strategy fixed it, and builds/pull-requests were again automatically built whenever pushes happened.   I'll try Mark F's JobDSL workaround next.

          vinoth SS added a comment -

          I found some issue on Build strategy plugin for tags, 

          if i specify Ignore tags newer than to 1 days, no automated builds are triggering, if i specify only 7 days builds are triggering, can we have that restriction to 1 day as well. so that automated builds will trigger only for tags which created less than 1 day.

           

          vinoth SS added a comment - I found some issue on Build strategy plugin for tags,  if i specify Ignore tags newer than to 1 days, no automated builds are triggering, if i specify only 7 days builds are triggering, can we have that restriction to 1 day as well. so that automated builds will trigger only for tags which created less than 1 day.  

          Liam Newman added a comment -

          ss_vinoth22
          Please open a new JIRA for that.

          Liam Newman added a comment - ss_vinoth22 Please open a new JIRA for that.

          vinoth SS added a comment -

          Sure, thanks i have opened up the ticket : https://issues.jenkins-ci.org/browse/JENKINS-57772

          vinoth SS added a comment - Sure, thanks i have opened up the ticket :  https://issues.jenkins-ci.org/browse/JENKINS-57772

          stephenconnolly rtyler

          This article clearly states that if we add "Discover tags" to multibranch pipeline, Jenkins will trigger builds when tags are pushed into repo. But this bug ( JENKINS-47496 ) says that tags are not supposed to trigger a build automatically. Could you please decide somehow which one of you is right?

          As a Jenkins user, I +1 for tag triggering. We want to use this to build/publish releases whenever Git tag is created. This is the way all other major CI systems work: Travis CI, CircleCI, AppVeyour.

          Marat Radchenko added a comment - stephenconnolly rtyler This article clearly states that if we add "Discover tags" to multibranch pipeline, Jenkins will trigger builds when tags are pushed into repo. But this bug ( JENKINS-47496 ) says that tags are not supposed to trigger a build automatically. Could you please decide somehow which one of you is right? As a Jenkins user, I +1 for tag triggering. We want to use this to build/publish releases whenever Git tag is created. This is the way all other major CI systems work: Travis CI, CircleCI, AppVeyour.

          Liam Newman added a comment -

          slonopotamusorama

          Please use the Basic Branch Build Strategies plugin.

          Liam Newman added a comment - slonopotamusorama Please use the Basic Branch Build Strategies plugin.

          stephenconnolly the are usecases where building all the tags in a random order (build storm) is not a problem.

          Indeed, if the pipeline build an artefact which is published in an artefact repository like nexus, there are no problem (except may be the extra workload for jenkins). If the tags is already built (already present in the artefact repository), the pipeline will fail as expected, and if the tag has never been built, the pipeline will succeed as expected.

          So adding this behaviour in the multibranch pipeline makes sense for me (with any warnings you want about the potential risks)

          Best regards,

          Manuel

          manuel boillod added a comment - stephenconnolly the are usecases where building all the tags in a random order (build storm) is not a problem. Indeed, if the pipeline build an artefact which is published in an artefact repository like nexus, there are no problem (except may be the extra workload for jenkins). If the tags is already built (already present in the artefact repository), the pipeline will fail as expected, and if the tag has never been built, the pipeline will succeed as expected. So adding this behaviour in the multibranch pipeline makes sense for me (with any warnings you want about the potential risks) Best regards, Manuel

            markewaite Mark Waite
            pmr Philipp Moeller
            Votes:
            0 Vote for this issue
            Watchers:
            15 Start watching this issue

              Created:
              Updated:
              Resolved: