Details
-
Type:
Improvement
-
Status: Closed (View Workflow)
-
Priority:
Minor
-
Resolution: Fixed
-
Component/s: delivery-pipeline-plugin
-
Labels:None
-
Environment:1.596.1
-
Similar Issues:
Description
I want to create a delivery pipeline view for just the jobs under a folder (using the cloudbees-folders plugin).
In attempting to use the regex match, it appears that the folder name is not part of the string being matched.
I can get everything (including those jobs I do not want) using ^(.+)$, so I know that regex filtering works. But when I try things like
- ^foldername/(.+)$
- ^foldername\/(.+)$
Then the view is completely empty.
The jobs in the folder do not have a consistent naming structure such that I can match against just those jobs.
Is there any way do this with this plugin?
Attachments
Issue Links
- is related to
-
JENKINS-27539 NPE when using jobs with the same name in different folders
-
- Closed
-
Activity
Stephan Pauxberger
added a comment - Pull Request: https://github.com/Diabol/delivery-pipeline-plugin/pull/98 Merged (should be in 0.8.11)
Stephan Pauxberger
added a comment - Merged (should be in 0.8.11) I built the 0.8.11 snapshot and this does fix the problem.
One small quirk though:
I have a job structure like this:
- cookbooks/foo
- cookbooks/bar
- workers/cookbooks/style
- workers/cookbooks/unit
- workers/cookbooks/integration
With this regex:
cookbooks/(.+)
All of these jobs show up in the view. I would have only expected foo and bar to be there.
Anchoring the regex:
^cookbooks/(.+)
Produces the desired results, but I'm unclear why the non-anchored pattern worked. I tested out the above on the regexplanet tester (http://www.regexplanet.com/advanced/java/index.html) and it works the way I expected it to (only foo and bar match whether the regex is anchored or not).
Thanks for the quick update though.
James FitzGibbon
added a comment - I built the 0.8.11 snapshot and this does fix the problem.
One small quirk though:
I have a job structure like this:
cookbooks/foo
cookbooks/bar
workers/cookbooks/style
workers/cookbooks/unit
workers/cookbooks/integration
With this regex:
cookbooks/(.+)
All of these jobs show up in the view. I would have only expected foo and bar to be there.
Anchoring the regex:
^cookbooks/(.+)
Produces the desired results, but I'm unclear why the non-anchored pattern worked. I tested out the above on the regexplanet tester ( http://www.regexplanet.com/advanced/java/index.html ) and it works the way I expected it to (only foo and bar match whether the regex is anchored or not).
Thanks for the quick update though. Released in 0.8.11
@James: You can either match() or find() a regexp to/in a String. `match()` returns only true if the whole string is matched by the regexp. `find()` on the other hand matches if there is any substring inside the string matching the regexp. You can convert a valid match()-regexp into a find()-regexp by anchoring it in ^ and $, and vice versa by putting '.*' behind and after the regexp (for single line strings, multiline would be a bit more complicated).
The code in the plugin uses find(), therefore you have to convert the find()-regexp into a match() regexp by anchoring, as you did. Personally, I think match() would have been the 'nicer' solution, but to change that now would break compatibility with previous versions.
So, continue to anchor your regexps (but for the record, you should also append '$').
Stephan Pauxberger
added a comment - @James: You can either match() or find() a regexp to/in a String. `match()` returns only true if the whole string is matched by the regexp. `find()` on the other hand matches if there is any substring inside the string matching the regexp. You can convert a valid match()-regexp into a find()-regexp by anchoring it in ^ and $, and vice versa by putting '.*' behind and after the regexp (for single line strings, multiline would be a bit more complicated).
The code in the plugin uses find(), therefore you have to convert the find()-regexp into a match() regexp by anchoring, as you did. Personally, I think match() would have been the 'nicer' solution, but to change that now would break compatibility with previous versions.
So, continue to anchor your regexps (but for the record, you should also append '$'). 
Unfortunately the regexp is only matched against the project name and not against the full name including the foldername.
I guess it is possible to fix the bug by matching against the full name.