1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
name: Publish to crates.io
# The published crate is SOURCE ONLY. `build.rs` reads GRR_CLIENT_ID /
# GRR_CLIENT_SECRET from the build environment and bakes them in, but a
# crates.io consumer compiles the sources with no such variables set, so
# `cargo install grr-cli` produces a binary with no embedded OAuth client.
#
# That is deliberate rather than a packaging bug:
# - Release binaries (GitHub Releases, Homebrew, winget) ARE built with the
# secrets and are therefore zero-config.
# - Source installs either set the two variables themselves, drop a `.env`
# next to Cargo.toml (see .env.example), or run `grr auth setup`.
#
# Do NOT inject the secrets into this workflow: a `.crate` tarball must never
# contain a compiled-in credential, and injecting them here would only
# affect the local verification build, never the shipped artifact.
on:
workflow_dispatch:
push:
tags:
concurrency:
group: publish
cancel-in-progress: false
jobs:
publish:
name: publish grr-cli
runs-on: ubuntu-latest
timeout-minutes: 90
environment: crates-io
permissions:
contents: read
id-token: write
steps:
- uses: actions/checkout@v7
timeout-minutes: 2
# No rust-cache and no rust-src here, deliberately. The crate is
# source-only (see the comment block above) and `--no-verify` skips
# cargo's verification build, so `cargo publish` compiles nothing: a
# cache restore resolved a `target/` that does not exist, and rust-src
# only exists to feed build-std, which never runs. Dropping both removes
# a pointless cache round trip and the rust-src component download
# (~15-40s) from every publish.
- uses: dtolnay/rust-toolchain@nightly
timeout-minutes: 10
- name: Authenticate with crates.io
uses: rust-lang/crates-io-auth-action@v1
timeout-minutes: 5
id: auth
- name: Publish grr-cli
timeout-minutes: 60
run: cargo publish --no-verify
env:
CARGO_REGISTRY_TOKEN: ${{ steps.auth.outputs.token }}