https://github.blog/changelog/2025-07-21-code-scanning-will-stop-combining-multiple-sarif-runs-uploaded-in-the-same-sarif-file/ broke all scan tools

[SwuduSusuwu]

Have used CodeQL for 2 years (without config files), all commits passed.
But https://github.blog/changelog/2025-07-21-code-scanning-will-stop-combining-multiple-sarif-runs-uploaded-in-the-same-sarif-file/ broke https://github.com/codacy/codacy-analysis-cli/ (codacy/codacy-analysis-cli#541), so Codacy was removed, which caused Exit code was 32 and last log line was: CodeQL detected code written in C/C++, but not any written in GitHub Actions. (guess the reason is that there were no other config files for GitHub Actions in .github/workflows/, but if so this new "error" is a regression, since CodeQL used to allow to use the default setup).

To workaround, used https://github.com/github/codeql/blob/main/.github/codeql/codeql-config.yml + https://github.com/github/codeql/blob/main/.github/workflows/codeql-analysis.yml (just as templates; replaced the directories + languages with those which SusuLib uses), but those config files trigger CodeQL analyses from advanced configurations cannot be processed when the default setup is enabled.

Is the sole solution to have CodeQL removed too? If so, are there other tools to use (which were not broken), or must produce scan tools from scratch now?

[SwuduSusuwu]

Partial workaround: replaced SwuduSusuwu/SusuLib@a367e84 with SwuduSusuwu/SusuLib@168370b (which introduces .github/workflows/codeql.yml, with no other differences), plus disabled the default CodeQL setup.

This "advanced config" passes, but wish to use the default setup (due to the fact that a program's default setup is often more forwards-compatible).

• Do not understand what is wrong with the default setup.

[SwuduSusuwu]

This discussion with Copilot is about performance issues with those custom configs.:

codeql-config.yml
codeql-analysis.yml
codeql.yml
git switch experimental continuous integration (preview)
You said: After this commit, @SwuduSusuwu/SusuLib/pull/67 shows ``` Code scanning -
After this commit, @SwuduSusuwu/SusuLib/pull/67 shows

Code scanning - action / CodeQL-Build (actions) (push)Successful in 45s
Code scanning - action / CodeQL-Build (c++) (push)
Code scanning - action / CodeQL-Build (c++) (push)Successful in 5m
Code scanning results / CodeQL
Code scanning results / CodeQLSuccessful in 2s — No new alerts in code changed by this pull request
CodeQL Advanced / Analyze (actions) (pull_request)
CodeQL Advanced / Analyze (actions) (pull_request)Successful in 56s
CodeQL Advanced / Analyze (actions) (push)
CodeQL Advanced / Analyze (actions) (push)Successful in 46s
CodeQL Advanced / Analyze (c-cpp) (pull_request)
CodeQL Advanced / Analyze (c-cpp) (pull_request)Successful in 5m
CodeQL Advanced / Analyze (c-cpp) (push)
CodeQL Advanced / Analyze (c-cpp) (push)Successful in 5m
Lint and Static Analysis / markdown-lint (push)
Lint and Static Analysis / markdown-lint (push)Successful in 13s

. Used templates for the config, am concerned that this wastes resources; the config has triggers for push as well as pull_request. Does this execute the tests twice if you git push into some pull request?

Copilot said: Yes, having both push and pull_request triggers in your GitHub Actions workflow will often result in the same workflow running twice for the same commit, if you push to a branch that also has an open pull request.
Why does this happen?

push: Runs the workflow on any push to the specified branches (e.g., main, preview, trunk).
pull_request: Runs the workflow on pull request events targeting those same branches.

When you push to a branch that is the source of an open pull request, GitHub triggers:

The push workflow for the branch update.
The pull_request workflow for the PR update.

Both workflows usually run with the same commit SHA and perform the same checks.
Example Scenario

You open PR #67 from preview to main.
You push new commits to preview.
Both the push and pull_request workflows are triggered for those commits.

Is this wasteful?

Yes, it can be.
Both workflows will test the same code, doubling compute and time—unless you have steps that only make sense in one context.
Should you keep both triggers?

Keep both if you want to:
    Ensure checks run on pushes (even when not part of a PR, e.g., direct pushes to main).
    Have checks run on PRs from forks, which may not trigger push events to your repo.
Remove push if you only care about PRs (for example, if you never push directly to protected branches).

Alternative: Use if: conditions or the workflow_run event to avoid duplicate work, but this is more advanced.
Summary Table
You push to a branch with an open PR push runs? pull_request runs? Work duplicated?
Yes ✅ ✅ ✅
You push to a branch with no PR ✅ ❌ ❌
You open a PR from a fork ❌ ✅ ❌

Recommendation:
If you want to avoid duplication, consider removing the push trigger (or limit it to relevant branches) and keep only pull_request for CI checks.
If you need both, you can add logic to skip jobs in certain contexts, but that adds complexity.

Let me know if you want help with an example workflow that avoids double runs!

Guess is that the default setup does not have such issues.