ci: add push trigger to zizmor workflow for changes to workflow files on main

[Copilot]

The zizmor workflow previously only ran on pull_request (path-filtered) and a weekly schedule, leaving a gap for direct pushes to main that modify workflow files.

Changes

• .github/workflows/zizmor.yml — adds a push trigger scoped to the main branch and .github/workflows/** paths:

on:
  pull_request:
    paths:
      - ".github/workflows/**"
  push:
    branches:
      - main
    paths:
      - ".github/workflows/**"
  schedule:
    - cron: "0 0 * * 6"

All existing triggers and behaviour are preserved. The concurrency group (keyed on github.ref) correctly serialises/cancels repeated pushes on the same branch. permissions: contents: read is unchanged.

Original prompt

Update PR #968 in CycloneDX/cyclonedx-python-lib to also run the zizmor workflow when workflow files change on push.

Context:

• PR adds .github/workflows/zizmor.yml.
• Currently triggers are:
  • pull_request with paths: [".github/workflows/**"]
  • schedule weekly.

Task:

1. Modify .github/workflows/zizmor.yml to include a push trigger that runs when .github/workflows/** changes.
2. Limit the push trigger to the repository default branch (determine actual default branch in the repo; do not assume main). If additional long-lived branches (e.g., master, develop, release branches) are clearly in use, consider including them only if appropriate—otherwise just default branch.
3. Keep existing triggers and behavior intact.
4. Ensure YAML remains valid and consistent with least-privilege approach already used.

Deliverable:

• Commit to the PR branch updating the workflow file.

Reference:

• PR URL: chore: add zizmor workflow to harden GitHub Actions security #968

The following is the prior conversation context from the user's chat exploration (may be truncated):

User: this PR adds a runner on schedule on on pull_request.

would it be benefitial to also have it on any change of a file ".github/workflows/**" ?

Assistant: Yes—it’s generally beneficial to run this on pushes that change .github/workflows/**, not just on pull_request and a weekly schedule.

Why add push (workflow-file changes)?

• Catches issues earlier on branches that don’t use PRs (direct pushes to default branch, maintenance branches, release branches, or admins merging via the UI).
• Covers “post-merge” workflow edits (e.g., someone tweaks a workflow after merge, or via a hotfix commit).
• Reduces the window of exposure compared to weekly schedule (you’ll get feedback immediately when workflow security posture changes).

When it might not add much

• If your repo requires PRs for all changes to .github/workflows/** (branch protection + CODEOWNERS + no direct pushes), then pull_request already covers most cases.
• If you’re concerned about CI load/noise, limiting push to specific branches helps.

Recommended configuration

Add a push trigger restricted to workflow paths and (optionally) to protected branches:

on:
  pull_request:
    paths:
      - ".github/workflows/**"
  push:
    branches:
      - main
      - master
    paths:
      - ".github/workflows/**"
  schedule:
    - cron: "0 0 * * 6"

If the default branch isn’t main/master, use the actual default branch name.

One nuance

You already have concurrency: group: ${{ github.workflow }}-${{ github.ref }}, which is fine; on push it’ll group by the branch ref, so repeated pushes will cancel in-progress runs on the same branch.

If you tell me the repo’s default branch name and whether workflow changes can be pushed directly, I can suggest the tightest trigger set.

User: okay, add this in

Assistant: I’ve queued up the change to add a push trigger (scoped to the repo’s default branch and only when .github/workflows/** changes), and I’m waiting on your approval/confirmation in the dialog before I can apply it to the PR.

This pull request was created from Copilot chat.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}