[improve][ci] Upgrade GitHub Actions to latest and ASF-approved revisions

[lhotari]

Motivation

Two Docker actions in our workflows are pinned to SHAs that are not on the ASF org-wide allowlist:

action	pinned SHA	on allowlist?
docker/setup-buildx-action	4d04d5d9	❌ no
docker/setup-qemu-action	ce360397	❌ no
docker/build-push-action	53b7df96	✅ yes (v7.3.0, current)

When a workflow references an action that is not allowlisted, the run fails with a bare "Startup failure" — per ASF infra: "no logs, no notifications, and the PR may appear green because no checks ran."

That is not hypothetical. #605 hit it: its PR validation run never started, so the build and unit tests did not execute on that head, while CodeQL and Analyze (cpp) still reported success — the PR looked green with its actual test suite never having run.

Modifications

ASF-allowlisted third-party actions — bumped to the latest approved revisions from apache/infrastructure-actions/actions.yml, with the tag in a trailing comment so Dependabot can track them (the recommended, Zizmor-friendly form):

• docker/setup-buildx-action → 37fe6310  # v4.3.0
• docker/setup-qemu-action → 96fe6ef7  # v4.2.0
• docker/build-push-action → unchanged SHA, comment added # v7.3.0
• jidicula/clang-format-action v4.11.0 → v4.18.0 (allowlisted via a @* wildcard)

GitHub-owned actions — the allowlist implicitly trusts actions/* and github/*, so these move to their latest majors:

• actions/checkout v3, v4 → v7 (12 call sites)
• actions/cache v3, v4 → v6 (9 call sites)
• actions/upload-artifact master → v7 (4 call sites)
• github/codeql-action/{init,analyze} v3 → v4

actions/upload-artifact was tracking @master — an unpinned moving target that could change under us at any time.

Verifying this change

The diff touches only uses: lines; no workflow logic changed. Verified locally:

• every non-GitHub-owned uses: ref now matches an entry in approved_patterns.yml, applying the same rules as apache/infrastructure-actions/allowlist-check
• all three workflow files still parse as YAML
• all four upload-artifact call sites already use unique, matrix-derived artifact names, so the v4+ "one upload per artifact name" restriction is satisfied

The real verification is this PR's own CI: if PR validation starts and runs to completion, the allowlist problem is fixed.

Follow-up worth considering

Adding the apache/infrastructure-actions/allowlist-check job to CI would catch this class of breakage at PR time instead of letting it surface as a silent startup failure. Left out here to keep this change to version bumps.

Does this pull request potentially affect one of the following parts:

• Dependencies (does it add or upgrade a dependency): yes (CI actions only; no change to the shipped client library)

Documentation

• doc-not-needed

[lhotari]

CI status: the allowlist fix works; the one remaining failure is pre-existing

The fix does what it is meant to. PR validation ran to completion on this branch instead of dying at startup — build, formatting, and 5 of 6 jobs green. That is the first PR validation run to actually execute on this repo since 2026-07-20; everything since has either hit startup_failure or not run.

The one failure is not from this change. This diff touches only uses: lines, so it cannot alter C++ behaviour. What failed:

tests/ReaderTest.cc:1001: Failure
Value of: hasMessageAvailable
  Actual: true
Expected: false
[  FAILED  ] Pulsar/ReaderSeekTest.testSeekToEndByTimestamp/0 and /1

Failed on all 3 retries for both parameters, so it is consistent rather than flaky.

Most likely cause: broker drift through an unpinned image. pulsar-test-service-start.sh starts the test broker from apachepulsar/pulsar:latest. That tag now resolves to 4.2.4, published 2026-08-03 — after the last green run on 07-20 and before this one. The test asserts client-visible behaviour of seek(INT64_MAX) by timestamp, which is broker-side behaviour, and its own comment notes the dependency on how the Java broker handles the timestamp.

I checked the alternatives and they do not hold up: the only commit touching tests/ReaderTest.cc, lib/ConsumerImpl.cc or lib/ReaderImpl.cc since the last green run is #604, and its diff does not touch seek, hasMessageAvailable, startMessageId or lastMessageIdInBroker — it only adds chunk handling.

So the honest reading is that main has been failing this test for roughly four weeks and nobody could see it, because the allowlist problem meant CI never ran.

Suggested split, since these are separate concerns:

1. Merge this PR on the strength of the startup failure being fixed — it strictly improves the situation and unblocks CI for every other PR.
2. Handle testSeekToEndByTimestamp separately: either adapt the expectation to Pulsar 4.2.4's behaviour if the change is intentional upstream, or treat it as a real client bug against newer brokers.
3. Consider pinning the test broker image rather than tracking :latest, so a broker release cannot turn CI red without a commit. I deliberately left that out of this PR — it changes test behaviour, and pinning could equally mask a genuine incompatibility, so it deserves its own decision.

Happy to take 2 or 3 in a follow-up.

[lhotari]

Correction: testSeekToEndByTimestamp is intermittent, not a deterministic 4.2.4 regression

New evidence changes the diagnosis I gave above, so flagging it before anyone acts on it.

#605 has now had a full PR validation run on 740b0500 — all 12 jobs green, including "Run unit tests". That branch carries the same #604 base, the same broker image (apachepulsar/pulsar:latest → 4.2.4) and the same action pins this PR introduced. So Pulsar/ReaderSeekTest.testSeekToEndByTimestamp failed 3/3 retries here and passed cleanly there.

That makes it flaky across runs, not a hard incompatibility with Pulsar 4.2.4. What misled me is that RETRY_FAILED=3 retries within a single run, so three consecutive failures show consistency inside one run while saying nothing about reproducibility across runs.

Revising the suggestions I made earlier:

• Point 2 stands, but reframed: testSeekToEndByTimestamp is worth treating as a flaky test to investigate, not a broken expectation to rewrite. Rewriting the assertion against 4.2.4 behaviour would have been the wrong fix.
• Point 3 (pinning the test broker image instead of tracking :latest) still seems worthwhile for reproducibility, but it is no longer supported by this particular failure.

The main claim in this PR is unaffected: the allowlist fix is what let PR validation run at all, and #605's green run is the confirmation — that repo had no successful PR validation run between 2026-07-20 and this change.