Fix failing copyright check for year 2026 #105

pahmann · 2026-01-30T10:21:57Z

In recent PRs, when using 2026 in the copyright header the scripting was failing. This patch provides a rewrite of convert_bre_to_regex to what I thought is more readable.

An example of a failing PR can be found here:
https://github.com/eclipse-score/process_description/actions/runs/21507834771/job/61967674606?pr=542#step:4:46

AI explained the root cause as follows (which I was not aware about):

The original implementation defines: metacharacters = r"\\.*+-?[]{}()^$|".

This list contains an invalid character class:
[] is an empty bracket expression, which is not valid in regular expressions.
As a result, when the code iterates through these characters and attempts to “unescape” them inside the escaped template string, the empty [] fragment leads to unpredictable and context‑dependent behavior in the replacement logic. In practice, this produces invalid or malformed regular expressions for certain inputs, depending on the surrounding escape sequences.
This caused the header‑matching logic to fail inconsistently (e.g., for specific years like 2026), even though the template itself was correct.

Note that the change still just checks for 4 digits and not if it is a reasonable year. So years like 1234 are as valid as 4321

Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>

pahmann · 2026-01-30T13:25:37Z

I hope my checks in the 3 commits were correct. My assumption was that the cr_checker.py from this PR is directly pulled and used to check the PR. If this is not the case the error actually is not really reproducible.

Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>

AlexanderLanin · 2026-01-30T15:47:30Z

cr_checker/tool/cr_checker.py

+        out.append(re.escape(ch))
+        i += 1
+
+    return "".join(out)


I'm not sure if this code is better or worse than the old regex.
But as long as it works... honestly... no one cares.

Do we know if it works? Like, it seems to accept this PR. But would it reject some other string?

Hi Alex, I am not sure, if it does it in all cases. I will use the script call as documented and see if I spot something.

@AlexanderLanin okay, I rerun the script locally. I checked with an "O" instead of "0" and also tried with 3 digit "202". It works properly. However, I also rerun the original unchanged script for a file with "2026" being the year and it also works there. So I cannot reproduce the original issue, so I also cannot check, if my change helps.

Copilot

Pull request overview

This PR fixes a bug in the copyright checking script that was causing failures when using year 2026 in copyright headers. The root cause was an invalid empty character class [] in the convert_bre_to_regex function's metacharacters string, which led to malformed regular expressions. The fix completely rewrites the function with a clearer, more maintainable implementation.

Changes:

Rewrote convert_bre_to_regex function to properly handle BRE-style escape sequences without the invalid [] character class
Updated copyright year to 2026 in the file header
Fixed typo "coypright" → "copyright" in the load_exclusion docstring

💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.

Copilot · 2026-01-30T15:51:44Z

cr_checker/tool/cr_checker.py

+    L = len(template)
+
+    while i < L:
+        ch = template[i]
+
+        # Escape sequences
+        if ch == "\\" and i + 1 < L:


Consider using a more descriptive variable name instead of 'L'. In Python, lowercase 'length' or 'template_len' would be more conventional and readable.

Suggested change

L = len(template)

while i < L:

ch = template[i]

# Escape sequences

if ch == "\\" and i + 1 < L:

template_len = len(template)

while i < template_len:

ch = template[i]

# Escape sequences

if ch == "\\" and i + 1 < template_len:

Copilot · 2026-01-30T15:51:45Z

cr_checker/tool/cr_checker.py

 def convert_bre_to_regex(template: str) -> str:
    """
-    Convert BRE-style template (literal by default) to standard regex.
-    In the template: * is literal, \\* is a metacharacter.
+    Convert a BRE-like template into a regex:
+    - '\' escapes one character into a regex meta character
+    - '*' is literal unless escaped as '\*' (implicitly covered)
+    - everything else is taken literally
    """
-    # First, escape all regex metacharacters to make them literal
-    escaped = re.escape(template)
-    # Now, find escaped backslashes followed by escaped metacharacters
-    # and convert them back to actual regex metacharacters
-    metacharacters = r"\\.*+-?[]{}()^$|"
-    for char in metacharacters:
-        escaped = escaped.replace(re.escape("\\" + char), char)
-    return escaped
+
+    out = []
+    i = 0
+    L = len(template)
+
+    while i < L:
+        ch = template[i]
+
+        # Escape sequences
+        if ch == "\\" and i + 1 < L:
+            nxt = template[i + 1]
+
+            # Next char becomes regex meta character
+            out.append(nxt)
+            i += 2
+            continue
+
+        # Literal characters → re.escape
+        out.append(re.escape(ch))
+        i += 1
+
+    return "".join(out)


