Replace monolithic docs workflow with staged deployment system#362
Replace monolithic docs workflow with staged deployment system#362mattleibow merged 14 commits intomainfrom
Conversation
- Add docs-deploy-main.yml: builds docs+Blazor on push to main and pushes to gh-pages root (preserving staging/)
- Add docs-deploy-staging-pr.yml: builds with staging base-href, deploys to staging/{pr}/, comments on PR
- Add docs-cleanup-staging-pr.yml: removes staging/{pr}/ when PR is closed
- Add docs-go-live.yml: deploys gh-pages branch to GitHub Pages via Actions
- Remove old builds-docs.yml (single-workflow monolith with peaceiris/actions-gh-pages)
Co-authored-by: mattleibow <1096616+mattleibow@users.noreply.github.com>
|
@copilot can you see if you can create a local composite action that runs the build so we don't need to duplicate the steps in the main vs staging. Or maybe see if there is a way to merge the deploy workflow and use different params/vars depending. Please try the merge first as that is the preferred way |
….yml
- Replace docs-deploy-main.yml and docs-deploy-staging-pr.yml with a
unified docs-deploy.yml that handles both push-to-main and PR triggers
- A setup step computes artifact name, base href, and segmentCount based
on github.event_name (push vs pull_request)
- Build job exposes outputs; deploy job uses conditional steps to either
update gh-pages root (main) or staging/{pr}/ (PR)
- comment job runs only for staging on PR open/reopen
- Update docs-go-live.yml workflow_run list to reference new name
Co-authored-by: mattleibow <1096616+mattleibow@users.noreply.github.com>
Done in 7bdb9e1. Merged A |
|
@copilot can we use the Ubuntu-latest for the docs. Then also switch to use the Maui-android workload. |
- Change build runner from windows-latest to ubuntu-latest - Change workload from maui to maui-android - Rewrite PowerShell copy/sed step as bash Co-authored-by: mattleibow <1096616+mattleibow@users.noreply.github.com>
|
📖 Documentation Preview The documentation for this PR has been deployed and is available at: This preview will be updated automatically when you push new commits to this PR. This comment is automatically updated by the documentation staging workflow. |
|
@copilot please review the workflow changes and let me know what issues there are. Also, please visit the staging links to make sure it all works. |
Add job-level if to deploy job so it only runs for same-repo PRs and push/workflow_dispatch events. For fork PRs the GITHUB_TOKEN is read-only so git push to gh-pages would fail. comment job is naturally skipped when deploy is skipped (via needs). Co-authored-by: mattleibow <1096616+mattleibow@users.noreply.github.com>
Review complete. One issue found and fixed (ea0c18f): Fixed — Fork PR deploy would fail: The Not fixed — pre-existing: Staging links: The Warning Firewall rules blocked me from connecting to one or more addresses (expand for details)I tried to connect to the following addresses, but was blocked by firewall rules:
If you need me to access, download, or install something from one of these locations, you can either:
|
|
@copilot there are now yaml errors: Invalid workflow file: .github/workflows/docs-deploy-fork-pr.yml#L135 Did you validate? |
| - name: Setup build variables | ||
| id: vars | ||
| env: | ||
| EVENT_NAME: ${{ github.event_name }} | ||
| PR_NUMBER: ${{ github.event.number }} | ||
| shell: bash | ||
| run: | | ||
| if [ "$EVENT_NAME" == "pull_request" ]; then | ||
| echo "artifact_name=staging-site-${PR_NUMBER}" >> $GITHUB_OUTPUT | ||
| echo "sample_base_href=/SkiaSharp.Extended/staging/${PR_NUMBER}/sample/" >> $GITHUB_OUTPUT | ||
| echo "sample_segment_count=4" >> $GITHUB_OUTPUT | ||
| echo "is_staging=true" >> $GITHUB_OUTPUT | ||
| echo "pr_number=${PR_NUMBER}" >> $GITHUB_OUTPUT | ||
| else | ||
| echo "artifact_name=main-site" >> $GITHUB_OUTPUT | ||
| echo "sample_base_href=/SkiaSharp.Extended/sample/" >> $GITHUB_OUTPUT | ||
| echo "sample_segment_count=2" >> $GITHUB_OUTPUT | ||
| echo "is_staging=false" >> $GITHUB_OUTPUT | ||
| echo "pr_number=" >> $GITHUB_OUTPUT | ||
| fi |
There was a problem hiding this comment.
The PR_NUMBER should be validated before use to prevent creating malformed artifact names. If github.event.number is empty or not a valid positive integer, the artifact name "staging-site-${PR_NUMBER}" could become "staging-site-" or contain invalid characters. Add validation similar to what's done in other workflows (e.g., lines 151-155) to ensure PR_NUMBER is a positive integer before using it to construct the artifact name and paths.
Removing the indentation from template literal content in the previous commit caused YAML parse errors: lines at column 0 inside a block scalar (script: |) terminate the scalar prematurely. Rewrote both comment bodies as string arrays joined with \n. This sidesteps the YAML indentation constraint entirely while producing identical output. Validated all 4 workflow files parse as valid YAML. Co-authored-by: mattleibow <1096616+mattleibow@users.noreply.github.com>
Fixed in 3c6ac9a. The root cause: removing the indentation from the template literal content left those lines at column 0, which YAML interprets as terminating the block scalar ( Replaced both comment bodies with |
|
/azp run |
|
@copilot can we add a PR number and commit message to the docs page and sample app. For main builds, just use "main" and for PR use "PR #2468" as the "source branch" and then a commit has. Maybe something like "source" (dot) "commit" in the footer or something. |
…alidate PR_NUMBER early
- docs-deploy.yml: validate PR_NUMBER as positive integer at start of
pull_request branch in Setup build variables (before constructing
artifact names and paths)
- docs-deploy.yml: emit source_label output ("main" or "PR #N")
- docs-deploy.yml: Build docs step uses jq to inject _appFooter into a
temp docfx-build.json; runs docfx on the patched config. Footer shows
"source: main · abc1234" or "source: PR #362 · abc1234"
- docs-deploy.yml: Copy Blazor sample step replaces BUILD_INFO_PLACEHOLDER
in index.html with "main · abc1234" or "PR #362 · abc1234"
- samples/SkiaSharpDemo.Blazor/wwwroot/index.html: add #build-info div
with BUILD_INFO_PLACEHOLDER (shows "BUILD_INFO_PLACEHOLDER" in local dev;
replaced at deploy time)
- samples/SkiaSharpDemo.Blazor/wwwroot/css/app.css: add small fixed
bottom-right badge style for #build-info
Co-authored-by: mattleibow <1096616+mattleibow@users.noreply.github.com>
Done in 841b7ce. Here's how it works in both surfaces: Docs site (docfx footer) — the
Blazor sample (fixed badge) — added a PR_NUMBER early validation (review comment |
|
@copilot Maybe we can set assembly attributes on wasm app and use that. there are msbuild items/properties we could use. Then at runtime it could update something in the layout razor or something. Wherever. insead of editing the html. |
….html
- SkiaSharpDemo.Blazor.csproj: add BuildInfo MSBuild property (defaults
to "local") and an AssemblyAttribute item that bakes it into the
assembly as AssemblyMetadataAttribute("BuildInfo", ...)
- Layout/MainLayout.razor: add @code block that reads BuildInfo from
the executing assembly at runtime; renders it in a <footer class="build-info">
- Layout/MainLayout.razor.css: add .build-info footer style (right-aligned,
monospace, muted, with top border)
- docs-deploy.yml: pass -p:BuildInfo="SOURCE_LABEL · SHA" to dotnet publish
so CI bakes the correct label into the assembly; remove sed
BUILD_INFO_PLACEHOLDER step and its env vars from the copy step
- wwwroot/index.html: remove BUILD_INFO_PLACEHOLDER div (no longer needed)
- wwwroot/css/app.css: remove #build-info fixed-position badge style
Co-authored-by: mattleibow <1096616+mattleibow@users.noreply.github.com>
Done in d213119. Replaced the
CI (
private string _buildInfo = typeof(App).Assembly
.GetCustomAttributes<AssemblyMetadataAttribute>()
.FirstOrDefault(a => a.Key == "BuildInfo")?.Value ?? "local";Renders it as
Local dev shows |
mattleibow
left a comment
mattleibow
left a comment
There was a problem hiding this comment.
@copilot what happened?
| border-top: 1px solid #eee; | ||
| } | ||
|
|
||
| @media (min-width: 641px) { |
There was a problem hiding this comment.
My edit that inserted .build-info accidentally swallowed the @media (min-width: 641px) { opening line, so all the responsive layout rules were unscoped. Fixed in 278019f — the @media line is restored at line 58, right after .build-info.
| .form-floating > .form-control-plaintext:focus::placeholder, .form-floating > .form-control:focus::placeholder { | ||
| text-align: start; | ||
| } No newline at end of file |
There was a problem hiding this comment.
The #build-info block (fixed-position badge in index.html) was removed in d213119 as part of refactoring from the sed/placeholder approach to the AssemblyMetadata approach. The build info is now surfaced via a <footer class="build-info"> in MainLayout.razor using a Blazor-scoped CSS rule in MainLayout.razor.css, so the global app.css entry was no longer needed.
The previous edit that inserted .build-info accidentally dropped the @media (min-width: 641px) { opening line, leaving the responsive layout rules unscoped and causing the orphaned } at the end. Restored. Co-authored-by: mattleibow <1096616+mattleibow@users.noreply.github.com>
.github/workflows/builds-docs.ymldocs-deploy.yml,docs-cleanup-staging-pr.yml,docs-go-live.ymldocs/docfx.json—net9.0→net10.0docs-deploy-fork-pr.yml— secure fork PR staging viaworkflow_runAssemblyMetadataMSBuild attribute +MainLayout.razorruntime read@media (min-width: 641px) {inMainLayout.razor.css💡 You can make Copilot smarter by setting up custom instructions, customizing its development environment and configuring Model Context Protocol (MCP) servers. Learn more Copilot coding agent tips in the docs.