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

Tag match filter shows more entries than direct command (git tag -l "$tagFilter")

    XMLWordPrintable

    Details

    • Type: Improvement
    • Status: Resolved (View Workflow)
    • Priority: Minor
    • Resolution: Fixed
    • Component/s: git-parameter-plugin
    • Labels:
      None
    • Environment:
      OS: Ubuntu 16.04.5 LTS
      Jenkins version: 2.150.1
      Git parameter plugin: 0.9.6
      git command line version: 2.7.4
    • Similar Issues:

      Description

      The help documentation indicates that tag filtering should behave like:
           git tag -l "$tagFilter"

      However, we see different tag lists for the command line git filter versus the plugin filter.

      Example:

      • Git Command:      git tag -l "MTRS-MBP-*"
        • Returns (truncated):
          MTRS-MBP-v02.02.00.RRC05
      • Plugin Filter:         MTRS-MBP-*
        • Returns (truncated):
          MTRS-MBP-v02.02.00.RRC05
          release/MTRS-MBP-v00.03.01.int.1.0.0.2_armhf

      The plugin appears to behave as though "*MTRS-MBP-*" is implied.
      Yet, we have other entries, like "CDR_MTRS-MBP-v01.00.00_Demo", that the plugin does not show.

      The expectation here is that the behavior of the filter follows the stated 'git tag -l' behavior.

       

        Attachments

          Issue Links

            Activity

            kbowen Kevin Bowen created issue -
            kbowen Kevin Bowen made changes -
            Field Original Value New Value
            Description The help documentation indicates that tag filtering should behave like:
                 {{git tag -l "$tagFilter"}}

            However, we see different tag lists for the command line git filter versus the plugin filter.

            Example:
             * Git Command:      git tag -l "MTRS-MBP-*"

             ** _Returns (truncated):_
            MTRS-MBP-v02.02.00.RRC05
             * Plugin Filter:         MTRS-MBP-*
             ** _Returns (truncated):_
            MTRS-MBP-v02.02.00.RRC05
            release/MTRS-MBP-v00.03.01.int.1.0.0.2_armhf

            The plugin appears to behave as though "*MTRS-MBP-*" is implied.
            Yet, we have other entries, like "CDR_MTRS-MBP-v01.00.00_Demo", that the plugin does not show.

            The expectation here is that the behavior of the filter follows the stated 'git tag -l' behavior.

             
            The help documentation indicates that tag filtering should behave like:
                  {{git tag -l "$tagFilter"}}

            However, we see different tag lists for the command line git filter versus the plugin filter.

            Example:
             * Git Command:      git tag -l "MTRS-MBP-*"
             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05

             * Plugin Filter:         MTRS-MBP-*

             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05
             release/MTRS-MBP-v00.03.01.int.1.0.0.2_armhf

            The plugin appears to behave as though "*MTRS-MBP-*" is implied.
             Yet, we have other entries, like "CDR_MTRS-MBP-v01.00.00_Demo", that the plugin does not show.

            The expectation here is that the behavior of the filter follows the stated 'git tag -l' behavior.

             
            kbowen Kevin Bowen made changes -
            Description The help documentation indicates that tag filtering should behave like:
                  {{git tag -l "$tagFilter"}}

            However, we see different tag lists for the command line git filter versus the plugin filter.

            Example:
             * Git Command:      git tag -l "MTRS-MBP-*"
             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05

             * Plugin Filter:         MTRS-MBP-*

             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05
             release/MTRS-MBP-v00.03.01.int.1.0.0.2_armhf

            The plugin appears to behave as though "*MTRS-MBP-*" is implied.
             Yet, we have other entries, like "CDR_MTRS-MBP-v01.00.00_Demo", that the plugin does not show.

            The expectation here is that the behavior of the filter follows the stated 'git tag -l' behavior.

             
            The help documentation indicates that tag filtering should behave like:
                  {{git tag -l "$tagFilter"}}

            However, we see different tag lists for the command line git filter versus the plugin filter.

            Example:
             * Git Command:      git tag \-l "MTRS-MBP-*"
             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05

             * Plugin Filter:         MTRS-MBP-*

             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05
             release/MTRS-MBP-v00.03.01.int.1.0.0.2_armhf

            The plugin appears to behave as though "*MTRS-MBP-*" is implied.
             Yet, we have other entries, like "CDR_MTRS-MBP-v01.00.00_Demo", that the plugin does not show.

            The expectation here is that the behavior of the filter follows the stated 'git tag -l' behavior.

             
            kbowen Kevin Bowen made changes -
            Description The help documentation indicates that tag filtering should behave like:
                  {{git tag -l "$tagFilter"}}

            However, we see different tag lists for the command line git filter versus the plugin filter.

            Example:
             * Git Command:      git tag \-l "MTRS-MBP-*"
             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05

             * Plugin Filter:         MTRS-MBP-*

             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05
             release/MTRS-MBP-v00.03.01.int.1.0.0.2_armhf

            The plugin appears to behave as though "*MTRS-MBP-*" is implied.
             Yet, we have other entries, like "CDR_MTRS-MBP-v01.00.00_Demo", that the plugin does not show.

            The expectation here is that the behavior of the filter follows the stated 'git tag -l' behavior.

             
            The help documentation indicates that tag filtering should behave like:
                  {{git tag -l "$tagFilter"}}

            However, we see different tag lists for the command line git filter versus the plugin filter.

            Example:
             * Git Command:      git tag \-l "MTRS-MBP-*"
             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05

             * Plugin Filter:         MTRS-MBP-*

             ** _Returns (truncated):_
             MTRS-MBP-v02.02.00.RRC05
             release/MTRS-MBP-v00.03.01.int.1.0.0.2_armhf

            The plugin appears to behave as though "\*MTRS-MBP-\*" is implied.
             Yet, we have other entries, like "CDR_MTRS-MBP-v01.00.00_Demo", that the plugin does not show.

            The expectation here is that the behavior of the filter follows the stated 'git tag -l' behavior.

             
            Hide
            klimas7 Boguslaw Klimas added a comment -

            Hi Kevin,

            Plugin don't use 'git tag' to getting  tags from repository, I explain this on wiki .

            Show
            klimas7 Boguslaw Klimas added a comment - Hi Kevin, Plugin don't use 'git tag' to getting  tags from repository, I explain this on  wiki  .
            Hide
            klimas7 Boguslaw Klimas added a comment -

            Work as design 

            Show
            klimas7 Boguslaw Klimas added a comment - Work as design 
            klimas7 Boguslaw Klimas made changes -
            Link This issue depends on JENKINS-40232 [ JENKINS-40232 ]
            klimas7 Boguslaw Klimas made changes -
            Resolution Not A Defect [ 7 ]
            Status Open [ 1 ] Closed [ 6 ]
            Hide
            kbowen Kevin Bowen added a comment - - edited

            The help supplied via the plugin seems to indicate otherwise.

            "This parameter is used to get tag from git.
            If is blank, parameter is set to "*".
            Properly is executed command: git tag -l "*" or git tag -l "$tagFilter".
            (from Git Parameter Plug-In)"

            How is the tag filter expected to do matching?
            Is it a regex style match, like for branch selection?
             
            Show
            kbowen Kevin Bowen added a comment - - edited The help supplied via the plugin seems to indicate otherwise. "This parameter is used to get tag from git. If is blank, parameter is set to "*". Properly is executed command: git tag -l "*" or git tag -l "$tagFilter" . (from Git Parameter Plug-In )" How is the tag filter expected to do matching? Is it a regex style match, like for branch selection?  
            kbowen Kevin Bowen made changes -
            Attachment GitParamPluginTagOptions.png [ 45822 ]
            Hide
            kbowen Kevin Bowen added a comment -

            Please review screenshot and comment.
            Thank you.

             

            Show
            kbowen Kevin Bowen added a comment - Please review screenshot and comment. Thank you.  
            kbowen Kevin Bowen made changes -
            Resolution Not A Defect [ 7 ]
            Status Closed [ 6 ] Reopened [ 4 ]
            klimas7 Boguslaw Klimas made changes -
            Status Reopened [ 4 ] In Progress [ 3 ]
            klimas7 Boguslaw Klimas made changes -
            Issue Type Bug [ 1 ] Improvement [ 4 ]
            Hide
            klimas7 Boguslaw Klimas added a comment - - edited

            HI,

            I changed help description in the plugin on this field

            This parameter is used to get tag from git.
            If is blank, parameter is set to "*".
            Properly is executed command: git ls-remote -t <repository> "*" or git ls-remote -t <repository> "$tagFilter"
            git-ls-remote documentation.

             In git documentation

            <refs>…​
            When unspecified, all references, after filtering done with --heads and --tags, are shown. When <refs>…​ are specified, only references matching the  given patterns are displayed.

            Show
            klimas7 Boguslaw Klimas added a comment - - edited HI, I changed help description in the plugin on this field This parameter is used to get tag from git. If is blank, parameter is set to "*". Properly is executed command: git ls-remote -t <repository> "*" or git ls-remote -t <repository> "$tagFilter" git-ls-remote documentation.  In git documentation <refs>…​ When unspecified, all references, after filtering done with --heads and --tags, are shown. When <refs>…​ are specified, only references matching the  given patterns are displayed.
            Hide
            kbowen Kevin Bowen added a comment -

            Please note that using "git ls-remote -t" appears to return a lot more tag refs than the actual "git tags" command.
            The "tags" returned in this case are not always appropriate.
            The limited wildcarding for the command makes it impossible to filter out the inappropriate tags.

            Could a configurable regex be applied to the returned tags to address the issue?

            Thanks for the follow-up on this issue.

             

            Show
            kbowen Kevin Bowen added a comment - Please note that using "git ls-remote -t" appears to return a lot more tag refs than the actual "git tags" command. The "tags" returned in this case are not always appropriate. The limited wildcarding for the command makes it impossible to filter out the inappropriate tags. Could a configurable regex be applied to the returned tags to address the issue? Thanks for the follow-up on this issue.  
            klimas7 Boguslaw Klimas made changes -
            Attachment screenshot-1.png [ 46105 ]
            klimas7 Boguslaw Klimas made changes -
            Attachment screenshot-2.png [ 46106 ]
            Hide
            klimas7 Boguslaw Klimas added a comment - - edited

            Hi,

            I have a similar example for you:

            git ls-remote -t git@github.com:klimas7/Learn.git "v*" 
            fb76e1fcbc6af5396f044489e4167ba3c06bb675        refs/tags/release-tags/v1.0.0 
            dbac4ccfa19f03fc79587c0159ba553b37895a1b        refs/tags/release/v1.0.0 
            dbac4ccfa19f03fc79587c0159ba553b37895a1b        refs/tags/v1.0.0
            git ls-remote -t git@github.com:klimas7/Learn.git "refs/tags/v*"
            dbac4ccfa19f03fc79587c0159ba553b37895a1b        refs/tags/v1.0.0

            if you set plugin as that:

            you get

             

            Help was changed in release 0.9.10

            Show
            klimas7 Boguslaw Klimas added a comment - - edited Hi, I have a similar example for you: git ls-remote -t git@github.com:klimas7/Learn.git "v*" fb76e1fcbc6af5396f044489e4167ba3c06bb675        refs/tags/release-tags/v1.0.0 dbac4ccfa19f03fc79587c0159ba553b37895a1b        refs/tags/release/v1.0.0 dbac4ccfa19f03fc79587c0159ba553b37895a1b        refs/tags/v1.0.0 git ls-remote -t git@github.com:klimas7/Learn.git "refs/tags/v*" dbac4ccfa19f03fc79587c0159ba553b37895a1b refs/tags/v1.0.0 if you set plugin as that: you get   Help was changed in release 0.9.10
            Hide
            klimas7 Boguslaw Klimas added a comment -

            Release 0.9.10

            Show
            klimas7 Boguslaw Klimas added a comment - Release 0.9.10
            klimas7 Boguslaw Klimas made changes -
            Resolution Fixed [ 1 ]
            Status In Progress [ 3 ] Resolved [ 5 ]
            Hide
            kbowen Kevin Bowen added a comment - - edited

            I tried the updated plugin.

            Thank you for the adjustments and functional explanation.

            I fully realize that there are limitations to how the standard "git ls-remote -t" works.

            Your suggestion to prepend "refs/tags/" to the match helps with one of our job config cases.
            However, it does not help with our need for a "refs/tags/*-MBP-*" match in other cases.
            The wildcarding picks up the extra "release/" still.

            I believe that I saw another ticket/request for a regex style filter for the tags.
            Given my use case and other user cases, you may want to consider it as a future enhancement.

            Thank you again for the adjustments/update for this ticket.

             

            Show
            kbowen Kevin Bowen added a comment - - edited I tried the updated plugin. Thank you for the adjustments and functional explanation. I fully realize that there are limitations to how the standard "git ls-remote -t" works. Your suggestion to prepend "refs/tags/" to the match helps with one of our job config cases. However, it does not help with our need for a "refs/tags/*-MBP-*" match in other cases. The wildcarding picks up the extra "release/" still. I believe that I saw another ticket/request for a regex style filter for the tags. Given my use case and other user cases, you may want to consider it as a future enhancement. Thank you again for the adjustments/update for this ticket.  
            Hide
            mouzaffar_a mouz added a comment -

            After update plugin to 0.9.9, the field Filter is disabled when Quick Filter. is checked. Anyone have this problem ?

            Show
            mouzaffar_a mouz added a comment - After update plugin to 0.9.9, the field Filter is disabled when Quick Filter. is checked. Anyone have this problem ?
            Hide
            kbowen Kevin Bowen added a comment -

            We are running in production with the updated 0.9.10 version and have not noticed and problems.

            Show
            kbowen Kevin Bowen added a comment - We are running in production with the updated 0.9.10 version and have not noticed and problems.

              People

              Assignee:
              klimas7 Boguslaw Klimas
              Reporter:
              kbowen Kevin Bowen
              Votes:
              0 Vote for this issue
              Watchers:
              3 Start watching this issue

                Dates

                Created:
                Updated:
                Resolved: