[ppkarwasz]

The repository had two workflows named "CodeQL": the original codeql-analysis.yml (Python and Actions) and a later codeql.yml (Actions only). Both uploaded results under the same category, so the Actions language was scanned twice on every push and PR, and two identically named checks showed up on each PR.

This PR deletes codeql.yml and cleans up the surviving workflow:

• run on ubuntu-latest
• use block-style lists for the branches and language arrays
• move the daily schedule off the top of the hour
• cancel in-progress runs only for pull requests, so push and scheduled runs always complete
• set top-level permissions: {} and grant only security-events: write on the job, since read permissions are implicit on a public repository
• drop the Autobuild step, which is a no-op for interpreted languages

Zizmor reports no findings on the updated workflow.

🤖 Generated with Claude Code

[raboof]

I agree we should drop codeql.yml and keep only codeql-analysis.yml (not sure how that happened, likely my bad).

I don't think we should deviate unnecessarily from upstream in codeql-analysis.yml, though - except perhaps for tightening the permissions and the name of the main branch.

[potiuk]

I don't think we should deviate unnecessarily from upstream in codeql-analysis.yml, though - except perhaps for tightening the permissions and the name of the main branch.

I see no big issue with that. With agents nowadays maintainin and updating differences is basically no-op. I completely changed the approach now in such cases after I started to use agents:

1. use something as a starting point
2. modify it according to your needs - strip down what is not needed (especially)
3. add a SKILL to keep it updated / reconcile with upstream or even a skill to upstream your changes

This is how it works with Magpie. And it works extremely well.

[ppkarwasz]

I don't think we should deviate unnecessarily from upstream in codeql-analysis.yml, though - except perhaps for tightening the permissions and the name of the main branch.

Where is the upstream?

In the short term I expect apache/infrastructure-asfyaml#122 to be accepted and after that we don't need to maintain CodeQL workflows any more (as we don't maintain Dependabot workflows).

[potiuk]

In the short term I expect apache/infrastructure-asfyaml#122 to be accepted and after that we don't need to maintain CodeQL workflows any more (as we don't maintain Dependabot workflows).

Oh.. How I would love asfyaml to be able to move faster - and I even have apache/infrastructure-asfyaml#127 to make it possible - with this workflow, we should be able to test asfyaml changes (both contributors and reviewers) in our forks end-2-end.

I would love some encouragemenet here (also in #infra-asfyaml channel on Slack @ppkarwasz

[raboof]

Where is the upstream?

Sorry, brainfart on my side :)