docs(ops): Slack Stage 1 spec; co-own .github/workflows/ - #72
Open
unixwhisperer wants to merge 1 commit into
Open
unixwhisperer wants to merge 1 commit into
unixwhisperer wants to merge 1 commit into
Conversation
Stage 1 of the approved Slack integration, plus the workflow co-ownership Matt asked for. No workflow file changes, so CI behaviour is unchanged. Slack (docs/ops/SLACK_INTEGRATION.md): - Official GitHub app for Slack, not a custom bot: OAuth, so there is no webhook URL and no token to store, commit or rotate. Secrets required: none. - Exact per-channel subscribe/unsubscribe commands for #flashstack-ci and #flashstack-security, defaults stripped rather than assumed low-noise. - Records a real limitation rather than papering over it: the official app has no subscription for Dependabot or code-scanning alerts, so the security channel gets Security Scan workflow outcomes and not the alert feed. - Activation is Slack-side and cannot be done from this repo. Nothing here is live on merge; §5 is the admin checklist for Matt. Stage 2 is deliberately NOT implemented. It depends on #69: while both audit steps carry continue-on-error, the job concludes success even with high/critical findings (PR #61's run did exactly that), so a summary built today would post false assurance into the security channel. CODEOWNERS: - /.github/workflows/ is now @unixwhisperer @mattglory. - Comment states the semantics plainly: GitHub satisfies a code-owner rule when ANY ONE listed owner approves. This widens who can approve a workflow change from Hillary to Hillary-or-Matt; it does not require both. Guaranteeing two reviewers needs branch protection (required approvals >= 2), which is admin-side and still unverifiable from the repo (Flashstack-ajv.2.5).
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Stage 1 of the Slack integration you approved, plus the workflow co-ownership you asked for. No workflow file changes — CI behaviour is byte-for-byte unchanged, and Stage 2 is deliberately not here.
Slack Stage 1 —
docs/ops/SLACK_INTEGRATION.mdOfficial GitHub app for Slack, not a custom bot. That choice does the security work for us: it's OAuth between GitHub and Slack, so there is no webhook URL and no bot token — nothing to store in secrets, nothing to commit, nothing to rotate. Secrets required: none. A custom bot would hand us a credential to own; this doesn't.
It also can't break the gate. Subscriptions are read-only consumers of GitHub events — there is no workflow step to fail, so Slack is structurally incapable of failing the security gate rather than merely configured not to.
The doc carries the exact per-channel commands. Defaults are stripped rather than assumed quiet:
/github subscribeapplies GitHub's defaults (issues, pulls, statuses, commits, releases, deployments), so each channel gets an explicitunsubscribeline.#flashstack-cigets PR/review/merge activity plusFlashStack CIscoped tomain;#flashstack-securitygetsSecurity Scanonmainand little else.One limitation I'd rather state than paper over
The official app has no subscription for Dependabot or code-scanning alerts. They're restricted to users with repo security access and aren't exposed as a Slack feature. So
#flashstack-securitygets Security Scan workflow outcomes, not the alert feed. §4.1 says so explicitly. If that gap matters to you, closing it is a Stage 2 job (an Actions step reading the alerts API), not something the official integration can do.Nothing here is live on merge
Every command is a Slack slash command, not a repository file. §5 is your checklist — install the app, create the channels,
/github signin, run the commands. I can't do any of it from the repo and haven't pretended otherwise.One ask: run
/github subscribe list featuresin each channel afterwards and paste the output. I'd like to replace the intended state in this doc with verified state.Stage 2 — not implemented, blocked on #69
Both audit steps in
security.ymlstill carrycontinue-on-error: true, so the job concludes success even with high/critical findings. PR #61's run did exactly that: severalSeverity: highprinted, conclusion success. A Stage 2 summary built today would post a green "Security CI passed" at precisely that moment — automating false assurance, which is worse than no notification at all.After #69 removes the flag, the failure is real and a summary can be trusted. §7 has the full diagram. Stage 2 waits.
CODEOWNERS — one thing to flag before you merge
/.github/workflows/is now@unixwhisperer @mattglory, as requested. But the semantics are worth being explicit about, because they're the opposite of what "co-owner" suggests:GitHub satisfies a code-owner requirement when ANY ONE listed owner approves — not all of them. Today the line is
@unixwhispereralone, so my approval on a workflow change is mandatory. After this PR it becomes "Hillary or Matt". For reaching both of us, that's right and it's what you asked for. But read strictly, it widens who can approve a workflow change rather than narrowing it.That's a small practical change on a two-person repo where you're the admin — and per
Flashstack-ajv.2.5,enforce_adminsis off, so admin bypass exists regardless. I'm not arguing against it; I've made the change. I just won't land a control that reads stronger than it is without saying so, and the file now carries that note inline.If you do want both reviewers guaranteed, CODEOWNERS can't express it — it needs branch protection with required approvals >= 2, which is admin-side.
Both handles verified against the collaborator list rather than guessed:
unixwhisperer(push) andmattglory(admin). CODEOWNERS syntax validated via the API — 0 errors.Validation
git difftouches exactly two paths:CODEOWNERS,docs/ops/SLACK_INTEGRATION.md.github/workflows/unchanged — confirmed empty diffhooks.slack.com, noxox*token, no mnemonic🤖 Generated with Claude Code