docs(ci): add .buildkite/ scaffold + Buildkite setup runbook#486
docs(ci): add .buildkite/ scaffold + Buildkite setup runbook#486mattwilkinsonn wants to merge 6 commits into
docs(ci): add .buildkite/ scaffold + Buildkite setup runbook#486Conversation
|
Note Reviews pausedIt looks like this branch is under active development. To avoid overwhelming you with review comments due to an influx of new commits, CodeRabbit has automatically paused this review. You can configure this behavior by changing the Use the following commands to manage reviews:
Use the checkboxes below for quick actions:
📝 WalkthroughWalkthroughAdds Buildkite CI: README and placeholders, an orchestrator pipeline that fans out to downstream pipelines via monorepo-diff, a ChangesBuildkite CI Infrastructure Documentation
Estimated code review effort🎯 3 (Moderate) | ⏱️ ~20 minutes Poem
🚥 Pre-merge checks | ✅ 5✅ Passed checks (5 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
Comment |
How to use the Graphite Merge QueueAdd either label to this PR to merge it via the merge queue:
You must have a Graphite account in order to use the merge queue. Sign up using this link. An organization admin has required the Graphite Merge Queue in this repository. Please do not merge from GitHub as this will restart CI on PRs being processed by the merge queue. This stack of pull requests is managed by Graphite. Learn more about stacking. |
Greptile SummaryThis PR migrates the
Confidence Score: 5/5Safe to merge — all changes are CI infrastructure and documentation with no impact on production code paths. The PR removes one GHA job and adds Buildkite pipeline YAML, a Dockerfile, a runbook, and local tooling install steps. None of the changes touch runtime code. The two files worth a second look are Dockerfile.ci (unpinned tool versions and a partial integrity check) and orchestrator.yml (mutable plugin reference), but neither introduces a defect that would break a build or expose sensitive data today. .buildkite/images/Dockerfile.ci — unpinned sccache/just/taplo versions and the arm64 SHA256 gap are worth tidying before the image is used at scale. Important Files Changed
Sequence DiagramsequenceDiagram
participant GH as GitHub
participant Orch as seal-ci-orchestrator
participant GCI as Graphite CI plugin
participant Lints as seal-lints
participant MD as monorepo-diff plugin
participant Down as downstream pipelines
GH->>Orch: pull_request / push webhook
Orch->>GCI: "withgraphite/graphite-ci#main"
GCI-->>Orch: skip or proceed signal
par after wait step
Orch->>Lints: trigger (async: false)
Lints-->>GH: buildkite/seal-lints status
and
Orch->>MD: diff against origin/main
MD->>Down: trigger steps for matched paths
Down-->>GH: "buildkite/<slug> status"
end
Reviews (8): Last reviewed commit: "feat(ci): containerized lints — seal-ci ..." | Re-trigger Greptile |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In @.buildkite/README.md:
- Around line 37-39: Update the phrasing for the `nightly.yml` bullet so it
doesn't claim "non-x64 runners" while listing `macos-26-intel`; instead describe
that `nightly.yml` runs across multiple architectures/hosts — e.g., "coverage
for multiple architectures/hosts (e.g., `ubuntu-24.04-arm`, `macos-latest`,
`macos-26-intel`)" — so the entry for `nightly.yml` accurately reflects
inclusion of both ARM and Intel mac runners.
In `@docs/buildkite-setup.md`:
- Around line 31-34: The text incorrectly treats "pull_request: synchronize" as
a separate event; update the sentence to say Buildkite listens to the GitHub
'pull_request' event (including actions like 'synchronize') and 'push' events,
so rephrase to clarify that 'synchronize' is an action under 'pull_request'
rather than its own event and ensure the identifiers 'pull_request' and
'synchronize' are used precisely in the sentence.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: ac2e0551-487e-416a-96f3-7661eec839b2
📒 Files selected for processing (4)
.buildkite/README.md.buildkite/hooks/.gitkeep.buildkite/pipelines/.gitkeepdocs/buildkite-setup.md
![greptile-apps[bot]](https://avatars.githubusercontent.com/in/867647?s=60&v=4){kind=small}
| .buildkite/ | ||
| ├── README.md (this file) | ||
| ├── pipelines/ (pipeline YAML — one per gate) | ||
| │ ├── lints.yml (fmt + actionlint + docs lint) | ||
| │ ├── test-linux.yml (clippy + Test Linux + build smoke) | ||
| │ ├── test-macos.yml (Test macOS — uses `just nextest-macos-pr`) | ||
| │ ├── live-tests.yml (Live API Tests, label/path-gated) | ||
| │ ├── clients-even-terminal.yml (Even Terminal — bun lint + test) | ||
| │ ├── deploy-docs.yml (Cloudflare Pages deploy + PR preview) | ||
| │ └── release.yml (4-target release matrix on tag push) | ||
| ├── scripts/ (helper scripts invoked from pipelines) | ||
| └── hooks/ (agent-side hooks, if any) |
There was a problem hiding this comment.
scripts/ directory is listed but has no placeholder
The layout tree shows a scripts/ directory alongside pipelines/ and hooks/, and both of those get .gitkeep files in this PR. scripts/ does not, so it exists only in documentation but not on disk. If another PR adds scripts that depend on the directory existing, the scaffolding will be inconsistent. Consider adding .buildkite/scripts/.gitkeep here while the structure is being established.
Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!
There was a problem hiding this comment.
Actionable comments posted: 2
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (1)
.buildkite/pipelines/orchestrator.yml (1)
169-183:⚠️ Potential issue | 🟡 MinorPrevent duplicate
seal-live-teststriggers when both LLM paths change and thelive-testslabel is present
- Buildkite doesn’t automatically deduplicate multiple
triggersteps that target the same downstream pipeline; each matching trigger step creates its own downstream build..buildkite/pipelines/orchestrator.ymlcontains two separateseal-live-teststriggers (the LLM path-filtered one plus the label-gated onebuild.pull_request.labels includes "live-tests"), with no cancellation/dedup mechanism configured here.- Mitigate by enabling “Cancel Intermediate Builds” on the
seal-live-testspipeline (or document that the double-run is intentional/acceptable).🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.buildkite/pipelines/orchestrator.yml around lines 169 - 183, The pipeline has two separate trigger steps that both call the downstream pipeline "seal-live-tests" (the LLM path-filtered trigger plus the label-gated trigger labeled ":satellite: Live API Tests (label-triggered)"), which can cause duplicate downstream builds when a PR both changes LLM paths and has the "live-tests" label; fix by enabling "Cancel Intermediate Builds" (or equivalent automatic dedup/cancellation) on the downstream "seal-live-tests" pipeline OR add documentation/comments near the trigger step explaining the double-run is intentional/acceptable so maintainers know why duplicates occur; ensure the change references the trigger name "seal-live-tests" and the label-gated step to avoid accidental edits elsewhere.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Inline comments:
In `@docs/buildkite-setup.md`:
- Around line 156-160: The PR objectives claim GRAPHITE_TOKEN is no longer
required but the docs and pipeline still reference GRAPHITE_TOKEN and the
orchestrator injects graphite_token: "$$GRAPHITE_TOKEN"; either update the PR
objectives summary to state that GRAPHITE_TOKEN is required, or remove
references and injection of GRAPHITE_TOKEN from docs/buildkite-setup.md and
.buildkite/pipelines/orchestrator.yml; specifically reconcile and change the PR
objectives text to match the actual state or remove the env var usage
(GRAPHITE_TOKEN and graphite_token) from the orchestrator pipeline and docs so
they are consistent.
In `@Justfile`:
- Around line 159-216: The bk download URL is incorrect; update the bk_url
construction in the bk installation block (where bk_tag is resolved) to use the
published asset name pattern "bk_${bk_tag}_linux_${bk_arch}.tar.gz" instead of
"cli_${bk_tag}_linux_${bk_arch}.tar.gz" so the URL becomes
https://github.com/buildkite/cli/releases/download/v${bk_tag}/bk_${bk_tag}_linux_${bk_arch}.tar.gz;
ensure this change is made in the code that sets bk_url (the section using
bk_tag and bk_arch before fetching and extracting bk).
---
Outside diff comments:
In @.buildkite/pipelines/orchestrator.yml:
- Around line 169-183: The pipeline has two separate trigger steps that both
call the downstream pipeline "seal-live-tests" (the LLM path-filtered trigger
plus the label-gated trigger labeled ":satellite: Live API Tests
(label-triggered)"), which can cause duplicate downstream builds when a PR both
changes LLM paths and has the "live-tests" label; fix by enabling "Cancel
Intermediate Builds" (or equivalent automatic dedup/cancellation) on the
downstream "seal-live-tests" pipeline OR add documentation/comments near the
trigger step explaining the double-run is intentional/acceptable so maintainers
know why duplicates occur; ensure the change references the trigger name
"seal-live-tests" and the label-gated step to avoid accidental edits elsewhere.
🪄 Autofix (Beta)
Fix all unresolved CodeRabbit comments on this PR:
- Push a commit to this branch (recommended)
- Create a new PR with the fixes
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: b12ca056-d8c2-4579-a0d5-edd3b391488d
📒 Files selected for processing (7)
.buildkite/README.md.buildkite/pipelines/lints.yml.buildkite/pipelines/orchestrator.yml.buildkite/scripts/lints-install-tools.sh.github/workflows/ci.ymlJustfiledocs/buildkite-setup.md
💤 Files with no reviewable changes (1)
- .github/workflows/ci.yml
| plugin and reads `GRAPHITE_TOKEN` from a pipeline-level | ||
| Buildkite secret. Set the secret via: | ||
|
|
||
| > Buildkite dashboard → Pipeline → Settings → Secrets → | ||
| > `GRAPHITE_TOKEN` |
There was a problem hiding this comment.
🧩 Analysis chain
🏁 Script executed:
#!/bin/bash
# Description: Check if GRAPHITE_TOKEN is referenced in orchestrator pipeline
# Search for GRAPHITE_TOKEN usage in orchestrator and related pipeline files
rg -n 'GRAPHITE_TOKEN' .buildkite/Repository: sealedsecurity/seal
Length of output: 256
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Search for GRAPHITE_TOKEN in .buildkite =="
rg -n 'GRAPHITE_TOKEN|graphite_token' .buildkite/
echo
echo "== Search for GRAPHITE_TOKEN in docs/buildkite-setup.md =="
rg -n 'GRAPHITE_TOKEN' docs/buildkite-setup.md
echo
echo "== Show PR objectives / summary context in docs/buildkite-setup.md =="
# Try to find the 'PR objectives' section or the exact summary sentence
rg -n 'PR objectives|Documents that GRAPHITE_TOKEN|Graphite-CI handles deduplication server-side' docs/buildkite-setup.md || trueRepository: sealedsecurity/seal
Length of output: 577
🏁 Script executed:
#!/bin/bash
set -euo pipefail
echo "== Search for GRAPHITE_TOKEN in .buildkite =="
rg -n 'GRAPHITE_TOKEN|graphite_token' .buildkite/
echo
echo "== Search for GRAPHITE_TOKEN in docs/buildkite-setup.md =="
rg -n 'GRAPHITE_TOKEN' docs/buildkite-setup.md
echo
echo "== Show PR objectives / summary context in docs/buildkite-setup.md =="
rg -n 'PR objectives|Documents that GRAPHITE_TOKEN|Graphite-CI handles deduplication server-side' docs/buildkite-setup.md || trueRepository: sealedsecurity/seal
Length of output: 577
Fix the GRAPHITE_TOKEN “no longer required” contradiction in the PR objectives
docs/buildkite-setup.md still instructs setting GRAPHITE_TOKEN (lines 156-160) and lists it for the orchestrator (line 189), and .buildkite/pipelines/orchestrator.yml still injects graphite_token: "$$GRAPHITE_TOKEN". Update the PR objectives summary to match the actual requirement (or change the pipeline/docs if the token truly became unnecessary).
🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
In `@docs/buildkite-setup.md` around lines 156 - 160, The PR objectives claim
GRAPHITE_TOKEN is no longer required but the docs and pipeline still reference
GRAPHITE_TOKEN and the orchestrator injects graphite_token: "$$GRAPHITE_TOKEN";
either update the PR objectives summary to state that GRAPHITE_TOKEN is
required, or remove references and injection of GRAPHITE_TOKEN from
docs/buildkite-setup.md and .buildkite/pipelines/orchestrator.yml; specifically
reconcile and change the PR objectives text to match the actual state or remove
the env var usage (GRAPHITE_TOKEN and graphite_token) from the orchestrator
pipeline and docs so they are consistent.
mattwilkinsonn
force-pushed
the
sea-587-buildkite-migration--poseidon
branch
from
6389736 to
8b87901
Compare
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
.buildkite/pipelines/orchestrator.yml (1)
39-39:⚠️ Potential issue | 🟠 MajorPin the Graphite Buildkite plugin to an immutable ref (don’t use
#main)In
.buildkite/pipelines/orchestrator.yml(line 39),- withgraphite/graphite-ci#main:should be changed to- withgraphite/graphite-ci#<git-tag>or the most robust- withgraphite/graphite-ci#<full-commit-sha>. Buildkite recommends immutable plugin refs (tags/SHAs) and avoiding branch refs like#main; Graphite’s plugin repo does not appear to provide stable version tags, so pinning to a specific commit SHA is the practical option here.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.buildkite/pipelines/orchestrator.yml at line 39, Replace the mutable plugin ref "- withgraphite/graphite-ci#main:" with an immutable ref by pinning to a specific tag or full commit SHA (e.g. "- withgraphite/graphite-ci#<git-tag>" or "- withgraphite/graphite-ci#<full-commit-sha>") so the Buildkite pipeline uses a fixed plugin version; update the occurrence of "- withgraphite/graphite-ci#main:" accordingly in the orchestrator pipeline definition.Justfile (1)
184-207:⚠️ Potential issue | 🟠 Major | ⚡ Quick winVerify downloaded Buildkite binaries before installing them to PATH.
This block installs executables from GitHub release tarballs without checksum/signature validation, which weakens the trust boundary for local developer tooling.
Suggested hardening
- if curl -fsSL -o "$tmp_dir/bk.tar.gz" "$bk_url"; then + checks_url="https://github.com/buildkite/cli/releases/download/v${bk_tag}/checksums.txt" + if curl -fsSL -o "$tmp_dir/checksums.txt" "$checks_url" \ + && curl -fsSL -o "$tmp_dir/bk.tar.gz" "$bk_url" \ + && (cd "$tmp_dir" && grep "bk_${bk_tag}_linux_${bk_arch}.tar.gz" checksums.txt | sha256sum --check --strict); then tar -xzf "$tmp_dir/bk.tar.gz" -C "$tmp_dir" bk install -m 0755 "$tmp_dir/bk" "$bin_dir/bk"#!/usr/bin/env bash set -euo pipefail echo "Agent release assets:" gh api repos/buildkite/agent/releases/latest --jq '.assets[].name' echo echo "CLI release assets:" gh api repos/buildkite/cli/releases/latest --jq '.assets[].name'🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In `@Justfile` around lines 184 - 207, The script currently downloads buildkite-agent and bk tarballs using ba_url/bk_url and installs files from tmp_dir without integrity/authenticity checks; update the download-and-install blocks for buildkite-agent (ba_url, tmp_dir, buildkite-agent) and bk (bk_url, tmp_dir, bk) to (1) fetch corresponding release asset checksums or signatures (via the GitHub releases API or provided .sha256/.asc assets), (2) verify the downloaded tarball using sha256sum --check or gpg --verify before extracting, (3) abort and emit a clear error if verification fails, and (4) only run tar/extract and install -m 0755 into $bin_dir once verification succeeds, ensuring tmp_dir cleanup still happens on both success and failure.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.buildkite/pipelines/orchestrator.yml:
- Line 39: Replace the mutable plugin ref "- withgraphite/graphite-ci#main:"
with an immutable ref by pinning to a specific tag or full commit SHA (e.g. "-
withgraphite/graphite-ci#<git-tag>" or "-
withgraphite/graphite-ci#<full-commit-sha>") so the Buildkite pipeline uses a
fixed plugin version; update the occurrence of "-
withgraphite/graphite-ci#main:" accordingly in the orchestrator pipeline
definition.
In `@Justfile`:
- Around line 184-207: The script currently downloads buildkite-agent and bk
tarballs using ba_url/bk_url and installs files from tmp_dir without
integrity/authenticity checks; update the download-and-install blocks for
buildkite-agent (ba_url, tmp_dir, buildkite-agent) and bk (bk_url, tmp_dir, bk)
to (1) fetch corresponding release asset checksums or signatures (via the GitHub
releases API or provided .sha256/.asc assets), (2) verify the downloaded tarball
using sha256sum --check or gpg --verify before extracting, (3) abort and emit a
clear error if verification fails, and (4) only run tar/extract and install -m
0755 into $bin_dir once verification succeeds, ensuring tmp_dir cleanup still
happens on both success and failure.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 57ff2619-cbcf-4754-92a7-104b1ad3af35
📒 Files selected for processing (4)
.buildkite/pipelines/lints.yml.buildkite/pipelines/orchestrator.ymlJustfiledocs/buildkite-setup.md
There was a problem hiding this comment.
Caution
Some comments are outside the diff and can’t be posted inline due to platform limitations.
⚠️ Outside diff range comments (2)
.buildkite/pipelines/orchestrator.yml (2)
25-42:⚠️ Potential issue | 🟠 Major | ⚡ Quick winPin the Graphite-CI plugin to a stable version or commit SHA.
The plugin reference
withgraphite/graphite-ci#maintracks themainbranch, which means the pipeline can break without warning if the plugin changes. For production CI stability, pin to a specific release tag or commit SHA (e.g.,withgraphite/graphite-ci#v1.2.3orwithgraphite/graphite-ci#abc123).📌 Proposed fix to pin the plugin version
plugins: - - withgraphite/graphite-ci#main: + - withgraphite/graphite-ci#v1.0.0: # Replace with actual stable version/SHA # GRAPHITE_TOKEN injected by Buildkite's pipeline-level🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.buildkite/pipelines/orchestrator.yml around lines 25 - 42, The pipeline step using the Graphite CI plugin (label ":graphite: Graphite CI optimizer", plugin reference withgraphite/graphite-ci#main) should be pinned to a specific release tag or commit SHA instead of tracking `#main`; update the plugin reference `withgraphite/graphite-ci#main` to a fixed identifier like `withgraphite/graphite-ci#vX.Y.Z` or `withgraphite/graphite-ci#<commit-sha>` to ensure CI stability and avoid unexpected breakage.
43-53: 🧹 Nitpick | 🔵 Trivial | ⚖️ Poor tradeoffVerify that synchronous lints trigger aligns with orchestrator performance goals.
The
async: falseconfiguration blocks the orchestrator step until theseal-lintspipeline completes. While this ensures correct commit-status ordering for branch protection, it also means the orchestrator agent remains occupied during the entire lints run (~8min cold-cache budget per lints.yml). If downstream pipelines will eventually run concurrently (seal-test-linux, seal-test-macos, etc.), confirm whether the orchestrator should block on lints or trigger all pipelines asynchronously and rely on GitHub's commit-status aggregation.🤖 Prompt for AI Agents
Verify each finding against current code. Fix only still-valid issues, skip the rest with a brief reason, keep changes minimal, and validate. In @.buildkite/pipelines/orchestrator.yml around lines 43 - 53, The orchestrator step for the Lints pipeline currently uses "async: false" which blocks the orchestrator agent while "seal-lints" runs; change the step with label ":hammer_and_wrench: Lints" (trigger: "seal-lints") to "async: true" so the orchestrator no longer waits for completion, and add/adjust a brief comment noting we rely on GitHub commit-status aggregation for final gating; if you decide to keep synchronous behavior instead, document the performance tradeoff and leave "async: false" intentionally.
🤖 Prompt for all review comments with AI agents
Verify each finding against current code. Fix only still-valid issues, skip the
rest with a brief reason, keep changes minimal, and validate.
Outside diff comments:
In @.buildkite/pipelines/orchestrator.yml:
- Around line 25-42: The pipeline step using the Graphite CI plugin (label
":graphite: Graphite CI optimizer", plugin reference
withgraphite/graphite-ci#main) should be pinned to a specific release tag or
commit SHA instead of tracking `#main`; update the plugin reference
`withgraphite/graphite-ci#main` to a fixed identifier like
`withgraphite/graphite-ci#vX.Y.Z` or `withgraphite/graphite-ci#<commit-sha>` to
ensure CI stability and avoid unexpected breakage.
- Around line 43-53: The orchestrator step for the Lints pipeline currently uses
"async: false" which blocks the orchestrator agent while "seal-lints" runs;
change the step with label ":hammer_and_wrench: Lints" (trigger: "seal-lints")
to "async: true" so the orchestrator no longer waits for completion, and
add/adjust a brief comment noting we rely on GitHub commit-status aggregation
for final gating; if you decide to keep synchronous behavior instead, document
the performance tradeoff and leave "async: false" intentionally.
ℹ️ Review info
⚙️ Run configuration
Configuration used: Organization UI
Review profile: ASSERTIVE
Plan: Pro Plus
Run ID: 099b1c85-d833-4290-b824-0e6d6f3a6085
📒 Files selected for processing (2)
.buildkite/pipelines/lints.yml.buildkite/pipelines/orchestrator.yml
![graphite-app[bot]](https://avatars.githubusercontent.com/in/158384?s=60&v=4){kind=small}
| && if [ "${actionlint_arch}" = "amd64" ]; then \ | ||
| echo "${ACTIONLINT_SHA256} /tmp/${tarball}" | sha256sum --check --strict; \ | ||
| fi \ |
There was a problem hiding this comment.
SHA256 verification is only performed for amd64 architecture but skipped for arm64. This creates a security vulnerability where arm64 builds could download and execute a compromised actionlint binary without integrity verification.
# Fix: Add SHA256 verification for arm64 as well
ARG ACTIONLINT_SHA256_ARM64=<arm64_sha256_here>
...
&& if [ "${actionlint_arch}" = "amd64" ]; then \
echo "${ACTIONLINT_SHA256} /tmp/${tarball}" | sha256sum --check --strict; \
elif [ "${actionlint_arch}" = "arm64" ]; then \
echo "${ACTIONLINT_SHA256_ARM64} /tmp/${tarball}" | sha256sum --check --strict; \
fi \| && if [ "${actionlint_arch}" = "amd64" ]; then \ | |
| echo "${ACTIONLINT_SHA256} /tmp/${tarball}" | sha256sum --check --strict; \ | |
| fi \ | |
| && if [ "${actionlint_arch}" = "amd64" ]; then \ | |
| echo "${ACTIONLINT_SHA256} /tmp/${tarball}" | sha256sum --check --strict; \ | |
| elif [ "${actionlint_arch}" = "arm64" ]; then \ | |
| echo "${ACTIONLINT_SHA256_ARM64} /tmp/${tarball}" | sha256sum --check --strict; \ | |
| fi \ | |
Spotted by Graphite
Is this helpful? React 👍 or 👎 to let us know.
mattwilkinsonn
force-pushed
the
sea-587-buildkite-migration--poseidon
branch
from
29c8c6b to
3013a87
Compare
mattwilkinsonn
force-pushed
the
sea-587-buildkite-migration--poseidon
branch
from
3013a87 to
d096d99
Compare
1 participant
Pull request
Summary
Establishes the Buildkite CI infrastructure by adding the
.buildkite/directory with an orchestrator pipeline, a lints pipeline, a tool-install script, and a comprehensive setup runbook (docs/buildkite-setup.md). Thelintsjob is removed from.github/workflows/ci.ymland migrated to Buildkite, where it runs as theseal-lintsdownstream pipeline triggered by the orchestrator.Changes
.buildkite/README.mddescribing the pipeline layout, path-filtering strategy, and which workflows intentionally remain on GitHub Actions.buildkite/pipelines/orchestrator.ymlas the single Buildkite GitHub App entrypoint: runs the Graphite-CI optimizer, then usesmonorepo-diff-buildkite-pluginto fan outtrigger:steps to per-concern downstream pipelines based on path filters mirroring.github/path-filters/*.yml.buildkite/pipelines/lints.ymlrunningcheck-fmt,actionlint, and the docs site lint/check suite (biome,markdownlint-cli2,astro check) on alinux-amd64hosted agent with S3-backed bun install cache.buildkite/scripts/lints-install-tools.shto idempotently installrustfmt,actionlint(SHA-pinned),just,nvm/Node 24, andbunon the agentlintsjob from.github/workflows/ci.ymlbuildkite-agentandbkCLI installation tojust install-deps— via Homebrew on macOS and via pinned release tarballs into$CARGO_HOME/binon Linuxdocs/buildkite-setup.mdcovering the full one-time setup: Buildkite org and agent queue configuration, GitHub App installation, required-status-check naming and two-step rollout order, path filtering, Graphite integration, per-pipeline secrets inventory, and S3-backed cache strategyNotes for reviewers
trigger:steps forseal-test-linux,seal-test-macos,seal-live-tests,seal-clients-even-terminal, andseal-docsare wired but those downstream pipeline YAML files are not included in this PR — they land separately.live-testslabel to a PR, independent of path changes, via a dedicatedtrigger:step in the orchestrator.buildkite/seal-lints,buildkite/seal-test-linux, etc.) are posted back to GitHub through the orchestrator's triggered builds.