tests.yaml: a new package's own test job can never trigger on its own changes

[antejavor]

What

tests.yaml gates the whole workflow on a top-level paths: filter listing each package directory. For a pull_request event that filter is evaluated against the base branch's copy of the workflow, not the PR's. So a PR that introduces a new package — and dutifully adds it to paths: and to the changes job's filter — still gets no workflow run at all when a push touches only that new package's files.

The job is configured correctly. It just never fires, because the decision to start the workflow is made before the PR's own workflow file is consulted.

Evidence

Observed on #311, which adds context-graph/eval:

commit	files touched	github-actions check suite created?
a211819	context-graph/agent-context-graph/** (in main's paths)	yes
45937ae	context-graph/eval/** only (in the branch's paths, not main's)	no

$ gh api repos/memgraph/ai-toolkit/commits/45937ae/check-suites --jq '.check_suites[].app.slug'
cursor
claude          # <- no github-actions suite

Three commits pushed 2026-08-28 touched only context-graph/eval/** and produced zero workflow runs. The branch went five days with no CI while looking untested-but-fine, and the test-context-graph-eval job — which exists on that branch and passes — had never once run against those commits.

Why it matters beyond the one PR

Two failure modes, and the second is the expensive one:

1. A new package is unprotected for exactly as long as it takes to merge it. Its tests run only incidentally, when the PR also happens to touch an older package.
2. It reads as green. No run means no failed check, so nothing on the PR says "untested". A reviewer sees a clean checks list. Compare with a job that runs and fails, which is self-announcing.

Related but separate: a genuine red also went unnoticed on the same PR — test-sessions-graph (3.10) failed on 2026-08-27 and stayed failed, because the next three pushes produced no runs to re-surface it. Fixed in #311, but the reason it stayed hidden is this.

Suggested fix

Either of:

• Drop the top-level paths: filter and rely on the changes job (dorny/paths-filter) that already exists. That filter runs inside the workflow, so it uses the PR's own definition and does not have this blind spot. The top-level filter is then redundant — it is a second, weaker copy of the same list, and the two must be kept in sync by hand.
• Or add an unfiltered fallback job that runs the whole workspace suite, so a package is never silently uncovered regardless of the filters.

The first is less machinery and removes a duplicated list. Note that the changes job is cheap (~7s) so paying it unconditionally costs little.

_{Found while merging main into #311.}