chore: regenerate tend workflows with 0.1.13 - #6126
Conversation
prql-bot
left a comment
There was a problem hiding this comment.
Generated-output review: the bump is consistent (all eight tend-*.yaml files move 0.1.11 → 0.1.13 in both the header and the action ref), and the substantive 0.1.13 additions — the secretless relay job + repository_dispatch re-entry, environment: tend on the secret-bearing jobs, the tend-review base-tree setup checkout, and the tend-notifications retry-with-logging — all read as coherent.
One blocker, though: this branch was generated against a 0.1.11 base (the diff is 0.1.11 → 0.1.13), but main already moved to 0.1.12 via #6101. So the PR conflicts with main (mergeable: CONFLICTING), and that's what pre-commit.ci - pr is surfacing as error during mergeable check rather than a real lint failure — every tend-*.yaml was touched on both sides.
It's not a duplicate — main at 0.1.12 has neither the relay job nor environment: gating, so 0.1.13 is a genuine new step. It just needs regenerating on top of current main so the diff becomes 0.1.12 → 0.1.13. Since these are generated files, a plain git rebase will fight the overlapping hunks; cleaner to branch off fresh origin/main and re-run uvx tend@0.1.13 init, then force-push. Happy to do that regeneration and push it to the branch if you'd like — just say the word.
# Conflicts: # .github/workflows/tend-ci-fix.yaml # .github/workflows/tend-mention.yaml # .github/workflows/tend-nightly.yaml # .github/workflows/tend-notifications.yaml # .github/workflows/tend-review-runs.yaml # .github/workflows/tend-review.yaml # .github/workflows/tend-triage.yaml # .github/workflows/tend-weekly.yaml
Regenerates the
tend-*.yamlworkflows against tend 0.1.13. Generated output only — no hand edits.The change that matters is that every workflow now names
environment: tend, so the bot token and the model credential can live in a deployment environment gated tomaininstead of as repo-level secrets, which any workflow on any branch can read.tend-mentiongains a secretlessrelayjob to go with it: a review or review-comment event runs onrefs/pull/N/merge, a ref no deployment-branch policy can admit, sorelayholds no secrets and re-posts only identifiers as arepository_dispatch, whichverifythen re-reads from the API.Merging this on its own changes nothing operationally. The
tendenvironment already exists on this repo withTEND_BOT_TOKENin it, and a job naming an environment can still read repo-level secrets, so the gate closes only when the repo-level copies are deleted — a follow-up once the model credential is in the environment too.