Add pre-commit auto-update workflow

[xylar]

Summary

Adds a monthly (and manually triggerable) workflow that runs pre-commit-update, pushes the result to an update-pre-commit-deps branch, and opens a PR with reviewers and the DevOps label.

Select one: This pull request is...

• a bug fix: increment the patch version
• a small improvement: increment the minor version
• a new feature: increment the minor version
• an incompatible (non-backwards compatible) API change: increment the major version

Please fill out either the "Small Change" or "Big Change" section (the latter includes the numbered subsections), and delete the other.

Small Change

• To merge, I will use "Squash and merge". That is, this change should be a single commit.
• Logic: I have visually inspected the entire pull request myself.
• Pre-commit checks: All the pre-commits checks have passed.

[xylar]

@forsyth2, we can run this manually after it merged and after #56 goes in. We can see if it has any further updates.

[forsyth2]

I've visually inspected the PR. As part of this review, providing some explanations for myself from Claude.

---

What the workflow does

This is a scheduled GitHub Actions job for the zppy-interfaces repo that keeps pre-commit hooks (and their pinned dependency versions in .pre-commit-config.yaml) up to date automatically:

1. Trigger: runs on a schedule, or manually via workflow_dispatch.
2. Set up environment: creates a conda/micromamba environment with Python 3.14.
3. Install tools: pre-commit, the pre-commit-update PyPI tool, and GitHub's gh CLI.
4. Apply updates: clones the repo fresh, creates a branch update-pre-commit-deps, runs pre-commit-update (which bumps hook versions), and commits the result. If nothing changed, the git commit fails, and that failure is caught to set UP_TO_DATE=true instead of erroring out the job.
5. Push changes: force-pushes the branch — but only if something actually changed (UP_TO_DATE == 'false').
6. Open a PR: creates a pull request from that branch, tagging reviewers and adding a DevOps label — again, only if there were changes.

[forsyth2]

From Claude:

---

Does cron: '0 8 1 * *' mean 8am on the 1st of every month?

Yes. The five fields are minute hour day-of-month month day-of-week, so:

• 0 → minute 0
• 8 → hour 8
• 1 → day-of-month 1
• * → every month
• * → any day-of-week (irrelevant since day-of-month is already fixed)

So it runs at 08:00 UTC on the 1st of every month. (Cron schedules in GitHub Actions are always in UTC, regardless of where the repo or runner is located.)

[forsyth2]

From Claude:

---

Where does 41898282 come from?

That's the actual GitHub user ID number for the github-actions[bot] account. GitHub documents this as the standard way to author commits "as" the bot so they display with the bot's avatar/identity and are properly attributed as automated commits (e.g., excluded from contributor stats, recognized by GitHub as a bot author). It's not something defined anywhere in this repo — it's a fixed, well-known constant that's commonly copy-pasted into workflows across many projects. You can verify it yourself by checking the public API for that account:

curl https://api.github.com/users/github-actions%5Bbot%5D

which returns "id": 41898282.

[forsyth2]

From Claude:

---

env.* (e.g. env.PYTHON_VERSION, env.UP_TO_DATE, env.REVIEWERS) — these are defined in this file, right at the top under the workflow-level env: block. UP_TO_DATE starts as false and gets overwritten later using echo "UP_TO_DATE=true" >> "$GITHUB_ENV" if the commit step finds no changes — that's the mechanism GitHub Actions provides for a step to update an env var that later steps can read.

[forsyth2]

From Claude:

---

secrets.GITHUB_TOKEN — this is not defined anywhere in the file or repo settings. GitHub Actions automatically creates and injects a fresh GITHUB_TOKEN secret for every workflow run, scoped to that repository, with permissions controlled by the repo's Actions settings (Settings → Actions → General → Workflow permissions). You never set this yourself.

[xylar]

Ah, that's a good point. We need to set this up.

[xylar]

Oh, or maybe not. Let's see if it's automatic like Claude says.

[xylar]

(I had to set up my own secret for at least some of my repos, but I guess it wasn't for this.)

[forsyth2]

From Claude:

---

github.token — this is just another way to reference that same automatic token, but via the built-in github context object rather than the secrets context. github.token and secrets.GITHUB_TOKEN refer to the identical token; the workflow actually uses both in different steps (a bit redundant, but harmless).

[Copilot]

Pull request overview

Adds a scheduled (monthly) and manually-triggerable GitHub Actions workflow to
auto-update pre-commit hook revisions, push the results to an
update-pre-commit-deps branch, and open a PR with preset reviewers/label.

Changes:

• Introduces a new Actions workflow triggered by cron + workflow_dispatch
• Creates a micromamba environment, runs pre-commit-update, commits changes
• Pushes the update branch and opens a PR via gh

Suppressed comments (1)

.github/workflows/pre_commit_update_workflow.yml:79

• gh is installed inside the micromamba environment, but this step does not activate that environment, so gh pr create is likely to fail with gh: command not found (each Actions step starts a fresh shell). Activate pre_commit_dev here before running gh.

      - name: Make PR and add reviewers and labels
        if: ${{ env.UP_TO_DATE == 'false' }}
        run: |
          cd update-pre-commit-deps
          gh pr create \

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[xylar]

Very good point. I'll add that.

[xylar]

python scripts/sync_pre_commit_versions.py should address this.

[Copilot]

Pull request overview

Copilot reviewed 5 out of 5 changed files in this pull request and generated no new comments.

Suppressed comments (2)

.pre-commit-config.yaml:45

• types-PyYAML is added as an additional_dependencies entry without any version constraint. That makes pre-commit runs non-reproducible (future releases could change type stubs and break mypy) and it also diverges from the existing pattern of constraining additional deps (e.g. flake8-isort==...). Consider pinning or at least adding a lower-bound to match the repo’s QA dependency constraints.

    hooks:
      - id: mypy
        args: ["--config=pyproject.toml"]
        additional_dependencies: [types-PyYAML]

.github/workflows/pre_commit_update_workflow.yml:93

• This step always runs gh pr create, which will fail (and fail the scheduled workflow) if an open PR already exists for update-pre-commit-deps from a prior run. Handling the “PR already exists” case (edit/update it instead of creating a new one) will make the monthly schedule reliable.

      - name: Make PR and add reviewers and labels
        if: ${{ env.UP_TO_DATE == 'false' }}
        run: |
          cd update-pre-commit-deps
          gh pr create \
          --title "Update pre-commit and its dependencies" \
          --body "This PR was auto-generated to update pre-commit and its dependencies." \
          --head update-pre-commit-deps \
          --reviewer ${{ env.REVIEWERS }} \
          --label DevOps