ci: fix CodeQL/daily schedule and add workflow_dispatch

[Copilot]

codeql-daily.yml was named "daily" but ran weekly (Thursdays only), and had no workflow_dispatch trigger — making it impossible to manually re-run the analysis on demand (e.g. to auto-close a false-positive alert without waiting up to a week).

Changes

• on.schedule: 0 12 * * 4 → 0 12 * * * (actually daily at 12:00 UTC)
• on.workflow_dispatch: added (no inputs) to enable manual runs from the Actions UI

on:
  schedule:
  - cron: '0 12 * * *'
  workflow_dispatch:

Note: the manual-trigger button only appears after this merges to main.

Original prompt

Summary

The CodeQL/daily workflow at .github/workflows/codeql-daily.yml is named "daily" but its cron schedule is actually weekly (Thursdays at 12:00 UTC). It also lacks a workflow_dispatch trigger, which means there is no way to manually run it from the Actions UI. This makes it slow/impossible to re-run the analysis on demand — for example, after fixing a CodeQL false-positive (such as alert #1881 for cpp/new-free-mismatch in <vector>) we have to wait up to a week for the next scheduled run before the alert auto-closes.

Changes required

Edit .github/workflows/codeql-daily.yml only. Two changes to the on: block:

1. Change the cron from weekly to daily.

   • Current:

     on:
       schedule:
       - cron: '0 12 * * 4'

   • New:

     on:
       schedule:
       - cron: '0 12 * * *'
       workflow_dispatch:

2. Add workflow_dispatch: with no inputs so the workflow can be manually triggered from the Actions UI.

That is the entire change. Do not modify any other steps, jobs, permissions, or the codeql-push.yml workflow.

Acceptance criteria

• .github/workflows/codeql-daily.yml on: block contains both schedule (with cron: '0 12 * * *') and workflow_dispatch:.
• No other files are modified.
• YAML remains valid (the workflow file should still parse — confirm by linting/syntax-checking the file, e.g. with yamllint or actionlint if available).
• The workflow's name: ("CodeQL/daily"), permissions, concurrency, and job definition are left unchanged.

Notes

• schedule and workflow_dispatch triggers only take effect once the workflow file is on the default branch (main), so the manual-run button will appear after this PR merges.
• Keep the existing comment block under Install deps referencing alert ssl: update BoringSSL to ae9f0616 (3202). #1881 untouched.

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: this one is super fucking annoying

we have tried now like 10 different things to make it go away but still it persists

rn i just want to know - what is actually triggering this - how do i get that piece of information - the report is useless

Assistant: Short answer: the UI is showing you the primary sink location (the delete call inside libc++'s vector header at line 492 — that's __vallocate/__deallocate_node territory). The piece you actually want — the matching new/malloc site in your code — is in the SARIF result's relatedLocations / codeFlows, which the GitHub UI for this query basically hides because the primary location lives in a header that isn't in the repo (hence "Preview unavailable").

The Code Scanning REST API endpoints for a single alert and its instances aren't exposed through my tooling here, but here's how you get it yourself.

How to get the actual triggering location

Option 1 — Pull the alert via the REST API (fastest)

gh api \
  -H "Accept: application/vnd.github+json" \
  /repos/envoyproxy/envoy/code-scanning/alerts/1881 \
  | jq '.most_recent_instance.location, .most_recent_instance.message'

That gives you the primary location only. To get all locations for the most recent instance (this is the important one):

gh api /repos/envoyproxy/envoy/code-scanning/alerts/1881/instances \
  | jq '.[0]'

The instance object includes message.text which for cpp/new-free-mismatch is rendered as:

There is a new/free mismatch between this free [here] and the corresponding new [here].

Each [here] is a placeholder backed by an entry — but the REST API's instance payload only returns the primary location. To get the related/secondary locations and the data flow path you need SARIF.

Option 2 — Download the SARIF (this is what you actually want)

1. Find the analysis ID for the alert:

   gh api /repos/envoyproxy/envoy/code-scanning/alerts/1881 | jq .most_recent_instance.analysis_key
   gh api "/repos/envoyproxy/envoy/code-scanning/analyses?ref=refs/heads/main&tool_name=CodeQL" \
     | jq '.[0:5] | .[] | {id, created_at, category, results_count}'

2. Download SARIF for that analysis:

   gh api -H "Accept: application/sarif+json" \
     /repos/envoyproxy/envoy/code-scanning/analyses/<ANALYSIS_ID> > envoy.sarif

3. Pull out alert 1881's full result, including relatedLocations and codeFlows:

   jq '.runs[].results[]
       | select(.ruleId=="cpp/new-free-mismatch")
       | {message: .message.text,
          primary: .locations[0].physicalLocation,
          related: .relatedLocations,
          flows: [.codeFlows[]?.threadFlows[]?.locations[]?.location.physicalLocation]}' envoy.sarif

related and flows are what tell you the actual new/malloc site — i.e. the line in Envoy code that allocated the memory whose deallocation inside vector:492 is being flagged.

Option 3 — Run CodeQL locally and use the path-problem viewer

Since this is a `path...

This pull request was created from Copilot chat.

[repokitteh-read-only]

As a reminder, PRs marked as draft will not be automatically assigned reviewers,
or be handled by maintainer-oncall triage.

Please mark your PR as ready when you want it to be reviewed!

🐱

Caused by: #44890 was opened by Copilot.

see: more, trace.