Zanie Blue
6b1ebc33dc
The way this works is 1. `release-gate` is an environment which requires approval from another person in the organization 2. Once approved, the release can continue 3. GitHub then requires approval for every subsequent job, which we use the `release` environment for 4. We do not require team members to approve on the `release` environment because we run _many_ child jobs during releases 5. The `release` environment uses a deployment protection rule which queries a GitHub App we manage 6. The GitHub App checks if the `release-gate` job was successful in the same workflow and approves or denies accordingly The GitHub App's source is at https://github.com/open-security-tools/ost-environment-gate and includes another explanation of what's going on in this process. We don't make the release-gate block everything, so builds can start at least while we wait for the release-gate to be approved.
34 lines
970 B
YAML
34 lines
970 B
YAML
# Publish a release to crates.io.
|
|
#
|
|
# Assumed to run as a subworkflow of .github/workflows/release.yml; specifically, as a publish job
|
|
# within `cargo-dist`.
|
|
name: "Publish to crates.io"
|
|
|
|
on:
|
|
workflow_call:
|
|
inputs:
|
|
plan:
|
|
required: true
|
|
type: string
|
|
|
|
jobs:
|
|
crates-publish-uv:
|
|
name: Upload uv to crates.io
|
|
runs-on: ubuntu-latest
|
|
environment:
|
|
name: release
|
|
permissions:
|
|
contents: read
|
|
id-token: write
|
|
steps:
|
|
- uses: actions/checkout@de0fac2e4500dabe0009e67214ff5f5447ce83dd # v6.0.2
|
|
with:
|
|
persist-credentials: false
|
|
- uses: rust-lang/crates-io-auth-action@bbd81622f20ce9e2dd9622e3218b975523e45bbe # v1.0.4
|
|
id: auth
|
|
- name: Publish workspace crates
|
|
# Note `--no-verify` is safe because we do a publish dry-run elsewhere in CI
|
|
run: cargo publish --workspace --no-verify
|
|
env:
|
|
CARGO_REGISTRY_TOKEN: ${{ steps.auth.outputs.token }}
|