Repository navigation
fix: [ci] Run integration tests on ubuntu-24.04 to match php8.3 - #53
Merged
Merged
Conversation
The integration-tests job installs libapache2-mod-php8.3 but pins
runs-on: ubuntu-22.04. Jammy ships PHP 8.1 and has no php8.3 mod_php in its
default repos, so the job dies in "Install system deps" before any Rust code
runs:
E: Unable to locate package libapache2-mod-php8.3
The job header says it mirrors MISP core's .github/workflows/main.yml, but it
has drifted from it. MISP core pairs each PHP version with the distro that
ships that version's mod_php, and says so explicitly in its matrix:
# 8.1 stays on jammy (libapache2-mod-php8.1 is in its default repos);
# 8.3's mod_php is only shipped by default on noble, so pin it to 24.04.
- os: ubuntu-22.04
php: '8.1'
- os: ubuntu-24.04
php: '8.3'
Re-syncs with that rule by moving this job to ubuntu-24.04, keeping php8.3.
Also adopts MISP core's --allow-releaseinfo-change on apt-get update.
The unit-tests and parity-badges jobs are left on ubuntu-22.04: neither
installs mod_php, so neither is affected. (They will want moving separately
once ubuntu-22.04 runners are retired.)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01JoSButbVaWEtGMXwTx73BZ
…vents With the runner fixed, integration-tests finally ran and 29/30 passed. test_search_publish_and_metadata failed at "Published ev1 should appear". It is a race, not a client bug. CI enables SimpleBackgroundJobs with supervisor workers (ci.yml:241-265), and EventsController::publish() delegates to publishRouter(); with MISP.background_jobs on it returns "Job queued" immediately (app/Controller/EventsController.php:4958-4975) and a worker sets the published flag afterwards. The test searched for published events straight after publish(), so it could observe ev1 still unpublished. Adds wait_until_published(), which polls events/view until the flag flips (30s cap, then panics with a clear message so a genuinely stuck worker is not mistaken for a flaky assertion), and calls it after the publish. This failure is pre-existing on main and unrelated to the client fixes in the other open PRs; it was simply invisible while the job died at apt. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JoSButbVaWEtGMXwTx73BZ
The previous commit added wait_until_published() and used it in the search test, but test_event_crud_lifecycle still reads the event back immediately after publish(). CI runs MISP with SimpleBackgroundJobs and supervisor workers enabled, so publish() only queues the job and returns; the read races the worker and "assertion failed: pub_ev.published" fails: test result: FAILED. 29 passed; 1 failed panicked at tests/integration_tests.rs:229:5: assertion failed: pub_ev.published This is the last thing keeping integration-tests red, and because every open PR runs the same job, it keeps all of them red. Call the existing helper before reading back. It also settles the worker before the unpublish assertion a few lines down: without it the worker can set published back to true after unpublish() has run, which would fail that assertion instead of this one. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
This was referenced Sep 3, 2026
Draft
This was referenced Sep 3, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
BLUF — The
integration-testsjob pins a runner that has nophp8.3mod_php, so it fails before any Rust runs..github/workflows/ci.yml,integration-testsinstallslibapache2-mod-php8.3but pinsruns-on: ubuntu-22.04, which ships no such package, so the job dies in Install system deps on every PR and has done so onmainsince ~2026-03-25 — a pairing MISP core's matrix rules out.integration-teststoubuntu-24.04, adopts--allow-releaseinfo-changeonapt-get update, comments the pairing rule, and de-racestest_event_crud_lifecycleintests/integration_tests.rs.ubuntu-22.04/php8.3 apt failure and thetest_event_crud_lifecyclerace — both fixed by this PR.Problem
integration-testsfails on every open PR, and has been failing onmainsince ~2026-03-25. It dies in Install system deps, before any Rust code runs:The job installs
libapache2-mod-php8.3but pinsruns-on: ubuntu-22.04. Jammy ships PHP 8.1 and carries nophp8.3mod_php in its default repos, so the package genuinely does not exist there.Why this is a drift, not a new bug
The job header states it "Mirrors the MISP project's own CI setup from
.github/workflows/main.yml". MISP core pairs each PHP version with the distro that actually ships that version's mod_php, and says so explicitly in its matrix:RustMISP adopted the
8.3half of that pairing but kept the22.04half — the one combination MISP core's comment rules out.Change
integration-testsmoves toubuntu-24.04, keepinglibapache2-mod-php8.3, restoring the MISP-core pairing.--allow-releaseinfo-changeonapt-get update.unit-testsandparity-badgesstay onubuntu-22.04: neither installs mod_php, so neither is affected. They will want moving separately once GitHub retires the 22.04 runners.shivammathur/setup-php(CLI PHP 8.3) is unchanged — it is runner-agnostic and was never the failure.Verification
The only real proof is this PR's own CI run, since the failure is environmental and cannot be reproduced locally. YAML validated; no other line in the workflow depends on the runner's PHP version (there are no
/etc/php/8.3/...paths in this file).Worth noting: because
integration-testshas been dying at the apt step, the integration suite has not actually executed against any recent commit. Once this lands, genuine test failures may surface that were previously masked.🤖 Generated with Claude Code