benchmarks.yml: Run on addition of label instead of comment

[EwoutH]

Instead of triggering on a specific comment, which caused issues with running in a different scope (issue_comment instead of pull_request_target), the workflow can now instead be triggered by adding a label "trigger-benchmarks" to the PR.

The label can be repeatedly added and removed to rerun benchmarks.

[github-actions]

Performance benchmarks:

Model	Size	Init time [95% CI]	Run time [95% CI]
Schelling	small	🔵 +1.3% [+1.0%, +1.5%]	🔵 +0.2% [+0.0%, +0.3%]
Schelling	large	🔵 +0.7% [+0.4%, +1.0%]	🔵 -1.2% [-2.4%, +0.0%]
WolfSheep	small	🔵 +0.5% [+0.1%, +0.8%]	🔵 +0.5% [+0.4%, +0.6%]
WolfSheep	large	🔵 +0.1% [-1.2%, +1.5%]	🔵 +0.1% [-1.8%, +2.0%]
BoidFlockers	small	🔵 +1.1% [+0.8%, +1.4%]	🔵 +1.9% [+1.3%, +2.5%]
BoidFlockers	large	🔵 +0.9% [+0.5%, +1.3%]	🔵 +1.1% [+0.6%, +1.6%]

[Corvince]

If this works this is probably a good solution. While your changing the trigger, maybe also now deactivate the trigger on open pull requests? I think a lot of PRs a not related to performance and the performance benchmark is a bit distracting there. Or maybe run on every PR, but don't comment without the label?

[rht]

What about reacting to the existing benchmark comment with a rocket emoji to retrigger the benchmark? Figuring out a more convenient way to do the retrigger than removing and readding the label.

[EwoutH]

@rht Good idea, but unfortunatly this only works if it's specifically in the PR scope. Everything related to comments isn't. Just an limitation of events in GitHub Actions.

A label is related to the PR scope, so thus it works.

@Corvince I like the explicit confirmation that a PR doesn't change performance. But I also recognize it can add noise. Let me think about it a bit.

[quaquel]

I also like the explicit performance check. Another hidden benefit is that it is a form of integration testing because we run three full models through the benchmark. Some of the weird backward compatibility issues we have seen would have been caught if this machinery had been in place.

[EwoutH]

I can’t think of a more elegant solution than using the label, consider the restrictions of GitHub Actions.

In #1999 I ensured the benchmarks don’t change if there weren’t Python code changes. That should help a little against the noise.

I would be in favor of merging this.

[quaquel]

looks good to me