[build] add a daily workflow to update the pinned CDDL specs

[titusfortner]

🔗 Related Issues

• Builds on [build] Add update_cddl script to refresh pinned w3c/webref CDDL files #17743 — schedules //scripts:update_cddl, which lost its only caller when 857ff4f dropped it from release preparation
• Follows [js][py][rb] derive BiDi field names and enum value types in the schema #17966 — the checked-in schema needs refreshing on every repin

💥 What does this PR do?

• Adds a daily workflow that repins the CDDL specs from w3c/webref and opens a PR when the spec actually changes.
• ./go update_cddl now also refreshes the checked-in BiDi schema and regenerates the Ruby protocol, so a repin lands with everything it feeds.

🔧 Implementation Notes

• The script writes nothing unless a consumed CDDL or dfns hash changed. webref's tip moves several times a day for specs we don't pin, so following it would open a PR most days; over the last four months only six commits touched a file we consume.
• The rendered spec HTML is repinned in lockstep with the CDDL rather than followed at its own tip, since it only annotates types that come from the grammar and gh-pages rebuilds on any prose edit.
• Regeneration is skipped when the pin didn't move, so a quiet daily run costs no Bazel build.
• Dropped the script's --commit/--branch flags: nothing passed them, and reverting the pin commit is the better way to back out a bad pin.

🤖 AI assistance

• AI assisted (complete below)
  • Tool(s): Claude Code (Opus 5)
  • What was generated: the workflow, the no-op gating, and this description
  • I reviewed all AI output and can explain the change

🔄 Types of changes

• New feature (CI tooling, no user-facing change)

[qodo-code-review]

PR Summary by Qodo

Automate daily CDDL repins and protocol regeneration

✨ Enhancement ⚙️ Configuration changes 🕐 20-40 Minutes

AI Description

• Schedules daily CDDL repins and opens pull requests only for consumed specification changes.
• Refreshes BiDi schema and Ruby protocol outputs whenever pinned content advances.
• Keeps rendered BiDi HTML aligned with CDDL changes while avoiding unnecessary builds.

Diagram

graph TD
  A["Daily trigger"] --> B["Bazel workflow"] --> C["Update task"] --> D{"Content changed?"}
  D -->|Yes| F["Refresh pins"] --> G["Regenerate outputs"] --> H["Automated PR"]
  D -->|No| E["No-op"]

Loading

High-Level Assessment

The chosen approach is appropriate: it reuses the existing Bazel workflow, gates on consumed content hashes, and regenerates all derived artifacts through established tasks. Following every upstream tip or regenerating unconditionally would create noisy pull requests and unnecessary builds without improving reproducibility.

Files changed (5) +127 / -32

Enhancement (3) +43 / -30

RakefileRegenerate dependent BiDi artifacts after pin changes +10/-1

Regenerate dependent BiDi artifacts after pin changes

• Extends the top-level update_cddl task to detect whether the pin file changed. When it did, the task refreshes the checked-in BiDi schema and invokes Ruby protocol generation; otherwise it skips expensive generation.

Rakefile

ruby.rakeAdd Ruby BiDi protocol regeneration task +6/-0

Add Ruby BiDi protocol regeneration task

• Adds the rb:update_cddl task, which runs the existing Bazel BiDi generator to refresh Ruby protocol classes from the pinned schema.

rake_tasks/ruby.rake

update_cddl.pyGate CDDL repins on consumed content changes +27/-29

Gate CDDL repins on consumed content changes

• Removes unused commit and branch arguments and always probes webref main. The updater now compares generated CDDL and definitions hashes while ignoring commit-only movement, repins rendered BiDi HTML only after meaningful changes, and writes pin and module files only when required.

scripts/update_cddl.py

Documentation (1) +3 / -2

webref_cddl.bzlDocument content-driven CDDL and HTML pin advancement +3/-2

Document content-driven CDDL and HTML pin advancement

• Clarifies that the webref commit intentionally advances only when consumed hashes change. It also documents that rendered BiDi HTML is repinned alongside CDDL content rather than independently following its branch tip.

common/webref_cddl.bzl

Other (1) +81 / -0

update-cddl.ymlSchedule daily CDDL updates and automated pull requests +81/-0

Schedule daily CDDL updates and automated pull requests

• Adds scheduled and manual execution of the CDDL update through the reusable Bazel workflow. It applies non-empty patch artifacts, creates a labeled pull request, and sends Slack notifications when the workflow fails or is cancelled.

.github/workflows/update-cddl.yml

[qodo-code-review]

Code Review by Qodo

🐞 Bugs (0) 📘 Rule violations (1) 📜 Skill insights (0)

1. Update failures are masked ✗ Dismissed 🐞 Bug ☼ Reliability ⭐ New

Description

The new workflow runs ./go update_cddl through a reusable job whose tee pipeline does not enable
pipefail, masking the command's nonzero exit status and potentially reporting a failed or
partially completed regeneration as successful. As a result, the workflow may create a PR from
incomplete changes, skip rerun diagnostics, and not trigger its failure notification.

Code

.github/workflows/update-cddl.yml[R17-18]

+      run: ./go update_cddl
+      artifact-name: cddl-updates

Evidence

The added workflow invokes the reusable Bazel workflow with ./go update_cddl and proceeds to PR
creation when that job succeeds. The reusable workflow pipes the command to tee without enabling
pipefail, so Bash normally reports tee's successful exit status rather than the update command's
failure; consequently, steps.run-bazel.outcome remains successful, and neither rerun diagnostics
nor the new failure-notification job detects the failed update.

.github/workflows/update-cddl.yml[14-24]
.github/workflows/update-cddl.yml[65-79]
.github/workflows/bazel.yml[248-264]
.github/workflows/bazel.yml[295-308]
.github/workflows/update-cddl.yml[12-18]
.github/workflows/update-cddl.yml[65-81]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
Ensure a failure from `./go update_cddl` makes the reusable Bazel workflow fail instead of being masked by the successful `tee` process. The current behavior can allow partial output to be uploaded, a PR to be created from incomplete changes, and failure diagnostics and notifications to be skipped.

## Issue Context
The new workflow supplies `./go update_cddl` to the reusable workflow, which executes its `run` input in a Bash pipeline and captures console output through `tee`. The reusable workflow already uses `continue-on-error` to permit failure diagnostics and checks `steps.run-bazel.outcome` to decide whether to rerun or collect diagnostics, but that outcome can only detect the failure if the pipeline preserves the update command's nonzero exit status. Enable pipeline failure propagation, for example with `set -o pipefail`, while preserving console-log capture, and verify that a nonzero update command causes the reusable workflow and dependent failure handling to fail.

## Fix Focus Areas
- .github/workflows/update-cddl.yml[14-18]
- .github/workflows/bazel.yml[248-264]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. No tests for no-op gate 📘 Rule violation ☼ Reliability ⭐ New

Description

The new content-comparison gate can suppress pin updates and downstream schema generation, but no
focused tests cover changed-content, commit-only, or unchanged-content cases. A regression in this
logic could silently leave generated protocol artifacts stale.

Code

scripts/update_cddl.py[R215-219]

+    # Probe with the pin already in the file so a gh-pages rebuild cannot open the gate.
+    webref_only = update_pin(old, commit, cddl_entries, dfns_entries, *current_bidi_pin(old))
+    if drop_commit(webref_only) == drop_commit(old):
+        print("No pinned spec content changed; leaving the pins at their current commits.")
+        return

Evidence

PR Compliance ID 5 requires focused coverage for behavioral changes. The cited code introduces an
early return controlling whether pins and generated artifacts are refreshed, while repository test
discovery found no tests covering update_cddl.

AGENTS.md: Add Focused Tests and Avoid Contract-Misrepresenting Mocks
scripts/update_cddl.py[215-219]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new CDDL no-op gate lacks focused regression tests for its content-normalization and early-return behavior.

## Issue Context
Tests should verify that unchanged content and commit-only changes produce no writes, while changed CDDL or dfns hashes update the pins and allow downstream regeneration. Mock network and filesystem boundaries without changing their contracts.

## Fix Focus Areas
- scripts/update_cddl.py[150-224]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

3. Patch added under third_party ✗ Dismissed 📘 Rule violation ⚙ Maintainability

Description

The PR directly adds third_party/bazel/rules_rs_zlib_snapshot.patch, which violates the explicit
prohibition on modifying files under third_party/. Relocate the patch to an approved
source-controlled patch directory and update the Bazel override reference.

Code

third_party/bazel/rules_rs_zlib_snapshot.patch[R1-3]

+diff --git a/rs/private/rustc_repository.bzl b/rs/private/rustc_repository.bzl
+--- a/rs/private/rustc_repository.bzl
++++ b/rs/private/rustc_repository.bzl

Evidence

PR Compliance ID 3 prohibits direct edits under third_party/. The cited newly added file is
located under third_party/bazel/ and contains the rules_rs dependency patch.

AGENTS.md: Do Not Modify Third-Party or Generated Output Directories
third_party/bazel/rules_rs_zlib_snapshot.patch[1-20]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new rules_rs patch is stored under `third_party/`, which the compliance checklist prohibits modifying directly.

## Issue Context
Preserve the immutable zlib snapshot override, but store the patch in a repository-approved location outside `third_party/` and update its Bazel label accordingly.

## Fix Focus Areas
- third_party/bazel/rules_rs_zlib_snapshot.patch[1-20]
- MODULE.bazel[44-53]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

View high (3)

4. ARM64 bootstrap URL unavailable ✗ Dismissed 🐞 Bug ≡ Correctness

Description

The aarch64 zlib bootstrap is redirected from Ubuntu’s ports archive to snapshot.ubuntu.com’s
/ubuntu tree, which does not serve ARM64 packages. Bazel initialization on Linux aarch64 will
therefore fail while downloading zlib.

Code

third_party/bazel/rules_rs_zlib_snapshot.patch[11]

++        url = "https://snapshot.ubuntu.com/ubuntu/20260801T000000Z/pool/main/z/zlib/zlib1g_1.3.dfsg-3.1ubuntu2.1_arm64.deb",

Evidence

The patched _LINUX_ZLIB aarch64 entry replaces an explicitly ports-hosted ARM64 package with the
/ubuntu snapshot tree, while the amd64 entry originates from the primary archive. Independent
build evidence documents that snapshot.ubuntu.com serves only the amd64/i386 /ubuntu tree and
lacks a usable Ubuntu ports snapshot, causing ARM64 fetch failures.

third_party/bazel/rules_rs_zlib_snapshot.patch[6-18]
🌐 Documents ARM64 builds failing because snapshot.ubuntu.com does not serve Ubuntu ports and its snapshot service only provides the amd64/i386 /ubuntu tree.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new snapshot URL uses snapshot.ubuntu.com’s `/ubuntu` archive for the ARM64 zlib package, but that service does not provide the Ubuntu ports archive. Native Linux aarch64 Bazel builds will fail to fetch the rules_rs bootstrap dependency.

## Issue Context
The original ARM64 package came from `ports.ubuntu.com/ubuntu-ports`, unlike the amd64 package from the primary Ubuntu archive. Replace it with an immutable source that actually retains the ARM64 package and preserve checksum verification.

## Fix Focus Areas
- third_party/bazel/rules_rs_zlib_snapshot.patch[9-11]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

5. No-op runs always fail ✗ Dismissed 🐞 Bug ☼ Reliability

Description

When update_cddl produces no changes, the reusable workflow deletes the empty patch and uploads no
artifact, but create-pr still runs and actions/download-artifact fails because cddl-updates
does not exist. Since unchanged pins are the expected common case, quiet daily runs will be reported
as workflow failures and trigger the Slack alert instead of completing successfully.

Code

.github/workflows/update-cddl.yml[R34-37]

+      - name: Download patch
+        uses: actions/download-artifact@v8
+        with:
+          pattern: cddl-updates

Evidence

The repository's reusable workflow removes changes.patch when the staged diff is empty and then
uses if-no-files-found: ignore, so the successful no-op update job has no cddl-updates artifact.
The download action's current implementation throws when filtering leaves zero artifacts, matching
the documented v4+ failure behavior for runs with no artifacts.

.github/workflows/bazel.yml[295-308]
.github/workflows/update-cddl.yml[20-46]
🌐 The action lists and filters artifacts and fails when no artifacts remain to download.
🌐 The maintainers' issue documents that v4+ exits with failure when a run has zero downloadable artifacts.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
No-op CDDL runs create no `changes.patch` artifact, yet the `create-pr` job always attempts to download it, causing expected quiet runs to fail.

## Issue Context
The reusable Bazel workflow removes an empty patch and configures upload-artifact to ignore a missing file. Expose whether a nonempty patch was produced and skip the PR job when false, or otherwise make the optional-artifact path complete successfully without masking genuine upload failures.

## Fix Focus Areas
- .github/workflows/update-cddl.yml[20-46]
- .github/workflows/bazel.yml[94-97]
- .github/workflows/bazel.yml[295-308]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

6. drop_commit docstring restates implementation ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

The added docstring merely narrates the substitution performed by the clearly named helper instead
of documenting rationale or a non-obvious constraint. This adds maintenance noise without explaining
why commit normalization is required.

Code

scripts/update_cddl.py[159]

+    """Content with the webref commit pin blanked, leaving only what gets downloaded."""

Evidence

Rule 6 prohibits comments that merely restate code. The added docstring at line 159 describes
exactly what the immediately following re.sub does and provides no rationale for the
normalization.

AGENTS.md: Comments Must Explain Why Rather Than Restate What Code Does
scripts/update_cddl.py[158-160]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `drop_commit` docstring restates the helper's implementation rather than explaining why commit normalization is necessary.

## Issue Context
Compliance rule 6 reserves comments for rationale, constraints, or non-obvious decisions. Remove the redundant docstring, or replace it with a concise explanation of why `_COMMIT` must be excluded when comparing pin content.

## Fix Focus Areas
- scripts/update_cddl.py[158-160]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

7. BiDi HTML updates are skipped ✗ Dismissed 🐞 Bug ≡ Correctness

Description

The no-op gate compares only webref CDDL/dfns content while preserving the existing BiDi HTML pin,
so it returns without checking for changes in the separately versioned webdriver-bidi rendered
specification. Consequently, changed or renamed BiDi prose anchors can leave the pinned HTML and
generated schema links stale indefinitely.

Code

scripts/update_cddl.py[R215-219]

+    # Probe with the pin already in the file so a gh-pages rebuild cannot open the gate.
+    webref_only = update_pin(old, commit, cddl_entries, dfns_entries, *current_bidi_pin(old))
+    if drop_commit(webref_only) == drop_commit(old):
+        print("No pinned spec content changed; leaving the pins at their current commits.")
+        return

Evidence

The gate builds its probe using the current BiDi commit and returns when only webref-derived content
is unchanged. The BiDi HTML is fetched from a separate repository and schema generation extracts its
prose anchors; the Rake task only regenerates when the BZL pin changes, so independent HTML updates
are skipped.

scripts/update_cddl.py[215-224]
common/webref_cddl.bzl[18-26]
Rakefile[78-85]
javascript/selenium-webdriver/BUILD.bazel[113-116]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The no-op gate returns before resolving the separately pinned WebDriver BiDi HTML whenever webref CDDL/dfns content is unchanged. Changes to BiDi prose anchors can therefore leave the checked-in HTML pin and generated schema links stale.

## Issue Context
The BiDi HTML comes from `w3c/webdriver-bidi` on `gh-pages`, independently of the webref CDDL commit. Schema generation extracts anchors from that HTML, so HTML changes can affect generated links without any CDDL hash change.

## Fix Focus Areas
- scripts/update_cddl.py[215-224]
- common/webref_cddl.bzl[18-26]
- Rakefile[78-85]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Context sources

Review mode: 🧠 Deep: This push contains substantial, independent logic across CI workflows, build/release tooling, Java runtime behavior, Python APIs, and CDDL automation, creating a high density of easy-to-miss defects.

Tip of the day

💡 Did you know, you can show, collapse, or hide each part of a finding: code, evidence, and all

More tips ↗ | Customize Qodo ↗ | Qodo docs ↗

Previous reviews

Review updated until commit 40c8bc0

Results up to commit fd52dfc ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. No-op runs always fail ✗ Dismissed 🐞 Bug ☼ Reliability

Description

When update_cddl produces no changes, the reusable workflow deletes the empty patch and uploads no
artifact, but create-pr still runs and actions/download-artifact fails because cddl-updates
does not exist. Since unchanged pins are the expected common case, quiet daily runs will be reported
as workflow failures and trigger the Slack alert instead of completing successfully.

Code

.github/workflows/update-cddl.yml[R34-37]

+      - name: Download patch
+        uses: actions/download-artifact@v8
+        with:
+          pattern: cddl-updates

Evidence

The repository's reusable workflow removes changes.patch when the staged diff is empty and then
uses if-no-files-found: ignore, so the successful no-op update job has no cddl-updates artifact.
The download action's current implementation throws when filtering leaves zero artifacts, matching
the documented v4+ failure behavior for runs with no artifacts.

.github/workflows/bazel.yml[295-308]
.github/workflows/update-cddl.yml[20-46]
🌐 The action lists and filters artifacts and fails when no artifacts remain to download.
🌐 The maintainers' issue documents that v4+ exits with failure when a run has zero downloadable artifacts.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
No-op CDDL runs create no `changes.patch` artifact, yet the `create-pr` job always attempts to download it, causing expected quiet runs to fail.

## Issue Context
The reusable Bazel workflow removes an empty patch and configures upload-artifact to ignore a missing file. Expose whether a nonempty patch was produced and skip the PR job when false, or otherwise make the optional-artifact path complete successfully without masking genuine upload failures.

## Fix Focus Areas
- .github/workflows/update-cddl.yml[20-46]
- .github/workflows/bazel.yml[94-97]
- .github/workflows/bazel.yml[295-308]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. drop_commit docstring restates implementation ✓ Resolved 📘 Rule violation ⚙ Maintainability

Description

The added docstring merely narrates the substitution performed by the clearly named helper instead
of documenting rationale or a non-obvious constraint. This adds maintenance noise without explaining
why commit normalization is required.

Code

scripts/update_cddl.py[159]

+    """Content with the webref commit pin blanked, leaving only what gets downloaded."""

Evidence

Rule 6 prohibits comments that merely restate code. The added docstring at line 159 describes
exactly what the immediately following re.sub does and provides no rationale for the
normalization.

AGENTS.md: Comments Must Explain Why Rather Than Restate What Code Does
scripts/update_cddl.py[158-160]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The `drop_commit` docstring restates the helper's implementation rather than explaining why commit normalization is necessary.

## Issue Context
Compliance rule 6 reserves comments for rationale, constraints, or non-obvious decisions. Remove the redundant docstring, or replace it with a concise explanation of why `_COMMIT` must be excluded when comparing pin content.

## Fix Focus Areas
- scripts/update_cddl.py[158-160]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Results up to commit f3baf24 🚀 Fast

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. BiDi HTML updates are skipped ✗ Dismissed 🐞 Bug ≡ Correctness

Description

The no-op gate compares only webref CDDL/dfns content while preserving the existing BiDi HTML pin,
so it returns without checking for changes in the separately versioned webdriver-bidi rendered
specification. Consequently, changed or renamed BiDi prose anchors can leave the pinned HTML and
generated schema links stale indefinitely.

Code

scripts/update_cddl.py[R215-219]

+    # Probe with the pin already in the file so a gh-pages rebuild cannot open the gate.
+    webref_only = update_pin(old, commit, cddl_entries, dfns_entries, *current_bidi_pin(old))
+    if drop_commit(webref_only) == drop_commit(old):
+        print("No pinned spec content changed; leaving the pins at their current commits.")
+        return

Evidence

The gate builds its probe using the current BiDi commit and returns when only webref-derived content
is unchanged. The BiDi HTML is fetched from a separate repository and schema generation extracts its
prose anchors; the Rake task only regenerates when the BZL pin changes, so independent HTML updates
are skipped.

scripts/update_cddl.py[215-224]
common/webref_cddl.bzl[18-26]
Rakefile[78-85]
javascript/selenium-webdriver/BUILD.bazel[113-116]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The no-op gate returns before resolving the separately pinned WebDriver BiDi HTML whenever webref CDDL/dfns content is unchanged. Changes to BiDi prose anchors can therefore leave the checked-in HTML pin and generated schema links stale.

## Issue Context
The BiDi HTML comes from `w3c/webdriver-bidi` on `gh-pages`, independently of the webref CDDL commit. Schema generation extracts anchors from that HTML, so HTML changes can affect generated links without any CDDL hash change.

## Fix Focus Areas
- scripts/update_cddl.py[215-224]
- common/webref_cddl.bzl[18-26]
- Rakefile[78-85]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

Results up to commit 2dd42cc ⚖️ Balanced

🐞 Bugs (0) 📘 Rule violations (0) 📎 Requirement gaps (0) 🎨 UX issues (0) 🔗 Cross-repo conflicts (0) 📜 Skill insights (0)

1. Patch added under third_party ✗ Dismissed 📘 Rule violation ⚙ Maintainability

Description

The PR directly adds third_party/bazel/rules_rs_zlib_snapshot.patch, which violates the explicit
prohibition on modifying files under third_party/. Relocate the patch to an approved
source-controlled patch directory and update the Bazel override reference.

Code

third_party/bazel/rules_rs_zlib_snapshot.patch[R1-3]

+diff --git a/rs/private/rustc_repository.bzl b/rs/private/rustc_repository.bzl
+--- a/rs/private/rustc_repository.bzl
++++ b/rs/private/rustc_repository.bzl

Evidence

PR Compliance ID 3 prohibits direct edits under third_party/. The cited newly added file is
located under third_party/bazel/ and contains the rules_rs dependency patch.

AGENTS.md: Do Not Modify Third-Party or Generated Output Directories
third_party/bazel/rules_rs_zlib_snapshot.patch[1-20]

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new rules_rs patch is stored under `third_party/`, which the compliance checklist prohibits modifying directly.

## Issue Context
Preserve the immutable zlib snapshot override, but store the patch in a repository-approved location outside `third_party/` and update its Bazel label accordingly.

## Fix Focus Areas
- third_party/bazel/rules_rs_zlib_snapshot.patch[1-20]
- MODULE.bazel[44-53]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

2. ARM64 bootstrap URL unavailable ✗ Dismissed 🐞 Bug ≡ Correctness

Description

The aarch64 zlib bootstrap is redirected from Ubuntu’s ports archive to snapshot.ubuntu.com’s
/ubuntu tree, which does not serve ARM64 packages. Bazel initialization on Linux aarch64 will
therefore fail while downloading zlib.

Code

third_party/bazel/rules_rs_zlib_snapshot.patch[11]

++        url = "https://snapshot.ubuntu.com/ubuntu/20260801T000000Z/pool/main/z/zlib/zlib1g_1.3.dfsg-3.1ubuntu2.1_arm64.deb",

Evidence

The patched _LINUX_ZLIB aarch64 entry replaces an explicitly ports-hosted ARM64 package with the
/ubuntu snapshot tree, while the amd64 entry originates from the primary archive. Independent
build evidence documents that snapshot.ubuntu.com serves only the amd64/i386 /ubuntu tree and
lacks a usable Ubuntu ports snapshot, causing ARM64 fetch failures.

third_party/bazel/rules_rs_zlib_snapshot.patch[6-18]
🌐 Documents ARM64 builds failing because snapshot.ubuntu.com does not serve Ubuntu ports and its snapshot service only provides the amd64/i386 /ubuntu tree.

Agent prompt

The issue below was found during a code review. Follow the provided context and guidance below and implement a solution

## Issue description
The new snapshot URL uses snapshot.ubuntu.com’s `/ubuntu` archive for the ARM64 zlib package, but that service does not provide the Ubuntu ports archive. Native Linux aarch64 Bazel builds will fail to fetch the rules_rs bootstrap dependency.

## Issue Context
The original ARM64 package came from `ports.ubuntu.com/ubuntu-ports`, unlike the amd64 package from the primary Ubuntu archive. Replace it with an immutable source that actually retains the ARM64 package and preserve checksum verification.

## Fix Focus Areas
- third_party/bazel/rules_rs_zlib_snapshot.patch[9-11]

ⓘ Copy this prompt and use it to remediate the issue with your preferred AI generation tools

---

[qodo-code-review]

Code review by qodo was updated up to the latest commit f3baf24

[qodo-code-review]

Code review by qodo was updated up to the latest commit 348b796

[qodo-code-review]

Code review by qodo was updated up to the latest commit 2dd42cc

[qodo-code-review]

Code review by qodo was updated up to the latest commit 40c8bc0