The convert_bre_to_regex function has been completely rewritten, but there are no direct unit tests for this function. Consider adding tests that verify the conversion logic with various inputs, such as templates with escaped characters, special regex metacharacters, and edge cases like trailing backslashes. This would help prevent regressions and document the expected behavior.

Copilot · 2026-01-30T15:51:45Z

cr_checker/tool/cr_checker.py

+    - '\' escapes one character into a regex meta character
+    - '*' is literal unless escaped as '\*' (implicitly covered)
+    - everything else is taken literally


The docstring's second bullet point is potentially confusing. It currently says '' is literal unless escaped as '*', but '*' produces the regex metacharacter '' (zero or more), not a literal asterisk. Consider rewording to clarify that '*' produces the regex wildcard metacharacter, while an unescaped '' is treated as a literal asterisk character. For example: "- '' is treated as a literal asterisk character\n- '*' produces the regex metacharacter '*' (zero or more of the preceding element)"

Suggested change

- '\' escapes one character into a regex meta character

- '*' is literal unless escaped as '\*' (implicitly covered)

- everything else is taken literally

- '\' escapes the following character and inserts it as a regex metacharacter

- '*' is treated as a literal asterisk character

- '\*' in the template yields the regex metacharacter '*' (zero or more of the preceding element)

- everything else is taken literally (escaped with re.escape)

Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>

AlexanderLanin · 2026-02-05T08:26:01Z

@pahmann maybe this was fixed in #88 which was released in https://github.com/eclipse-score/tooling/releases/tag/v1.0.5

Did you use an older tooling version?

github-project-automation bot added this to INF - Infrastructure Community Jan 30, 2026

github-project-automation bot moved this to Draft in INF - Infrastructure Community Jan 30, 2026

pahmann marked this pull request as draft January 30, 2026 10:22

Fix failing cr check for year 2026

5e791d0

Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>

pahmann force-pushed the pahmann/fix-cr-year branch from 32f4585 to 5e791d0 Compare January 30, 2026 10:34

pahmann added 2 commits January 30, 2026 14:05

break to test checker

ce293b0

Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>

Modify to 2026 for testing

181a30d

Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>

pahmann changed the title ~~[DRAFT] Fix failing cr check for year 2026~~ Fix failing copyright check for year 2026 Jan 30, 2026

pahmann marked this pull request as ready for review January 30, 2026 13:24

Add statement for AI supported in commit

7e6506e

Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>

pahmann requested review from AlexanderLanin, MaximilianSoerenPollak, dcalavrezo-qorix and nradakovic January 30, 2026 13:58

AlexanderLanin reviewed Jan 30, 2026

View reviewed changes

AlexanderLanin requested a review from Copilot January 30, 2026 15:47

Copilot started reviewing on behalf of AlexanderLanin January 30, 2026 15:48 View session

Copilot AI reviewed Jan 30, 2026

View reviewed changes

Fix CoPilot findings

5ea029e

Signed-off-by: Philipp Ahmann <Philipp.Ahmann@de.bosch.com>

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Fix failing copyright check for year 2026 #105

Fix failing copyright check for year 2026 #105

Uh oh!

pahmann commented Jan 30, 2026 •

edited

Loading

Uh oh!

pahmann commented Jan 30, 2026

Uh oh!

AlexanderLanin Jan 30, 2026

Uh oh!

pahmann Jan 30, 2026

Uh oh!

pahmann Jan 30, 2026

Uh oh!

Copilot AI left a comment

Uh oh!

Copilot AI Jan 30, 2026

Uh oh!

Copilot AI Jan 30, 2026

Uh oh!

Copilot AI Jan 30, 2026

Uh oh!

AlexanderLanin commented Feb 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

-    - '\' escapes one character into a regex meta character
-    - '*' is literal unless escaped as '\*' (implicitly covered)
-    - everything else is taken literally
+    - '\' escapes the following character and inserts it as a regex metacharacter
+    - '*' is treated as a literal asterisk character
+    - '\*' in the template yields the regex metacharacter '*' (zero or more of the preceding element)
+    - everything else is taken literally (escaped with re.escape)

Fix failing copyright check for year 2026 #105

Are you sure you want to change the base?

Fix failing copyright check for year 2026 #105

Uh oh!

Conversation

pahmann commented Jan 30, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

pahmann commented Jan 30, 2026

Uh oh!

AlexanderLanin Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

pahmann Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

pahmann Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI left a comment

Choose a reason for hiding this comment

Pull request overview

Uh oh!

Copilot AI Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

Copilot AI Jan 30, 2026

Choose a reason for hiding this comment

Uh oh!

AlexanderLanin commented Feb 5, 2026

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

2 participants

pahmann commented Jan 30, 2026 •

edited

Loading