Repository navigation
Migrate GitHub Actions secrets with bk - #1004
Conversation
Amp-Thread-ID: https://ampcode.com/threads/T-01a0e511-5621-775a-a89a-08bf60db27eb Co-authored-by: Amp <[email protected]>
![buildsworth-bk-app[bot]](https://avatars.githubusercontent.com/in/3010600?s=60&v=4){kind=small}
There was a problem hiding this comment.
I found no actionable issues in the prepare and dispatch paths. Because this introduces secret migration and grant creation, the credential boundary needs a human review before approval.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 32725, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
About buildsworth
Model: gpt-6-sol with xhigh thinking.
How to request a review: Comment @buildsworth-bk review on the PR, or request buildsworth-bk as a reviewer.
Risk labels (how buildsworth classifies risk) — buildsworth classifies risk itself from the diff. Unless repository policy already allows L2 approval, grant it by mentioning @buildsworth-bk (see approval ceiling and L2 approval grant):
- L1 — Low risk (dep bumps, docs/copy, lockfiles, small presentational fixes). buildsworth may approve by default.
- L2 — Standard risk (new UI, additive API fields, refactors). Approved only when repository policy or a verified grant allows it; otherwise comment-only.
- L3 — High risk (auth, migrations, payments, secrets, perf-critical pipeline paths). Human approval required unless repository policy explicitly allows L3 approval; per-PR grants cannot allow it.
mcncl
left a comment
mcncl
left a comment
There was a problem hiding this comment.
I don't love the way this has been implemented, but can appreciate that it will likely be used by LLMs for the most part and the command structure suits that usage (clear options etc).
If we do consider additional sources further down the line we might want to implement some interfaces so that we can have a common pattern, but that's not in scope right now.
Amp-Thread-ID: https://ampcode.com/threads/T-01a0e511-5621-775a-a89a-08bf60db27eb Co-authored-by: Amp <[email protected]>
|
🤖 @mcncl I revisited the structure after your review. The command/auth layer now delegates to a concrete GitHub Actions migration orchestrator, with narrow Buildkite and GitHub capability interfaces at the external boundaries; policy validation and deterministic workflow generation are separated by responsibility. I deliberately avoided a generic provider interface until a second source proves a genuinely shared lifecycle. Behavior and generated workflow bytes are unchanged, and the full local checks plus an Oracle architecture/security review are clean. Would you give the new head another look and let me know whether this resolves your concern? |
There was a problem hiding this comment.
No actionable issues found in this revision. Grant creation and the secret-transfer workflow put this above the L2 approval ceiling, so this is comment-only.
Want to dig deeper?
Paste this into your agent to explore the findings from this review's Buildkite build:
Download the buildsworth logs from build 32871, then answer my questions about the findings.
Install the reading-buildsworth-logs skill to run this.
|
Looks good to me. Followed up with Amp on future support of external providers. Status: happy |
2 participants
Description
Move the GitHub Actions repository-secret migration shipped in
buildkite-ghav0.90.0 intobk, so Buildkite authentication, pipeline discovery, destination preflight, and grant creation use the CLI's native authenticated API client.The new command is:
bk secret migrate github-actions prepare --match 'DEPLOY_*' --output .github/workflows/migrate-buildkite-secrets.yml bk secret migrate github-actions run --workflow .github/workflows/migrate-buildkite-secrets.ymlChanges
--no-inputprepare flows with static secret selection, create-only destination checks, restricted policy validation, and deterministic workflow generation.gh.buildkite-ghav0.90.0 so either CLI can run an already reviewed workflow.buildkite-gha migrate-secretswrapper/deprecation follow-up.--watchis intentionally omitted because not every supported dispatch path returns an immutable run ID.Testing
mise run test)mise run format)mise run lint)mise run vulncheck)Disclosures / Credits
Amp implemented the command, tests, documentation, and compatibility checks based on
buildkite-ghaPR #247 / v0.90.0, then ran local auto-review and validation.