[hwantage]

Summary

If GitHub ever skips the CI run for a merge on main, a maintainer can now press CI → Run workflow on main (or run gh workflow run ci.yml --ref main), and when that run passes the web editor and the website deploy as usual. No empty-commit PR is needed anymore.

What Changed

• ci.yml: add workflow_dispatch.
• deploy-web-editor.yml, deploy-website.yml: the gate now judges the latest CI run for the workflow revision on main whose event is push or workflow_dispatch. It still requires the same commit, branch main and a successful latest run; pull request runs never count. The event is filtered in jq because the runs API accepts a single event. Because a revision can now have several runs and a re-run keeps its created_at, the gates pick the attempt started last (run_started_at, falling back to created_at).
• Tests: the gate tests cover which events count, that the latest push or hand-started run decides, and that a re-run of an older run decides once it starts last; the policy test pins the new CI triggers.
• Docs: the recovery step in docs/CLOUD-SHARE.md, website/README.md and docs/RELEASE.md, which also notes that the release gate still requires a push run.

Why

For #248 (merge commit dea1d96) GitHub created no push run of CI, so production kept the old bundle (#249). ci.yml had no manual trigger, both deploy gates accepted only push runs (so Web editor → Run workflow skipped the deploy), and the main ruleset only takes pull requests, so the only recovery was the empty-commit PR #250.

Rejected alternatives:

• A local wrangler pages deploy script would need the Cloudflare token on a workstation and could publish code that never passed CI.
• A scheduled job that detects and reruns missing CI was judged more than this rare failure needs.

release.yml is unchanged: a tag still needs a CI run from a push to main.

Linked Issue

Fixes #251

Visual Proof

No visual change: only GitHub Actions workflows, their tests and documentation change.

Testing

