`branch_pattern` not matching multiple patterns as expected (v4.1)
Closed this issue · 2 comments
Orb version:
4.1
What happened:
We are using the branch_pattern
parameter with multiple comma-delimited patterns, but the notify command is failing to match and send a Slack notification when expected.
Setup:
SLACK_TRUNK_OR_REL_BRANCH_REGEX: &SLACK_TRUNK_OR_REL_BRANCH_REGEX trunk,release\/\d{4}-\d{2}-\d{2}[a-zA-Z]*
orbs:
slack: circleci/slack@4.1
...
- slack/notify:
event: fail
template: basic_fail_1
branch_pattern: *SLACK_TRUNK_OR_REL_BRANCH_REGEX
channel: alert-trunk-station
Given:
branch = "release/2023-05-03"
Error:
NO SLACK ALERT
Current reference "release/2023-05-03" does not match any matching parameter
Current matching pattern: trunk,release\/\d{4}-\d{2}-\d{2}[a-zA-Z]*
CircleCI received exit code 0
Expected behavior:
The notify
command should recognize the given branch as matching one of our patterns, and send a Slack notification when our pipeline fails.
Additional Information:
I have tried but failed to recreate the issue locally; I recreated a bash script with the FilterBy()
function copied from source and ran some tests, but the filter seems to work as expected running locally.
I also realize we're several minor versions behind, but I haven't spotted anything in the code or release tags to indicate that there was a change to this behavior. I'm more than happy to upgrade and solve this, but without reproducing I'm wary of the upgrade not solving it.
Thanks for taking a look with me!
Update: we found the culprit...
The regex pattern we're using contains \d
which is part of Perl-compatible regex. Locally, we've been testing on MacOS, which uses BSD grep
and supports these expressions. However, in CircleCI we're running tests on a linux machine using GNU grep
which only supports basic (POSIX) expressions.
We'll resolve this on our end with an appropriate POSIX expression.
I'd like to leave this issue open for comment, though, as it might be valuable for documentation of the branch_pattern
parameter to specify that POSIX-compatible regex should be used, or there might be another suggestion for a pattern-matching mechanism that would work the same for different operating systems.
@nikbuskirk-dh, thank you for bringing this to our notice.
I'm modifying the parameter description to mention POSIX expressions as a requirement.