GitHub Code Quality runs now have their own GitHub Actions workflow path and actor. Existing repository scans continue without reconfiguration, but usage reports, billing exports, dashboards, and scripts may undercount work if they still recognize only the old shared CodeQL identity.
The new workflow path is dynamic/github-code-quality/codeql, and the actor is github-code-quality. Code scanning continues to use dynamic/github-code-scanning/codeql and the github-advanced-security actor. The practical task is to separate the two without breaking historical comparisons.
Find every place that assumes the old identity
Search reporting code, warehouse transformations, dashboard filters, scheduled exports, alerts, and cost-allocation queries. Repository workflow YAML may not contain these dynamic paths because GitHub generates the runs.
rg "dynamic/github-code-scanning/codeql|github-advanced-security" \
analytics scripts dashboards infrastructure .github
Also search saved queries in the analytics platform and spreadsheet formulas outside the repository. A code change cannot fix a filter embedded in a manually maintained dashboard.
Create an inventory with owner, purpose, data source, update cadence, and expected output. Mark whether each consumer wants all CodeQL activity, security-only scanning, or quality-only analysis. That business meaning determines the correct migration.
Do not replace the old filter blindly
If a report previously counted all CodeQL work through the old path, replacing it with the new path will erase code scanning. Use an explicit classification instead:
CASE
WHEN workflow_path = 'dynamic/github-code-quality/codeql'
OR actor = 'github-code-quality'
THEN 'code_quality'
WHEN workflow_path = 'dynamic/github-code-scanning/codeql'
OR actor = 'github-advanced-security'
THEN 'code_scanning'
ELSE 'other'
END AS analysis_type
Prefer the workflow path as the primary signal and retain the actor as supporting evidence. Store the raw fields too. If GitHub changes a display name later, historical records remain interpretable.
Use exact equality rather than a broad condition such as path contains codeql. Broad matching can accidentally include custom workflows, experiments, or future products with different billing meaning.
Preserve a before-and-after baseline
Choose a transition window that includes several days before and after August 20, 2026. Calculate run count, duration, billable minutes, active repositories, active committers where available, and failure rate using both the old and updated logic.
The total should not suddenly drop merely because runs moved category. If the new quality series begins while the old scanning series remains stable, the split is behaving as expected. If both disappear, the ingestion or filter is wrong.
Keep three numbers visible during migration:
| Metric | Purpose |
|---|---|
| All CodeQL-related runs | Detect missing ingestion |
| Code Quality runs | Understand quality adoption and cost |
| Code scanning runs | Preserve security trend continuity |
Do not compare quality findings and security alerts as if they were the same unit. Their severity, remediation workflow, licensing, and expected volume differ.
Update usage and billing reports safely
GitHub specifically calls out Actions usage and billing reports filtered on the old dynamic path. Add the new path before removing any fallback logic. Backfill the transition period if the warehouse supports it.
For cost allocation, attach repository ownership and cost-center metadata after classifying the run. A repository rename should not create a new cost center, so use stable repository identifiers where the export provides them.
function classifyCodeqlRun(run) {
if (run.workflowPath === 'dynamic/github-code-quality/codeql') {
return 'code_quality';
}
if (run.workflowPath === 'dynamic/github-code-scanning/codeql') {
return 'code_scanning';
}
return null;
}
Write tests for both identities and for an unrelated workflow. A reporting migration without fixture tests tends to fail silently, which is worse than a visible CI failure.
Reconcile the actor in automation and alerts
Some scripts identify generated runs through github-advanced-security. Add github-code-quality only where quality runs should be included. Examples include cancellation tools, stale-run monitors, concurrency reports, and incident dashboards.
Do not grant permissions based solely on the actor string. Displayed actors are useful for classification, not authorization. Sensitive automation should rely on GitHub’s verified event context, token permissions, repository policy, and API guarantees.
If an alert watches failure rates, give Code Quality its own threshold. A pilot rollout can create legitimate volume changes that would look like a security-scanning incident in a combined series.
Use the new audit events for configuration history
GitHub also added audit events for Code Quality enablement changes: repo.code_quality_enabled, repo.code_quality_disabled, and repo.code_quality_updated. Each records the repository, actor, and time.
Join these events to usage data when investigating a sudden change. A cost increase after enablement is different from a duplicated export. A drop after disablement is different from a scanning outage.
Keep audit-log ingestion separate from Actions run ingestion and correlate by stable repository identity and time range. This makes the dashboard explainable without treating configuration events as usage records.
Verify the migration with known repositories
Select at least three repositories:
- Code Quality enabled and actively receiving commits.
- Code scanning enabled without Code Quality.
- Neither product enabled.
For each one, compare the GitHub Actions UI with exported rows and the dashboard. Confirm path, actor, duration, classification, and date. Then verify organization totals equal the sum of classified records plus a visible unclassified bucket.
Keep the unclassified bucket during rollout. Hiding unknown rows makes a dashboard look clean while concealing schema drift.
Migration checklist
- Inventory filters using the old path or actor.
- Define whether each report needs quality, security, or both.
- Add exact classification for both workflow paths.
- Preserve raw path and actor fields.
- Backfill the transition window.
- Test known repositories against the Actions UI.
- Add Code Quality audit events to configuration history.
- Monitor unclassified generated workflows.
- Document the owner of each dashboard and cost report.
Primary references
- GitHub Changelog: separate GitHub Actions path for GitHub Code Quality
- GitHub Changelog: track Code Quality enablement changes in the audit log
- GitHub documentation: Code Quality billing
- GitHub documentation: reviewing the audit log
The product keeps scanning without a repository change, but reporting does not fix itself. Classify both identities explicitly, validate against known runs, and preserve the audit trail that explains when repositories entered or left the quality program.
Discussion
What would you try, change, or challenge after reading this guide? Specific results and errors help the next reader.
Comments will load as you reach this section.