CodeQL default setup: required checks never report on PRs that don't touch analyzed languages, which blocks merging

[Pissmyran]

🏷️ Discussion Type

Bug

💬 Feature/Topic Area

Code quality

Discussion Details

Summary

With CodeQL default setup, a pull request that only changes files outside the analyzed languages (for example Markdown, TOML, JSON or YAML that is not a workflow) gets no CodeQL check at all. If the base branch ruleset requires Analyze (<language>) or "Require code scanning results", the PR stays in blocked state forever. Nothing fails, nothing is pending in the checks list, and there is no way to re-run anything.

I would like CodeQL to work out which analyses a PR actually needs from the files it changes, and to always report a result for the required checks, so a skipped analysis counts as passed instead of blocking.

What I observed

Public repository, Swift project with a few helper scripts and workflows, CodeQL default setup, query suite default.

Ruleset on the default branch requires:

• status check Analyze (swift)
• code scanning results from CodeQL (errors, high or higher)

PR changes	CodeQL checks on the PR	Mergeable state
Files under .github/workflows	Analyze (actions) plus the other configured languages	unblocked after checks pass
Only *.md, *.toml, *.json, *.yaml (no workflow, no source)	none	blocked

On the blocked PR the commit has check runs from other tools, but no CodeQL run and no commit status. GET /repos/OWNER/REPO/commits/SHA/status returns state: pending with an empty statuses list. The ruleset still waits for Analyze (swift).

Default setup API for the repo reports state: configured, so setup itself is fine.

Why this is a problem

• A docs-only PR cannot be merged, even with auto-merge, branch protection and bot reviewers all green.
• The cause is invisible in the PR UI. The merge box says required checks are expected, but there is nothing to re-run and nothing to wait for.
• Documented workarounds all require leaving default setup: switch to advanced setup, add a path-filter job plus an always-running gate job, and make that gate the required check. That means owning a workflow file, which is exactly what default setup is meant to avoid. Repositories that forbid agents or contributors from editing workflows cannot use it at all.
• The opposite problem also exists. Some PRs trigger every configured language even when only one is relevant, which wastes runner time.

Suggestion

1. Decide per PR which languages need analysis, based on the changed files (and the build inputs those languages depend on, such as Package.swift, lockfiles and workflow files).
2. Always publish the required check names for default setup, with a neutral or successful conclusion and a short description such as "No files relevant to swift changed, analysis skipped", so rulesets stay satisfiable.
3. Make "Require code scanning results" treat "not needed for this diff" as satisfied, not as missing.
4. Show the decision in the PR, for example "CodeQL: swift skipped (no relevant changes), actions analyzed", so the person merging can see why.
5. Fall back to analyzing everything whenever the diff is ambiguous (very large diffs, new languages, changes to setup itself).

This keeps default setup simple, saves Actions minutes on docs-only PRs, and removes a merge blocker for repositories that rely on rulesets.

Questions for the community

• Is there a supported way today, within default setup, to get the required checks reported on PRs that do not touch analyzed languages?
• Is anything like this on the roadmap?

[github-actions[bot]]

💬 Your Product Feedback Has Been Submitted 🎉

Thank you for taking the time to share your insights with us! Your feedback is invaluable as we build a better GitHub experience for all our users.

Here's what you can expect moving forward ⏩

• Your input will be carefully reviewed and cataloged by members of our product teams. 
  • Due to the high volume of submissions, we may not always be able to provide individual responses.
  • Rest assured, your feedback will help chart our course for product improvements.
• Other users may engage with your post, sharing their own perspectives or experiences. 
• GitHub staff may reach out for further clarification or insight. 
  • We may 'Answer' your discussion if there is a current solution, workaround, or roadmap/changelog post related to the feedback.

Where to look to see what's shipping 👀

• Read the Changelog for real-time updates on the latest GitHub features, enhancements, and calls for feedback.
• Explore our Product Roadmap, which details upcoming major releases and initiatives.

What you can do in the meantime 💻

• Upvote and comment on other user feedback Discussions that resonate with you.
• Add more information at any point! Useful details include: use cases, relevant labels, desired outcomes, and any accompanying screenshots.

As a member of the GitHub community, your participation is essential. While we can't promise that every suggestion will be implemented, we want to emphasize that your feedback is instrumental in guiding our decisions and priorities.

Thank you once again for your contribution to making GitHub even better! We're grateful for your ongoing support and collaboration in shaping the future of our platform. ⭐