-
Notifications
You must be signed in to change notification settings - Fork 881
chore: allow search by build params in workspace search filter #12694
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. |
061909b
to
3fe88c4
Compare
8112eb2
to
aecf9c0
Compare
aca699c
to
2bcdbd9
Compare
2bcdbd9
to
819e861
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM but would like to see some more test cases before merge
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I pointed a couple of fuses to check.
@@ -184,6 +194,40 @@ WHERE | |||
workspaces.owner_id = @owner_id | |||
ELSE true | |||
END | |||
-- Filter by build parameter | |||
-- @has_param will match any build that includes the parameter. | |||
AND CASE WHEN array_length(@has_param :: text[], 1) > 0 THEN |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
As this operates on 1 and 0, maybe we can simplify it:
AND (
array_length(@has_param :: text[], 1) = 0
OR EXISTS (
SELECT 1
FROM workspace_build_parameters
WHERE
workspace_build_parameters.workspace_build_id = latest_build.id AND
workspace_build_parameters.name ILIKE ANY(@has_param)
)
)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that is true, however we have this CASE WHEN
syntax for other params, and other array style params. Do you feel it's worth having a differing syntax?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I admit that I like the consistency, although it is tempting to simplify this query wherever it is possible. Anyway, this is not a must-have, your syntax is also correct 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm going to decide to leave it for consistency. All the params are identical right now in how they are handled.
{ | ||
Name: "ParamExcessValue", | ||
Query: "param:foo=bar=baz", | ||
ExpectedErrorContains: "can only contain 1 '='", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it would be great to see if the user can set the parameter value to a random string with =
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
You are correct, an equals sign in the right hand side will break this.
The parser here is pretty dumb. 😢
What this does
closes: #10661
Adds a
param:<name>[=<value>]
option to the workspaces search.param:name
will match any workspace that has the parameter valueparam:name=value
will match only if the parameter has the value given.param:name=value1 param:name=value2
will match both.Demo:
Screencast.from.2024-03-20.14-58-40.webm
Wildcard support
I want to get this PR in and working in the exact match state. I have an open PR for allowing a more regex style support.