.github/workflows/Benchmark.yml gates both of its triggers on a path that does not exist, so the kernel benchmark has not run on anything for seven months.
The filter
push:
branches: [master]
paths:
- "./Sources/AngouriMath/AngouriMath"
pull_request:
branches: ['*']
paths:
- "./Sources/AngouriMath/AngouriMath"Sources/AngouriMath/AngouriMath is not a path in the tree. The kernel is Sources/AngouriMath/, and the project file is Sources/AngouriMath/AngouriMath.csproj — there is no nested AngouriMath directory, and the pattern has no wildcard, so it can only ever match that one literal non-existent path. (The leading ./ is separately wrong — path filters are globs matched against repo-root-relative paths — but it does not matter, because the target does not exist either way.)
Measured
Last run of the workflow, from gh run list --workflow "Kernel Benchmark":
completed success fix: issue620 Updated referenced versions issue-620 pull_request 2026-01-02T14:24:55Z
The filter was re-added in f51c7e0 ("Update Benchmark.yml (#588)"), committed 2026-01-02 22:26:12 +0800 — 14:26 UTC, two minutes after that last run. The January runs happened during the #640 CI work while the filter was temporarily absent, which is why the history looks alive up to that point and stops dead there.
98 PRs have merged since 2026-01-02. None of them were benchmarked.
Why it matters
The inter-version CPU and RAM benchmarks are the mechanism behind #529 and #500, and they are the only automated guard on the thing @Happypig375 asked us to keep watching in #746 — that we do not lose speed or memory on popular use cases. Right now a PR can regress Simplify by any factor and CI will be entirely green.
Suggested fix
Sources/AngouriMath/** for both triggers. Worth deciding at the same time whether the pull_request leg should filter at all: the job takes 9–11 minutes, which is why the filter was presumably wanted, but a filter that silently matches nothing is worse than no filter.
A path-filter change cannot really be verified except by pushing something that should and should not trigger it, so whoever takes this should confirm the trigger fires rather than reasoning about the glob.
.github/workflows/Benchmark.ymlgates both of its triggers on a path that does not exist, so the kernel benchmark has not run on anything for seven months.The filter
Sources/AngouriMath/AngouriMathis not a path in the tree. The kernel isSources/AngouriMath/, and the project file isSources/AngouriMath/AngouriMath.csproj— there is no nestedAngouriMathdirectory, and the pattern has no wildcard, so it can only ever match that one literal non-existent path. (The leading./is separately wrong — path filters are globs matched against repo-root-relative paths — but it does not matter, because the target does not exist either way.)Measured
Last run of the workflow, from
gh run list --workflow "Kernel Benchmark":The filter was re-added in f51c7e0 ("Update Benchmark.yml (#588)"), committed
2026-01-02 22:26:12 +0800— 14:26 UTC, two minutes after that last run. The January runs happened during the #640 CI work while the filter was temporarily absent, which is why the history looks alive up to that point and stops dead there.98 PRs have merged since 2026-01-02. None of them were benchmarked.
Why it matters
The inter-version CPU and RAM benchmarks are the mechanism behind #529 and #500, and they are the only automated guard on the thing @Happypig375 asked us to keep watching in #746 — that we do not lose speed or memory on popular use cases. Right now a PR can regress
Simplifyby any factor and CI will be entirely green.Suggested fix
Sources/AngouriMath/**for both triggers. Worth deciding at the same time whether thepull_requestleg should filter at all: the job takes 9–11 minutes, which is why the filter was presumably wanted, but a filter that silently matches nothing is worse than no filter.A path-filter change cannot really be verified except by pushing something that should and should not trigger it, so whoever takes this should confirm the trigger fires rather than reasoning about the glob.