Run on macOS in this worktree. A fresh-context adversarial review found the re-run ordering issue above, which is fixed in this PR; it also noted that docs/RELEASE.md gives no way to release a merge commit that has no push CI run, which stays out of scope (#251).

• pnpm check — exit 0.
• node --test config/scripts/workflow-hardening.test.mjs config/scripts/workflow-policy.test.mjs — 42 passed, 0 failed.
• With only deploy-web-editor.yml restored to main, the new and updated gate tests fail (3 tests); with only its ordering reverted to created_at, the re-run cases fail (1 test). So the tests exercise both parts of the change.
• bash config/scripts/check-actionlint.sh — exit 0.

Not verifiable before merge: a real CI → Run workflow on main triggering the Web editor and Website deployments. After merge, the push CI of the merge commit should deploy as before.

Desktop check: none — no app or desktop code changes.

Platform Notes

N/A

Checklist

• pnpm check
• Affected unit/spec files (list exact commands in Testing)
• pnpm rust:fmt:check && pnpm rust:clippy && pnpm rust:test — src-tauri/ unchanged
• pnpm test:site — website/ code unchanged (README only)
• pnpm bundle:local — bundling unchanged
• Affected documentation and links are updated; new permanent docs have a stated purpose

Summary by CodeRabbit

• Workflow Improvements

  • CI can now be started manually. Successful CI runs started by a push or manually can qualify the matching revision for website and web-editor deployment.
  • Deployment checks account for the latest run attempt and proceed only after it succeeds.

• Documentation

  • Updated deployment and release guidance with instructions for manually running CI and retrying deployments.

[coderabbitai]

Navigate logical layers of code changes, visualize relationships, and explore their blast radius.

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Repository: hwantage/CanvaSlide/.coderabbit.yaml

Review profile: CHILL

Plan: Advanced

Run ID: 8171aa06-e711-47c4-a293-5e543495ed11

📥 Commits

Reviewing files that changed from the base of the PR and between f0f8f7b and dd82ed0.

📒 Files selected for processing (8)

• .github/workflows/ci.yml
• .github/workflows/deploy-web-editor.yml
• .github/workflows/deploy-website.yml
• config/scripts/workflow-hardening.test.mjs
• config/scripts/workflow-policy.test.mjs
• docs/CLOUD-SHARE.md
• docs/RELEASE.md
• website/README.md

Included review availability: This review used your included allowance. Your plan provides up to 10 included reviews per hour; 9 remain after this review.

---

📝 Walkthrough

Walkthrough

The CI workflow can now run manually. Both deployment gates consider eligible push and manual CI runs and select the latest attempt. Deployment instructions describe how to recover when a merge on main starts no CI run.

Changes

Manual CI deployment recovery

Layer / File(s)	Summary
Enable manual CI runs .github/workflows/ci.yml, config/scripts/workflow-policy.test.mjs	The CI workflow adds workflow_dispatch. The policy test checks that the event is enabled.
Select eligible CI attempts .github/workflows/deploy-web-editor.yml, .github/workflows/deploy-website.yml, config/scripts/workflow-hardening.test.mjs	Both deployment gates consider push and workflow_dispatch runs. They select the latest attempt by start time, with creation time and run ID as tie-breakers. Tests cover event filtering, reruns, and result ordering.
Document deployment recovery docs/CLOUD-SHARE.md, docs/RELEASE.md, website/README.md	The deployment instructions describe manually running CI on main when a merge has no CI run. Release-tag verification still requires CI triggered by a push.

Priority: ➖ Normal

Estimated code review effort: 3 (Moderate) | ~20 minutes

Change: Bug fix · Severity of issue fixed: Medium

Sequence Diagram(s)

sequenceDiagram
  participant Operator
  participant CI
  participant GitHub Actions
  participant Deployment workflows
  participant GitHub API
  Operator->>CI: Manually run CI on main
  CI->>GitHub Actions: Complete CI run
  GitHub Actions->>Deployment workflows: Trigger workflow_run
  Deployment workflows->>GitHub API: Query CI runs for workflow revision
  GitHub API-->>Deployment workflows: Return push and workflow_dispatch runs
  Deployment workflows->>Deployment workflows: Select latest attempt and check success

Loading

Merge Risk: ⚪ Minimal · up to dd82e

This change lets maintainers recover deployments by manually running CI on main when a merge had no push run. Tests and docs were updated, and the release gate is unchanged. No concrete merge-blocking risk was identified.

Security Architecture Review

Security architecture risk: 🔵 Low · up to dd82e

Manual CI recovery adds a route to production deployment, but deployments still require successful CI for the matching revision on main. Who may start manual runs and whether deployment environments require approval should be confirmed.

Retained concerns
No architecture-level concerns identified.

Security review details

Security Blast Radius

• inferred — The newly eligible manual CI result can affect two production publication paths: the website and the hosted web editor. The inspected release gate is outside that expansion.

Security Findings and Attack Paths

• observed — The inspected manual trigger takes no revision input, and neither deployment gate accepts a run unless its event, branch, head SHA, and completed-success state satisfy the gate. This bounds the new route to the workflow revision on main; it does not establish who is authorized to start it.

Trust Boundaries and Controls

• observed — GitHub run metadata crosses into deployment eligibility, while publication authority remains in downstream jobs. The inspected workflows do not specify repository-level manual-dispatch permissions or environment approval rules.

Resilience and Maintainability Implications

• inferred — A newer CI attempt beginning after a gate query will not be considered by that already-running deployment. Because the prior gate also queried once before publication, the inspected diff does not establish this as a newly introduced failure mode.

Hardening Proposals

• proposed — Confirm that repository dispatch permissions and deployment-environment protections give only intended operators the ability to initiate this recovery path and approve its publication.

🚥 Pre-merge checks | ✅ 4

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and concisely describes the main change: enabling manual CI runs on main to recover missed push runs and allow deployment.
Description check	✅ Passed	The description includes all required sections, explains the change and rationale, identifies the linked issue, states that there is no visual change, documents testing and limitations, and records ch…
Linked Issues check	✅ Passed	The PR meets the coding requirements in [#251]. .github/workflows/ci.yml adds workflow_dispatch while retaining the existing push and pull_request triggers. Both deployment gates query the sam…
Out of Scope Changes check	✅ Passed	The changes stay within [#251]. The workflow comments, gate tests, policy test, and updates to docs/CLOUD-SHARE.md, website/README.md, and docs/RELEASE.md support the manual CI recovery behavior…

✨ Finishing Touches

📝 Generate docstrings

• Commit to this branch
• Create a new PR

🧪 Generate unit tests (beta)

• Commit to this branch
• Create a new PR

---

_{Comment @coderabbitai help to get the list of available commands.}

[cloudflare-workers-and-pages]

Deploying canvaslide with    Cloudflare Pages

Latest commit:	dd82ed0
Status:	✅  Deploy successful!
Preview URL:	https://54cd6b92.canvaslide.pages.dev
Branch Preview URL:	https://chore-ci-dispatch-redeploy.canvaslide.pages.dev

View logs