Repository navigation
[3417 by Claude Opus 5.5] Fix the hosted UI release deploy (app.propr.dev) added in #3409. Check current upstream main first. - #3418
Conversation
![propr-dev[bot]](https://github.githubassets.com/images/gravatars/gravatar-user-420.png){kind=avatar}
…s also a new workflow to re-deploy an already-published release from `main`. I reproduced the original failure on the v0.9.1 tag and confirmed the fix builds there. Nothing was merged, tagged, dispatched or deployed. Upstream `main` is still `dcd3bb97d`, the same commit this branch starts from, so there was nothing new to bring in. Proof against the v0.9.1 tag (a copy of the tag with a fresh `npm ci`): - `packages/shared/dist` doesn't exist after the install. - `npm run build -w propr-ui` on its own fails with the same error as the release run: `Failed to resolve entry for package "@propr/shared"`. - `npm run build -w @propr/shared && npm run build -w propr-ui` succeeds, and the built bundle contains `"0.9.1"`. - The UI only needs `@propr/shared` built. `@propr/client` is read straight from its source through the UI's build config. What changed - New `.github/workflows/hosted-ui-deploy.yml`: the deploy steps now live here. The release job calls it, and you can also run it by hand with a `release_tag` input. It: - refuses to run from any branch other than `main`. - requires a `v<semver>` tag that exists in the repo. - runs in `hosted-ui-production`, one deploy at a time. - checks out the tag and confirms the root `package.json` version matches it. - runs `npm ci`, builds shared then the UI, deploys with the pinned `wrangler@4.156.0`, and runs the verify script. Actions are pinned by SHA and permissions are read-only. The skip notice when Cloudflare credentials are missing is unchanged, and the failure summary now points to this workflow. - `docker-images.yml`: `deploy-hosted-ui` keeps its name, `if` and `needs`, and now just calls the new workflow with the release tag. No secrets are passed from the release workflow; the deploy job reads them from its own environment. Because the steps live in one file, the release path and the manual path can't drift. - `package.json`: `deploy:hosted-ui` now builds `@propr/shared` first. - Docs: `hosted-ui-release.md` has a new "Re-deploy a published release" section using `gh workflow run hosted-ui-deploy.yml --ref main -f release_tag=v0.9.1`. It also notes that tags up to v0.9.1 still have the old `deploy:hosted-ui` script, so a manual deploy of those needs `npm run build -w @propr/shared` first. - CHANGELOG: an entry under `## [Unreleased]` → `### Fixed`. Tests: I extended `test/hostedUiReleaseDeploy.test.mjs`. It checks that shared is built before the UI in both the workflow and the npm script, and that the release job uses the shared workflow. It runs the tag check against a stub `gh`, covering bad formats, a missing tag, dispatch from a non-`main` branch or a tag, and the call from the release workflow. It also covers the skip and recovery messages. All 15 tests pass. actionlint 1.7.12 with shellcheck reports nothing on both workflow files. The other workflow test files I ran (dedup, runner routing, Chromium install, release validation, change classification, full-suite selection, preview CLI, nightly contract) and the docs manifest test all pass. One thing I couldn't check offline: when the release workflow calls the deploy workflow, I'm relying on GitHub's documented behaviour that the called job reads secrets from its own `environment:`. If that turned out not to hold, the release job would show the "deploy skipped" notice rather than fail. Running the new workflow by hand would still deploy, because it reads the environment's secrets directly. To deploy app.propr.dev for v0.9.1 once this is merged, run the Hosted UI Deploy workflow from `main` with `release_tag=v0.9.1`. No preview images: nothing in this change is visible in the UI.
|
/review |
|
✅ AI Code Review Complete requested by @integry Posted 1 review: |
🔍 AI Code Review — codex:gpt-6-astraOverall EvaluationThe PR fixes the missing workspace build and provides a reusable recovery workflow. It needs a localized change before merge: the new manual path accepts existing tags without establishing that their releases were published. ✅ Correct build order — Both deployment paths now build ✅ Shared deployment implementation — Automatic releases and manual recovery reuse the same build, deployment, and verification steps. ✅ Focused regression coverage — Tests cover command ordering, dispatch restrictions, credential skipping, and recovery guidance. This review is based on static inspection; no commands were run. The supplied issue objective is truncated after item 2, so unseen requirements could not be assessed. The authoritative checks show no failures and 16 pending checks. Merge blockersEvery finding below was introduced by this PR and must be resolved before merging. F1: 🔴 Require a published release before deployment
SuggestionsThese are optional follow-ups and are not sent to S1: 🟢 Clarify old-tag manual recovery guidanceThe new failure summary recommends ScoreThe core build fix and reusable workflow are sound, with focused tests. The new manual path needs a publication check before it preserves the release deployment contract. Score: 6/10 🤖 Review Details
Copy and edit to choose records from this review: 🤖 Review by ProPR |
|
/fix |
|
✅ Applied the requested follow-up changes in commit 2022eb4
Summary of ChangesI fixed F1: the hosted UI deploy now refuses to run unless the requested tag has a published GitHub release that isn't a draft. What changed
Tests (
The tests also check that the release lookup is actually made. Verification
Other findings: nothing outside F1. No other step relies on the tag existing to mean it was published: the checkout and version check use the validated tag. The remaining gap is a race no workflow can close: a release could be deleted or set back to draft after this check passes and before the deploy. No screenshots were taken because the change is workflow-only. Gmail, Google Calendar and Google Drive need authorizing in your claude.ai connector settings before they can be used. This task didn't need them. 🤖 Implementation Details
Undo Changes • View Task Execution 💡 ProPR Slash Commands
🤖 Generated by ProPR |
…the requested tag has a published GitHub release that isn't a draft. I fixed F1: the hosted UI deploy now refuses to run unless the requested tag has a published GitHub release that isn't a draft. **What changed** - **Workflow** (`.github/workflows/hosted-ui-deploy.yml`, step `Validate release tag`): the tag-exists check is unchanged. After it, the step calls `gh api repos/$GITHUB_REPOSITORY/releases/tags/$RELEASE_TAG --jq '.draft'` and stops in two cases: - **No release found:** "has no published GitHub release". This covers a tag whose release run failed before `publish-github-release`. - **Draft is anything but `false`:** "is not published (draft: …)". That endpoint already leaves out draft releases; checking the flag as well costs nothing. - **Both entry points:** the check runs for a manual run from `main` and for the call from the release workflow. That call only happens after `publish-github-release` succeeds, so a normal release still passes. - **Docs** (`hosted-ui-release.md`, "Re-deploy a published release"): step 1 now says the workflow refuses a tag with no published release. **Tests** (`test/hostedUiReleaseDeploy.test.mjs`): the fake `gh` now has four tags: - `v0.9.1` and `v1.0.0-rc.1` have published releases and are still accepted. - `v0.9.2` exists but has no release, and is rejected whether run by hand or called from the release workflow. - `v0.9.3` has a draft release and is rejected. The tests also check that the release lookup is actually made. **Verification** - All 15 tests in that file pass. With the workflow from the last commit put back, the tag-validation test fails (14 pass, 1 fail), so the new cases do catch the gap. - The docs tests pass. - actionlint 1.7.12 reports nothing on `hosted-ui-deploy.yml` or `docker-images.yml`. shellcheck isn't installed in this container, so the shell checks inside actionlint did not run this time. **Other findings:** nothing outside F1. No other step relies on the tag existing to mean it was published: the checkout and version check use the validated tag. The remaining gap is a race no workflow can close: a release could be deleted or set back to draft after this check passes and before the deploy. No screenshots were taken because the change is workflow-only. Gmail, Google Calendar and Google Drive need authorizing in your claude.ai connector settings before they can be used. This task didn't need them. PR: #3418 Comment by: @integry (ID: 6557137869) Model: Claude Opus 5.5
|
/review |
|
✅ AI Code Review Complete requested by @integry Posted 1 review: |
🔍 AI Code Review — codex:gpt-6-astraOverall EvaluationThe PR fixes the missing shared-workspace build and provides a reusable deployment workflow for recovering already-published releases. It is merge-ready within the visible scope, conditional on the two pending checks completing successfully. ✅ Correct build order — Both deployment paths build ✅ Release-aware recovery — The new workflow validates the published release, checks out its tag, confirms its version, serializes production deployments, and verifies the served bundle. ✅ Focused regression coverage — Tests exercise validation failures, caller versus direct-dispatch behavior, missing credentials, and build ordering. This review used static analysis only; no commands were run. The original issue description is truncated, so requirements beyond its visible portion could not be assessed. The supplied current checks show no failures. Merge blockersNo merge blockers. SuggestionsThese are optional follow-ups and are not sent to S2: 🟢 Clarify legacy-tag recovery guidanceIn ScoreThe implementation addresses the demonstrated failure with consistent build steps and useful validation coverage. No merge-blocking regression was identified; live deployment was not independently verified, and two checks remain pending. Score: 9/10 🤖 Review Details
Copy and edit to choose records from this review: 🤖 Review by ProPR |
AI Implementation Summary
Closes #3417
Branch:
3417/claude-opus-5-5-fix-the-hosted-ui-release-20261101-1053-g99Commits: ✅ Changes committed (198a34e)
AI Processing Completed
Execution Details:
Summary:
The hosted UI deploy now builds
@propr/sharedbefore the UI. There's also a new workflow to re-deploy an already-published release frommain. I reproduced the original failure on the v0.9.1 tag and confirmed the fix builds there. Nothing was merged, tagged, dispatched or deployed.Upstream
mainis stilldcd3bb97d, the same commit this branch starts from, so there was nothing new to bring in.Proof against the v0.9.1 tag (a copy of the tag with a fresh
npm ci):packages/shared/distdoesn't exist after the install.npm run build -w propr-uion its own fails with the same error as the release run:Failed to resolve entry for package "@propr/shared".npm run build -w @propr/shared && npm run build -w propr-uisucceeds, and the built bundle contains"0.9.1".@propr/sharedbuilt.@propr/clientis read straight from its source through the UI's build config.What changed
New
.github/workflows/hosted-ui-deploy.yml: the deploy steps now live here. The release job calls it, and you can also run it by hand with arelease_taginput. It:main.v<semver>tag that exists in the repo.hosted-ui-production, one deploy at a time.package.jsonversion matches it.npm ci, builds shared then the UI, deploys with the pinnedwrangler@4.156.0, and runs the verify script.Actions are pinned by SHA and permissions are read-only. The skip notice when Cloudflare credentials are missing is unchanged, and the failure summary now points to this workflow.
docker-images.yml:deploy-hosted-uikeeps its name,ifandneeds, and now just calls the new workflow with the release tag. No secrets are passed from the release workflow; the deploy job reads them from its own environment. Because the steps live in one file, the release path and the manual path can't drift.package.json:deploy:hosted-uinow builds@propr/sharedfirst.Docs:
hosted-ui-release.mdhas a new "Re-deploy a published release" section usinggh workflow run hosted-ui-deploy.yml --ref main -f release_tag=v0.9.1. It also notes that tags up to v0.9.1 still have the olddeploy:hosted-uiscript, so a manual deploy of those needsnpm run build -w @propr/sharedfirst.CHANGELOG: an entry under
## [Unreleased]→### Fixed.Tests: I extended
test/hostedUiReleaseDeploy.test.mjs. It checks that shared is built before the UI in both the workflow and the npm script, and that the release job uses the shared workflow. It runs the tag check against a stubgh, covering bad formats, a missing tag, dispatch from a non-mainbranch or a tag, and the call from the release workflow. It also covers the skip and recovery messages. All 15 tests pass. actionlint 1.7.12 with shellcheck reports nothing on both workflow files. The other workflow test files I ran (dedup, runner routing, Chromium install, release validation, change classification, full-suite selection, preview CLI, nightly contract) and the docs manifest test all pass.One thing I couldn't check offline: when the release workflow calls the deploy workflow, I'm relying on GitHub's documented behaviour that the called job reads secrets from its own
environment:. If that turned out not to hold, the release job would show the "deploy skipped" notice rather than fail. Running the new workflow by hand would still deploy, because it reads the environment's secrets directly.To deploy app.propr.dev for v0.9.1 once this is merged, run the Hosted UI Deploy workflow from
mainwithrelease_tag=v0.9.1.No preview images: nothing in this change is visible in the UI.
Detailed Logs:
616eb80f-07c7-4f75-9cf8-1a3f78d74727Log files stored at:
/usr/src/app/logs/executions/issue-3417-2026-11-01T11-01-20-524Z-conversation.json/usr/src/app/logs/executions/issue-3417-2026-11-01T11-01-20-524Z-output.txtLatest Conversation Messages
This PR was created automatically by ProPR after processing issue #3417.
💡 Need changes?
Comment on this PR to request refinements — the AI agent monitors comments and will update the implementation based on your feedback. Keep iterating until you're satisfied!