mlevkov · Sep 24, 2026 · Sep 24, 2026
@@ -206,28 +206,8 @@ jobs:
           files: artifacts/**/*
           generate_release_notes: true
 
-  # ==========================================================================
-  # Publish to crates.io (optional)
-  # ==========================================================================
-  # TD-2026-09-04: this job cannot succeed (there is no CRATES_IO_TOKEN
-  # secret, and Cargo.toml sets publish = false), and continue-on-error hides
-  # that. Resolve the record before editing the job.
-  publish:
-    name: Publish to crates.io
-    runs-on: ubuntu-latest
-    needs: [validate, release]
-    # Only publish stable releases
-    if: needs.validate.outputs.is_prerelease == 'false'
-    steps:
-      - uses: actions/checkout@v7
-      - uses: dtolnay/rust-toolchain@02cb101ec7c40f2c49e1d9714d64511d8e1b74de # master
-        with:
-          toolchain: stable
-      - uses: Swatinem/rust-cache@f0d9c3887740aee45f6153b24b3a6b815192ec16 # v2
-
-      - name: Publish to crates.io
-        run: cargo publish --token ${{ secrets.CRATES_IO_TOKEN }}
-        continue-on-error: true  # Don't fail if already published
+  # No crates.io publish job: the crate is publish = false and releases are
+  # repo-level only (TD-2026-09-04).
 
   # ==========================================================================
   # Deploy documentation

@@ -5,10 +5,10 @@
 # runs scripts/verify-release.sh after each one: a problem shows up as a
 # failed run here instead of waiting for someone to remember the script.
 # Re-running jobs of a Release run makes a new attempt of it, which runs
-# this again once it succeeds. Until TD-2026-09-04 is resolved it fails on
-# every stable release, by design: the crates.io publish step fails
-# silently there. It can also be run by hand for any tag (Actions > Verify
-# Release > Run workflow).
+# this again once it succeeds. It fails on the stable releases up to
+# v0.4.1, by design: their crates.io publish step failed silently, and the
+# job is gone since (TD-2026-09-04). It can also be run by hand for any tag
+# (Actions > Verify Release > Run workflow).
 
 name: Verify Release
 

@@ -16,22 +16,29 @@ and this project adheres to [Semantic Versioning](https://semver.org/spec/v2.0.0
   target; the Pages deployment and the served docs; crates.io against
   Cargo.toml's `publish`; and that the host platform's binary runs, isolated
   and time-bounded. It fails on a step that failed under `continue-on-error`,
-  which the Actions API reports as a success: the crates.io publish step has
-  failed that way on every stable release (TD-2026-09-04). It handles a run
-  whose jobs were re-run, where the jobs an attempt did not re-run carry
-  over with their logs, and needs gh 2.75 or later to fetch those
+  which the Actions API reports as a success: the crates.io publish step
+  failed that way on every stable release through v0.4.1 (TD-2026-09-04).
+  It handles a run whose jobs were re-run, where the jobs an attempt did not
+  re-run carry over with their logs, and needs gh 2.75 or later to fetch
+  those
 - The Verify Release workflow runs it after every green Release run,
   re-runs included, on exactly the run and attempt that triggered it, so a
   hidden failure fails a run instead of waiting for someone to look; it can
-  also be run by hand for any tag. Until TD-2026-09-04 is resolved it fails
-  on every stable release, by design
+  also be run by hand for any tag. It fails on the stable releases up to
+  v0.4.1, by design, for that masked publish step
 - CI lints shell scripts with shellcheck, as part of the required CI Success
   check
 - CONTRIBUTING.md describes releasing, and exercising `release.yml` with a
   pre-release tag, including the two things that outlive the exercise: the
   Pages deployment (with how to restore it, and the limits of doing so) and
   the tag itself
 
+### Removed
+
+- release.yml's crates.io publish job. The crate is `publish = false`, and
+  its releases are repo-level only; the job could not succeed and failed on
+  every stable release, hidden by `continue-on-error` (TD-2026-09-04)
+
 ### Fixed
 
 - The README no longer says coverage is uploaded to Codecov: every upload

@@ -195,9 +195,10 @@ trigger is the next release.
 
 A green run does not mean every step worked, since a step under
 `continue-on-error` fails silently. So `.github/workflows/verify-release.yml`
-runs `scripts/verify-release.sh` after every green Release run; until
-TD-2026-09-04 is resolved it fails on every stable release, by design. To
-check a run by hand:
+runs `scripts/verify-release.sh` after every green Release run. It fails
+on the stable releases up to v0.4.1, by design: their crates.io publish
+step failed silently, and release.yml has had no publish job since
+(TD-2026-09-04). To check a run by hand:
 
 ```bash
 scripts/verify-release.sh v0.4.2

@@ -5,10 +5,9 @@ edition = "2024"
 rust-version = "1.93.0"
 description = "A comprehensive demonstration of Apache Iggy message streaming with Axum"
 license = "MIT"
-# Repo-level releases only - never published to crates.io (enforced here,
-# not just in CI: cargo refuses to publish with this set). release.yml still
-# runs a publish job, which fails silently: with no token it stops before
-# reaching this setting, and with one this would stop it. TD-2026-09-04.
+# Repo-level releases only (GitHub Releases and Pages): never published to
+# crates.io, and cargo refuses to publish with this set. release.yml has no
+# publish job (TD-2026-09-04).
 publish = false
 repository = "https://github.com/mlevkov/iggy_sample"
 homepage = "https://github.com/mlevkov/iggy_sample"

@@ -17,6 +17,6 @@ condition under which the record MUST be resolved (not "someday").
 | [TD-2026-09-01](TD-2026-09-01.md) | API listener serves cleartext HTTP/2 by feature unification | RUSTSEC-2026-0258 remediation (h2 exposure) | A tripwire failing (CI feature-graph check or either h2c test), next change to the serving path, next `h2` advisory, or next minor bump of `axum`/`hyper-util`/`metrics-exporter-prometheus` | open |
 | [TD-2026-09-02](TD-2026-09-02.md) | Validate dependabot.yml in CI, and put the Dockerfile on an updater | RustSec 2026-09 remediation review, rounds 1-2 | Next edit to `.github/dependabot.yml` after it lands, or the next `rust-version` change | open |
 | [TD-2026-09-03](TD-2026-09-03.md) | The Codecov upload fails silently for want of a token | Dependabot first-wave triage (codecov-action bump, PR #37) | Next edit to ci.yml's coverage job, the next major `codecov-action` bump, or the next release | open |
-| [TD-2026-09-04](TD-2026-09-04.md) | The crates.io publish job cannot succeed | Dependabot first-wave triage (release.yml exercise, PR #37) | The next stable release tag, or the next edit to the publish job or to `publish` in Cargo.toml | open |
+| [TD-2026-09-04](TD-2026-09-04.md) | The crates.io publish job cannot succeed | Dependabot first-wave triage (release.yml exercise, PR #37) | The next stable release tag, or the next edit to the publish job or to `publish` in Cargo.toml | resolved (2026-09-24: job deleted) |
 | [TD-2026-09-05](TD-2026-09-05.md) | rust-cache is pinned to a branch head under a release comment | Dependabot first-wave triage (SHA pin check, PR #37); carries TD-2026-07-07's addendum | The next github-actions Dependabot PR that moves the rust-cache or audit-check pin | open |
 | [TD-2026-09-06](TD-2026-09-06.md) | main accepts a pull request whose checks ran against an older main | Dependabot first-wave triage (merging PRs #37-#42) | Before merging the next Dependabot wave (next scheduled run 2026-09-28) | open |
@@ -2,7 +2,7 @@
 
 **Source:** Dependabot first-wave triage (2026-09-23), exercising release.yml
 for PR #37's action bumps.
-**Status:** open
+**Status:** resolved (2026-09-24: option 1, the job is deleted)
 
 ## Problem
 
@@ -54,3 +54,17 @@ User-Agent; crates.io answers 403 without one).
 Whichever comes first: the next stable release tag (the Verify Release
 workflow fails on it until this is resolved), or the next edit to the
 publish job or to `publish` in Cargo.toml.
+
+## Resolution (2026-09-24)
+
+The maintainer ruled out publishing to crates.io, so option 1: release.yml's
+publish job is deleted, and no workflow references `CRATES_IO_TOKEN` any
+more. `publish = false` stays, and cargo's refusal remains the guard that
+TD-2026-07-07 relies on; the Cargo.toml comment no longer describes the job.
+
+Verify Release checks each run against the release.yml that run used, so
+the stable releases up to v0.4.1 still fail it on the masked step, as its
+first run did. From the next release on, the verifier finds no publish job,
+PASSes that against `publish = false`, and still checks that crates.io lacks
+the version. The job also held one of TD-2026-09-05's rust-cache pins,
+which leaves 16.
@@ -8,8 +8,9 @@ TD-2026-07-07's 2026-09-23 addendum.
 ## Problem
 
 TD-2026-07-07's convention is `uses: owner/action@<sha> # vX`, with the SHA a
-release commit. `Swatinem/rust-cache` breaks it in all 17 of its uses (ci.yml
-5, extended-tests.yml 6, pr.yml 3, release.yml 3): since PR #37 the pin is
+release commit. `Swatinem/rust-cache` breaks it in all 16 of its uses (ci.yml
+5, extended-tests.yml 6, pr.yml 3, release.yml 2; 17 when filed, before
+TD-2026-09-04's resolution took the publish job's): since PR #37 the pin is
 `f0d9c388… # v2`, the head of upstream `master`, five commits past v2.9.2
 (`6323deb`, where the `v2` tag points). Those commits are one fix (#377,
 cleanup timestamp pruning) and two dependency bumps with their merges. The
@@ -47,7 +48,7 @@ open, and this record carries it.
 
 - Re-pin rust-cache to v2.9.2's commit with an accurate comment,
   `Swatinem/rust-cache@6323deb102c322ba6fcbdcafc7e3dddab59af2b6 # v2.9.2`, in
-  all 17 places. With a tagged SHA, Dependabot proposes releases from then
+  all 16 places. With a tagged SHA, Dependabot proposes releases from then
   on.
 - Move audit-check to a release SHA the same way once upstream tags a
   release that includes its Node 24 change.

@@ -16,9 +16,10 @@
 # runs instead, and VERIFY_RUN_ATTEMPT an earlier attempt.
 #
 # .github/workflows/verify-release.yml runs this after every green Release
-# run, for the run and attempt that triggered it, and on demand. Until
-# TD-2026-09-04 is resolved every stable release gets one FAIL, for its
-# crates.io publish step, which fails under continue-on-error.
+# run, for the run and attempt that triggered it, and on demand. Stable
+# releases up to v0.4.1 get one FAIL, for the crates.io publish step their
+# release.yml ran, which failed under continue-on-error; release.yml has had
+# no publish job since TD-2026-09-04 was resolved.
 #
 # A tag with a hyphen (v0.4.1-ci.1) is a pre-release: the publish job must be
 # skipped and the release must not become Latest. The docs job still deploys
@@ -239,10 +240,12 @@ if gh api --paginate "repos/$REPO/actions/runs/$RID/attempts/$ATTEMPT/jobs" \
     check "one build job per release.yml target ($(wc -l <"$WORK/targets.txt" | tr -d ' '))" \
         cmp -s "$WORK/targets.txt" "$WORK/built.txt"
     # shellcheck disable=SC2016 # $1 and $2 are awk fields
-    check "every job except publish succeeded" \
+    check "every job$([ "$HAS_PUBLISH" = true ] && echo " except publish") succeeded" \
         awk -F'\t' '$1 != "Publish to crates.io" && $2 != "success" { bad = 1 } END { exit bad }' "$WORK/jobs.tsv"
     publish=$(awk -F'\t' '$1 == "Publish to crates.io" { print $2 }' "$WORK/jobs.tsv")
-    if [ "$HAS_PUBLISH" = false ]; then
+    if [ "$HAS_PUBLISH" = false ] && [ "$PUBLISH" = false ]; then
+        pass "no publish job, as Cargo.toml's publish = false wants (release.yml at ${SHA:0:7})"
+    elif [ "$HAS_PUBLISH" = false ]; then
         skip "publish job (release.yml at ${SHA:0:7} has none)"
     elif [ -z "$publish" ]; then
         fail "publish job is in the run"