Is your feature request related to a problem or challenge?
The present CI benches use the issue_comment event type, and are triggered by a /benchmark keyword in a PR comment.
This now works, but there are some issues with the dev experience around it, as demonstrated in #9620.
In particular the issue_comment event type will use the workflow as it is on the default (i.e. main) branch, meaning any changes introduced to it via a PR can't be tested until the PR is merged, which is suboptimal.
Describe the solution you'd like
The proper way to test new changes to this workflow is to use the pull_request event type, which would enable a tight feedback loop during development (i.e. testing the workflow version that is in the PR code). However to my knowledge this event type can't be triggered by a PR comment then (the sole purpose of this is to reduce noise, and don't benchmark/comment on every PR/change).
Instead, the pull_request-based workflow can be made conditional upon a label.
In addition, the Benchmarks workflow could be triggered through a workflow_call event from inside the Rust workflow (which itself has a pull_request event trigger). This would ensure that the benches could be run only if the build/tests pass. One downside to this though is that the whole chain would need to be kickstarted again (by a push or manually) even once the label has been added to get the first benchmark results. Every subsequent run would then perform benchmarks (as long as the label is present).
Describe alternatives you've considered
Continue with multi-step development, since this is probably not going to be changed that often.
Additional context
No response
Is your feature request related to a problem or challenge?
The present CI benches use the
issue_commentevent type, and are triggered by a/benchmarkkeyword in a PR comment.This now works, but there are some issues with the dev experience around it, as demonstrated in #9620.
In particular the
issue_commentevent type will use the workflow as it is on the default (i.e. main) branch, meaning any changes introduced to it via a PR can't be tested until the PR is merged, which is suboptimal.Describe the solution you'd like
The proper way to test new changes to this workflow is to use the
pull_requestevent type, which would enable a tight feedback loop during development (i.e. testing the workflow version that is in the PR code). However to my knowledge this event type can't be triggered by a PR comment then (the sole purpose of this is to reduce noise, and don't benchmark/comment on every PR/change).Instead, the
pull_request-based workflow can be made conditional upon a label.In addition, the
Benchmarksworkflow could be triggered through a workflow_call event from inside theRustworkflow (which itself has apull_requestevent trigger). This would ensure that the benches could be run only if the build/tests pass. One downside to this though is that the whole chain would need to be kickstarted again (by a push or manually) even once the label has been added to get the first benchmark results. Every subsequent run would then perform benchmarks (as long as the label is present).Describe alternatives you've considered
Continue with multi-step development, since this is probably not going to be changed that often.
Additional context
No response