Closed EricChen1248 closed 1 week ago
gitlab-ci-local <job-name>
might achieve what you're hoping for
ie.
though, this probably wont work for include with rules:changes
True, though doesn't work well for jobs that need to depend on it. Also, relies heavily on devs knowing when to run it and when not to, instead of just providing them with a variables file to run with.
Another side thing, unmentioned, is we're actually also using this as a tool to validate our pipeline rules, using --list. We run --list with many different sets of variables, and compare the output to what we expect it to be in each scenario. Not the intended use for this probably, so less of a concern.
Another side thing, unmentioned, is we're actually also using this as a tool to validate our pipeline rules, using --list.
oh, cool but do take it with a pinch of salt, i don't think our rule evaluation are perfect yet, do let us know if you discovered any discrepancy.
Is your feature request related to a problem? Please describe. in #1221 rules:changes was implemented to match the behavior on GitLab.
However, our environment relies on some external environment on our actual runners to make use of the changes (no need to recompile files that were already compiled previously on the runners), which doesn't exist on the local environment. So in our local environment, we want to let it always run, without considering rules:changes, i.e., back to what it was doing before.
Describe the solution you'd like An additional flag like
--ignore-rule-changes
that lets it run with its previous behavior.Describe alternatives you've considered A way to "fake" changes as part of the .gitlab-ci-local-variables.yml would also work
Additional context Add any other context or screenshots about the feature request here.