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 #2985

Activity

1. SwuduSusuwu commented on Jul 22, 2025

   

   SwuduSusuwu

   on Jul 22, 2025

   Last edited by SwuduSusuwu

   Author

   More actions

   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.
2. SwuduSusuwu commented on Jul 23, 2025

   

   SwuduSusuwu

   on Jul 23, 2025

   Last edited by SwuduSusuwu

   Author

   More actions

   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.