Repository navigation
Publish the status dashboard on staging only; point public status at status.internetcomputer.org - #194
Merged
Conversation
…status.internetcomputer.org The public status surface for ICP MCP is the "ICP MCP" component on status.internetcomputer.org, driven by the deployment's status dashboard (monitoring/mcp-status) through its Statuspage pusher. The dashboard itself is not meant to be reachable on the production origin: its edge already answers /status/ with a redirect, and the Caddyfile block that published it there was dead weight that would come back on the next rollout. Gate that block on SERVE_STATUS, passed by deploy-native.yml for the staging environment only, exactly as MCP_SERVE_BETA already is. deploy.sh renders the Caddyfile keeping the block (minus its marker lines) on staging and deleting it on production. The imcp-status service is still installed and started on every host: the Statuspage pusher runs inside it, and the repository cannot tell which host holds /etc/imcp-status/statuspage.env, so removing the service anywhere risks silencing the public component. Re-point the two remaining public references to the retired origin URL: the health workflow's Slack alert link and the Anthropic submission doc's status/health row, which had flagged the origin's /status/ as cut off. Verified: bash -n on deploy.sh; the Caddyfile rendered both ways with the exact sed pipeline (staging keeps redir + handle_path /status/* with no marker lines left, production has neither and no marker lines, the comment block is intact in both); both workflow files parse as YAML. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw
There was a problem hiding this comment.
Copilot review overview
🟡 Changes recommended
Several authoritative deployment references still incorrectly state that every host publishes the dashboard.
Get a fresh assessment by requesting another Copilot review.
Review effort: Balanced
Findings: 1
Open (1)
What changed in this PR
Restricts the native status dashboard to staging while directing users to the public ICP Statuspage.
Changes:
- Conditionally renders the Caddy
/status/route viaSERVE_STATUS. - Enables dashboard exposure only in staging deployments.
- Updates documentation and public status links.
| File | Description |
|---|---|
.github/workflows/deploy-native.yml |
Enables SERVE_STATUS for staging. |
.github/workflows/health.yml |
Updates the Slack status link. |
deploy/native/Caddyfile |
Marks the staging-only status route. |
deploy/native/deploy.sh |
Conditionally renders that route. |
deploy/native/README.md |
Documents status publication behavior. |
docs/anthropic-directory-submission.md |
References the public Statuspage component. |
💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.
…found stale The parent change made the dashboard's /status/ exposure staging-only but left three authoritative statements saying every host publishes it: the monitoring README's deploy paragraph, the imcp-status unit's header comment, and the LANDING_SITE doc comment in main.rs, which said /status/ was "published by the fronting proxy" as if that held on production. Each now says the same thing as the Caddyfile and deploy README: staging publishes the dashboard at /status/ (SERVE_STATUS); production runs the unit too, because its Statuspage pusher feeds status.internetcomputer.org, but does not publish the dashboard at its origin. A tree sweep found no other stale statement: the remaining /status/ mentions are the robots.txt Disallow, a test's list of machine paths, and factual notes about production's edge answering /status/ with a redirect, all of which stay true. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw
Collaborator
Author
|
CI note: the The job died at its Install dist step, before There is no fix to port — the failure is upstream of the repository. I've re-run the failed job once. If the download 500s again, that's GitHub's release CDN and I'll keep the PR watched until it recovers rather than retry further. Generated by Claude Code |
sea-snake
approved these changes
Sep 22, 2026
aterga
pushed a commit
that referenced
this pull request
Sep 22, 2026
The staging deploy for #194's merge (Deploy main run 35719911932) failed in build.sh's Docker stage at apt-get install, before any compilation: thirteen packages apt chose from bullseye-security -- perl, libcurl4, libexpat1, libicu67, libxml2, dpkg-dev and friends -- answered 404 from the pool. The suite's index still advertises those versions (perl 5.32.1-4+deb11u5), but bullseye left LTS on 2026-08-31 and its security pool has since been pruned underneath the index, so every apt-get that consults it fails the same way. It is not this change's doing: the same stage passed on 2026-09-03 and the merge touched no Dockerfile, Cargo or apt input. Staying on bullseye is deliberate and documented (glibc 2.31 so the binary runs on Amazon Linux 2023's 2.34; bookworm's 2.36 would not), so the fix is to stop consulting the dead suite: the stage now writes a sources.list with the bullseye main suite alone before apt-get update. main is intact and carries every package this stage installs (verified against its current arm64 index and pool: perl 5.32.1-4+deb11u3, libcurl4 7.74.0-1.3+deb11u13, cmake 3.18.4-2+deb11u1, clang 1:11.0-51+nmu5, ...). The comment records the next step for when deb.debian.org drops bullseye entirely: archive.debian.org already mirrors the main suite. The Docker daemon is not available where this was prepared, so the stage was not rebuilt locally; the next push to main exercises it end to end in the staging deploy, which is exactly the run that failed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw
6 of 10 tasks
Collaborator
Author
|
Post-merge note: the staging deploy this merge triggered (Deploy main run 35719911932) failed — but not because of anything in this PR.
Fix is in #195: keep the deliberate bullseye base (glibc 2.31 for AL2023) but resolve apt from the intact Generated by Claude Code |
aterga
added a commit
that referenced
this pull request
Sep 22, 2026
…#195) * Cross-build from bullseye main only: the -security pool is gone The staging deploy for #194's merge (Deploy main run 35719911932) failed in build.sh's Docker stage at apt-get install, before any compilation: thirteen packages apt chose from bullseye-security -- perl, libcurl4, libexpat1, libicu67, libxml2, dpkg-dev and friends -- answered 404 from the pool. The suite's index still advertises those versions (perl 5.32.1-4+deb11u5), but bullseye left LTS on 2026-08-31 and its security pool has since been pruned underneath the index, so every apt-get that consults it fails the same way. It is not this change's doing: the same stage passed on 2026-09-03 and the merge touched no Dockerfile, Cargo or apt input. Staying on bullseye is deliberate and documented (glibc 2.31 so the binary runs on Amazon Linux 2023's 2.34; bookworm's 2.36 would not), so the fix is to stop consulting the dead suite: the stage now writes a sources.list with the bullseye main suite alone before apt-get update. main is intact and carries every package this stage installs (verified against its current arm64 index and pool: perl 5.32.1-4+deb11u3, libcurl4 7.74.0-1.3+deb11u13, cmake 3.18.4-2+deb11u1, clang 1:11.0-51+nmu5, ...). The comment records the next step for when deb.debian.org drops bullseye entirely: archive.debian.org already mirrors the main suite. The Docker daemon is not available where this was prepared, so the stage was not rebuilt locally; the next push to main exercises it end to end in the staging deploy, which is exactly the run that failed. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw * Install the cross-build's packages from a bullseye snapshot, not main alone Copilot's review of the previous commit was right: restricting apt to bullseye main is unsatisfiable against this image. rust:1-slim-bullseye (built 2026-08-25) has its base packages at the final security versions -- perl-base 5.32.1-4+deb11u5, libc6 2.31-13+deb11u14, dpkg 1.20.14 and 25 more -- while main carries perl 5.32.1-4+deb11u3, which depends on perl-base (= 5.32.1-4+deb11u3), and libc6-dev 2.31-13+deb11u11, which depends on libc6 (= 2.31-13+deb11u11). apt will not downgrade the installed perl-base or libc6 to satisfy those, so the install fails. Verified by reading /var/lib/dpkg/status out of the image's base layer from the registry and comparing it with main's arm64 index. Install from snapshot.debian.org at 2026-08-30 instead, for both suites: the last state in which bullseye and bullseye-security were complete, after the image was built. Its security index carries exactly the versions the image has (perl-base +deb11u5, libc6 and libc6-dev +deb11u14, dpkg and dpkg-dev 1.20.14) and all thirteen packages that 404 on deb.debian.org (perl, libcurl4 7.74.0-1.3+deb11u16, libexpat1, libicu67, libxml2, libglib2.0-0, ...), and its pool serves them. Both suites are frozen, so the pin is the permanent final state, reproducible, with nothing to downgrade. check-valid-until=no because the snapshot's Release files expired on 2026-09-05; Acquire::Retries=3 for snapshot's throttling. Still not rebuilt locally (no Docker daemon here); the staging deploy on merge remains the end-to-end proof. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw * Narrow the reproducibility claim in build.sh's apt comment The previous commit's comment said the snapshot made "the build reproducible". It does not: rust:1-slim-bullseye is a mutable tag and BUILD_TIME is stamped at build time, so the binary and its metadata still vary from build to build. What the dated snapshot fixes is apt's inputs, so the comment now says that package resolution is reproducible and names the two things that are not. Review nit from Copilot on 829622b. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw * Fetch the bullseye snapshots over https With check-valid-until=no, apt no longer rejects an index past its Valid-Until, so its remaining defence against a network attacker replaying an older, still validly signed snapshot index -- and thereby an older package set than the timestamp names -- is the transport. Fetch both snapshot lines over https so the dated path is authenticated in transit. The rust:1-slim-bullseye image installs ca-certificates in its own layer (alongside gcc, libc6-dev and wget), so https works before this stage installs anything; snapshot.debian.org serves https end to end, redirecting to same-origin content-hash paths. Review finding from Copilot on 69506cb. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw --------- Co-authored-by: Claude <noreply@anthropic.com>
This was referenced Sep 22, 2026
aterga
pushed a commit
that referenced
this pull request
Sep 22, 2026
Resolves the conflict in deploy/native/deploy.sh between this branch's OAUTH_CIMD_ENABLED substitution on the unit_mcp line and #194's SERVE_STATUS block around the caddyfile line: both are kept, the CIMD comment and substitution first, then the status block as main has it. The other files main touched (#172, #194, #195) merged cleanly. Co-Authored-By: Claude Fable 5.1 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Xd7VT72Qt16qiAJynu9EKj
9 tasks done
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
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.
Summary
The public status surface for ICP MCP is the ICP MCP component on https://status.internetcomputer.org/, driven by the deployment's status dashboard (
monitoring/mcp-status) through its Statuspage pusher. The dashboard itself is not meant to be reachable on the production origin: its edge already answers/status/with a redirect, and the Caddyfile block that published it there was dead weight that would come back on the next rollout.This gates that block on
SERVE_STATUS, passed bydeploy-native.ymlfor the staging environment only — the same mechanismMCP_SERVE_BETAalready uses.deploy.shrenders the Caddyfile keeping the block (minus its marker lines) on staging and deleting it on production.Deliberately unchanged:
imcp-status.serviceis still installed and started on every host. The Statuspage pusher runs inside it, and the repository cannot tell which host holds/etc/imcp-status/statuspage.env, so removing the service anywhere risks silencing the public component. Only the dashboard's exposure at/status/becomes staging-only. Once the operators confirm which host carries the credentials, the other host's dashboard instance can be pruned as a follow-up.Also re-points the two remaining public references to the retired origin URL: the health workflow's Slack alert link, and the Anthropic submission doc's status/health row (which had flagged the origin's
/status/as cut off — it now cites the Statuspage as the one public surface).Related issues
Companion to dfinity/internetcomputer-org's removal of the copied dashboard under
/icp-mcp/status/. Follows #165 (landing pages moved to internetcomputer.org/icp-mcp) and #188 (dashboard stopped grading/version).Changes
deploy/native/Caddyfile: the/statusredir +handle_path /status/*block is wrapped in__STATUS_BEGIN__/__STATUS_END__marker comments; comment explains the staging-only exposure.deploy/native/deploy.sh: renders the Caddyfile keeping the marked block (markers stripped) whenSERVE_STATUSis set, deleting the whole block otherwise..github/workflows/deploy-native.yml: passesSERVE_STATUS: ${{ inputs.environment == 'staging' && '1' || '' }}alongsideMCP_SERVE_BETA.deploy/native/README.md: documents the staging-only publication and the public Statuspage in the three places that described/status/..github/workflows/health.yml: Slack alert "Status page" link →https://status.internetcomputer.org/.docs/anthropic-directory-submission.md: status/health row → the Statuspage component; drops the "cut off" warning.Testing
bash -n deploy/native/deploy.shsedpipeline fromdeploy.sh: staging keepsredir /status+handle_path /status/*with no marker lines left; production has neither directive and no marker lines; the comment block is intact in both (17 source comment lines → 15 rendered, exactly the two markers).github/scripts/scan-internal-identifiers.sh origin/main...HEAD— cleancargo build --locked --all-targets— n/a, no Rust changedcargo test --locked --all-targets— n/a, no Rust changedcargo fmt --all/cargo clippy --all-targets— n/a, no Rust changednpm test --prefix monitoring/mcp-status— n/a, dashboard code unchangedChecklist
🤖 Generated with Claude Code
https://claude.ai/code/session_01TGhwpdTbUqQbR5AiiN8Ljw
Generated by Claude Code