chore(.github/workflowsw): move main CI checks to merge queue runs#3887
Conversation
acd62bd to
b742c82
Compare
BenchmarksBenchmark execution time: 2025-09-03 14:40:47 Comparing candidate commit 957c7cf in PR branch Found 0 performance improvements and 0 performance regressions! Performance is the same for 24 metrics, 0 unstable metrics. |
d742705 to
849e00d
Compare
main CI checks to merge queue runsmain CI checks to merge queue runs
8635ff7 to
58b7fa2
Compare
f9521df to
bd8a68a
Compare
|
/merge |
|
View all feedbacks in Devflow UI.
This merge request is not mergeable yet, because of pending checks/missing approvals. It will be added to the queue as soon as checks pass and/or get approvals.
[email protected] unqueued this merge request |
| runs-on: ${{ matrix.runs-on }} | ||
| ref: ${{ inputs.ref || github.ref }} | ||
| secrets: inherit | ||
| go-version: "1.25" # Should be the highest supported version of Go |
There was a problem hiding this comment.
Would be neat if that supported the stable alias?
There was a problem hiding this comment.
That introduces the "risk" of having red CI if a new Go release causes the pipeline to fail. I prefer to have control, in the same line of the previous point about stating explicitly configs equivalent to the defaults.
|
/merge -c |
|
View all feedbacks in Devflow UI.
|
| inputs: | ||
| ref: | ||
| description: 'System Tests ref/tag/branch' | ||
| required: true | ||
| default: main | ||
| type: string | ||
| inputs: | ||
| ref: | ||
| description: 'System Tests ref/tag/branch' | ||
| required: true | ||
| default: main | ||
| type: string |
There was a problem hiding this comment.
Is it just me or I think this part in indented differently ?
There was a problem hiding this comment.
It had extra indentation, that's why it was modified.
…e soon-to-be merged PR as they ran on it
…flakiness is more probable while testing the PR
…and Integration Tests
…le validation workflow
ba0972d to
957c7cf
Compare
|
/merge |
|
View all feedbacks in Devflow UI.
The expected merge time in
|
…us (#4704) ## Problem The [CodeQL status page](https://github.com/DataDog/dd-trace-go/security/code-scanning/tools/CodeQL/status) shows the last scan date as **2025-09-03**, even though CodeQL runs successfully on every PR and every `mq-working-branch-**` push. This is an **association problem, not an execution problem.** GitHub Code Scanning indexes each SARIF upload by the `ref` the trigger event carried. The default-branch status panel only counts uploads tagged with `refs/heads/main`. CodeQL is running, but every upload it produces is filed under a non-default ref. ### Root cause PR #3887 (2025-09-04, _"move `main` CI checks to merge queue runs"_) restructured the workflow triggers: | Removed | Kept / Added | |---|---| | `push: branches: [main, master]` | `push: branches: [mq-working-branch-**]` | | `pull_request: branches: [main]` | `pull_request:` (no branch filter) | | `merge_group:` | `workflow_call:` (unused — no caller wires CodeQL) | After this change, CodeQL only ever sees refs of the form `refs/pull/<n>/merge` or `refs/heads/mq-working-branch-XXX`. The repository's merge mechanism fast-forwards `main` onto a green staging commit and deletes the staging branch — no `push` event for `refs/heads/main` fires, so CodeQL never runs against the default branch. The SARIF uploaded during the queue run stays tagged with the staging ref even after that exact SHA becomes `HEAD` of `main`. This is asymmetric with GitHub's _native_ merge queue: native queue events arrive on `refs/heads/gh-readonly-queue/main/<sha>` and Code Scanning rolls those uploads up to the default branch on completion. Custom queues built on fast-forward branches get no such roll-up. ### Why it matters - The [security tab](https://github.com/DataDog/dd-trace-go/security/code-scanning/tools/CodeQL/status) shows the configuration as inactive, which trips compliance alarms and looks like a regression to auditors. - New CodeQL findings introduced after 2025-09-03 are recorded against PR / staging refs and never roll up to the canonical `main` view. - Branch-protection rules of the form "CodeQL must be passing on default branch" can mis-report. ## Verification - [x] `git diff` shows exactly one inserted line: ` - main` - [x] `actionlint .github/workflows/codeql-analysis.yml` passes with no errors - [ ] After merge, the Actions tab shows a new "CodeQL" run on `refs/heads/main` - [ ] The [status page](https://github.com/DataDog/dd-trace-go/security/code-scanning/tools/CodeQL/status) shows a timestamp newer than 2025-09-03, still with configuration ID `FZTWS5DIOVRC653POJVWM3DPO5ZS6Y3PMRSXC3BNMFXGC3DZONUXGLTZNVWA` Co-authored-by: darccio <[email protected]>
What does this PR do?
Updates workflows so
mainCI checks happen during a merge queue run. Specifically it marks all workflows that run in push events tomainto run on those events on branches starting withmq-working-branch.Additionally:
pull_requesttriggers to explicitly setopened,reopened, andsynchronizeddefault states.tags-ignoreforpushtriggers to ignore all nested modules' version tags.merge_grouptriggers.synchronizedevent onpull-request-title-validation.pull-requestworkflow.main-branch-testswithpull-requests, making sure any flakiness is early detected.main-branch-testsrun only high-signalunit-integration-testswith a smaller set.system-tests.system-tests,pull-request, ormain-branch-tests.Motivation
Clarify CI usage and ensure that failing CI checks have visibility and impact. Currently we can only see if anything is wrong on
mainby looking at the CI checks for a commit in GitHub's UI.Note 1: this PR requires a small change on repository's settings to move the required checks
PR Unit and Integration Tests / test-coreandPR Unit and Integration Tests / test-contribtoPR Unit and Integration Tests.Note 2: this PR would cause that no check will run if somebody with admin privileges doesn't use the merge queue. It should be possible to avoid that by setting some kind of break glass job that must run when merging directly from the UI. Merge queue should work by skipping it.
Reviewer's Checklist
./scripts/lint.shlocally.Unsure? Have a question? Request a review!