Taming Orphaned CodeQL Workflows: A Key to Achieving Your Engineering Team Goals

In the fast-paced world of software development, maintaining efficient CI/CD pipelines is paramount for achieving your engineering team goals. Unwanted or "orphaned" workflows can introduce friction, waste resources, and obscure critical build statuses. A recent discussion on GitHub's community forum highlighted just such a challenge, where a CodeQL default-setup workflow continued to run despite being officially disabled, leaving developers scratching their heads.

The Persistent CodeQL Phantom

The problem, as described by Justin140672, was straightforward yet frustrating: a private repository, no longer configured for CodeQL code scanning, continued to trigger dynamically generated CodeQL workflows on every push. These runs would inevitably fail with the message: “Code scanning is not enabled for this repository.” The usual avenues for disabling the workflow—via GitHub Actions settings or the repository’s Advanced Security section—were either non-functional or entirely absent, leaving an unwanted process consuming valuable CI/CD minutes and cluttering workflow logs.

Unmasking the Root Cause: Configuration vs. UI

The key to understanding this phantom workflow lies in how GitHub manages its Code Security settings, especially for private repositories. As potomyznaesh astutely pointed out, when Code Security is turned off for a private repository, the CodeQL default setup isn't necessarily "deconfigured" in the backend; its state simply becomes inaccessible and unchangeable through the standard UI. The system still registers the default setup as "configured," leading to the dynamic workflow generation, even as the CodeQL configuration section vanishes from the repository's Settings → Advanced Security page.

This means the workflow isn't truly disabled; it's merely in a state where its execution is blocked by the overarching Code Security setting, but its trigger mechanism remains active. The dynamic nature of CodeQL default setup means there's no physical workflow file (like a .github/workflows/codeql.yml) to delete, making traditional workflow management ineffective. Justin140672's separate .github/workflows/semgrep.yml workflow, being a standard YAML file, was correctly unaffected by this issue.

The API-Driven Solution

To truly disable an orphaned CodeQL default setup, direct interaction with GitHub's API is required. potomyznaesh provided a clear, step-by-step guide:

1. Check the Stored State: Use the GitHub CLI (gh) to query the current default setup configuration. This reveals whether the system still believes CodeQL is configured.

   gh api repos/OWNER/REPO/code-scanning/default-setup

   Replace OWNER and REPO with your repository's details.

2. Switch Off Directly: If the state shows "configured," use a PATCH request to explicitly set it to "not-configured."

   gh api -X PATCH repos/OWNER/REPO/code-scanning/default-setup -f state=not-configured

3. Admin Intervention (If Necessary): In some cases, step 2 might return a 403 error, indicating that GitHub Advanced Security is not enabled or licensed for the repository, preventing even API-based changes. If this occurs, an administrator must temporarily re-enable Code Security for the repository in Settings → Advanced Security. Once re-enabled, perform step 2, confirm the state is not-configured, and then Code Security can be safely disabled again. If re-enabling Code Security isn't an option (e.g., due to license limitations), contacting GitHub Support with the output from step 1 is the next course of action.

Justin140672 later confirmed that the issue resolved itself, with subsequent pushes running CI and Semgrep without the unwanted CodeQL workflow. This suggests that the underlying configuration was eventually cleared, possibly due to a background process or a delayed effect of previous attempts, though the API method provides a reliable, immediate solution.

Key Takeaways for Streamlined Development

This incident underscores the importance of understanding the underlying API and configuration states, especially when UI options prove insufficient. For development teams striving for efficiency and aiming to meet their engineering team goals, proactively managing CI/CD workflows and troubleshooting such "phantom" issues is crucial. Leveraging tools like the GitHub CLI for deeper configuration management can save significant time and resources, ensuring your pipelines run smoothly and predictably.