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

No automatic builds for tags

    XMLWordPrintable

    Details

    • Type: Bug
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Not A Defect
    • Labels:
      None
    • Environment:
      Jenkins 2.73.2, Git Plugin 3.6.0, Pipeline: Multibranch 2.16
    • Similar Issues:

      Description

      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?

       

        Attachments

          Issue Links

            Activity

            Hide
            sobi3ch Piotr Sobieszczański added a comment -

            Hi Stephen, I understand that tags are not built in order. That obvious. Because I don't care about tags in my project up to now (= until I implement my repository with Jenkins), they can build in whatever order they want (Ideal situation would be if I could mark checkbox with label saying "Do not run old tags, only new one". And yes I understand you can have thousands of tags already, but in real life, you set up repo and then you set up the project with your CI/CD, so you don't have at all, or maybe after some time with maximum several dozens). I just want to build new tags and as you know you don't create several tags per minute. Normally there is one, two maybe three tags per day and that's all. In this situation, you are totally fine with an automatic build. So for instance, you creating a new tag, pushing it to a repo, then Jenkins is detecting it (and this is the only new tag comparing to his repo), and finally triggering it. That's the whole idea.

            Show
            sobi3ch Piotr Sobieszczański added a comment - Hi Stephen, I understand that tags are not built in order. That obvious. Because I don't care about tags in my project up to now (= until I implement my repository with Jenkins), they can build in whatever order they want (Ideal situation would be if I could mark checkbox with label saying "Do not run old tags, only new one". And yes I understand you can have thousands of tags already, but in real life, you set up repo and then you set up the project with your CI/CD, so you don't have at all, or maybe after some time with maximum several dozens). I just want to build new tags and as you know you don't create several tags per minute. Normally there is one, two maybe three tags per day and that's all. In this situation, you are totally fine with an automatic build. So for instance, you creating a new tag, pushing it to a repo, then Jenkins is detecting it (and this is the only new tag comparing to his repo), and finally triggering it. That's the whole idea.
            Hide
            stephenconnolly Stephen Connolly added a comment -

            Piotr Sobieszczański I recommend that you create a plugin with the variation of https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/src/main/java/jenkins/branch/buildstrategies/basic/TagBuildStrategyImpl.java that you need (if the implementation that is already available does not do what you actually need).

            Seriously, how hard is it to install the Basic Branch Build Strategies plugin and then do?

            If you need something for building tags that is different from the one in Basic Branch Build Strategies then it is trivial to create your own.

            But it looks to me like you were not even reading my comments...

            Because I said over a month ago how to build tags automatically... just that it will not exactly meet everyone's requirements because there are cases where building tags could result in build storms and this is why you have to explicitly configure it and decide what risk of build storms you are willing to take

            Show
            stephenconnolly Stephen Connolly added a comment - Piotr Sobieszczański I recommend that you create a plugin with the variation of https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/src/main/java/jenkins/branch/buildstrategies/basic/TagBuildStrategyImpl.java that you need (if the implementation that is already available does not do what you actually need). Seriously, how hard is it to install the Basic Branch Build Strategies plugin and then do? If you need something for building tags that is different from the one in Basic Branch Build Strategies then it is trivial to create your own. But it looks to me like you were not even reading my comments... Because I said over a month ago how to build tags automatically... just that it will not exactly meet everyone's requirements because there are cases where building tags could result in build storms and this is why you have to explicitly configure it and decide what risk of build storms you are willing to take
            Hide
            aarondmarasco_vsi Aaron Marasco added a comment -

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

            Show
            aarondmarasco_vsi Aaron Marasco added a comment - Stephen Connolly thanks for that plug-in; it's exactly what I needed. No more needing checkboxes in my job asking "Do you really mean it?"
            Hide
            reitzig Raphael Reitzig added a comment - - edited

            Stephen Connolly, 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.

            Show
            reitzig Raphael Reitzig added a comment - - edited Stephen Connolly , 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.
            Hide
            gnomeza 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('')
                            }
                        }
                } } } }
                ...
            }
            
            Show
            gnomeza 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('') } } } } } } ... }

              People

              • Assignee:
                markewaite Mark Waite
                Reporter:
                pmr Philipp Moeller
              • Votes:
                0 Vote for this issue
                Watchers:
                7 Start watching this issue

                Dates

                • Created:
                  Updated:
                  Resolved: