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

No automatic builds for tags

    XMLWordPrintable

Details

    • Bug
    • Status: Closed (View Workflow)
    • Minor
    • Resolution: Not A Defect
    • None
    • Jenkins 2.73.2, Git Plugin 3.6.0, Pipeline: Multibranch 2.16

    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

            Tags are not built by default (because otherwise you could have a build storm when checking out a repository) and worse, the order tags will be built in is unpredictable... and you might have a Jenkinsfile that deploys to production when a tag is built.

            There is an extension point in branch-api called BranchBuildStrategy which - if implemented - will allow deciding whether to build tags.

            See https://github.com/jenkinsci/github-branch-source-plugin/pull/158#issuecomment-332773194 for starting point on how to create such an extension plugin... I believe there is some work on one at https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin

            stephenconnolly Stephen Connolly added a comment - Tags are not built by default (because otherwise you could have a build storm when checking out a repository) and worse, the order tags will be built in is unpredictable... and you might have a Jenkinsfile that deploys to production when a tag is built. There is an extension point in branch-api called BranchBuildStrategy which - if implemented - will allow deciding whether to build tags. See https://github.com/jenkinsci/github-branch-source-plugin/pull/158#issuecomment-332773194 for starting point on how to create such an extension plugin... I believe there is some work on one at https://github.com/AngryBytes/jenkins-build-everything-strategy-plugin

            Functioning as designed

            stephenconnolly Stephen Connolly added a comment - Functioning as designed

            you could have a build storm when checking out a repository

            I don't get this. What do you mean? I'm quite surprised by this design decision, other CI system build tags automatically and I never had any problems with it.

            Checking out the repository where could have a build storm?

            lucasocio Leandro Lucarella added a comment - you could have a build storm when checking out a repository I don't get this. What do you mean? I'm quite surprised by this design decision, other CI system build tags automatically and I never had any problems with it. Checking out the repository where could have a build storm?

            You could have a build storm if you have 200 tags, they all get discovered and queued for building... and your tags are set up to deploy to production because they are tags... and jenkins does not guarantee the order in which the tags will be discovered or actually executed... so production is constantly cycling different versions.

             

            In any case, if you want to build tags just install the Basic Branch Build Strategies plugin and configure it: https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/docs/user.adoc#tags

            stephenconnolly Stephen Connolly added a comment - You could have a build storm if you have 200 tags, they all get discovered and queued for building... and your tags are set up to deploy to production because they are tags... and jenkins does not guarantee the order in which the tags will be discovered or actually executed... so production is constantly cycling different versions.   In any case, if you want to build tags just install the Basic Branch Build Strategies plugin and configure it:  https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/docs/user.adoc#tags

            You could have a build storm if you have 200 tags, they all get discovered and queued for building... and your tags are set up to deploy to production because they are tags... and jenkins does not guarantee the order in which the tags will be discovered or actually executed... so production is constantly cycling different versions.

            That is stupid. Why the person who is responsible for configuration cannot decide about this? There could be simple checkbox (unchecked by default) with message: "Trigger build as well" and additionally funcionallity from 'Basic Branch Build Stratiegies' could be copy over. I'm talking about tags being older then X days and so on.

            sobi3ch Piotr Sobieszczański added a comment - You could have a build storm if you have 200 tags, they all get discovered and queued for building... and your tags are set up to deploy to production because they are tags... and jenkins does not guarantee the order in which the tags will be discovered or actually executed... so production is constantly cycling different versions. That is stupid. Why the person who is responsible for configuration cannot decide about this? There could be simple checkbox (unchecked by default) with message: "Trigger build as well" and additionally funcionallity from 'Basic Branch Build Stratiegies' could be copy over. I'm talking about tags being older then X days and so on.

            sobi3ch So first off we have the Jenkins Queue.

            The queue does not know about multibranch as belonging to a single "project" so instead it sees them all as different jobs. The queue is designed to care about the order within a job but not the order between jobs.

            Each tag gets its own job, thus the tag v1 could be built after the tag v5 even if v1 was put in the queue before v5... there is nothing to do with multibranch, you can get the same effect with regular freestyle jobs

            Next, the tag discovery is not in a deterministic order from git.

            Simple tags do not even have a creation timestamp in the git data model

            Annotated tags do have a creation timestamp, but that does not reflect the push time

            So we have no way to reconstruct the order of simple tags, and we only have a way to reconstruct the creation order of annotated tags... that is not the actual release (i.e. push to canonical repo) order

            Ok, so you might say "well sort the tags"... hmmm except sorting version numbers is a hard problem... does where does RC go w.r.t. alpha, beta, milestone, etc. There are some widely held conventions... but nothing that is a hard and fast rule.

            Finally, if you really want them built on discovery, it's an extension point you can write a plugin that does exactly that and install it... then just configure that option in the build strategies... I just choose not to enable users to easily shoot themselves in the foot... I do not prevent the foot shootings

            stephenconnolly Stephen Connolly added a comment - sobi3ch So first off we have the Jenkins Queue. The queue does not know about multibranch as belonging to a single "project" so instead it sees them all as different jobs. The queue is designed to care about the order within a job but not the order between jobs. Each tag gets its own job, thus the tag v1 could be built after the tag v5 even if v1 was put in the queue before v5 ... there is nothing to do with multibranch, you can get the same effect with regular freestyle jobs Next, the tag discovery is not in a deterministic order from git. Simple tags do not even have a creation timestamp in the git data model Annotated tags do have a creation timestamp, but that does not reflect the push time So we have no way to reconstruct the order of simple tags, and we only have a way to reconstruct the creation order of annotated tags... that is not the actual release (i.e. push to canonical repo) order Ok, so you might say "well sort the tags"... hmmm except sorting version numbers is a hard problem... does where does RC go w.r.t. alpha, beta, milestone, etc. There are some widely held conventions... but nothing that is a hard and fast rule. Finally, if you really want them built on discovery, it's an extension point you can write a plugin that does exactly that and install it... then just configure that option in the build strategies... I just choose not to enable users to easily shoot themselves in the foot... I do not prevent the foot shootings

            Seriously, all you need to do is copy one class and change the logic for automatic build to return head instanceof TagSCMHead; (cf https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/src/main/java/jenkins/branch/buildstrategies/basic/BranchBuildStrategyImpl.java#L55-L64) and then you can shoot your own foot off.

            I will not be adding such an implementation into any plugin I maintain (because I do not want to hear the howls of users on the receiving end of self-foot-shootings) but feel free to roll your own and release it as a plugin to the community (as long as you support the users with the shot feet)

            stephenconnolly Stephen Connolly added a comment - Seriously, all you need to do is copy one class and change the logic for automatic build to return head instanceof TagSCMHead; (cf https://github.com/jenkinsci/basic-branch-build-strategies-plugin/blob/master/src/main/java/jenkins/branch/buildstrategies/basic/BranchBuildStrategyImpl.java#L55-L64 ) and then you can shoot your own foot off. I will not be adding such an implementation into any plugin I maintain (because I do not want to hear the howls of users on the receiving end of self-foot-shootings) but feel free to roll your own and release it as a plugin to the community (as long as you support the users with the shot feet)

            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.

            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.

            sobi3ch 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

            stephenconnolly Stephen Connolly added a comment - sobi3ch 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

            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?"

            aarondmarasco_vsi 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?"
            reitzig 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.

            reitzig 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.
            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('')
                            }
                        }
                } } } }
                ...
            }
            
            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('') } } } } } } ... }
            jayache80 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.

            jayache80 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.
            ss_vinoth22 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.

             

            ss_vinoth22 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.  
            bitwiseman Liam Newman added a comment -

            ss_vinoth22
            Please open a new JIRA for that.

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

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

            ss_vinoth22 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.

            slonopotamusorama 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.
            bitwiseman Liam Newman added a comment -

            slonopotamusorama

            Please use the Basic Branch Build Strategies plugin.

            bitwiseman 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

            mboillod 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

            People

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

              Dates

                Created:
                Updated:
                Resolved: