What the agent does
For a Rust repo like rust-lang/mdBook, the agent inventories .github/workflows before changing a line. mdBook is a 2024-edition workspace (Cargo.toml workspace.package.edition = "2024", rust-version = "1.88.0", mdbook version 0.5.4) with crates under crates/* and workflows deploy.yml, main.yml, publish-crates-io.yml and update-dependencies.yml. main.yml alone defines a large CI matrix (stable/beta/nightly Linux, musl, aarch64, macOS, Windows MSVC, MSRV), plus jobs for Rustfmt, Spell Check with Typos (crate-ci/typos@v1.50.3), GUI tests that call actions/setup-node@v7, API docs, cargo-semver-checks, cargo audit and a Success gate.
Pinning is inconsistent today: deploy.yml, publish-crates-io.yml and update-dependencies.yml already pin actions/checkout to 3d3c42e5aac5ba805825da76410c181273ba90b1 with a # v7.0.1 comment, and publish-crates-io.yml pins rust-lang/crates-io-auth-action to c6f97d42243bad5fab37ca0427f495c86d5b1a18 # v1.0.5. main.yml still uses floating tags actions/checkout@v7, actions/setup-node@v7 and crate-ci/typos@v1.50.3. The agent resolves each action’s current release commit on GitHub, rewrites every uses: line to the full SHA and puts the human version in a trailing comment, matching the style already used in deploy.yml.
For each bumped action it reads the release notes for breaking inputs. setup-node and checkout major lines are checked for renamed inputs and required permissions. typos action input changes are applied in the Spell Check job if needed. The agent does not bump Rust toolchains, MSRV or crate dependencies in this job; those stay on their existing pins unless an action changelog forces a workflow edit.
It opens a pull request and watches the workflow checks on that branch. Locally it may run cargo test or the GUI npm steps only when a workflow change clearly requires a smoke check; the proof that matters is the GitHub Actions run on the PR. Failures tied to the new action version are fixed in the workflow; unrelated flaky jobs are reported rather than silently skipped.
Start it with one API call
POST https://api.prix.dev/o/{org}/sessions with this body:
{
"agent": "codex",
"input": "Update every action used in .github/workflows to its latest release, pinned by full commit SHA with the version as a comment. Read each action's changelog for breaking input changes and adjust the workflow. Open a pull request and make sure its checks pass.",
"resources": [
{
"url": "https://github.com/your-org/your-app"
}
]
}- Get an API key. In the console, open Settings, then API keys, and create a key for your org. Send it in the Authorization header as a Bearer token.
- Send the request. POST the body in request.json to https://api.prix.dev/o/{org}/sessions, with your repository as the resources URL. The run starts in its own cloud sandbox.
- Read what came back. Follow the run on its live stream or wait for the run.completed webhook, then read the result and its trajectory.
What comes back
The pull request updates workflow YAML under .github/workflows so every third-party action uses a full commit SHA with a version comment. In an mdBook-shaped repo that means bringing main.yml’s checkout, setup-node and typos lines in line with the SHA style already present in deploy.yml and publish-crates-io.yml, plus any input renames required by the new releases.
The PR description lists each old ref, new SHA, version comment and changelog item that forced an input change. A reviewer confirms no application crate versions moved, that rust-version and the MSRV job are untouched, and that the CI, GUI and audit jobs on the pull request are green. Session result and PR metadata are on GET /o/{org}/sessions/{id}.
Run it on every Monday morning
Schedule a weekly job that POSTs this session body once per Rust repository with that repo in resources. Use a new Idempotency-Key each week so retries stay safe without starting duplicate bump runs.
Set webhook_url on the API key to receive run.completed. When the PR is open, your bot can subscribe to check suites or wait for the session result text that names the PR URL.
The use case this job follows, with its automation and trigger: Upgrade dependencies weekly.
Why run it on Rush?
Floating action tags can move under you; SHA pins with version comments are the durable form, but resolving SHAs and reading changelogs across several workflows is tedious on a laptop. The sandbox clones the repo, edits every workflow and lets GitHub run the real matrix on the PR.
Several Rust services can be updated in parallel, each in its own session under your key’s concurrency limit. The transcript keeps the changelog reads and the exact YAML diffs for audit.
Frequently asked questions
Does it change Cargo dependencies or the MSRV?
No. This job only updates GitHub Actions refs and workflow inputs required by those actions. rust-version 1.88.0 and crate versions stay as they are unless you start a separate upgrade session.
What about workflows that are already SHA-pinned?
The agent still checks for newer releases. If deploy.yml’s checkout SHA is already current, it leaves it alone and says so in the PR description.
Will it rewrite reusable workflows in other repositories?
It only edits files under this repository’s .github/workflows. External reusable workflow references are updated only if they appear as uses: lines in those files and the prompt covers them.
How does it prove the workflows still pass?
By opening the pull request and relying on the repository’s GitHub Actions checks (the mdBook CI matrix, GUI job, audit and related jobs). The session transcript records any local smoke commands it ran as well.