Run arm64 tests on merge queue and master#11832
Conversation
Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
Co-authored-by: Sarah Chen <sarah.chen@datadoghq.com>
🟢 Java Benchmark SLOs — All performance SLOs passed
PR vs. master results
Commit: Load and DaCapo benchmarks can be triggered manually in the GitLab pipeline. Results will appear in the Benchmarking Platform UI after completion. |
This comment has been minimized.
This comment has been minimized.
|
/ddci trigger |
|
View all feedbacks in Devflow UI.
Tasks sourcing running asynchronously in workflow devflow:12b7b7cc-f1b5-46b6-994d-79c2c710b517_44:019f1fc4-d372-764e-a94d-e6a964b51039 under run id 019f1fc4-da75-7307-94a0-3bcde3f50b22 |
|
/merge -f --reason "arm64 MQ & master enabled, no need to re-run" |
|
View all feedbacks in Devflow UI.
The expected merge time in
Warning This change was merged without running any pre merge CI checks Reason: arm64 MQ & master enabled, no need to re-run |
What Does This Do
Reworks the
rulesin the shared.test_job_arm64template (inherited by all arm64 test jobs) so they trigger in three contexts:mq-working-branch-*): full matrix — both default and non-default JVMs — runningon_success(gating).8, 11, 17, 21, 25, tip) runningon_success(gating).manual,allow_failure: true(non-blocking).ibm8/oracle8are excluded across all variants via a single top guard rule (when: never) since no arm64 images are published upstream.Motivation
Previously arm64 jobs were
manual+allow_failureonly, so arm64 was never exercised automatically. This gives real coverage: the full JVM matrix runs in the merge queue, default JVMs gatemaster, and developers can still trigger default-JVM runs manually on MRs.Additional Notes
arm64tested on GitLab manually for ~1 month, no issues so far, let's give a shot.