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

Build Parameter variable in branch name causes polling to detect false changes in GIT

    • Icon: Bug Bug
    • Resolution: Unresolved
    • Icon: Major Major
    • git-plugin
    • None
    • Jenkins 1.537
      Jenkins GIT Plugin 2.0
      Jenkins Multiple SCM Plugin 0.2

      Create a Job with a parameter:
      branch

      In GIT configuration set branch to:
      ${branch}
      or
      */${branch}

      This causes polling to keep detecting changes, even when there are none.

      Everything is fine when I hardcode branch name like so:
      */master

          [JENKINS-20427] Build Parameter variable in branch name causes polling to detect false changes in GIT

          Mark Espiritu added a comment -

          Not sure if related to JENKINS-19569.

          Mark Espiritu added a comment - Not sure if related to JENKINS-19569 .

          Lan Wu added a comment -

          This is broken for us too when we upgraded from Git 1.4 to 2.0. I think it's related to this fix:
          https://issues.jenkins-ci.org/browse/JENKINS-7411

          Our parameterized build was working fine before.

          We had to go back to 1.4 to make things work.

          I'd suggest that this is not a minor bug, should be much higher.

          Lan Wu added a comment - This is broken for us too when we upgraded from Git 1.4 to 2.0. I think it's related to this fix: https://issues.jenkins-ci.org/browse/JENKINS-7411 Our parameterized build was working fine before. We had to go back to 1.4 to make things work. I'd suggest that this is not a minor bug, should be much higher.

          Mark Waite added a comment -

          Based on the testing of JENKINS-20969, this is fixed in git-client-plugin 1.6.2 and git-plugin 2.0.1

          Mark Waite added a comment - Based on the testing of JENKINS-20969 , this is fixed in git-client-plugin 1.6.2 and git-plugin 2.0.1

          Maciej Matys added a comment - - edited

          It still doesn't work if you specify ** or leave blank job ${branch} parameter

          Maciej Matys added a comment - - edited It still doesn't work if you specify ** or leave blank job ${branch} parameter

          Mark Waite added a comment -

          I'll need more information about your configuration (upload a copy of the job definition) and a copy of the git polling log in order to understand why it doesn't work in your case and does work in other cases. Can you upload that information?

          Mark Waite added a comment - I'll need more information about your configuration (upload a copy of the job definition) and a copy of the git polling log in order to understand why it doesn't work in your case and does work in other cases. Can you upload that information?

          Maciej Matys added a comment - - edited

          Mark,
          No problem I can upload my config tell me how do it and from where get it, generally speaking it like JENKINS-20969 I have a build parameter (string parameter) - branch name to build , which is passed to the git "Branches to build" setting. When this parameter is set to *, **, or is empty, the code checkout in last build gets built again and again instead of an updated branches. I have a trigger to poll scm.
          What I want from this job is to monitor changes in all branches and also to be run against specified branch defined by build parameter manually. Moreover then this job is trigged by upstream job or manually with branch to build parameter set to * or ** or left blank I want to rebuild all branches.

          Maciej Matys added a comment - - edited Mark, No problem I can upload my config tell me how do it and from where get it, generally speaking it like JENKINS-20969 I have a build parameter (string parameter) - branch name to build , which is passed to the git "Branches to build" setting. When this parameter is set to *, **, or is empty, the code checkout in last build gets built again and again instead of an updated branches. I have a trigger to poll scm. What I want from this job is to monitor changes in all branches and also to be run against specified branch defined by build parameter manually. Moreover then this job is trigged by upstream job or manually with branch to build parameter set to * or ** or left blank I want to rebuild all branches.

          Mark Waite added a comment -

          The config file can be downloaded to your web browser by appending /config.xml to the end of the URL of your Jenkins job. For example, I have a job named "git-client-plugin-multi". I download the job configuration file from http://localhost:8080/git-client-plugin-multi/config.xml . Once you've downloaded, then you can use the "More Actions" -> "Attach Files" operation on the bug report to attach a file.

          I believe the bug that a branch name parameter is not correctly handled by polling has already been reported, and is not yet fixed.

          I believe that your intended use model will mostly work, except for the assumption that if the build parameter is the wild card it should rebuild all branches. I think that there is no way with the git plugin to force multiple builds of unchanged branches if they've been built before. I may be wrong on that, but I've not found a way to force a rebuild of all branches when the branches had not changed since the last time they were built.

          Mark Waite added a comment - The config file can be downloaded to your web browser by appending /config.xml to the end of the URL of your Jenkins job. For example, I have a job named "git-client-plugin-multi". I download the job configuration file from http://localhost:8080/git-client-plugin-multi/config.xml . Once you've downloaded, then you can use the "More Actions" -> "Attach Files" operation on the bug report to attach a file. I believe the bug that a branch name parameter is not correctly handled by polling has already been reported, and is not yet fixed. I believe that your intended use model will mostly work, except for the assumption that if the build parameter is the wild card it should rebuild all branches. I think that there is no way with the git plugin to force multiple builds of unchanged branches if they've been built before. I may be wrong on that, but I've not found a way to force a rebuild of all branches when the branches had not changed since the last time they were built.

          Jason Miller added a comment -

          I don't think this is fixed, or else there's been a regression (Jenkins 1.565).

          If I have a simple build that uses a BRANCH parameter that defaults to 'master', it will always trigger when notified to look for changes by Stash (via the /git/notifyCommit api), even if there's no changes.

          Git polling log looks like this:

          Started on Jun 23, 2014 2:01:35 PM
          Using strategy: Default
          [poll] Last Built Revision: Revision f22fe57691485df88098480c2e56c4e51a68ad67 (origin/master)
          using GIT_SSH to set credentials 
           > git ls-remote -h ssh://git@stash.domain.com/project/repository.git ${BRANCH}
          Done. Took 0.45 sec
          Changes found
          

          We're not using wildcards, it's just a simple string parameter with a default setting.

          Versions:
          Jenkins 1.565
          Git client plugin 1.9.1
          Git plugin 2.2.1

          Jason Miller added a comment - I don't think this is fixed, or else there's been a regression (Jenkins 1.565). If I have a simple build that uses a BRANCH parameter that defaults to 'master', it will always trigger when notified to look for changes by Stash (via the /git/notifyCommit api), even if there's no changes. Git polling log looks like this: Started on Jun 23, 2014 2:01:35 PM Using strategy: Default [poll] Last Built Revision: Revision f22fe57691485df88098480c2e56c4e51a68ad67 (origin/master) using GIT_SSH to set credentials > git ls-remote -h ssh://git@stash.domain.com/project/repository.git ${BRANCH} Done. Took 0.45 sec Changes found We're not using wildcards, it's just a simple string parameter with a default setting. Versions: Jenkins 1.565 Git client plugin 1.9.1 Git plugin 2.2.1

          Ollie Edwards added a comment - - edited

          Confirm this is still reproducible on Jenkins 1.570, git 2.2.2, git-client 1.9.1

          I've tested just a plain string

           ${BRANCH} 

          parameter which defaults to 'develop'

          If I push to another branch I see

          Started on Jul 1, 2014 1:40:05 PM
          Using strategy: Default
          [poll] Last Built Revision: Revision 582ed36314b3df24d849a92065bc2f997bebeb3e (origin/develop)
          using GIT_SSH to set credentials 
           > git ls-remote -h servicejenkins@vmrepos01:git/mfoMobileClient.git ${BRANCH}
          Done. Took 0.72 sec
          Changes found
          

          Ollie Edwards added a comment - - edited Confirm this is still reproducible on Jenkins 1.570, git 2.2.2, git-client 1.9.1 I've tested just a plain string ${BRANCH} parameter which defaults to 'develop' If I push to another branch I see Started on Jul 1, 2014 1:40:05 PM Using strategy: Default [poll] Last Built Revision: Revision 582ed36314b3df24d849a92065bc2f997bebeb3e (origin/develop) using GIT_SSH to set credentials > git ls-remote -h servicejenkins@vmrepos01:git/mfoMobileClient.git ${BRANCH} Done. Took 0.72 sec Changes found

          Don Ross added a comment - - edited

          I am seeing this same behavior after upgrading from 1.1.21 to 2.2.2.

          I noticed that the default is now to always use 'Fast remote polling'; in my production environment I have this option turned off. So, I enabled 'Force polling using workspace', and I am now seeing a different message (but the same behavior of false changes being found), as follows:

          Started on Jul 14, 2014 1:16:38 PM
          Polling SCM changes on slave-host-name
          Using strategy: Default
          [poll] Last Built Revision: Revision 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f (origin/release_branch)
           > git rev-parse --is-inside-work-tree
          Fetching changes from the remote Git repositories
           > git config remote.origin.url ssh://build@gitserver/git/product.git
          Fetching upstream changes from ssh://build@gitserver/git/product.git
           > git --version
           > git fetch --tags --progress ssh://build@gitserver/git/product.git +refs/heads/*:refs/remotes/origin/*
          Polling for changes in
           > git rev-parse "origin/release_branch^{commit}"
           > git rev-parse "release_branch^{commit}"
           > git log --full-history --no-abbrev --format=raw -M -m --raw 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f..9f74e3057c7fb30d2c001f886e394d5bea0271a
          Done. Took 1.8 sec
          Changes found
          

          It is interesting to me that the '9f74e3' commit ID in that git log command is the commit immediately before the '44bfcc7' commit. I would have expected the parameters to be in the other order.

          Don Ross added a comment - - edited I am seeing this same behavior after upgrading from 1.1.21 to 2.2.2. I noticed that the default is now to always use 'Fast remote polling'; in my production environment I have this option turned off. So, I enabled 'Force polling using workspace', and I am now seeing a different message (but the same behavior of false changes being found), as follows: Started on Jul 14, 2014 1:16:38 PM Polling SCM changes on slave-host-name Using strategy: Default [poll] Last Built Revision: Revision 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f (origin/release_branch) > git rev-parse --is-inside-work-tree Fetching changes from the remote Git repositories > git config remote.origin.url ssh: //build@gitserver/git/product.git Fetching upstream changes from ssh: //build@gitserver/git/product.git > git --version > git fetch --tags --progress ssh: //build@gitserver/git/product.git +refs/heads/*:refs/remotes/origin/* Polling for changes in > git rev-parse "origin/release_branch^{commit}" > git rev-parse "release_branch^{commit}" > git log --full-history --no-abbrev --format=raw -M -m --raw 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f..9f74e3057c7fb30d2c001f886e394d5bea0271a Done. Took 1.8 sec Changes found It is interesting to me that the '9f74e3' commit ID in that git log command is the commit immediately before the '44bfcc7' commit. I would have expected the parameters to be in the other order.

          Don Ross added a comment -

          I ran these two commands on my slave and got the same results:
          > git rev-parse "origin/release_branch^

          {commit}"
          44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f
          > git rev-parse "release_branch^{commit}

          "
          9f74e3057c7fb30d2c001f886e394d5bea0271a

          It looks like the local branch is not being updated to match the remote.

          Which is not a surprise to me, since behavior in 1.1 was to check out detached, and never even create a local branch.

          Don Ross added a comment - I ran these two commands on my slave and got the same results: > git rev-parse "origin/release_branch^ {commit}" 44bfcc7cdf27d192f1d8e29a2863ff3c3940cb6f > git rev-parse "release_branch^{commit} " 9f74e3057c7fb30d2c001f886e394d5bea0271a It looks like the local branch is not being updated to match the remote. Which is not a surprise to me, since behavior in 1.1 was to check out detached, and never even create a local branch.

          Don Ross added a comment -

          After some fiddling and testing, I got this to work. I had to delete the local instance of the branch, at which point Jenkins started recognizing changes. So, it appears that using non-fast polling (ie, 'Force polling using workspace') is an effective workaround if you have a build parameter in the branch name.

          HOWEVER, if you have a local instance of the branch in the workspace, then non-fast polling seems to always think there are changes, irrespective of whether you have a variable or not. I will do some more testing and submit a bug report if I can get it to reproduce consistently.

          Don Ross added a comment - After some fiddling and testing, I got this to work. I had to delete the local instance of the branch, at which point Jenkins started recognizing changes. So, it appears that using non-fast polling (ie, 'Force polling using workspace') is an effective workaround if you have a build parameter in the branch name. HOWEVER, if you have a local instance of the branch in the workspace, then non-fast polling seems to always think there are changes, irrespective of whether you have a variable or not. I will do some more testing and submit a bug report if I can get it to reproduce consistently.

          I can confirm this bug. With Jenkins 1.572, git client plugin 1.9.2 and git plugin 2.2.2 the polling module does not resolve our "$branch" variable, set in the parametrized build configuration:

          Started on Jul 17, 2014 10:50:00 AM
          Using strategy: Default
          [poll] Last Built Revision: Revision 2d1a169f855f69312b4b47819283063ea15c1448 (origin/master)
          > git ls-remote -h git://github.com/gem/oq-nrmllib.git $branch
          Done. Took 0.54 sec
          No changes

          If we disable the parametrized buildand just set 'master' as branch it works.

          Daniele Vigano added a comment - I can confirm this bug. With Jenkins 1.572, git client plugin 1.9.2 and git plugin 2.2.2 the polling module does not resolve our "$branch" variable, set in the parametrized build configuration: Started on Jul 17, 2014 10:50:00 AM Using strategy: Default [poll] Last Built Revision: Revision 2d1a169f855f69312b4b47819283063ea15c1448 (origin/master) > git ls-remote -h git://github.com/gem/oq-nrmllib.git $branch Done. Took 0.54 sec No changes If we disable the parametrized buildand just set 'master' as branch it works.

          Derek Douville added a comment - - edited

          I've been struggling with the same problem all week.

          What I've determined is that the git plugin is either ignoring any variables created in Parameterized Build, or they are not getting passed. However, Parameterized Build can override variables the Git Plugin cares about.

          Environment:

          • Use separate directories for workspace set to $GIT_BRANCH/src
          • Delete workspace & Force Clone
          • Git Plugin: 2.2.2
          • Git Client Plugin: 1.10
          • GitHub API Plugin: 1.55
          • GitHub Plugin: 1.90

          Test Case 1: Override GIT_BRANCH
          If you create a GIT_BRANCH parameter and run a build with garbage text, you can see the github plugin use that text (by the way, overriding GIT_BRANCH is bad, because it will override all of your automatic github push triggers too). This test shows that Parameterized Build at least runs before the git plugin uses its GIT_BRANCH variable.

          Test Case 2: Create a new variable "MYBRANCH", specify $MYBRANCH as the branch to build.
          If you now run a paramarized build and set this with some garbage (eg. not a real branch), the git clone should fail. But $MYBRANCH is treated as whitespace because it doesn't exist to the git plugin, thus performing default build behavior and building the last branch to get an update.

          Test Case 3: Wrap MYBRANCH with curly braces ${MYBRANCH}
          No difference

          Test Case 4: Put garbage directly into the branch to build path
          Type "asdasd" into the branch to build and see the build fail.

          I also then added the EnvInject plugin and attempted to set the GIT_BRANCH variable from there, based on another variable's value, to no success.

          My conclusion is that the Git plugin is not evaluating any environment variables passed into the branch specifications. This basically means parameterized builds are useless.

          Derek Douville added a comment - - edited I've been struggling with the same problem all week. What I've determined is that the git plugin is either ignoring any variables created in Parameterized Build, or they are not getting passed. However, Parameterized Build can override variables the Git Plugin cares about. Environment: Use separate directories for workspace set to $GIT_BRANCH/src Delete workspace & Force Clone Git Plugin: 2.2.2 Git Client Plugin: 1.10 GitHub API Plugin: 1.55 GitHub Plugin: 1.90 Test Case 1: Override GIT_BRANCH If you create a GIT_BRANCH parameter and run a build with garbage text, you can see the github plugin use that text (by the way, overriding GIT_BRANCH is bad, because it will override all of your automatic github push triggers too). This test shows that Parameterized Build at least runs before the git plugin uses its GIT_BRANCH variable. Test Case 2: Create a new variable "MYBRANCH", specify $MYBRANCH as the branch to build. If you now run a paramarized build and set this with some garbage (eg. not a real branch), the git clone should fail. But $MYBRANCH is treated as whitespace because it doesn't exist to the git plugin, thus performing default build behavior and building the last branch to get an update. Test Case 3: Wrap MYBRANCH with curly braces ${MYBRANCH} No difference Test Case 4: Put garbage directly into the branch to build path Type "asdasd" into the branch to build and see the build fail. I also then added the EnvInject plugin and attempted to set the GIT_BRANCH variable from there, based on another variable's value, to no success. My conclusion is that the Git plugin is not evaluating any environment variables passed into the branch specifications. This basically means parameterized builds are useless.

          same issue for me, ${BRANCH} in Branch Specifier is ignored

          David McWhorter added a comment - same issue for me, ${BRANCH} in Branch Specifier is ignored

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/ea62814db213b41b0e8fe99dbca6898aa369da97
          Log:
          [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/ea62814db213b41b0e8fe99dbca6898aa369da97 Log: [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling

          Mark Waite added a comment -

          Fixed in git plugin 2.2.7, available from update center.

          Mark Waite added a comment - Fixed in git plugin 2.2.7, available from update center.

          Mark Waite added a comment -

          Fix included in git plugin 2.3.1, released 29 Nov 2014

          Mark Waite added a comment - Fix included in git plugin 2.3.1, released 29 Nov 2014

          Code changed in jenkins
          User: Nicolas De Loof
          Path:
          src/main/java/hudson/plugins/git/GitSCM.java
          http://jenkins-ci.org/commit/git-plugin/75e4e6c2282e069bd26fbce0ead19c1c5b722c04
          Log:
          [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling

          SCM/JIRA link daemon added a comment - Code changed in jenkins User: Nicolas De Loof Path: src/main/java/hudson/plugins/git/GitSCM.java http://jenkins-ci.org/commit/git-plugin/75e4e6c2282e069bd26fbce0ead19c1c5b722c04 Log: [FIXED JENKINS-20427] [FIXED JENKINS-14276] expanded vars in branch spec for remote polling

          I'm observing the bug again, Jenkins 2.7, Git plugin 2.5.2 (see also JENKINS-29896)

          Konstantin Yegupov added a comment - I'm observing the bug again, Jenkins 2.7, Git plugin 2.5.2 (see also JENKINS-29896 )

          Mark Waite added a comment -

          yk4ever can you provide more details on the case where you're seeing the problem?

          I can't duplicate the problem on my Jenkins 2.7.1 with Git plugin 2.5.2 and git client plugin 1.19.6.

          Mark Waite added a comment - yk4ever can you provide more details on the case where you're seeing the problem? I can't duplicate the problem on my Jenkins 2.7.1 with Git plugin 2.5.2 and git client plugin 1.19.6.

          So, I'm updating the Jenkins config like this:
          http://imgur.com/0H945kK

          The polling log before the change (extracted from a build, so ends with "changes found", but doesn't have to):
          http://pastebin.com/3Mv3HUQd

          The polling log after the change:
          http://pastebin.com/igztfdwu
          ...and then it starts to rebuild the same branch 495 it has just built before (not 1205).

          So, apparently, the behavior is very different depending on whether you specify BranchSpec directly as "*" or via a variable that should have the value of "*"

          Konstantin Yegupov added a comment - So, I'm updating the Jenkins config like this: http://imgur.com/0H945kK The polling log before the change (extracted from a build, so ends with "changes found", but doesn't have to): http://pastebin.com/3Mv3HUQd The polling log after the change: http://pastebin.com/igztfdwu ...and then it starts to rebuild the same branch 495 it has just built before (not 1205). So, apparently, the behavior is very different depending on whether you specify BranchSpec directly as "* " or via a variable that should have the value of " *"

          (bold unintended, should have been double asterisks)

          Konstantin Yegupov added a comment - (bold unintended, should have been double asterisks)

          @Nicolas De Loof Any updates on this? This is is a major issue for us as sometimes builds fail because of network issue and when we try to rerun, the job picks up some random branch!

          Puneeth Nanjundaswamy added a comment - @Nicolas De Loof Any updates on this? This is is a major issue for us as sometimes builds fail because of network issue and when we try to rerun, the job picks up some random branch!

          Mark Waite added a comment -

          puneeth_n, ndeloof is no longer a maintainer of the git plugin. I was unable to duplicate the problem in my most recent attempt. Can you provide step by step instructions which show the failure on an "out of the box" Jenkins installation? Even better is to provide those step by step instructions and a docker image (like a bug verification job as a pull request to my lts-with-plugins docker instance).

          Every time I need to guess what a user is doing it is more time that I could have spent helping in other ways (like fixing other bugs, reviewing proposals, etc.)

          Mark Waite added a comment - puneeth_n , ndeloof is no longer a maintainer of the git plugin. I was unable to duplicate the problem in my most recent attempt. Can you provide step by step instructions which show the failure on an "out of the box" Jenkins installation? Even better is to provide those step by step instructions and a docker image (like a bug verification job as a pull request to my lts-with-plugins docker instance ). Every time I need to guess what a user is doing it is more time that I could have spent helping in other ways (like fixing other bugs, reviewing proposals, etc.)

          markewaite Thanks for the response. I have created a seperate JIRA ticket with all details. Here is the link: https://issues.jenkins-ci.org/browse/JENKINS-38406

          Let me know in case of more info

          Puneeth Nanjundaswamy added a comment - markewaite Thanks for the response. I have created a seperate JIRA ticket with all details. Here is the link: https://issues.jenkins-ci.org/browse/JENKINS-38406 Let me know in case of more info

          Stephen Rufle added a comment -

          I have seen this same issue with the TFS plugin used in Jenkins Multiple SCM plugin 0.5

          Stephen Rufle added a comment - I have seen this same issue with the TFS plugin used in Jenkins Multiple SCM plugin 0.5

          Alex Taylor added a comment -

          markewaite- I was finally able to reproduce this issue 100% if you have access to bitbucket.

          1. Have Bitbucket repository with at least 10 branches

          2. Create a freestyle job and configure it to use the git plugin but connect to a Bitbucket repository at `$BITBUCKET_URL/git/$PROJECT/$REPO.git`

          3. Add a parameter called BRANCH and has the default value of **

          4. Use that parameter in the `Branches to build` section

          5. Add a poll for changes of `* * * * *` so that it will build every minute

          6. Add a shell step of something like "echo hello"

          7. Run one build

           

          This will then launch a new build for every branch and then once that is done you will see it build every minute seeing changes.

           

          Let me know if that does not work for you because it has worked 2x for me so far.

          Alex Taylor added a comment - markewaite - I was finally able to reproduce this issue 100% if you have access to bitbucket. 1. Have Bitbucket repository with at least 10 branches 2. Create a freestyle job and configure it to use the git plugin but connect to a Bitbucket repository at `$BITBUCKET_URL/git/$PROJECT/$REPO.git` 3. Add a parameter called BRANCH and has the default value of ** 4. Use that parameter in the `Branches to build` section 5. Add a poll for changes of `* * * * *` so that it will build every minute 6. Add a shell step of something like "echo hello" 7. Run one build   This will then launch a new build for every branch and then once that is done you will see it build every minute seeing changes.   Let me know if that does not work for you because it has worked 2x for me so far.

          Alex Taylor added a comment -

          See my last comment since I think it is still an issue

          Alex Taylor added a comment - See my last comment since I think it is still an issue

          This is a major issue for people using a cloud build and has been open since 2013.

           

          Is it not possible to use the same solution for polling without wild cards as it is with wild cards?

          Michael Krussel added a comment - This is a major issue for people using a cloud build and has been open since 2013.   Is it not possible to use the same solution for polling without wild cards as it is with wild cards?

          Mark Waite added a comment -

          mkrussel it is not possible to use the same solution without wild cards as with wild cards as far as I know. Pull requests with automated tests that show the problem and include a fix are certainly welcomed.

          Mark Waite added a comment - mkrussel it is not possible to use the same solution without wild cards as with wild cards as far as I know. Pull requests with automated tests that show the problem and include a fix are certainly welcomed.

            Unassigned Unassigned
            m_a_r_k_y Mark Espiritu
            Votes:
            12 Vote for this issue
            Watchers:
            25 Start watching this issue

              Created:
              Updated: