ci: drop broken 'QA - Sync from scratch' trigger from update-disk-sizes - #22556
Merged
bloxster merged 1 commit intoJul 20, 2026
Merged
Conversation
The plain 'QA - Sync from scratch' workflow matches neither the minimal nor full-node keyword in the prune-mode detection, so each time it completed it fired update-disk-sizes, which errored at 'Determine prune mode'. It also emits no disk-usage-* artifacts, so there'd be nothing to process even if a mode were guessed. The two dedicated producers already cover the use case. The least-privilege App-token scoping added in #22547 needs no change: the RELEASE_BOT_APP installation was granted contents + pull-requests write, so create-github-app-token now mints the scoped token successfully. Supersedes #22553.
lystopad
enabled auto-merge
July 17, 2026 12:43
bloxster
pushed a commit
that referenced
this pull request
Jul 20, 2026
Bring the release/3.5 copy in line with main's maintained determine logic and the static-markers flow: - Trigger on the dedicated producers "(minimal node)" and "(full node)"; drop the broken plain "QA - Sync from scratch" trigger (matches #22556): it emits no disk-usage-* artifact, so it only ever fired a failing run. - Adopt main's determine logic: minimal -> minimal, full node -> full, else -> ::error:: (explicit guard, not a silent "full" fallback). - Fix base_branch release/3.4 -> release/3.5 (workflow_run paths + the workflow_dispatch default): docs deploy from release/3.5 now. Note: on release/3.5 this workflow is only reachable via manual workflow_dispatch — workflow_run events run the copy from the default branch (main). The render-disk-sizes.py step added here therefore also needs to land on main's update-disk-sizes.yml to keep CI-generated disk-size PRs in sync with the static markers. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
bloxster
approved these changes
Jul 20, 2026
github-merge-queue
Bot
removed this pull request from the merge queue due to failed status checks
Jul 20, 2026
ADD12
pushed a commit
to ADD12/erigon
that referenced
this pull request
Jul 21, 2026
…to main) (erigontech#22628) Forward-port of erigontech#22596 (merged to `release/3.5`) to `main`. ## What & why The hardware-requirements "Current Disk Usage" numbers were pulled at runtime from one shared `disk-sizes.json`. Every docs version imported the **same** file, so the `/v3.4/` page showed the **current** numbers instead of 3.4's — and a missing value silently rendered `—`. This makes the numbers **static text**, so each docs version keeps its own correct values. ## How it works now - Values live in the page between markers: `{/* ds:mainnet:full */}920 GB{/* ds:end */}`. - `scripts/render-disk-sizes.py` fills those markers from `disk-sizes.json`. CI runs it with `--check` and **fails the build** if the page and JSON disagree, or if any page still imports the JSON. - Because the page is static, `docusaurus docs:version` freezes the right numbers automatically — no extra step at release time. ## Changes - Current + **v3.4** hardware pages: static values + "measured as of" date; runtime import removed. - New `render-disk-sizes.py` + tests (fail-closed on typo'd/unpaired markers, bad dates, unsafe values). - CI (`docs-site-build.yml`): render `--check` + guard against dynamic references. (Keeps main's `checkout@v7` / `persist-credentials` / `timeout-minutes`.) - `update-disk-sizes.yml`: **only** adds the render step + commit-both. Main's app-token infra (erigontech#22547), trigger cleanup (erigontech#22556), and `base_branch=release/3.5` are preserved. This is also where the main-side workflow change from the erigontech#22596 discussion lands. - README: documents the data flow + version-cut runbook. - `llms-full.txt`: regenerated (real values instead of `—`). ## Verification `render --check`, guard, **78 script tests**, `generate-llms.py --check`, typecheck, and build all pass. Ported content is byte-identical to merged erigontech#22596; adversarially reviewed for merge correctness (main-only workflow features confirmed preserved). ## Note `update-disk-sizes` dispatched against a base branch that lacks `render-disk-sizes.py` (e.g. retired `release/3.4`) now fails at the render step — fail-loud and expected. 🤖 Generated with [Claude Code](https://claude.com/claude-code) --------- Co-authored-by: Bloxster <gianni.morselli@erigon.tech> Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
update-disk-sizesfires onworkflow_runcompletion of three workflows and picks its prune mode from the triggering workflow's name:*minimal*→ minimal,*full node*→ full, else::error::+ exit 1.The plain
QA - Sync from scratchmatches neither keyword, so every time it completes it firesupdate-disk-sizes, which dies immediately at the "Determine prune mode" step. It also has no "Measure disk usage" step and uploads nodisk-usage-*artifact (only the minimal/full workflows do), so there is nothing to process even if a mode were guessed.update-disk-sizeshas 0 successful runs recently — this trigger is one of the reasons.Fix
Remove the
QA - Sync from scratchentry from theworkflow_runtriggers. The two dedicated producers (… (minimal node),… (full node)) name themselves correctly and emit the disk-usage artifacts, so they fully cover the use case. This does not change theQA - Sync from scratchworkflow itself — it just stops it kicking off a guaranteed-failingupdate-disk-sizesrun.Note on the App token
The separate token failure that appeared after #22547 (
create-github-app-token→ "permissions requested are not granted to this installation") is now resolved out-of-band: theRELEASE_BOT_APPinstallation was granted contents: write + pull-requests: write, so the least-privilege scoping added in #22547 mints the scoped token successfully. No code change needed here for that.Verification
zizmor 1.26.1 --config .github/zizmor.yml→ exit 0,github-app0 findings (bothrelease.ymlandupdate-disk-sizes.ymlpass the audit scoped, no suppression).actionlinton the workflow → clean.Supersedes #22553.