[Feature] Procedure filters

[C0untZero]

At the moment creating a procedure to, for instance, deploy or redeploy all stacks on a server is tedious - you have to specifically add a DeployStack action for each stack on the server. And this is not limited to stacks only, any procedure action with a target resource is the same.

Based on our discussion on Discord, filters could help with this. The idea is to create one action with a filter target which could then filter on any resource property, like name, server, tag, image registry, git provider/account etc. The target dropdown should have a use custom filter option at the top which when pressed shows a query building window. This window should have a list of properties we can filter on for the relevant resource type (based on selected action). Each property to filter on would support exact name matching, simple wildcard search, or advanced regex matching. An example toml for a filter would be any of the three options below:

[[filter]]
server = "server1"

[[filter]]
name = "$reg\arr$\"

[[filter]]
name = "*arr"

Once a filter is created and the query window is closed, the target column for the configured row should show the filter query instead of a specific resource name:

Another nice to have feature would also be to show resource names that matched the query when the filter is hovered over, or maybe in the query config window at the bottom or something.

A simple implementation for this would be wildcard matching multiple resources based on one property.
A more advanced implementation could be built from this to support regex as well as matching on multiple properties using logic operators AND, OR, NOT, etc. Something akin to JQL - KQL (Komodo Query Language) maybe? ;)

[mbecker20]

Thanks for the write up C0unt!

It's going to be a great feature and I'm really excited by the possibilities here. I'm not sure how I will include it in the upcoming versions at this point, maybe hesitantly in 1.15. For now I will leave it as an enhancement.

🦎

[mbecker20]

Regex support at the library level will be using the already included regex crate.
In terms of "Wildcard" syntax, we can use the cloudflare standard handled by their wilcard crate.

[mbecker20]

1.16.5 gets most of the way there. It doesn't allow you to match on anything other than the resource name though, and currently doesn't have any preview of which resources are matched.

[C0untZero]

Looking good, thanks for the progress on this.

I'm not sure about the decision of introducing duplicate actions with batch in name. Kinda crowds the action list imo.
Is this just temporary until the full query builder interface is built?

[mbecker20]

Thanks for the quick feedback. There is a reason it was done this way, I can try to explain.

There is another issue #93 which request to be able to make executions on more than one Stacks / Containers by selecting multiple in the table. This is best accomplished by adding ability to eg DeployStack, but target more than one Stack in the call.

Looking at the API for DeployStack, you see it returns a single Update. This is an issue, because a batch call to this API will under the hood call DeployStack on the individual stacks, each will produce an Update.

If you call to DeployStack targeting multiple Stacks, the return type of the data should actually be something like Vec<Update>, a list of all of the Updates for each Stacks deploy. So either the return type of DeployStack needs to change, or it needs another api. I think DeployStack -> Update is still a good API to expose and want to keep it as it is, so BatchDeployStack and the other Batch executions were created.

They all have this return type: BatchExecutionResponse. It is basically Vec<Update> but with some error handling, each underlying Update in the batch call may instead be some Error case which needs to be returned to user.

With this Batch execution handling setup, the frontend can use it to handle the batch executions when user select multiple resources in a table, and also Actions can call this API directly.

For Procedures, I felt it was clearer to make this matching behavior explicit at API method level. This way, Procedures continue to map 1-to-1 with the behavior of the API when called outside of Procedures. Ie, it won't work to call the DeployStack api directly passing arr-* as the stack, but using that with BatchDeployStack will work. Procedures just follow this standard, users should use the Batch apis if they intend to do a batch execution targetting multiple underlying resources.

The only downside I can see is the crowding of action list. But there is a search feature there, its not too bad when you start typing deploy.

[C0untZero]

Ok, now that I understand the backend part it makes sense. The search feature does make it easy though, so I guess it's all good.