CI: split integration tests into parallel suites; shard the upgrade property test (#757)

[ako]

Closes #757

What was slow (measured, not guessed)

CI run 36319810164 (PR #742), make test-integration = 22.4 min of a 30 min step. Per package:

package	CI	local (10 cores, loaded)
mdl/roundtrip	1265 s (upgrade property test ~1160 s, laws ~100 s)	554 s (upgrade 471 s)
mdl/executor	933 s	not run
cmd/mxcli/docker	285 s	not run
mdl/upgrade (unit test, re-run under the tag)	167 s	—

go test already ran packages in parallel, so the step's wall time was mdl/roundtrip's alone; raising the timeout would not have made room for TestApp (#743).

Change

• Makefile: new suites test-integration-{executor,roundtrip,upgrade,other}. roundtrip = mdl/roundtrip with -skip ^TestUpgradeExecutesToTheSameModel$ (all round-trip laws + the execute-both controls); upgrade = that test alone; other = every other package that has integration-tagged tests, found by grepping the build tag (hidden dirs excluded), so a new integration package cannot be missed. make test-integration is unchanged in scope (./...), timeout 30m -> 60m.
• Upgrade property test: MXCLI_UPGRADE_SHARD=i/n executes every n-th executable script (round-robin). Every shard still upgrades/parses/checks every script (cheap). The "fewer than 50 executed" sanity floor scales to 50/n.
• push-test.yml: integration moved out of build-and-test into an integration matrix job: executor, roundtrip, upgrade 1/3, 2/3, 3/3, other (mxbuild only for executor/other), step timeout 30 min, job 45 min, plus an integration-passed aggregate job as one stable check name.
• nightly.yml: per-version step timeout 30 -> 60 min; new upgrade-full-corpus job (3 shards) with MXCLI_UPGRADE_ALL=1, once (independent of Mendix version), not gating the release.

Nothing leaves per-PR CI at its default scope: the round-trip laws and the execute-both upgrade test both still run. The only thing no longer run per PR is the unit tests of packages with no integration files being re-run under -tags integration; make test runs those.

Expected CI timings (per job, incl. ~3 min checkout/grammar/build)

job	expected
executor	~19 min (933 s + setup + mxbuild)
roundtrip	~4 min; room for TestApp (#743)
upgrade 1/3..3/3	~9-10 min each (1160 s / 3 + setup; ratio local 150-167 s vs 471 s unsharded)
other	~8 min
overall wall	~19-20 min, bounded by executor (was 22.4 min in one step)

Headroom: every suite's go test step is under ~2/3 of its 30 min step timeout. If executor grows it is the next to shard (by -run pattern).

Test plan (what I actually ran)

• make build, make lint (Go vet incl. -tags integration, TS) — pass.
• actionlint on both workflows — clean; control: renaming needs: integration makes it report the missing job.
• Baseline, unsharded: go test -tags integration ./mdl/roundtrip/ — pass, 554 s, 224 scripts executed, 452 header-only.
• Sharded, in parallel: MXCLI_UPGRADE_SHARD={1,2,3}/3 make test-integration-upgrade — pass, 150 s / 167 s / 161 s, executing 75 + 74 + 75 = 224 scripts, exactly the unsharded count.
• make test-integration-roundtrip — pass, 38 s; runs every roundtrip test except the property test (incl. controls, TestParseShard, TestShardsPartition).
• make -n test-integration-other resolves to ./cmd/mxcli ./cmd/mxcli/docker ./cmd/mxcli/marketplace. Not executed locally (needs mxbuild 11.12.2, which this machine lacks); CI runs it.
• Revert checks: shard.has returning true -> TestShardsPartition fails ("item 0 is in 2 shards"); dropping the 1 <= i <= n bound -> TestParseShard fails on 4/3.

Design choices not settled by the ADRs

• Sharding is round-robin over executed scripts (after the header-only filter), so shards balance the expensive work rather than the file list.
• integration-passed aggregate so a future branch rule does not have to list matrix legs.
• Carry Studio Pro content on create or modify of workflow, external entity, OData client and OData service; add TestApp to the round-trip test #743 will need submodules: true on the checkout of the roundtrip suite; left as a comment there rather than enabling it before the submodule exists.
• The nightly full-corpus job does not gate the nightly release, to keep release behaviour unchanged.

🤖 Generated with Claude Code