[CI] Add CI workflow to run compute-benchmarks on incoming syclos PRs

[ianayl]

This PR:

• adds a "benchmark" mode to sycl-linux-run-tests.yml, which benchmarks a given SYCL branch/build using compute-benchmarks
  • stores benchmark results in a git repo, and
  • aggregates benchmark results in order to produce a median, which is used to pass or fail the benchmark workflow

The current plan is to enable this benchmark to run nightly in order to catch regressions, although there is potential for this workflow to be used in precommit. As a result, a lot of components in this workflow are either separate reusable components, or directly written with precommit in mind. The current benchmarking workflow functions as so:

1. An "aggregate" workflow is ran, which aggregates historic benchmark results in the aforementioned git repo, and produces a historical median
   • This calls upon aggregate.py to handle the actual compute heavy-lifting
2. The core benchmarking workflow is ran:
   • This calls upon benchmark.sh, which handles the logic for building and running compute-benchmarks
   • Then, compare.py is called upon for the actual comparing of benchmark data against the historical median generated prior

The workflows are fully configurable via benchmark-ci.conf; enabled compute-benchmarks tests can be configured via enabled_tests.conf.

Feel free to test out the workflow via manual dispatches of sycl-linux-run-tests.yml on branch benchmarking-workflow, but be aware that the run currently will always fail, as Github repository secrets are not yet added.

[ianayl]

@uditagarwal97 @aelovikov-intel Mind if I ask for another review? Thanks in advance!
Latest run is here: https://github.com/intel/llvm/actions/runs/13140739081.

[aelovikov-intel]

Do we prohibit >= 10 days?

[ianayl]

Good catch, thanks!

[aelovikov-intel]

In that case, why isn't type: number enough?

[ianayl]

It probably is, but I've learned that github in itself is a vulnerability (e.g. failure to scrub secrets, injections via branch names); This doesn't seem too extreme, and I'd rather not rely on github if it's convenient.

[aelovikov-intel]

Why do we calculate it here instead of making it part of the results repo calculated on each upload?

[ianayl]

That's a good point; I think there was a discussion long time ago, and the conclusion was that all code should be stored in this repo, although I forget why this was done. Let me address this at the next meeting.