skills(running-tend): record that credential-environments is maintainer-owned - #411
skills(running-tend): record that credential-environments is maintainer-owned#411dormouse-bot wants to merge 2 commits into
Conversation
…er-owned The nightly's drift dedup searches only open issues, so the closed #339 would let it re-file the same FAIL every night. Suppress it while that check is the only failure, and say when to file anyway.
Deploying mouseterm with
|
| Latest commit: |
a4a76ba
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://a07f67c3.mouseterm.pages.dev |
| Branch Preview URL: | https://docs-running-tend-credential.mouseterm.pages.dev |
dormouse-bot
left a comment
dormouse-bot
left a comment
There was a problem hiding this comment.
Docs-only. I checked the load-bearing claims and they hold: release.yml build-standalone and build-vscode both carry id-token: write with no environment: key (only publish-vscode has one), #339 was closed by nedtwigg at 2026-08-18T19:41:21Z, and nightly step 2's dedup really is gh issue list --state open --author '@me' --search '"configuration drift" in:title', so a closed tracker leaves it filing nightly. The suppression is worth recording.
One gap in the escape hatch, inline below: the "file when a different check fails" clause doesn't pin the issue title, and nightly step 2 dedups and auto-closes purely on the literal string configuration drift in the title. A future session reading "scope the issue to that check" is one plausible step from titling it tend check: credential-environments FAIL, at which point the next night's dedup finds nothing and files again — the exact spam this note exists to stop. Same string gates the STATUS=ok auto-close, so an off-title issue also never closes itself.
Related, and folded into the same suggestion: the note says to "note it in the run summary and move on" while credential-environments is the sole FAIL, but doesn't say what happens to a drift issue opened for some other check once that check clears — a literal reading leaves it open forever listing a fixed FAIL.
Nightly step 2 dedups and auto-closes drift issues by matching the literal string "configuration drift" in the title, so an issue filed for a different check under a check-specific title would be re-filed every night and never auto-close. Also say what to do with that issue once the other check clears.
1 participant
tend checkstill reports one FAIL on this repo —credential-environments, for the tworelease.ymljobs that mintid-token: writeforactions/attest-build-provenanceoutside any environment. You closed #339 yesterday with that FAIL outstanding and after discussing it in the thread, so I read the close as a decision rather than an oversight and didn't re-file tonight.The problem is that nothing in the repo records that decision. The nightly's step-2 dedup searches only open bot-authored issues, so the next run sees a FAIL and no open tracker and files a fresh drift issue — and so does the one after that. This adds a
running-tendnote so the suppression is deliberate and survives, rather than depending on each night's session re-reading a closed thread and reaching the same conclusion.Scoped narrowly: the note suppresses re-filing only while
credential-environmentsis the sole FAIL, and explicitly says to file when a different check starts failing. It also carries forward the two facts from #339 a future run would otherwise re-derive — that the fix needs a newv*-tag-only environment created before anyenvironment:key references it, and that the bot's standing offer to open the two-blockrelease.ymlchange is still open.Docs-only, so no test. If you'd rather the nightly keep filing this one, close this and I'll leave the behavior as is.