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

Multibranch pipeline still showing Git tags older than configured threshold

      I've got some Multibranch pipeline jobs configured to use a Git repository, together with "Build strategies" -> "Any Strategies Match" -> "Any of" -> "Tags" -> "Ignore tags older than" -> 7. But when looking at the "Tags" tab of those jobs, they still show (subjobs for) tags that are way older than 7 days.

      Configuring the same for branches works just fine.

          [JENKINS-64810] Multibranch pipeline still showing Git tags older than configured threshold

          OK, maybe I need to clarify further. I'm referring to tags that have actually been built. As opposed to branches, tags will most likely not go away again, so a multibranch pipeline collects subjobs for all the tags it has ever built. My request is that jobs for those tags that would now be ignored because of their age be removed again.

          Dirk Heinrichs added a comment - OK, maybe I need to clarify further. I'm referring to tags that have actually been built. As opposed to branches, tags will most likely not go away again, so a multibranch pipeline collects subjobs for all the tags it has ever built. My request is that jobs for those tags that would now be ignored because of their age be removed again.

          Another two months have passed and we're still collecting endless numbers of tag subjobs per multibranch pipeline. Any news here?

          Dirk Heinrichs added a comment - Another two months have passed and we're still collecting endless numbers of tag subjobs per multibranch pipeline. Any news here?

          Hello! Can I ask you if there is any news about this ticket? Or if anyone that commented here has found an alternative solution? I have a repo with many many tags and the scan of it is causing a lot of pain at the moment. Thank you in advance!

          Alessandro Baldi Vitali added a comment - Hello! Can I ask you if there is any news about this ticket? Or if anyone that commented here has found an alternative solution? I have a repo with many many tags and the scan of it is causing a lot of pain at the moment. Thank you in advance!

          Maybe I should raise the prio...

          Dirk Heinrichs added a comment - Maybe I should raise the prio...

          Kalle Niemitalo added a comment - Bitbucket Aged References SCM Filter or GitHub Aged References SCM Filter may be suitable. I have not tried them.

          FIrst, thank you for the answer! Second, unfortunately I'm trying it now and it doesn't look to do anything useful. I just setup a threshold of 30 days and did a couple of scans. It always fetches all the tags querying with a high rate the Bitbucket APIs. 

          Alessandro Baldi Vitali added a comment - FIrst, thank you for the answer! Second, unfortunately I'm trying it now and it doesn't look to do anything useful. I just setup a threshold of 30 days and did a couple of scans. It always fetches all the tags querying with a high rate the Bitbucket APIs. 

          liangqi added a comment -

          It seems this ticket got left out again..

          liangqi added a comment - It seems this ticket got left out again..

          Daniel added a comment -

          Does this ticket need to be re-created to get attention?  I think the title and description are looking for one thing but the feature mentioned is doing something else. 

          is my interpretation right?

          • the feature mentioned will automatically build or not depending on age of the tag
          • we want to only see the x most recent tags, since an active repo will quickly have many and tags aren’t usually ever cleaned up

          I hope I’m not derailing if my use case goes a step farther: I would use this for releases but tags can be anything. I want to only show the last x tags matching my pattern for release tags

          Daniel added a comment - Does this ticket need to be re-created to get attention?  I think the title and description are looking for one thing but the feature mentioned is doing something else.  is my interpretation right? the feature mentioned will automatically build or not depending on age of the tag we want to only see the x most recent tags, since an active repo will quickly have many and tags aren’t usually ever cleaned up I hope I’m not derailing if my use case goes a step farther: I would use this for releases but tags can be anything. I want to only show the last x tags matching my pattern for release tags

          Mark Waite added a comment -

          wgc1929 I don't think that recreating the issue will give it any more attention. Unless the recreated issue is significantly different than this issue, then the recreated issue will be resolved as a duplicate of this issue.

          The description of this issue says:

          when looking at the "Tags" tab of those jobs, they still show (subjobs for) tags that are way older than 7 days.

          The later discussions in the thread seem to align with that phrase. They want to remove tags from the list of jobs if they are older than a threshold. When a tag is removed from the list, it won't be built.

          In terms of getting attention, the most effective way for an enhancement to get attention is for someone to implement the enhancement, test it for their own use, then submit it as a pull request. Others can then test the pull request as well and report their experiences with the incremental build of the pull request.

          I'm happy to have users express their interest in a feature, but that doesn't get us any closer to an implementation of the feature.

          Mark Waite added a comment - wgc1929 I don't think that recreating the issue will give it any more attention. Unless the recreated issue is significantly different than this issue, then the recreated issue will be resolved as a duplicate of this issue. The description of this issue says: when looking at the "Tags" tab of those jobs, they still show (subjobs for) tags that are way older than 7 days. The later discussions in the thread seem to align with that phrase. They want to remove tags from the list of jobs if they are older than a threshold. When a tag is removed from the list, it won't be built. In terms of getting attention, the most effective way for an enhancement to get attention is for someone to implement the enhancement, test it for their own use, then submit it as a pull request. Others can then test the pull request as well and report their experiences with the incremental build of the pull request. I'm happy to have users express their interest in a feature, but that doesn't get us any closer to an implementation of the feature.

          Daniel added a comment - - edited

          Sorry, I saw this comment too late ....

          With my understanding of the goal, I believe this is filed against the wrong component so unlikely to be addressed.  I use gitlab so GitHub Aged References SCM Filter is not relevant, and I see other discovery features implemented in gitlab-branch-source-plugin, see JENKINS-73165.  If they're duplicates, feel free to close whichever is miscategorized or has least context

           

          Daniel added a comment - - edited Sorry, I saw this comment too late .... With my understanding of the goal, I believe this is filed against the wrong component so unlikely to be addressed.  I use gitlab so GitHub Aged References SCM Filter is not relevant, and I see other discovery features implemented in gitlab-branch-source-plugin , see JENKINS-73165 .  If they're duplicates, feel free to close whichever is miscategorized or has least context  

            Unassigned Unassigned
            dhs Dirk Heinrichs
            Votes:
            6 Vote for this issue
            Watchers:
            11 Start watching this issue

              Created:
              Updated: