Admin Deployments Tab

Admin Deployments Tab

Table of the last 15 GitHub Actions runs across every workflow that deploys something users can see, surfaced in the admin panel under Deployments (/admin.html -> tab select -> Deployments). Filed as #367.

Why this exists

Post-CF Pages migration a single push can end up on any of four different deploy workflows, and the four deploy at different speeds, sometimes queued behind each other by the shared concurrency group. Answering "is my push live yet?" required cross-referencing gh run list, the Actions UI, the live version.json, and squinting at the SHA. Two recent bugs (a stale pipeline overwriting a fresh shell push; a timezone-normalization bug in the version guard skipping legitimate deploys) both hit specifically because there was no single view of what was happening.

This tab is that view. It reads directly from the public GitHub Actions API, cached 45s to stay under the unauthenticated 60/hr rate limit.

Where the code lives

Piece	Path
Tab component	js/admin/components/deployments.js
Wiring into TAB_LOADERS	js/admin/main.js
Permission gate	js/admin/permissions.js (deployments: ['view_analytics'])
Tab option + section	admin.html
CSP allow-list for api.github.com	admin.html connect-src
Tests	tests/deploymentsTab.test.js (9 cases)

What it shows

Whitelisted workflows (the only runs that appear -- everything else is filtered out client-side):

• Publish Shell to Cloudflare Pages -- shell push per branch
• Deploy Cloudflare Workers -- pp-edge-status
• Build Site Data -- the full pipeline (finalize deploys)
• Deploy Cloudflare Functions -- Supabase edge fns

Columns:

• When -- relative timestamp with the ISO on hover
• Status -- color-coded pill: success (green), failure (red), in progress / queued (blue), skipped / cancelled (grey)
• Workflow -- one of the four whitelisted names
• Branch -- staging or main
• SHA -- short SHA, linked to the commit on GitHub
• Target -- inferred per workflow:
  • Publish Shell + staging -> staging.proton-pulse.com
  • Publish Shell + main -> www.proton-pulse.com
  • Deploy Workers -> pp-edge-status worker
  • Build Site Data -> pipeline (<branch>) — ambiguous because the deploy step depends on dispatch inputs; click the run link for detail
• Link -- run -> opens the GH Actions run page

Controls:

• Refresh button -- bypasses cache and refetches.
• Auto-refresh (60s) checkbox -- default on, keeps the view current while the tab is open.

Caching + rate limits

Reads unauthenticated from https://api.github.com/repos/mdeguzis/proton-pulse-web/actions/runs?per_page=40 (public repo, no token needed). GitHub's unauthenticated rate limit is 60 requests/hour per IP.

To stay under it:

• Response cached 45s in sessionStorage under pp:admin:deployments.
• Auto-refresh at 60s means an idle tab burns ~60 requests/hour peak -- right at the ceiling. If two admins have the tab open in the same office at once, expect intermittent 429s. Manual Refresh clears the cache and forces a fresh fetch.

For higher throughput switch to an authenticated request with a fine-grained PAT scoped to Actions:Read. Not shipped in v1 because the extra secret rotation is not worth it for a diagnostic panel.

What the "Target" column cannot always tell you

Build Site Data can dispatch with any combination of staging_only, staging_with_pipeline, staging_with_finalize, deploy_target=ghpages|cloudflare, pages_only, etc. Those inputs are not exposed on the Actions runs API without a per-run detail fetch, which would blow the rate limit. So a Build Site Data row shows pipeline (staging) or pipeline (main) and expects the operator to click through to the run for detail.

For most operators this is fine -- the vast majority of confusion is "did the last Publish Shell run for my push succeed?", and that row is unambiguous.

When to look here vs elsewhere

Situation	Look at
"Did my push go live?"	Deployments tab, filter by SHA
"Is CI green?"	GH Actions UI (this tab hides non-deploy workflows on purpose)
"Did an error happen at runtime?"	Admin Logging tab
"What was the last data pipeline run?"	Deployments tab -- the Build Site Data row
"What secret / config is used by which workflow?"	Restore-Runbook

Follow-ups queued (not in v1)

• Auto-refresh cadence heuristic (backoff when no runs are in-flight, faster when one is)
• "Trigger re-deploy" per-row button (dispatches the same workflow again with same inputs)
• Cross-reference version.json on each target to show "currently live" per environment
• Authenticated fetch to escape the 60/hr limit

Related

• Admin Logging Tab -- companion for runtime bug tracing
• Web-Deploy-Workflow -- the workflows themselves