GitHub Issue

Tune Swift CodeQL so it can run reliably

Discovered On Jul 1, 2026

Primary Metric open

## Problem PR #23 moved CodeQL to a checked-in advanced workflow and fixed the current code scanning configuration error by disabling default setup. GitHub Actions CodeQL now passes on PRs, but Swift CodeQL was too slow or stuck to keep as a per-PR gate. ## Evidence from PR #23 - Manual Swift CodeQL release builds stayed in the Build step for several minutes and had to be cancelled. - Narrowed manual builds for the Contained product still stayed in the Build step. - Disabling SwiftPM sandboxing did not make the manual build healthy enough for PR gating. - GitHub-generated autobuild got into analysis, but still ran too long for a healthy required PR check. ## Current policy - CodeQL Actions analysis runs on PRs, pushes, weekly schedule, and manual dispatch. - Swift CodeQL remains scheduled/manual while we tune it. - Appcast/docs/release-note-only paths are ignored so generated feed commits do not burn macOS scan minutes. - Repo/workflow validation runs through `Scripts/check.sh repo` and release/script fixtures after the `Scripts/` consolidation. - Workflow timeout and path-filter hygiene from the July 2026 audit has been folded into PR #48; this issue remains open for the deeper Swift CodeQL reliability question. ## Research / design checklist - [ ] Find the smallest Swift CodeQL configuration that completes reliably on this SwiftPM macOS app. - [ ] Compare manual build, autobuild, and narrowed target strategies. - [ ] Decide whether Swift CodeQL should stay scheduled/...

View Raw Thread

Developer & User Discourse

Ace2932 • Jul 2, 2026

The stayed-in-Build-and-had-to-be-cancelled failure mode is the one place where config can cap the damage while you tune the analysis itself. You've already got `timeout-minutes` on both CodeQL jobs (15 and 45), but the four workflows that run the same SwiftPM build on macos-26 (PR, Nightly, Beta, Stable) don't set one, so the identical wedge outside CodeQL runs until GitHub's 6-hour default kills it. On macOS that hurts twice: the runner minutes are the expensive kind, and free-plan macOS concurrency is capped at 5 jobs, so one wedged build can also hold up the other channels' runs. It's one line per job, sized a bit above a normal build:

```yaml
jobs:
pr:
runs-on: macos-26
timeout-minutes: 30
```

For what it's worth, the concurrency groups across these workflows, and the path-ignores keeping appcast and docs commits off the macOS runners, are already tighter than almost anything I've scanned, this looked like the one real gap. Bit of a plug, but I built a free scanner for...

tdeverx • Jul 3, 2026

Progress note from draft PR #48 (`56700b8d`): repository validation and workflow path filters were tightened, and `./scripts/ci-validate.sh` now covers release-note shape, docs/wiki mapping, package-boundary invariants, script strict mode, and workflow path filters.

This issue should stay open because the core question remains Swift CodeQL reliability/per-PR suitability. Current PR CI shows Actions analysis passing and Swift analysis skipped by policy.

tdeverx • Jul 3, 2026

@Ace2932 thanks you for the tips/website, i'm going to be folding these fixes into the next build 🤝

tdeverx • Jul 4, 2026

Progress note from draft PR #48 at `51d9c734`: the workflow hygiene from the July audit has been folded in: repo validation now runs through `Scripts/check.sh repo`, stale path guards cover the new `Scripts/`/`Documentation/`/`Changes/` layout, and timeout/path-filter policy is documented. The latest local validation included `./Scripts/check.sh all`.\n\nStill open: Swift CodeQL itself remains scheduled/manual until we find a reliable configuration suitable for PR gating.