[low] ci: require a version bump when a cluster or galaxy's content changes

[elhoim]

BLUF — CI now requires a version bump whenever a cluster or galaxy's content changes in a PR

• Problem — MISP only re-imports a galaxy or cluster file whose version is higher than the one an instance holds, but nothing here enforces that: 685 commits across 70 files changed content without bumping version, so those edits never reached instances with the old copy.
• Fix — Add tools/chk_version_bump.py, which re-serialises each changed file with version removed, compares it to the base branch and requires a strict increase when content differs, wired into .github/workflows/pytest.yml.
• Effect — A content edit without a bump is caught in review; only files a PR touches are inspected, so the backlog does not turn CI permanently red.
• Cost — Contributors must bump version on any content change to a cluster or galaxy, or the PR fails CI.

Problem

MISP synchronises galaxies by version: an instance only re-imports a file whose version is higher than the one it already holds. So content that changes without the version moving is committed here and never reaches any instance that already has the old copy — the edit is invisible everywhere it matters, and nothing warns about it.

It happens routinely. Walking first-parent history and hashing each file's content with version removed (so the ~429 pure-reformat commits are excluded):

685 commits across 70 files changed content without bumping `version`
  threat-actor.json  315
  ransomware.json     76
  tool.json           53
  rat.json            29
  target-information  15
  attck4fraud         11
  malpedia            10
  ...

Fix

tools/chk_version_bump.py compares the working tree against a baseline revision. For each changed cluster or galaxy it re-serialises the document with version removed and compares that against the baseline's; if the content differs, version must have strictly increased.

Two properties keep it from being noisy:

• It only inspects files the change actually touches, so it never fails for history it did not cause — no backfill needed and no permanently-red CI.
• Ignoring version when comparing content means a version-only bump is not mistaken for a content change, and a reformat that leaves content identical does not demand a bump.

The CI step runs it against the PR's base branch. GITHUB_BASE_REF is an Actions-provided branch name rather than user-authored text, and it is read as an environment variable rather than interpolated into the script.

Verification

All four cases:

=== 1. clean tree: nothing changed, must PASS ===
No cluster or galaxy files changed against origin/main.
   exit=0

=== 2. content changed, version NOT bumped: must FAIL ===
  FAIL  clusters/tea-matrix.json    content changed, version 2 -> 2
   exit=1

=== 3. same content change WITH a version bump: must PASS ===
  OK    clusters/tea-matrix.json    bumped (2 -> 3)
   exit=0

=== 4. version bumped but content identical: must PASS (no false positive) ===
No content changes in clusters/ or galaxies/.
   exit=0

The workflow YAML parses and the step is ordered after validate_all.sh.

Note

Two clusters currently sit below a version they have already published (tidal-software.json at 1 against a historic 2, nace.json at 2 against a historic 2.1), which this check cannot see because it only looks at the diff. That is fixed separately.

🤖 Generated with Claude Code

[elhoim]

Note for merging: #1283 also adds a step to .github/workflows/pytest.yml and the same fetch-depth: 0 on the checkout step. Whichever of the two merges second will need a trivial conflict resolution there — the two checks are independent and both steps should end up present.