SemianiakaVY/elsa-core
1
0
Fork 0
Code Issues Pull requests Actions 1 Packages Projects Releases Wiki Activity

Document template browser release checks (#8023)

Browse source
This commit is contained in:
Sipke Schoorstra 2026-09-05 08:58:18 -07:00 committed by GitHub
parent aeb982dcef
commit 0b1186ee07
No known key found for this signature in database
GPG key ID: B5690EEEBB952194
1 changed files with 4 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

4
.agents/skills/elsa-release/references/runbook.md
View file

@ -78,6 +78,10 @@ For Templates, the required generated matrix covers at least:
Run the matrix from an isolated temporary directory after installing the exact published package (`dotnet new install Elsa.Templates::<version> --nuget-source <verified-feed>` or the equivalent local package source). Do not substitute an unversioned or preview template package. For browser-hosted variants, a server `200` or successful compilation is insufficient: load the actual route in a browser, check framework/ICU/static asset requests for failures, and complete the sign-in route with a configured test identity. Capture the selected template parameters, generated project package references, build/startup result, browser/WASM asset result, authentication result, and package URL in the release record. A package's successful NuGet verification does not replace these generated-project checks.
For generated-project validation on macOS, resolve both the output directory and build working directory to their canonical filesystem paths before building (for example, `/private/tmp` rather than its `/tmp` symlink). A build through a symlink can emit incorrect Razor page identifiers, so regenerate and rebuild from a canonical path before diagnosing a missing fallback page. Do not carry routing workarounds from an old generated directory into release source without reproducing the failure from the current package.
Check each selectable hosting mode explicitly. Verify the root and login routes repeatedly, confirm the selected Server or WebAssembly boot script loads, and complete browser sign-in followed by an authenticated workflow API request. A prerendered sign-in form, an HTTP 200, or a successful direct API login does not prove that the browser is interactive. Give hybrid host pages distinct non-root routes so the configured fallback selects the correct mode. For .NET 10 hosts whose components come entirely from packages, verify that framework scripts are included; [Microsoft documents `RequiresAspNetWebAssets`](https://learn.microsoft.com/en-us/aspnet/core/blazor/project-structure?view=aspnetcore-10.0#location-of-the-blazor-script) for hosts without a local `.razor` component. Restore after changing this property because the SDK resolves the framework asset pack during restore. When using a different test port, adapt the generated browser client's backend configuration as well as the server settings, and record the override in the evidence.
Review and commit only intended changes. Integrate into the intended release branch according to actual branch protection: ordinary fast-forward where permitted, otherwise PR plus required checks/review and authorized merge. The explicit full-release instruction includes routine dependency/version integration. It does not authorize bypassing branch protection, unrelated fixes, or changing existing release tags. Wait for branch CI build/test/pack success before tagging. An independent preview feed upload need not delay a stable tag once that validation passed.
## 4. Freeze notes, package inventory, and source