Regular expression matching not working as expected

[luishernandezv]

I'm having an issue with regular expressions matching with Bats 1.11.0 in macOS Sonoma 14.5.

Say you have the following resources

kubectl get pods -n foo                                                                                                                              
NAME                                                      READY   STATUS    RESTARTS   AGE
my-pod-5fcfc99f7-hnt5x                      1/1     Running   0          119m

And the following test:

load "lib/utils"
load "lib/detik"

DETIK_CLIENT_NAME="kubectl"
DETIK_CLIENT_NAMESPACE="foo"

@test "should find pods" {
    try "at most 1 times every 5s to get pod named '^my-pod-[a-z0-9]{9,10}-[a-z0-9]{5}$' and verify that 'status' is 'running'"
}

This test would fail with no matches found.

Now I see that in this line the grep is not using extended regular expressions which might be partially the cause of this issue. I have verified that is not just adding -E to that grep to make it work since using the $ to match to the end of the line would still cause some issues

Look at the return of the eval

eval kubectl --namespace=foo get pod -o custom-columns=NAME:.metadata.name,PROP:.status.phase 
# my-manager-5fcfc99f7-hnt5x               Running

My question is, is this expected behaviour? If it is, should it be added to the docs?

Also one thing I noticed is that using the examples for the Regex in the docs using multi line will result in Invalid expression: it does not respect the expected syntax.

Thanks.

[vincent-zurczak]

Indeed, it appears as a huge mistake in the README.
We do support regular expressions in attributes values. But not in resource names. Maybe this is a feature we should have.

[vincent-zurczak]

The good news is that fixing it is fairly simple.
Using grep -E for resource names is fine. However, you would have one change to apply on your regular expression, i.e. ^my-pod-[a-z0-9]{9,10}-[a-z0-9]{5}\b. That's because grep will return the entire line.

Would it be acceptable for you @luishernandezv?
Given that resource names in K8s cannot include spaces, that should normally not be an issue.

[vincent-zurczak]

I am spamming this issue, sorry.
But we could also review the way we work to really extract the resource name only and apply it the grep -E filter. This way, you could keep the original regexp.

[luishernandezv]

The good news is that fixing it is fairly simple. Using grep -E for resource names is fine. However, you would have one change to apply on your regular expression, i.e. ^my-pod-[a-z0-9]{9,10}-[a-z0-9]{5}\b. That's because grep will return the entire line.

Would it be acceptable for you @luishernandezv? Given that resource names in K8s cannot include spaces, that should normally not be an issue.

I think it might be confusing for users to have a regex matching on something that is not necessarily the resource name but a string that includes other properties. Like I understand it could make it work but I think it would make kind of hard for users to sort that out unless the docs explicitly show examples explaining why $ wouldn't work in their regex for example

I am spamming this issue, sorry.
But we could also review the way we work to really extract the resource name only and apply it the grep -E filter. This way, > you could keep the original regexp.

This sounds like a better solution, another thing to consider is detik could transform the regex to account for the state, not sure if it is feasible but like you suggested something like this:

^my-pod-[a-z0-9]{9,10}-[a-z0-9]{5}$ maybe could be automatically transformed into ^my-pod-[a-z0-9]{9,10}-[a-z0-9]{5}\b

Instead of the user doing it the library does it for you. This would be more clear for the library user but it might be a hacky thing to implement.

[vincent-zurczak]

Hello,

A PR is in progress.
You can review the README file if you want. Basically, it fits the original requirement.

[vincent-zurczak]

The version 1.3.2 has just been published and fixes this issue.

[luishernandezv]

Thanks @vincent-zurczak I'll give it a shot