keith / rules_multirun

Bazel rules for running multiple commands in parallel in a single bazel invocation
Apache License 2.0
72 stars 15 forks source link

Need to passthru bazel provider from one of command to multirun target #26

Closed farcop closed 7 months ago

farcop commented 10 months ago

Hello!

I have a multirun that push and sign image sequential.

    multirun(
        name = "push_and_sign",
        commands = [
            ":push_index",
            ":attest",
            ":sign",
        ],
    )

In push_index target I have custom provider similar to PushInfo and need to be exposed after push_and_sign run.

Is it possible to do this?

keith commented 10 months ago

Right now this isn't possible. As a quick workaround you could potentially wrap your multirun rule in another custom rule that used an aspect to extract the provider.

Thinking about how we could implement this in rules_multirun, the issue I see is about combining providers if multiple existed in the targets in commands.

In a theoretical world where you could pass an extra list of providers to the rule:

    multirun(
        name = "push_and_sign",
        commands = [
            ":push_index",
            ":attest",
            ":sign",
        ],
        propagate_providers = [PushInfo],
    )

We'd still have the issue in the implementation of how to pick these:

extra_providers = []
for command in ctx.attr.commands:
    for provider in ctx.attr.propagate_providers:
        if provider in command:
            extra_providers.append(provider) # This would cause issues if multiple targets had this provider

...

return extra_providers + ...

While this example wouldn't work I think if we could solve this issue we could come up with something. I think this example https://github.com/fmeum/rules_meta/blob/64ef1ae48adecb50d3101a7e7dff6c5c489cdc43/meta/internal/forwarding.bzl#L37-L40 does actually work how we'd need if we could solve this. I imagine we could do something complex around providing a way to pass a function to combine them, but that might get unwieldy from the caller side.