release-notes: drop per-PR effort metric, resolve skia links locally#4176
Closed
mattleibow wants to merge 1 commit into
Closed
release-notes: drop per-PR effort metric, resolve skia links locally#4176mattleibow wants to merge 1 commit into
mattleibow wants to merge 1 commit into
Conversation
The "Update Release Notes" agentic workflow
(.github/workflows/update-release-notes.md, timeout-minutes: 15) timed out on
its first post-merge run. The cause was the per-PR "effort" badge: it ran one
network `git fetch refs/pull/N/head` per PR to recover pre-squash commit
detail. For the 4.148 release that is 162 serial fetches, each paying full
proxied-TLS setup (~4s) behind the workflow's Squid firewall — ~11 min plus an
unshallow, blowing the 15-min cap. On timeout `safe_outputs` is skipped, so no
PR is ever opened and the cold author-cache never warms: the cold start cannot
self-heal.
The effort value (commit count + working days) earned none of that cost: it is
not rendered in the notes and the model never surfaced it. Everything actually
shown — title, author, number, body, companion skia link — already comes from a
single local `git log`.
Changes:
* Remove the effort computation and its rendering entirely
(_get_pr_effort_from_git, compute_pr_effort, _fetch_skia_pr_effort,
add_pr_effort). This alone takes a cold full `--all` from a 15-min timeout
to ~35s.
* Keep the companion `skia: mono/skia#N` hint, parsed locally from the PR
body, and add the `mono/skia#N` shorthand that milestone bumps use.
* Resolve the companion link for submodule-bump PRs that don't spell it out,
purely locally. The bump and its target skia SHA are read from the
superproject tree (`git rev-parse <commit>:externals/skia` vs its parent);
the bumped skia commit's own subject ((#N) / "Merge pull request #N") is then
read from the submodule. The only network is one batched, blobless, shallow
`git fetch` of just the bumped SHAs; already-present commits are skipped, so
`--all` fetches each skia commit at most once (a handful per run, not 162).
For 4.148 this lifts companion-link coverage of skia-bumping PRs from 18 to 22
of 23. The single remaining gap is an anomalous backwards gitlink (PR #4081
resets the submodule to mono/skia's scaffold root, which has no PR); its real
companion, skia #242, is already linked via the forward bump. The other
historical misses are skia commits pushed directly to mono/skia with no PR at
all, so there is nothing to link.
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
Contributor
📦 Try the packages from this PRWarning Do not run these scripts without first reviewing the code in this PR. Step 1 — Download the packages bash / macOS / Linux: curl -fsSL https://raw.githubusercontent.com/mono/SkiaSharp/main/scripts/get-skiasharp-pr.sh | bash -s -- 4176PowerShell / Windows: iex "& { $(irm https://raw.githubusercontent.com/mono/SkiaSharp/main/scripts/get-skiasharp-pr.ps1) } 4176"Step 2 — Add the local NuGet source dotnet nuget add source ~/.skiasharp/hives/pr-4176/packages --name skiasharp-pr-4176More options
Or download manually from Azure Pipelines — look for the Remove the source when you're done: dotnet nuget remove source skiasharp-pr-4176 |
Contributor
|
📖 Documentation Preview The documentation for this PR has been deployed and is available at: 🔗 View Staging Site This preview will be updated automatically when you push new commits to this PR. This comment is automatically updated by the documentation staging workflow. |
Contributor
Author
|
Folded into #4177 — we're shipping the release-notes and API-changelog fixes together. |
mattleibow
added a commit
that referenced
this pull request
Jun 17, 2026
… local skia links (#4177) [docs] Unify changelog + release-notes generation: stable rollups and local skia links (#4177) Context: #4171 (shared versions.json), #4173 (bot/api-diff PR), #4176 (folded in here) Two fixes to the shared versions.json-driven docs pipeline, shipped together because they are the two halves of the same "one rollup per release line" model. ~~ API changelogs: one folder per release line, not per preview ~~ The unify-versioning refactor (#4171) started passing --nugetDiffPrerelease=true to docs-api-diff-past so the 4.x line — which ships only as previews/rcs until it stabilises — would get changelogs at all. But the loop still emitted a folder for *every* enumerated version, so each intermediate preview produced its own directory: the last API Diff run filled bot/api-diff (#4173) with 4.147.0-preview.{1,2,3}, 4.148.0-rc.1.2 and 4.150.0-preview.1.1 dirs across every tracked package (~2,300 added files). Historically changelogs/ held stable versions only. Collapse the feed to one entry per release line (numeric version core with the prerelease label stripped: 4.148.0-rc.1.2 -> 4.148.0; a genuine 4-part stable like 1.49.2.1 keeps its fourth digit) and emit a single rollup changelog per line, diffed against the line's representative package — the newest stable if it shipped, otherwise the newest prerelease. This mirrors the release-notes pages, which are stable-named rollups of the previews in between. A line is emitted when it shipped stable, or when it is an active dev line (preview-only, not superseded, and newer than the last stable — e.g. 4.148, 4.150). Abandoned preview-only lines (superseded in versions.json, e.g. 4.147) and old never-shipped previews are skipped; their changes are absorbed into the successor's cumulative diff. Baselines are unchanged: versions.json compare_to overrides win, otherwise diff against the previous emitted line. * RunBreakingAndFullDiff (published overload) now takes the changelog folder name separately from the diffed package version, since they differ while a line is still in preview. For SkiaSharp this regenerates to the stable set plus the two active lines: it adds 3.119.4 (the shipped stable, previously missing) and the 4.148.0/4.150.0 rollups, and prunes the superseded preview-only 3.0.0 and 3.119.3 directories that predated versions.json. Once merged, the API Diff workflow regenerates #4173 with the collapsed set. ~~ Release notes: drop per-PR effort metric, resolve skia links locally ~~ The --all run was timing out: the now-removed "effort" metric and the companion-skia-PR link resolution each issued one network fetch per PR (162 serial round-trips). * Removed the per-PR effort metric entirely (it never appeared in output). * Made skia-link resolution pure-local: detect submodule bumps via git rev-parse <commit>:externals/skia against the parent, batch-fetch only the bumped SHAs (blobless + shallow) into externals/skia, and read each skia commit subject to parse the companion mono/skia#N PR — no per-PR network. Result: companion links resolved for 22/23 skia-bumping PRs in 4.148 (the one miss is an anomalous backwards gitlink with no PR), and a cold full --all run drops to ~35s. Co-authored-by: Matthew Leibowitz <mattleibow@live.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Why
The Update Release Notes agentic workflow (
update-release-notes.md,timeout-minutes: 15) timed out on its first post-merge run. The cause was the per-PR effort badge: it ran one networkgit fetch refs/pull/N/headper PR to recover pre-squash commit detail. For the 4.148 release that's 162 serial fetches, each paying full proxied-TLS setup (~4s) behind the workflow's Squid firewall — ~11 min plus an unshallow, blowing the 15-min cap. On timeoutsafe_outputsis skipped, so no PR is opened and the cold author-cache never warms; the cold start can't self-heal.The effort value (commit count + working days) earned none of that cost: it isn't rendered in the notes and the model never surfaced it. Everything actually shown — title, author, number, body, companion skia link — already comes from a single local
git log.Changes
_get_pr_effort_from_git,compute_pr_effort,_fetch_skia_pr_effort,add_pr_effort) and its rendering. This alone takes a cold full--allfrom a 15-min timeout to ~35s.skia: mono/skia#Nhint (parsed locally from the PR body) and add themono/skia#Nshorthand that milestone bumps use.git rev-parse <commit>:externals/skiavs its parent); the bumped skia commit's own subject ((#N)/Merge pull request #N) is then read from the submodule. The only network is one batched, blobless, shallowgit fetchof just the bumped SHAs; already-present commits are skipped, so--allfetches each skia commit at most once (a handful per run, not 162).Coverage
For 4.148 this lifts companion-link coverage of skia-bumping PRs from 18 → 22 of 23. The one gap is an anomalous backwards gitlink (PR #4081 resets the submodule to mono/skia's scaffold root, which has no PR); its real companion, skia #242, is already linked via the forward bump. The other historical misses are skia commits pushed directly to mono/skia with no PR, so there's nothing to link.
Verification
--all(noexternals/skiaobjects, caches atmain): 35.5s, exit 0, 1 skia fetch batch, 2 author-API batches.+103 / -186); no generated pages/cache committed — the workflow regenerates onmain.Co-authored-by: Copilot 223556219+Copilot@users.noreply.github.com