You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Add a repository-scoped azd release canvas for the GitHub Copilot app, guiding core CLI releases from changelog preparation through publishing and follow-ups. Teammates discover it with the repository; there is no separate canvas package to install.
Private tracking issues hold both authoritative release events and separate, timestamped display snapshots. Opening the canvas or selecting Refresh loads saved progress using GitHub only, so teammates can follow releases without Azure login. Explicit live reads refresh observations; the release driver shares sanitized snapshots while observers' live reads stay local. The canvas supplements the release runbook, not service permissions, publishing approvals, or operator judgment.
Top 5 features
Shared tracking, fast saved views, and clear ownership. Create tracking with just a version and select active or historical releases. Driver-authored events establish release state; separate observation comments preserve the roadmap across machines and extension restarts. Each section shows its observation time, author, shared/local origin, and stale or failed-attempt status. Partial/abandoned releases remain explicitly irregular.
GitHub-first team access. Verify authenticated access to the private tracking repository and its issues before displaying any release data. Saved views require no Azure login. Live reads and backend actions independently revalidate access; denied or unverifiable access clears private UI state and local previews. Cached observations never grant permissions or authorize publishing.
Changelog preparation inside the release. Prepare a changelog in a new isolated session by default, preserving the skill's review and approval steps, or verify and link an existing PR. Explicit live refresh discovers the requested PR through its correlation marker; linking checks its target and CLI/SDK/changelog versions.
Explicit, guarded pipeline orchestration. Discover and verify the pipeline identity, preview a pinned source commit and live/playback parameters, require confirmation, and persist a queue reservation to prevent duplicate publishing. Existing publishing runs can be verified and adopted. Azure DevOps approvals stay in Azure DevOps; failure analysis refetches live evidence rather than relying on cached log references.
Distribution readiness before version announcements. Follow changelog → CI/signing → publishing → package readiness → version increment. One explicit button checks exact WinGet availability, Chocolatey approval/validation/verification, Homebrew cask and formula definitions, and public standalone/MSI/DEB/RPM artifacts. Independent ready/blocked/unknown cards update without a full-canvas refresh. Driver checks share compact gate results; run/source/version-bound readiness expires after ten minutes. Missing evidence and disabled submissions never waive gates.
Main flow
flowchart TD
Open[Open the azd release canvas] --> Access{Private GitHub tracking access?}
Access -->|No or unverified| Denied[Team access required - stop before Azure checks]
Access -->|Yes| Tracking[Create or select a private tracking issue]
Tracking --> Saved[Load saved observations - no Azure login needed]
Saved -. Explicit live refresh .-> Live[Verify live access and query services]
Live --> Driver{Release driver?}
Driver -->|Yes| Share[Append sanitized snapshots with per-section timestamps]
Share --> Saved
Driver -->|No| Local[Local observations only]
Tracking --> Changelog[Driver prepares with skill approvals or verifies and links a PR]
Changelog --> Merge[Review and merge changelog PR]
Merge --> Queue[Fresh verification - preview and confirm publishing or adopt an existing run]
Queue --> CI[CI and signing]
CI --> Approval[Review publishing approval in Azure DevOps]
Approval --> Publishing[Publishing]
Publishing --> Check[Check package readiness on demand]
Local -. Verified GA publishing run .-> Check
Check --> Gates{All five distribution gates ready?}
Gates -->|Blocked or unknown| Hold[Hold announcement - inspect evidence and coordinate owners]
Gates -->|Yes| Review[Review pipeline health, runbook and release policy separately]
Review --> Markers[Authorized operator reviews final version-marker approval]
Markers --> Increment[Review and merge generated version-increment PR]
CI -. Failure .-> Analysis[Read-only agent investigation - no automatic recovery]
Publishing -. Failure .-> Analysis
Loading
Package checks can run while publishing has failed or remains unfinished. They neither repair the pipeline nor authorize publishing, moderation requests, or marker recovery. The existing pipeline's Chocolatey availability check is weaker than this canvas's approval and verification requirements; this PR does not change pipeline YAML.
Screenshots
These screenshots capture an earlier iteration of the actual canvas HTML/CSS/JavaScript against synthetic demo fixtures. Usernames, release versions, issue/PR/build numbers, and observations are examples, not real private tracking data. The current UI adds shared/live refresh controls and per-section provenance, and expands the pictured WinGet-only check to five distribution-readiness cards. Fixture servers, browser profiles, and PNG files are not committed.
Earlier roadmap iteration: local WinGet verification
Changelog preparation inside a tracked release
Team-access-required view
Scope and safety
Includes the project canvas, focused offline tests, a usage/security guide, documentation navigation, and the core changelog skill's canvas handoff. No pipeline YAML changes.
GitHub and Azure DevOps remain authoritative permission boundaries. Public source contains configuration identifiers, not embedded credentials or real private release state.
Open / Refresh performs no Azure or public-status queries, writes no snapshots, and does not poll. Refresh live data & share explicitly appends driver observations to the private issue; observers' live reads never write shared snapshots. Snapshots are separate from authoritative events, bound to release identities, and merged per section by timestamp. Failed reads retain historical values and original observation times with separate failed-attempt labels; failed saves are explicit and not automatically retried.
Snapshot projection excludes raw logs, timeline names, previous-attempt diagnostics, free-form errors and package diagnostics, credentials, signed URLs, permission state, and queue tickets. Failure analysis refetches live identifiers. No automatic retries, credential rotation, or publishing approvals.
Package checks refresh local WinGet and share sanitized results only for the driver. They install nothing, execute no Homebrew definitions, request no moderation actions, and change no version markers. Public artifact HEAD/size checks are distribution evidence, not installation or checksum tests. Shared WinGet evidence describes the checking machine, not the viewer's catalog.
Saved views require a canvas-capable Copilot app, Node.js 22+, and GitHub CLI with private tracking access. Live pipeline reads/actions additionally require Azure CLI and its Azure DevOps extension. The WinGet gate requires WinGet on Windows; missing WinGet stays unknown while other gates run. Chocolatey and Homebrew do not require their local CLIs. Readiness checking targets verified GA releases; preview policy requires separate review.
Reloaded the provider and exercised real snapshot sharing, package checks, and GitHub-only saved reloads against authorized services. Verified browser provenance timestamps, saved readiness rendering, and the neutral Azure-not-queried view. Real release observations and private diagnostics are intentionally omitted here.
Earlier synthetic screenshot scenarios were verified in an isolated headless browser without changing real credentials or publishing anything.
Draft for team review of the release workflow, safety boundaries, and UX.
Azure Pipelines:
26 pipeline(s) were filtered out due to trigger conditions.
There may be pipelines that require an authorized user to comment /azp run to run.
Note the Analyze failure button. Canvas has all the context, the links and access to the logs. It can start the session directly from there to investigate and it also has the context from all issues or known issues to see if it is the same and there's a known workaround
Thanks for the contribution! Please link a GitHub issue to this PR by adding Fixes #123 to the description or using the sidebar.
No issue yet? Feel free to create one!
Adds a repository-scoped GitHub Copilot canvas for coordinating azd core releases. It supplements the release runbook with private shared tracking, explicit live checks, and guarded publishing actions.
Changes:
Adds release tracking, saved observations, pipeline previews, and a five-step roadmap.
Introduces independent distribution-readiness checks with freshness and provenance.
Adds offline tests, usage documentation, and a core changelog handoff.
Discard queue previews after access or release changes, verify active Homebrew checksums per platform, and synchronize discovered panel selections for SDK actions.
Co-authored-by: Copilot App <223556219+Copilot@users.noreply.github.com>
Copilot-Session: 19fa3be1-2642-4d68-96ba-0bf5cab9c737
The reason will be displayed to describe this comment to others. Learn more.
🔵 Needs a closer look
Stale pipeline observations can overwrite newer results, invalid Homebrew architecture mappings can pass readiness checks, and failed observer refreshes can discard prior local evidence.
No open issues 🎉
3 previously missed issues
In code that hasn't changed since last review
Validate architecture mapping before cask readiness
The cask check accepts the interpolated #{arch} URLs without validating the arch declaration that determines their filenames. Removing that declaration or swapping its ARM/Intel mappings in the existing fixture still returns ready, even though the resolved downloads are missing or target the wrong architecture. Require the expected active architecture mapping before marking this gate ready.
The build is read before the package checks, but this update receives its timestamp only after those checks finish. If another client shares a completed run while WinGet or public checks are pending, the older inProgress result is stamped later and wins mergeObservations, regressing the team's saved pipeline health and making stale status appear fresh. Capture the observation time when build() returns and pass it to observationUpdate.
Preserve local observations across failed refreshes
Observer refreshes merge only against shared issue observations, not the observer's preceding local read. After a successful local read, a failed live refresh therefore drops the previous pipeline/PR evidence or replaces it with an older shared snapshot. Retain account- and release-bound local sections between live refreshes and merge failed attempts into them, clearing them on an explicit saved-state refresh or access loss.
The reason will be displayed to describe this comment to others. Learn more.
Thanks for putting that care into the workflow, Victor.
A couple of things to tighten up:
Before merging, let’s handle competing changelog links safely. Two driver sessions can link different PRs and leave tracking unreadable. Keep the first valid link and give the second session a clear conflict so nobody needs to repair issue comments manually.
As a follow-up, let’s mark readiness cards expired when the ten-minute window ends, without polling services. Someone returning to an open canvas during approvals should see that they need a fresh check, rather than cards that still look ready.
Competing changelog links now keep the first link in GitHub comment-ID order (or an existing issue-body link). The losing request gets an explicit conflict after posting, and ignored competing links are visible as warnings rather than breaking tracking. Added a two-client race regression.
Homebrew cask readiness now requires the active ARM/Intel filename mapping; missing, commented, or swapped mappings fail closed.
Package checks capture the build observation time before slow package reads, preventing an older build result from overwriting newer shared pipeline evidence.
Local live refreshes retain account- and release-bound sections across failed retries with original provenance and separate failed-attempt receipts. Explicit saved refresh and access loss clear retained local sections.
The readiness-card expiration request remains a follow-up, as suggested in the review; this commit adds no polling or automatic expiration timer. All 119 offline canvas tests and documentation spell checking pass.
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
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.
Kristen Womack (kristenwomack)
left a comment
Summary
Add a repository-scoped azd release canvas for the GitHub Copilot app, guiding core CLI releases from changelog preparation through publishing and follow-ups. Teammates discover it with the repository; there is no separate canvas package to install.
Private tracking issues hold both authoritative release events and separate, timestamped display snapshots. Opening the canvas or selecting Refresh loads saved progress using GitHub only, so teammates can follow releases without Azure login. Explicit live reads refresh observations; the release driver shares sanitized snapshots while observers' live reads stay local. The canvas supplements the release runbook, not service permissions, publishing approvals, or operator judgment.
Top 5 features
Main flow
flowchart TD Open[Open the azd release canvas] --> Access{Private GitHub tracking access?} Access -->|No or unverified| Denied[Team access required - stop before Azure checks] Access -->|Yes| Tracking[Create or select a private tracking issue] Tracking --> Saved[Load saved observations - no Azure login needed] Saved -. Explicit live refresh .-> Live[Verify live access and query services] Live --> Driver{Release driver?} Driver -->|Yes| Share[Append sanitized snapshots with per-section timestamps] Share --> Saved Driver -->|No| Local[Local observations only] Tracking --> Changelog[Driver prepares with skill approvals or verifies and links a PR] Changelog --> Merge[Review and merge changelog PR] Merge --> Queue[Fresh verification - preview and confirm publishing or adopt an existing run] Queue --> CI[CI and signing] CI --> Approval[Review publishing approval in Azure DevOps] Approval --> Publishing[Publishing] Publishing --> Check[Check package readiness on demand] Local -. Verified GA publishing run .-> Check Check --> Gates{All five distribution gates ready?} Gates -->|Blocked or unknown| Hold[Hold announcement - inspect evidence and coordinate owners] Gates -->|Yes| Review[Review pipeline health, runbook and release policy separately] Review --> Markers[Authorized operator reviews final version-marker approval] Markers --> Increment[Review and merge generated version-increment PR] CI -. Failure .-> Analysis[Read-only agent investigation - no automatic recovery] Publishing -. Failure .-> AnalysisPackage checks can run while publishing has failed or remains unfinished. They neither repair the pipeline nor authorize publishing, moderation requests, or marker recovery. The existing pipeline's Chocolatey availability check is weaker than this canvas's approval and verification requirements; this PR does not change pipeline YAML.
Screenshots
These screenshots capture an earlier iteration of the actual canvas HTML/CSS/JavaScript against synthetic demo fixtures. Usernames, release versions, issue/PR/build numbers, and observations are examples, not real private tracking data. The current UI adds shared/live refresh controls and per-section provenance, and expands the pictured WinGet-only check to five distribution-readiness cards. Fixture servers, browser profiles, and PNG files are not committed.
Earlier roadmap iteration: local WinGet verification
Changelog preparation inside a tracked release
Team-access-required view
Scope and safety
Validation
Draft for team review of the release workflow, safety boundaries, and UX.