glob pattern matching for specific job(s) execution
Is your feature request related to a problem? Please describe. When building CI tasks from multiple underlying "base jobs", I am not able run a select subset of tasks without listing out each individual job name.
Describe the solution you'd like
Using a simple example: it would be nice to be able to run gitlab-ci-local "job-type-*" and have all jobs prefixed with job-type execute.
Describe alternatives you've considered
There are alternatives that can solve the problem in other ways, such as categorizing the select tasks into the same stage in tandem with --stage <stage> CLI argument. Using --needs, which may help in some cases. However, I do not want to break stages down so granular.
Additional context Imagine a flow like-so:
I do not necessarily want to create a stage for job, nor do I want to specify prep / build/ deploy stages.. it would be helpful to be able to specify gitlab-ci-local job-* and have the 4 tasks execute. I think a code change here may allows this 🤔
You will have to come up with some sort of custom cli options or argument parsing.
It would be hard to implement a job-* solution. Since an actual job name in Gitlab CI/CD can contain *, and we are not going to "disallow" using * in names, when Gitlab CI/CD supports it.
As illustrated here
---
job-*:
script:
- echo "Heja"
mjn@mjn-lapdows:~/workspace/mjn-gitlab-ci-debugging$ gitlab-ci-local job-*
parsing and downloads finished in 50 ms.
json schema validated in 235 ms
job-* starting shell (test)
job-* $ echo "Heja"
job-* > Heja
job-* finished in 13 ms
PASS job-*
Fair point! What do you think of an additional boolean CLI argument parse-jobs-as-regexp that evaluates the job names as a regexp if flagged? Could also do this with glob pattern matching, but if we're going all the way... this way the feature is explicit, covers more cases, and supported Gitlab CI/CD names that use such characters could even be regexp'd.
At a high-level, something like so:
.option("parse-jobs-as-regexp", {
type: "boolean",
description: "Parse the job name(s) as a regular expression instead of literal string comparison",
requiresArg: false,
})
const parseJobsAsRegexp = parser.parseJobsAsRegexp;
...
jobArgs.forEach(jobArgName => {
if (parseJobsAsRegexp) {
<new flow>
}
else {
<existing flow>
}
That would be a good cli option yeah.