Bump CI cache key

[malberts]

To get newer versions of MW with updated PHPUnit dependency. Current CI fails due to a security issue in older PHPUnit.

Summary by CodeRabbit

• Chores
  • Updated CI pipeline cache version identifier from v21 to v22 to align caching across runs.
  • Ensures caches are invalidated and refreshed consistently when pipeline cache version changes.
  • No functional behavior or build logic was altered; this is a cache/versioning maintenance update.

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

---

📝 Walkthrough

Walkthrough

Updated the CI workflow cache key for MediaWiki in the repository's GitHub Actions configuration: the MediaWiki cache key suffix changed from v21 to v22. No other logic or control-flow changes were made.

Changes

Cohort / File(s)	Summary
CI Workflow Cache Key \.github/workflows/ci\.yml	Updated MediaWiki cache key version suffix from v21 to v22.

Estimated code review effort

🎯 1 (Trivial) | ⏱️ ~2 minutes

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.
Title check	✅ Passed	The title 'Bump CI cache key' accurately describes the main change—updating the CI cache key version from v21 to v22 in the workflow file.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Post copyable unit tests in a comment
• Commit unit tests in branch malberts-patch-3

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Caution

Some comments are outside the diff and can’t be posted inline due to platform limitations.

⚠️ Outside diff range comments (1)

.github/workflows/ci.yml (1)

226-232: ⚠️ Potential issue | 🟡 Minor

code-style Composer cache key not bumped — inconsistent with PHPStan.

The PHPStan job's Composer cache was updated from composer_static_analysis → composer_static_analysis-v1 (line 172), but the code-style job at line 232 still uses the original composer_static_analysis. Both jobs previously shared this key, so if stale cached packages are the root cause of CI failures, code-style will continue to restore the old cache and may still be affected.

🔧 Proposed fix

-          key: composer_static_analysis
+          key: composer_static_analysis-v1

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml around lines 226 - 232, The code-style job's
Composer cache block still uses the old key value "composer_static_analysis",
which is inconsistent with the PHPStan job that was bumped to
"composer_static_analysis-v1"; update the cache action in the code-style job
(the "Cache Composer cache" step) to use the same key
("composer_static_analysis-v1") so both jobs share the updated cache identifier.

🧹 Nitpick comments (1)

.github/workflows/ci.yml (1)

158-167: PHPStan MediaWiki cache includes vendor/ but its key (mw_phpstan) was not bumped.

Unlike the other jobs, the PHPStan MediaWiki cache path includes mediawiki/vendor/ (no ! exclusion), so the old vendor tree — potentially containing the vulnerable PHPUnit — is restored before composer update runs. In practice composer update (line 190) will overwrite it, but a stale restore still lands on disk momentarily. Consider bumping this key to mw_phpstan-v1 for consistency and to force installMediaWiki.sh to re-run with a clean slate.

🔧 Proposed fix

-          key: mw_phpstan
+          key: mw_phpstan-v1

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In @.github/workflows/ci.yml around lines 158 - 167, The cache key for the
"Cache MediaWiki" step (id: cache-mediawiki) still uses the old value
"mw_phpstan" while its path includes mediawiki/vendor/, so stale vendor files
may be restored; update the key to a new value (e.g. "mw_phpstan-v1") in the
with:key entry to force a fresh install (so installMediaWiki.sh / composer
update runs against a clean workspace) and ensure any dependent logic using the
key is updated if referenced elsewhere.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Outside diff comments:
In @.github/workflows/ci.yml:
- Around line 226-232: The code-style job's Composer cache block still uses the
old key value "composer_static_analysis", which is inconsistent with the PHPStan
job that was bumped to "composer_static_analysis-v1"; update the cache action in
the code-style job (the "Cache Composer cache" step) to use the same key
("composer_static_analysis-v1") so both jobs share the updated cache identifier.

---

Nitpick comments:
In @.github/workflows/ci.yml:
- Around line 158-167: The cache key for the "Cache MediaWiki" step (id:
cache-mediawiki) still uses the old value "mw_phpstan" while its path includes
mediawiki/vendor/, so stale vendor files may be restored; update the key to a
new value (e.g. "mw_phpstan-v1") in the with:key entry to force a fresh install
(so installMediaWiki.sh / composer update runs against a clean workspace) and
ensure any dependent logic using the key is updated if referenced elsewhere.