regression between `4.71.0` and `4.72.0`

[ticapix]

Hello,

As hinted in #1844 (comment), I experience a regression bug that I reproduced here

https://gitlab.com/pierre-gronlier/debug-ci with the ./test.sh which dl version 4.71.0 and 4.72.0 and run it against:

• the TBC semver template
• a simplified version of the template

Minimal .gitlab-ci.yml illustrating the issue

workflow:
  rules:
    - if: $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ $PROD_REF || $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ $INTEG_REF
      when: never
variables:
  PROD_REF: /^(master|main)$/

The error is

  Error attempting to evaluate the following rules:
    rules:
      - if: 'null =~ "/^(master|main)$/" || null =~ null'
  as
  ```javascript
  false || null =~ null

[ticapix]

using bisect script, I narrowed it down to commit fcccb7e

--- Claude analysis ---

First bad commit: fcccb7e — "feat: implement workflow:rules:variables support (#1832) (#1833)"

What the commit does

It adds a new code path in src/parser.ts that evaluates workflow:rules early during parsing to extract and merge variables into the global scope.

Why it causes the bug

The evaluation calls Utils.getRulesResult with the workflow rules and a variable set that does not include $INTEG_REF (it's undefined at parse time). The rule expression is:

$CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ $PROD_REF || $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME =~ $INTEG_REF

With $CI_MERGE_REQUEST_SOURCE_BRANCH_NAME = null (not in MR context) and $INTEG_REF = null (undefined), this reduces to:

false || null =~ null // ← throws instead of returning false

The null =~ null case in the rules evaluator throws an error rather than gracefully returning false.

Why it didn't fail before

Before fcccb7e, workflow rules were not evaluated during --preview parsing. The new code path is what exposes the pre-existing null =~ null unhandled case in the expression evaluator.

The fix

Either in the workflow-rules evaluation added by fcccb7e, or in the underlying expression evaluator, null =~ null (and more generally, =~ null) should return false rather than throwing.

[ticapix]

While trying to fix the error, I found other errors.

I wrote a simple test.sh script to reproduce what I found with 4.71.0 and 4.72.0: https://gitlab.com/pierre-gronlier/debug-ci

$ ./test.sh
==> Running gitlab-ci-local --preview (v4.71.0)...
Error attempting to evaluate the following rules:
  rules:
    - if: 'null =~ null'
as
```javascript
null =~ null
```

==> Running gitlab-ci-local --preview (v4.71.0)...
Error attempting to evaluate the following rules:
  rules:
    - if: '"0.0.0-dev" =~ "/^v?[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9\-\.]+)?(\+[a-zA-Z0-9\-\.]+)?$/"'
as
```javascript
"0.0.0-dev".matchRE2JS(RE2JS.compile("^v?[0-9]+\.[0-9]+\.[0-9]+(-[a-zA-Z0-9\-\.]+)?(\+[a-zA-Z0-9\-\.]+)?$", 0)) != null
```

==> Running gitlab-ci-local --preview (v4.72.0)...
Error attempting to evaluate the following rules:
  rules:
    - if: 'null =~ "/^(master|main)$/" || null =~ null'
as
```javascript
false || null =~ null
```

==> Running gitlab-ci-local --preview (v4.72.0)...
Error attempting to evaluate the following rules:
  rules:
    - if: '"Commit Title\nMore commit text" =~ "/\[(ci skip|skip ci) on ([^],]*,)*tag(,[^],]*)*\]/" && null'
as
```javascript
"Commit Title\nMore commit text".matchRE2JS(RE2JS.compile("\[(ci skip|skip ci) on ([^],]*,)*tag(,[^],]*)*\]", 0)) != null && null
```

[ottok]

I am getting this error, is it likely the same issue?

± gitlab-ci-local
RHS (${rhs}) must be a regex pattern. Do not rely on this behavior!
Refer to https://docs.gitlab.com/ee/ci/jobs/job_rules.html#unexpected-behavior-from-regular-expression-matching-with- for more info...

How do I run gitlab-ci-local in a more verbose mode to debug this?

[ticapix]

I am getting this error, is it likely the same issue?

Do you have the .gitlab-ci.yml file ? or at least the part of the config raising the error ? You can copy the output of gitlab-ci-local --preview ?

Also, could you clone & build gitlab-ci-local from https://github.com/ticapix/gitlab-ci-local/tree/fix/rules-if-jsep-evaluator to see if it fixes your error ?

(It's the branch behind #1876 )

[ottok]

I am getting this error, is it likely the same issue?

Do you have the .gitlab-ci.yml file ? or at least the part of the config raising the error ? You can copy the output of gitlab-ci-local --preview ?

± gitlab-ci-local --file debian/salsa-ci.yml --preview
RHS (${rhs}) must be a regex pattern. Do not rely on this behavior!
Refer to https://docs.gitlab.com/ee/ci/jobs/job_rules.html#unexpected-behavior-from-regular-expression-matching-with- for more info...

The GitLab config is complex, and does not make sense to paste here in full. Seems there is no debug mode to run that would pinpoint what line is triggering the regex error?

Also, could you clone & build gitlab-ci-local from https://github.com/ticapix/gitlab-ci-local/tree/fix/rules-if-jsep-evaluator to see if it fixes your error ?

(It's the branch behind #1876 )

I tried building from source, but currently the npm install step that runs node-gyp -j max rebuild fails on my Debian unstable dev environment, so need to debug that a bit more.

[ottok]

OK, so when compiled from current git master branch HEAD I get:

± gitlab-ci-local --file debian/salsa-ci.yml --preview
51 | 	if (NETLIFY) {
52 | 		return true;
53 | 	}
54 | 
55 | 	// If they specify no colors, they probably don't want hyperlinks.
56 | 	if (!createSupportsColor(stream)) {
           ^
TypeError: SM.createSupportsColor is not a function. (In 'SM.createSupportsColor(D)', 'SM.createSupportsColor' is undefined)
      at PM (node_modules/supports-hyperlinks/index.js:56:7)
      at node_modules/supports-hyperlinks/index.js:153:10

After doing git pull https://github.com/ticapix/gitlab-ci-local.git fix/rules-if-jsep-evaluator and recompiling it works:

± gitlab-ci-local --file debian/salsa-ci.yml --preview

 WARN  Avoid overriding predefined variables [FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR] as it can cause the pipeline to behave unexpectedly.
If you know what you're doing and would like to suppress this warning, use one of the following methods:
	• via cli options
		• --ignore-predefined-vars FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR
	• via environment variable
		• GCL_IGNORE_PREDEFINED_VARS=FF_DISABLE_UMASK_FOR_DOCKER_EXECUTOR
parsing and downloads finished in 1.27 s.
json schema validated in 295 ms
---
stages:
  - .pre
  - provisioning
  - build
...

Strong 👍 from me!

[firecow]

#1876 fixes this, pending review