mirror of
https://github.com/microsoft/PowerToys.git
synced 2026-08-29 10:09:43 +02:00
980d4193df2d4f912870877e89ba14278741ea83
18 Commits
| Author | SHA1 | Message | Date | |
|---|---|---|---|---|
|
|
5759a62d4a |
[UITests][Keyboard Manager] UI tests for new keyboard manager. (#50059)
<!-- Suggested title: [UITests][Keyboard Manager] Add and stabilize UI tests for the unified editor --> ## Summary of the Pull Request Closes: #40662 Adds a new `Microsoft.PowerToys.UITest.Next` end-to-end suite for Keyboard Manager and hardens the unified editor behavior uncovered while exercising it on Windows 10, Windows 11, x64, and ARM64. The Keyboard Manager suite executes 32 test cases covering: - Unified editor create, edit, save, enable/disable, delete, restart persistence, missing-profile recovery, validation, and special actions. - Single-key, key-to-shortcut, shortcut-to-shortcut, shortcut-to-key, disabled-key, and app-specific remapping. - Modifier ordering and release behavior, including Alt+Tab and Alt+F4 targets. - Real keyboard behavior through Windows Notepad and Calculator fixtures rather than synthetic input windows. The PR also adds 26 managed unit tests around settings normalization, profile reconciliation, metadata ownership, active-state changes, and canonical modifier ordering. ## Detailed Description of the Pull Request / Additional comments ### Keyboard Manager UI tests Adds `src/modules/keyboardmanager/Tests/KeyboardManager.UITests` as a Microsoft Testing Platform executable using `UITestAutomation.Next` and winappcli. The suite includes: - `KeyboardManager.Editor.CreateEditPersistDelete` - Creates and edits mappings. - Verifies native profile and editor metadata persistence across restarts. - Exercises active-state toggling, row deletion, and missing native-profile recovery. - `KeyboardManager.Editor.InputAndValidation` - Covers key recording, dropdown input, keyboard navigation, cancellation, and app-specific validation. - `KeyboardManager.Editor.ActionPersistence` - Covers Open URL, Open app, and Insert text actions and verifies canonical readback after restart. - Parameterized runtime tests for key/shortcut combinations, disabled targets, app-specific mappings, modifier release order, Alt+Tab, and Alt+F4. The test support code provides: - A shared cross-process fixture lock and isolated Keyboard Manager settings scope. - Real Notepad documents with exact window/document ownership and cleanup. - Win10/Win11-aware Calculator window ownership for Alt+F4 assertions. - A low-level keyboard event recorder that validates injected key-down/key-up sequences and flags. - Authoritative persisted JSON assertions instead of relying only on transient UI state. ### Keyboard Manager correctness fixes found by the suite The tests exposed product races and persistence issues that are fixed in the same PR: - Native profile JSON is written through checked same-directory atomic replacement instead of a truncation-prone direct write. - Editor metadata and native mappings are normalized and reconciled per profile. - Create, edit, delete, and active-state mutations commit metadata and native state transactionally under a cross-process lock. - Startup reconciliation preserves inactive metadata owned by other profiles and repairs legacy/profileless settings. - Native Boolean return values use one-byte marshaling to match the C++ ABI. - Modifier keys and serialized targets are canonicalized consistently. - Unit-test initialization no longer starts real settings synchronization. ### CI stability hardening The editor workflows use coordinate-free UIA invocation for command buttons and authoritative-signal retries for idempotent row interactions. Window fixtures bind exact top-level HWNDs and distinguish the Win10 Calculator `ApplicationFrameWindow` from its child content window. The child-specific `UITestAutomation.Next` updates add or improve: - `WindowShowWatcher` lifecycle handling used by the Keyboard Manager window fixtures. - Exact HWND foreground, close, and process-tree cleanup helpers required by the Win10/Win11 tests. ### Pipeline workflow Adds the internal `ui-tests-pipeline-ci` skill and Azure DevOps helper used during stabilization: - Uses an existing Azure CLI session plus Azure DevOps REST APIs without per-call authentication prompts. - Supports paged branch/build discovery, preview and queue operations, exact-SHA reconciliation, stage retry/cancel, logs, test results, artifacts, and direct result-attachment downloads. - Uses build-scoped one-shot completion monitoring and retains the three-run stabilization guardrail. ## Validation Steps Performed ### Azure DevOps UI Test Automation Final verification build: - https://microsoft.visualstudio.com/Dart/_build/results?buildId=155512681&view=results - https://microsoft.visualstudio.com/Dart/_build/results?buildId=155525972&view=results ## Reviewer guide Suggested review order: 1. `src/modules/keyboardmanager/Tests/KeyboardManager.UITests/` - intended workflows and assertions. 2. `KeyboardManagerEditorUI/Settings/SettingsManager.cs` and `Pages/MainPage.xaml.cs` - transaction and reconciliation ownership. 3. `common/MappingConfiguration.cpp` and `Interop/KeyboardManagerInterop.cs` - native persistence and ABI fixes. 4. `src/common/UITestAutomation.Next/WindowControl.cs` and `WindowShowWatcher.cs` - child-specific window lifecycle hardening. 5. `.github/skills/ui-tests-pipeline-ci/` - internal Azure CLI/REST stabilization workflow. Local evidence: <img width="1237" height="854" alt="image" src="https://github.com/user-attachments/assets/ff49652e-fbc8-4581-a48f-836dbed37b6e" /> |
||
|
|
d68980a81b |
[UITests][FancyZones + Editor] Migrate FZ UI tests to .Next framework + add new tests (#49985)
# test(fancyzones): migrate and expand UI tests to winappcli ## Summary of the Pull Request Part of #40658. Adds `FancyZones.UITests.Next`, a Microsoft.Testing.Platform test executable built on `UITestAutomation.Next` and winappcli. It ports the 18 active legacy FancyZones tests and adds 3 conservative backend scenarios selected from the larger manual plan: - quick-layout switching during an active window drag - excluded-app enforcement - one-monitor keyboard snapping, zone cycling, and last-zone restore on reopen The suite now contains 21 tests. Editor CRUD and layout-authoring coverage remains in the separate `FancyZonesEditor.UITests` project. The migration also fixes two FancyZones defects exposed by the new tests: swallowed Shift input did not update drag state, and the first Shift-triggered zone highlight was reset after it was calculated. ## PR Checklist - [ ] Closes: #49426 - [x] CI Green https://microsoft.visualstudio.com/Dart/_build/results?buildId=155118915 ## Detailed Description of the Pull Request / Additional comments ### FancyZones test migration - Registers `FancyZones.UITests.Next` for x64 and ARM64 in `PowerToys.slnx`. - Ports dragging, quick-layout, virtual-desktop, window-switching, transparency, editor-launch, and process-start coverage. - Adds focused coverage for excluded apps, keyboard snap override/cycling, last-zone restore, and quick-layout switching during a drag. - Uses per-monitor-v2 DPI awareness and keeps the legacy WinAppDriver suite in place. ### Stable behavioral signals - Uses `app-zone-history.json`, `applied-layouts.json`, and per-HWND `FancyZones_zones` properties instead of relying on visual geometry alone. - Uses WinEvent hooks for transient zone flashes and Win32 window/process queries for cheap readiness checks. - Drives the layout editor through its named event and verifies the resulting files. - Tracks Explorer windows by HWND, validates title-bar point ownership, recomputes grab coordinates after failures, and retries the complete drag gesture. - Keeps modifier state through `MOVESIZEEND` and avoids cursor movement that changes the selected zone. ### Product fixes - Records Shift state before the low-level hook swallows the key during an active move loop. - Enters snapping mode before calculating the first highlighted zone so the transition does not reset that result. ### Shared framework and CI hardening - Adds reusable named-event, window-show watcher, keyboard-state, window-property, alpha, foreground, and capture helpers to `UITestAutomation.Next`. - Advances the centrally managed .NET package set from `10.0.10` to `10.0.11` to match the runtime packs selected by SDK `10.0.400` and prevent dependency-audit collisions. - Documents Azure Artifacts runtime-pack cache misses and the authenticated upstream-cache workflow. The broader manual checklist remains intentionally manual where automation would be costly or fragile: multi-monitor/span scenarios, lock/reboot and device reconnect, administrator boundaries, child/popup windows, appearance color rendering, and overlap-algorithm visuals. FancyZones Editor creation/copy/delete/grid/canvas workflows are already covered by its dedicated UI-test project. --------- Co-authored-by: copilot-swe-agent[bot] <198982749+Copilot@users.noreply.github.com> Co-authored-by: khmyznikov <6115884+khmyznikov@users.noreply.github.com> |
||
|
|
e753ec51fb |
feat(release): automate draft preview release preparation (#49797)
## Summary of the Pull Request Adds a `Prepare Preview Release` custom agent that autonomously turns a successful PowerToys Azure DevOps release-candidate build into a complete GitHub draft prerelease for final human review. The implementation extends the existing `release-note-generation` skill instead of duplicating it. It adds exact-build metadata resolution, published-release baseline selection, semantic PR deltas across `main` and `stable`, release asset validation, idempotent draft-only release updates, and final draft verification. ## PR Checklist - [x] **Communication:** The autonomous preview-release design was reviewed and approved before implementation - [x] **Tests:** Added/updated and all pass - [x] **Localization:** N/A; no end-user-facing strings were added - [x] **Dev docs:** Added preview scenario, delta, draft safety, and reporting references ## Detailed Description of the Pull Request / Additional comments - Adds `.github/agents/prepare-preview-release.agent.md` with a no-mid-run-decision workflow and a strict prohibition on publishing releases. - Extends `.github/skills/release-note-generation/SKILL.md` with stable/preview scenario routing while preserving the existing stable-release workflow. - Adds canonical scripts under `.github/skills/release-note-generation/scripts/` to: - Resolve and validate ADO build metadata. - Select the latest published stable or preview baseline before build queue time. - Calculate same-lineage or branch-transition PR deltas using PR numbers, cherry-pick provenance, and patch-ID equivalence. - Collect normalized PR metadata and create `release-manifest.json`. - Download and validate installers, symbols, and GPO assets, including hashes, signatures, and ZIP contents. - Create or update draft prereleases while preserving human text outside managed markers. - Verify draft flags, immutable target commit, body markers, and uploaded assets. - Updates `.pipelines/resolveBuildMetadata.ps1` and `.pipelines/v2/release.yml` with explicit `auto`, `preview-release`, and `stable-release` intent handling so preview candidates can be built from either `main` or `stable`. - Adds `.pipelines/writeReleaseMetadata.ps1` so each signed build artifact records its resolved version, channel, intent, source branch, and immutable source commit. - Keeps release publication outside the agent: the automation can only create or update a draft prerelease. ## Validation Steps Performed - `Invoke-Pester` for: - `.pipelines/tests/resolveBuildMetadata.Tests.ps1` - `.pipelines/tests/writeReleaseMetadata.Tests.ps1` - `.github/skills/release-note-generation/tests/preview-release.Tests.ps1` - 37 tests passed, covering stable-branch preview intent, metadata contracts, baseline selection, same-lineage and branch-transition deltas, patch-ID equivalence, managed-body preservation, and published-release refusal. - Parsed all added or modified PowerShell scripts with the PowerShell AST parser. - Parsed the modified pipeline YAML files with `ConvertFrom-Yaml`. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85 Copilot-Session: e9f79ac2-9a7b-4083-834c-0d87e8c83bfd Copilot-Session: 1ecea747-b313-49a1-9969-543c01ba1be8 |
||
|
|
e48152c52d |
[UITests] Add UITest.Next suites (Image Resizer, Peek, File Explorer add‑ons, File Locksmith) + local‑VM tooling and CI test‑signing (#49671)
## Summary Adds end‑to‑end UI tests on the `Microsoft.PowerToys.UITest.Next` (winappcli) framework for three modules, grows the shared `.Next` test framework with the helpers those suites needed, and adds the CI plumbing that lets shell‑extension tests exercise the **real** Windows 11 modern context menu. Also ships two agent skills that document how to write and run these tests. Product runtime behavior is **unchanged** — the only product edits are test‑observability hooks in Peek and a unit‑test project exclude. Closes: https://github.com/microsoft/PowerToys/issues/40660 https://github.com/microsoft/PowerToys/issues/49424 https://github.com/microsoft/PowerToys/issues/40661 ## What's added ### New UI test suites - **Image Resizer** — `src/modules/imageresizer/tests/ImageResizer.UITests`: context‑menu enable/disable tracking, the resize dialog, custom presets, every fit mode, every unit, filename format, keep‑date, shrink‑only, replace‑in‑place, and orientation. - **Peek** — `src/modules/peek/Peek.UITests.Next`: file‑preview coverage across image/text/archive/ markdown types with per‑arch visual baselines. - **File Explorer add‑ons** — `src/modules/previewpane/PreviewPane.UITests`: Preview Pane handlers and thumbnail providers. ### `UITestAutomation.Next` framework - New helpers: `ExplorerShell` (Shell selection/view‑mode interop), `WaitHelper` (structured stable waits), `WindowControl` (foreground/context‑menu/process control), `VisualAssert` (image compare), `WindowHelper`. - Updates to `Session`, `UITestBase`, `SettingsConfigHelper`, `WinappCli`. - New `UITestAutomation.Next.UnitTests` project covering the new wait/settings/CLI helpers. ### CI — sign sparse MSIX so the modern menu registers - **`.pipelines/signSparsePackages.ps1`** — self‑signs each sparse context‑menu MSIX with a publisher‑matching test certificate and force‑trusts it (machine stores), so `AddPackageByUriAsync` succeeds on otherwise‑unsigned PR builds. Robust `signtool` discovery with a NuGet fallback; test‑only trust that asserts no security. - Wired into **`.pipelines/v2/templates/job-test-project.yml`** as a best‑effort step covering the run‑in‑place, machine‑install, and per‑user‑install locations. Signs nothing it can't (skips already‑signed packages) and never fails the job. ### Product changes (test observability only) - **Peek `FilePreview.xaml` / `.xaml.cs`** — a named `LoadingIndicator` and a hidden automation peer that exposes the current preview state as text, so tests can read load state deterministically. No runtime behavior change. - **`ImageResizer.UnitTests.csproj`** — exclude the sibling `ImageResizer.UITests\**` folder from the unit‑test compilation. ### Agent skills & docs - **New `ui-tests-local-vm` skill** — run `.Next` suites in persistent dockur/windows VMs: setup, agentic loop, image customization, troubleshooting, the shell‑extension **signing** reference, plus controller/guest scripts and VM templates. - **Updated `ui-tests-migration` skill** — WinAppDriver/Selenium → `.Next` porting guidance (CI stability, Explorer/shell‑extension test design, patterns & pitfalls). - **`doc/devdocs/development/ui-tests.md`** — updated for the `.Next` workflow. ## Testing - All three suites pass locally and in CI across **x64 Win10**, **x64 Win11**, and **arm64** (machine and per‑user install legs). ## Reviewer notes - No product runtime behavior changes; product edits are limited to the Peek test hooks above. - The CI signing step is a **test‑only** trust anchor (self‑signed, scoped to the agent) and is best‑effort, so it can only add modern‑menu coverage and never regress the job. |
||
|
|
558e633c59 |
Add preview release versioning and update channel support (#49414)
## Summary - Publish scheduled `main` builds as GitHub prereleases while keeping manual `main` runs as preview validation builds. - Add an opt-in Settings switch for prerelease update checks; stable updates remain the default. - Use one MSI-safe version across bundles, MSI packages, binaries, symbols, and package manifests. - Prevent preview releases from triggering Microsoft Store, WinGet, or public-symbol publication. - Label preview builds explicitly in Settings, update notifications, and What's New. ## Build intent | Source | Trigger | Intent | | --- | --- | --- | | `main` | Scheduled | Publish a preview release | | `main` | Manual | Validate a preview build without publishing | | `stable` | Manual | Produce a stable release | | Other branches | Any supported trigger | Produce a private validation build | ## MSI-safe release versioning Windows Installer compares only `major.minor.build` and ignores the fourth version component. Preview and stable release builds therefore use: ```text major.minor.YDDDB.0 ``` - `Y`: zero-based number of calendar years since `ReleaseTrainEpoch`. - `DDD`: three-position calendar day of year. - `B`: daily release sequence `1-9`. - The fourth component is always `0`. With `ReleaseTrainVersion=0.100` and `ReleaseTrainEpoch=2026-01-01`: ```text 0.100.2111.0 = July 30, 2026, release build 1 0.100.3659.0 = December 31, 2026, release build 9 0.100.10011.0 = January 1, 2027, release build 1 ``` The allocator formats `DDD` as exactly three digits before converting the MSI component to its numeric representation. Leading zeros may not be displayed because Windows version components are numeric; decoding remains positional: ```text B = component % 10 DDD = (component / 10) % 1000 Y = component / 10000 ``` `ReleaseTrainVersion` and `ReleaseTrainEpoch` are checked in under `src/Version.props`. The epoch remains January 1 of the active epoch year and advances on the first release-train minor change in a new year. ## Daily release counter Azure DevOps persists the daily sequence server-side using a counter keyed as `release-YYYYMMDD`. - `main` and `stable` share the same daily counter. - Other branches do not evaluate or consume the release counter. - Failed or canceled `main`/`stable` runs may leave gaps. - The build fails when the daily sequence exceeds `9`. - The counter date and encoded `YDDD` date both use `pipeline.startTime`. Private branches retain independent `0.0.<extended-day><NN>.0` validation versions. ## Update behavior - Stable users continue to query GitHub's stable latest-release path. - Users who explicitly enable preview updates can select newer GitHub prereleases. - Preview releases and notifications are labeled as PowerToys Preview. - What's New separates preview entries from stable release history and hides previews by default. ## Validation - 17 Pester tests cover `main`, `stable`, private branches, year rollover, epoch reset, monotonicity, override validation, sequence limits, and date alignment. - Version propagation verified `0.100.2111.0` in `Version.props` and all affected AppX/MSIX manifests. - Azure DevOps pipeline dry-runs succeeded for both `refs/heads/main` and `refs/heads/stable`. - The affected native version project builds successfully. - PR CI is green for x64, ARM64, Command Palette SDK, dependency review, telemetry detection, and CLA. ## Remaining end-to-end checks - Install two locally or officially produced installers with consecutive MSI-visible `YDDDB` versions and verify the upgrade preserves binaries, package registrations, hardlinks, and shell integrations. - On the first natural post-merge `main` or `stable` run, verify the production counter value and resolved version in the release logs. ## Local GPO verification Validated locally with the signed `v0.100.2171` build from Azure DevOps build [153961073](https://microsoft.visualstudio.com/Dart/_build/results?buildId=153961073). These checks cover the administrative-template integration and Settings behavior. ### Policy enabled: preview updates are disabled With `PreviewUpdatesDisabled=1`, **Include prerelease updates** is forced off and locked, and Settings displays the managed-by-your-organization notice.  ### Policy removed: the user preference is preserved After removing `PreviewUpdatesDisabled` and restarting PowerToys, the previously selected preview-update preference is restored and editable. The policy suppresses the preference without overwriting it.  ### Group Policy Editor After importing the updated ADMX/ADML templates, **Disable preview build updates** appears under **Microsoft PowerToys > Installer and Updates**. The policy dialog documents that **Enabled** blocks preview updates, while **Disabled** or **Not Configured** leaves the choice available to the user.  --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: ad8b7909-0472-4464-bdee-deaeca726f94 Copilot-Session: 8e04a72e-3b0f-4ac4-8156-d04ea9b8bb85 |
||
|
|
160492abcf |
docs(skills): recommend WindowEx for WinUI 3 migrations (#49303)
## Summary of the Pull Request Updates the WPF-to-WinUI 3 migration skill to make the established PowerToys windowing pattern explicit: - Default WinUI 3 top-level windows to `WinUIEx.WindowEx` or an existing PowerToys base derived from it, such as `TransparentWindow` for transient overlays. - Keep supported size, presenter, title bar, topmost, backdrop, and persistence behavior declarative in XAML instead of manual `AppWindow` / `OverlappedPresenter` code-behind. - Document the centrally managed `<PackageReference Include="WinUIEx" />`, WPF-to-`WindowEx` property mappings, and existing repository examples. - Add a value-converter decision guide that prefers `VisualStateManager`, direct `x:Bind` conversion, WinUI theme resources, and `CommunityToolkit.WinUI.Converters` over mechanically porting WPF converters. This follows the migration-skill feedback from @niels9001 in [PR #49174](https://github.com/microsoft/PowerToys/pull/49174#discussion_r3535181101). ## PR Checklist - [x] **Communication:** This change follows review feedback from a core contributor in PR #49174. - [x] **Tests:** The updated guidance passed 5/5 fresh agent migration scenarios. - [x] **Dev docs:** Added/updated. ## Detailed Description of the Pull Request / Additional comments `SKILL.md` now states the default PowerToys pattern and limits raw `AppWindow` / presenter code to behavior that `WindowEx` does not expose. The package mapping reference records the exact centrally managed dependency. The windowing reference adds a complete XAML example, a WPF-to-`WindowEx` mapping table, regular-window examples, and the `TransparentWindow` overlay exception. The XAML migration reference now also documents converter selection and reuse: control state belongs in `VisualState`s, count visibility can share one Toolkit `DoubleToVisibilityConverter` with `ConverterParameter=True`, and corner-radius converter resources come from `XamlControlsResources`. This is an atomic documentation-only change; no product code or dependencies are modified. ## Validation Steps Performed - Verified the documented `WindowEx` APIs and `TransparentWindow` inheritance against the repository and compiled WinUIEx assembly. - Verified all cited repository paths, the Markdown anchor, and central package management entry. - Ran five fresh current-branch agent scenarios; all selected `<PackageReference Include="WinUIEx" />` without a version, `WindowEx`, XAML-declared properties, and `CenterOnScreen()` only where required. - Ran a focused converter migration scenario before and after the guidance update; the updated skill selected `VisualState`s, one reusable Toolkit numeric converter, and existing WinUI corner-radius resources without custom converters. - Ran `git diff --check` with no errors. - Completed an independent read-only review with no findings. - Product builds and unit tests were not run because this change only updates agent guidance. --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> Copilot-Session: fe9b24eb-99f0-43e8-aaa4-839f4579f6f9 Copilot-Session: d5afc36b-3356-46af-b8cb-071b87a64532 |
||
|
|
d5fe397b05 |
Follow-up: UITest framework Next - stability improvements (#49242)
This pull request addresses several CI flakiness and reliability issues in the UI test automation harness, especially around foreground window handling and build artifact resolution. The main improvements ensure that UI interactions (like real mouse clicks) reliably target the correct window, even in complex CI and build environments, and that test code accurately locates module executables regardless of output layout. **Foreground window handling and input reliability:** * Added `Session.EnsureForeground()` and improved `WindowControl.TryBringToForeground()` to reliably raise the target window above others, defeating the Win32 foreground lock using `AttachThreadInput` and related APIs. This prevents coordinate-based clicks from landing on the wrong window, a common cause of CI test flakiness. (`src/common/UITestAutomation.Next/Session.cs`, `src/common/UITestAutomation.Next/WindowControl.cs`, `src/common/UITestAutomation.Next/Element/Element.cs`, `.github/skills/ui-tests-migration/references/ci-stability.md`, `src/modules/MeasureTool/Tests/ScreenRuler.UITests.Next/TestHelper.cs`) [[1]](diffhunk://#diff-713524f4ead9951000b3578248f2740088729981051b68c3fa3655ebb548f20fR91-R118) [[2]](diffhunk://#diff-60be6ec24a99f8974cff00414fc47ea1e60e3ab9aee706b5d6845eb8df19165fR59-R76) [[3]](diffhunk://#diff-60be6ec24a99f8974cff00414fc47ea1e60e3ab9aee706b5d6845eb8df19165fL247-R332) [[4]](diffhunk://#diff-3c00581cb1d2b6a4302b8378b87c27cdad2f87c2aefc37eec0bdc6c39af9291aR100-R103) [[5]](diffhunk://#diff-98e5aea12baaac99aba10e7dd341ed3f2efdd24cb80b29306bb500816de09e2fR96-R114) [[6]](diffhunk://#diff-d8766b48614fe4a99e3f100e69e611ca2464de6ba0be257586c12d51f9278ed0L498-R504) **Build artifact and executable path resolution:** * Refactored `ModuleInfo.GetDevelopmentPath()` to dynamically walk up from the test assembly and find the module executable in various build output layouts, including CI artifacts and local builds. This eliminates hardcoded path offsets and makes test launches robust to different build structures. (`src/common/UITestAutomation/ModuleInfo.cs`) * Updated `ModuleConfigData.GetModulePath()` to use the improved path resolution and fall back to installed builds if necessary, ensuring that test runs can always locate the correct executable. (`src/common/UITestAutomation/ModuleConfigData.cs`) * Simplified `SessionHelper` so that `locationPath` is always empty, leveraging the fact that module paths are now absolute. (`src/common/UITestAutomation/SessionHelper.cs`) [[1]](diffhunk://#diff-c001f0fd3432c8b6102c3120597fc48f24902eaa0d755f51adfa7646344b3833L7-L10) [[2]](diffhunk://#diff-c001f0fd3432c8b6102c3120597fc48f24902eaa0d755f51adfa7646344b3833L46-R54) These changes collectively improve test reliability, especially in CI environments, and make the harness more resilient to changes in build output structure. --------- Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
|
85f698677a |
[UITests] AI migration skill + ScreenRuler tests example port. (#48842)
This PR is build on top of https://github.com/microsoft/PowerToys/pull/48717 and https://github.com/microsoft/PowerToys/pull/48467 It adds the ui-tests-migration skill which should be used to migrate the old UITest module by module to use new .Next UI framework. As an example, the screen ruller tests was ported here. --------- Co-authored-by: Boliang Zhang (from Dev Box) <bozhang@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
|
4395b1d0ca |
[skill] Generalize verification skill into 2 scenarios (module checklist / PR validation) (#48848)
## Summary of the Pull Request Generalizes the `powertoys-verification` agent skill from "one module checklist" into a **single shared engine that serves two verification scenarios**, using the *shared engine + per-scenario reference docs* design (no duplication of the winapp mechanics): - **A — Module checklist**: verify a supplied module checklist against the installed build. - **B — PR validation**: derive each PR's checklist from its description + diff, then drive it. A single **bits sub-decision** picks the target — drive the **installed** build when the PR's code is already shipped (a merged PR, or a whole release/hotfix set, e.g. the 0.100.1 14-PR sign-off), or **build + sideload** the affected module when it isn't (an unmerged or not-yet-released PR, e.g. #45242). Both scenarios share the same `winapp ui` drive techniques, helper scripts, per-module profiles, taxonomy, and report format. They differ mainly on **what bits you run**, so the only new content is a thin scenario layer. ## PR Checklist - [ ] **Closes:** N/A (follow-up to the merged `powertoys-verification` skill) - [x] **Communication:** design discussed and agreed before implementation - [x] **Tests:** N/A — docs/skill-only change; validated link/constraint checks (see below) - [x] **Localization:** N/A - [x] **Dev docs:** this PR *is* skill documentation - [x] **New binaries:** none ## Detailed Description of the Pull Request / Additional comments **`SKILL.md` (shared engine)** — broaden `description` + "When to use" to cover both scenarios, add a **Step-0 scenario router** (plus, for B, the bits sub-decision "is the PR's code in the build under test?"), keep the supplied-checklist read **Scenario-A-only**, and make the bootstrap/placeholders/"What NOT to do" scenario-aware. **`references/scenarios/`:** - `index.md` — router table (A/B); the **"bits under test" contract** (the one real conflict: installed-and-immutable, vs build-and-sideload when the PR's code isn't in the build, echoed in the report header so the evidence chain is trustworthy); and a verdict-vocabulary mapping (engine `PASS/FAIL/BLOCKED` <-> legacy labels). - `module-checklist.md` (A) — supplied checklist, installed bits. - `pr-validation.md` (B, **new — merges the former release-PR and active-PR docs**) — derive each PR's checklist from `gh pr view/diff`; the **bits sub-decision**; a **PR-discovery model with a size gate** (auto-verify hotfix-sized sets <=25; for full ~100-PR releases, scope-and-confirm instead of blind-looping) and a non-runtime-PR pre-filter; per-PR folders + roll-up; and the **build + sideload** front-end (in-repo worktree helper + build commands), unpackaged (run the built runner, dismiss the expected partial-build dialogs) vs packaged/CmdPal (`Add-AppxPackage -Register`) deploy recipes, prove-your-bits, and restore-to-shipped cleanup. Removed the separate `release-pr-signoff.md` and `active-pr-validation.md` (folded into `pr-validation.md`). The existing engine docs (`winapp-ui-testing.md`, `pre-flight.md`, `reporting-format.md`), per-module profiles, and helper scripts are reused unchanged — single source of truth. The `BITS:` header version is a `<version>` placeholder (not pinned to a release). ## Validation Steps Performed - `SKILL.md` within authoring limits: **331 lines** (< 500) and **description 999 chars** (< 1024). - All relative markdown links in `references/scenarios/*.md` resolve, and every engine doc they cite exists. - Scenario B exercised end-to-end both ways: the 0.100.1 14-PR sign-off (8 PASS / 6 BLOCKED, installed bits) and PR #45242 (Advanced Paste, 3/3 PASS, build + sideload). --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
|
d6319516d0 |
[Skills] Fix wpf-to-winui3-migration SKILL.md failing to load (#49059)
## Summary of the Pull Request The `wpf-to-winui3-migration` agent skill failed to load. The `description` field in its `SKILL.md` YAML frontmatter was an **unquoted** plain scalar containing `Keywords: ` (a colon followed by a space). YAML interprets `: ` as a mapping key/value separator, so the skill loader failed with: > failed to parse YAML frontmatter: mapping values are not allowed in this context at line 2 column 651 Because `.claude/skills` is a symlink to `.github/skills`, the CLI enumerates the same file twice, so this single defect surfaced as **two** skill load errors (`skill_error_count: 2`). Fix: wrap the `description` value in single quotes so the colon is treated literally. No wording changes; the description stays 926 characters (well under the 1024 limit). ## PR Checklist - [ ] Closes: #xxx — N/A, trivial metadata fix, no tracking issue - [x] **Communication:** Metadata-only fix; no design discussion needed - [ ] **Tests:** N/A — no test harness for skill frontmatter; validated by YAML parsing (see below) - [x] **Localization:** N/A — not end-user-facing - [ ] **Dev docs:** N/A - [ ] **New binaries:** N/A ## Detailed Description of the Pull Request / Additional comments `.github/skills/wpf-to-winui3-migration/SKILL.md` line 3 changed from: ```yaml description: Guide for migrating ... after migration. Keywords: WPF, WinUI, ... SoftwareBitmap. ``` to: ```yaml description: 'Guide for migrating ... after migration. Keywords: WPF, WinUI, ... SoftwareBitmap.' ``` The three other top-level skills already quote (or avoid `: ` in) their descriptions, so only this one was affected. Single quotes are used because the description contains no quote characters, so no escaping is required. ## Validation Steps Performed - Reproduced the loader error from the Copilot CLI logs: `mapping values are not allowed in this context at line 2 column 651`. - Parsed the frontmatter of all 9 `SKILL.md` files with a YAML parser: before = 1 failure (this file), after = **0 failures**. - Confirmed parsed `name` (`wpf-to-winui3-migration`), `description` (926 chars, ≤ 1024), and `license` are intact and the literal `Keywords: WPF...` text is preserved. Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
|
7e877558b9 |
Add powertoys-module-verification agent skill (#48717)
## Summary of the Pull Request
Adds a new **GitHub Copilot Agent Skill**,
`powertoys-module-verification`, under `.github/skills/`. It packages
the workflow, drive techniques, helper scripts, and per-module reference
data an AI agent uses to verify a single PowerToys module's
release-checklist items end-to-end (each checkbox → a structured PASS /
FAIL / BLOCKED verdict with evidence).
This is **docs/automation tooling only** — no product code, binaries, or
end-user strings are touched.
## PR Checklist
- [ ] Closes: #xxx
- [x] **Communication:** Internal tooling for release sign-off; happy to
adjust scope/placement based on review.
- [x] **Tests:** N/A — documentation/skill bundle only (no product code
paths). The 12 bundled `.ps1` helpers are agent utilities, not part of
the product build/test.
- [x] **Localization:** N/A — no end-user-facing strings.
- [x] **New binaries:** N/A — no binaries added.
- [x] **Dev docs:** This PR *is* developer-facing documentation/tooling.
## Detailed Description of the Pull Request / Additional comments
Layout follows the repo's Agent Skill guidelines
(`.github/instructions/agent-skills.instructions.md`) and matches the
existing skills under `.github/skills/`:
```
.github/skills/powertoys-module-verification/
├── SKILL.md # single entry doc (name/description/license frontmatter)
├── LICENSE.txt # Apache 2.0 (matches existing skills)
├── scripts/ # 12 PowerShell helper utilities used by the agent
└── references/
├── winapp-ui-testing.md # UIA-mechanics prerequisite doc
├── pre-flight.md / reporting-format.md / environment-setup.md / explorer-context-menu-flow.md
├── modules/ # per-module verification profiles
└── release-checklist/ # per-module checklists + index
```
Notes for reviewers:
- **`references/winapp-ui-testing.md`** is adapted from the
`winui-ui-testing` skill in
[microsoft/win-dev-skills](https://github.com/microsoft/win-dev-skills)
(MIT, © Microsoft Corporation and Contributors), with PowerToys-specific
edits. Provenance is recorded in the file header. Its skill frontmatter
was intentionally stripped so it is treated as a reference doc, not a
separately-discovered skill.
- **Checklist scope:** only modules already verified end-to-end (with a
sign-off report) are included for now — Environment Variables, File
Locksmith, Image Resizer, New+, Peek, PowerRename. Remaining modules'
checklists will be added as each is verified.
- No existing files are modified; this is purely additive under
`.github/skills/`.
## Validation Steps Performed
- Validated the bundle against the Agent Skill checklist in
`.github/instructions/agent-skills.instructions.md`: valid `name` (≤64
chars) + `description` + `license` frontmatter; `SKILL.md` body under
the 500-line guidance; single `SKILL.md`; `scripts/` + `references/`
resource buckets; all resource references use relative paths.
- Verified internal cross-references resolve after the migration (no
stale `helpers/`, `Winapp-SKILL.md`, or absolute-path tokens;
`src/modules/...` source citations left intact).
Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
|
||
|
|
d221f84d8f |
[Skills] Update WinUI3 migration skills to add more migration mapping item (#47043)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #46464 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng (from Dev Box) <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|
|
3948fcc19d |
[release-notes skill] Use local agent for PR summaries; vendor prepare-release-assets.ps1 (#47651)
## Summary Two related changes to the `release-note-generation` agent skill: ### 1. Step 3 reviews: use the local agent instead of `mcp_github_request_copilot_review` Step 3.1 previously instructed the agent to call `mcp_github_request_copilot_review` for every milestone PR so that the `CopilotSummary` column in `sorted_prs.csv` would be populated by the GitHub-side Copilot bot. When this skill is driven from a CLI / coding agent, that request comes from a bot identity, and the GitHub API rejects it (`Bot reviewers cannot be requested`). The PR ends up with no Copilot review and `CopilotSummary` stays empty. `references/step3-review-grouping.md` has been rewritten to instead have **the local agent** that is running the skill perform the review itself: - Fetch each PR's diff with a non-mutating tool (`mcp_github_pull_request_read` `get_diff` / `get_files`, or `gh pr diff`). - Produce a 1-3 sentence user-facing summary in the same style as a Copilot PR review. - Write the summary directly into the `CopilotSummary` column of `Generated Files/ReleaseNotes/sorted_prs.csv`, preserving row order and skipping rows that already have a non-empty summary. Step 3.2 (re-run `dump-prs-since-commit.ps1`) is demoted to optional, with a note that re-running the dump will overwrite the locally-generated summaries. `SKILL.md` was updated to match: front-matter description, "When to Use", workflow diagram, the 3.1-3.3 row in the summary table, prerequisites (no longer requires "GitHub Copilot code review enabled for the org/repo"; mentions MCP for fetching diffs), and the troubleshooting row for empty `CopilotSummary` now points at Step 3.1 with the bot-rejection caveat. ### 2. Vendor `prepare-release-assets.ps1` into the skill Added `scripts/prepare-release-assets.ps1` -- previously kept in OneDrive at `Tools/prepare-release.ps1`. Renamed because the script does more than download installers: it also pulls per-arch symbol archives, computes SHA256, and emits the **Installer Hashes** markdown table for the GitHub release page. "Release assets" captures all of that. Header `.SYNOPSIS` / `.DESCRIPTION` / `.EXAMPLE` blocks were updated to reflect the new filename and the symbol-archive behavior (the original synopsis only mentioned installers). `SKILL.md` registers the new script in the "Available Scripts" table, lists Azure CLI + the `azure-devops` extension as a prerequisite (only when running this script), adds a "Prepare GitHub release assets" entry to "When to Use", and adds a troubleshooting row for the most common failure (`Failed to acquire ADO access token` -> `az login`). ## Files changed | File | Change | |------|--------| | `.github/skills/release-note-generation/SKILL.md` | Updated description, prerequisites, workflow, scripts table, troubleshooting | | `.github/skills/release-note-generation/references/step3-review-grouping.md` | Rewritten to use local-agent review; demoted refresh step | | `.github/skills/release-note-generation/scripts/prepare-release-assets.ps1` | New (vendored from OneDrive) | ## Validation - PowerShell parser ([`Parser]::ParseFile`) reports no errors on the new script. - Documentation-only / scripts-only change -- no product code touched, so the standard PowerToys build / test gates do not apply. - The change preserves the existing CSV schema (`Id, Title, Labels, Author, Url, Body, CopilotSummary, NeedThanks`), so downstream Step 3.3 (`group-prs-by-label.ps1`) and Step 4 summarization continue to work without modification. --------- Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
|
f8a10550f3 |
Update release notes skill (#47158)
Change the formatting from: "PR description in #123. Thanks @user" to "PR description in #123 by @user" ---- this follows the GitHub release notes format and makes sure people are correctly listed at the bottom of the release page |
||
|
|
7051b8939b |
[Skills] Add WPF to WinUI 3 migration agent skill (#46462)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request With this skills, we can easily enable AI to complete most of the tasks involved in migrating from WPF to WinUI3. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [x] Closes: #46464 <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed --------- Co-authored-by: Yu Leng <yuleng@microsoft.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com> |
||
|
|
eeeb6c0c93 |
feat(winmd-api-search): add WinMD cache generator script and related files (#45606)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Adds a new Copilot agent skill (`winmd-api-search`) that lets AI agents discover and explore Windows desktop APIs by searching a local cache of WinMD metadata. The skill covers Windows Platform SDK, WinAppSDK/WinUI, NuGet package WinMDs, and project-output WinMDs — providing full API surface details (types, members, enumeration values, namespaces) without needing external documentation lookups. **Key components:** - `.github/skills/winmd-api-search/SKILL.md` — Skill definition with usage instructions, search/detail workflows, and scoring guidance - `scripts/Invoke-WinMdQuery.ps1` — PowerShell query engine supporting actions: `search`, `type`, `members`, `enums`, `namespaces`, `stats`, `projects` - `scripts/Update-WinMdCache.ps1` — Orchestrator that builds the C# cache generator, discovers project files, and runs the generator - `scripts/cache-generator/CacheGenerator.csproj` + `Program.cs` — .NET console app using `System.Reflection.Metadata` to parse WinMD files from NuGet packages, project references, Windows SDK, and packages.config into per-package JSON caches - `scripts/cache-generator/Directory.Build.props`, `Directory.Build.targets`, `Directory.Packages.props` — Empty isolation files to prevent repo-level Central Package Management and build targets from interfering with this standalone tool <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- Replace with issue number if applicable --> - [x] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass — N/A: This is an offline agent skill (PowerShell + standalone .NET tool) with no integration into the main product build or runtime. Validated manually by running the cache generator across multiple project contexts (ColorPickerUI, CmdPal.UI, runner, ImageResizer, etc.) and exercising all query actions. - [ ] **Localization:** All end-user-facing strings can be localized — N/A: No end-user-facing strings; this is an internal developer/agent tool - [ ] **Dev docs:** Added/updated — The SKILL.md itself serves as the documentation - [ ] **New binaries:** Added on the required places — N/A: The cache generator is a standalone dev-time tool, not shipped in the installer - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: N/A <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments ### Cache Generator (`Program.cs`, ~1000 lines) A self-contained .NET console app that: 1. **Discovers WinMD sources** from four channels: - `project.assets.json` (PackageReference — modern .csproj/.vcxproj) - `packages.config` (legacy NuGet format) - `<ProjectReference>` bin/ output (class libraries producing `.winmd`) - Windows SDK `UnionMetadata/` (highest installed version) 2. **Parses WinMD files** using `System.Reflection.Metadata` / `PEReader` to extract: - Types (classes, structs, interfaces, enums, delegates) with full namespace - Members (methods with decoded signatures/parameters, properties with accessors, events) - Enum values - Base types and type kinds 3. **Outputs per-package JSON** under `Generated Files/winmd-cache/`: - `packages/<Id>/<Version>/meta.json` — package summary (type/member/namespace counts) - `packages/<Id>/<Version>/namespaces.json` — ordered namespace list - `packages/<Id>/<Version>/types/<Namespace>.json` — full type detail per namespace - `projects/<ProjectName>.json` — maps each project to its package set 4. **Deduplicates** at the package level — if a package+version is already cached, it's skipped on subsequent runs. ### Build Isolation Three empty MSBuild files (`Directory.Build.props`, `Directory.Build.targets`, `Directory.Packages.props`) in the cache-generator folder prevent the repo's Central Package Management and shared build configuration from interfering with this standalone tool. ### Query Engine (`Invoke-WinMdQuery.ps1`) Supports seven actions: `search` (fuzzy text search across types/members), `type` (full detail for a specific type), `members` (filtered members of a type), `enums` (enumeration values), `namespaces` (list all namespaces), `stats` (cache statistics), and `projects` (list cached projects with their packages). <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed 1. **Cache generation:** Ran `Update-WinMdCache.ps1` across 310+ project files in the repo — 8 packages parsed, 316 reused from cache, all completed without errors 2. **Query testing on multiple projects:** - `ColorPickerUI` — verified Windows SDK baseline (7,023 types) - `Microsoft.CmdPal.UI.ViewModels` (after restore) — verified 13 packages, 49,799 types, 112,131 members including WinAppSDK, AdaptiveCards, CsWinRT, Win32Metadata - `runner` (C++ vcxproj) — verified packages.config fallback path - `ImageResizerExt` — verified project reference WinMD discovery 3. **All seven query actions validated:** `stats`, `search`, `namespaces`, `type`, `enums`, `members`, `projects` — all returned correct results 4. **Spell-check compliance:** SKILL.md vocabulary reviewed against repo's check-spelling dictionaries; replaced flagged words with standard alternatives --------- Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com> Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com> |
||
|
|
d28f312b81 |
Copilot Skills: Release note generation skill should also quote co-authors (#45819)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request Release note generation skill add support for quoting co-authors <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: #xxx <!-- - [ ] Closes: #yyy (add separate lines for additional resolved issues) --> - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [ ] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [ ] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [ ] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: #xxx <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Result may vary because of uncertainty of LLM, while I can get this result during my tests <img width="696" height="147" alt="image" src="https://github.com/user-attachments/assets/9d20670f-b9fb-4630-b6b4-f94c2a5d2284" /> |
||
|
|
5422bc31bb |
docs(prompts): Enhance release notes generation and implement GitHub issue tools (#44762)
<!-- Enter a brief description/summary of your PR here. What does it fix/what does it change/how was it tested (even manually, if necessary)? --> ## Summary of the Pull Request This update improves the release notes generation process by restructuring documentation for clarity and enhancing workflows. It introduces new tools for handling GitHub issue images and attachments, along with automated tests to ensure functionality. <!-- Please review the items on the PR checklist before submitting--> ## PR Checklist - [ ] Closes: N/A - [ ] **Communication:** I've discussed this with core contributors already. If the work hasn't been agreed, this work might be rejected - [x] **Tests:** Added/updated and all pass - [ ] **Localization:** All end-user-facing strings can be localized - [x] **Dev docs:** Added/updated - [ ] **New binaries:** Added on the required places - [ ] [JSON for signing](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ESRPSigning_core.json) for new binaries - [ ] [WXS for installer](https://github.com/microsoft/PowerToys/blob/main/installer/PowerToysSetup/Product.wxs) for new binaries and localization folder - [ ] [YML for CI pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/ci/templates/build-powertoys-steps.yml) for new test projects - [ ] [YML for signed pipeline](https://github.com/microsoft/PowerToys/blob/main/.pipelines/release.yml) - [x] **Documentation updated:** If checked, please file a pull request on [our docs repo](https://github.com/MicrosoftDocs/windows-uwp/tree/docs/hub/powertoys) and link it here: N/A <!-- Provide a more detailed description of the PR, other things fixed, or any additional comments/features here --> ## Detailed Description of the Pull Request / Additional comments The changes include updates to the release notes summarization process and workflow documentation for better clarity. New scripts for managing PR diffs, grouping, and milestone assignments have been added. Additionally, tools for downloading images and attachments from GitHub issues have been implemented, ensuring a more streamlined process. <!-- Describe how you validated the behavior. Add automated tests wherever possible, but list manual validation steps taken as well --> ## Validation Steps Performed Automated tests were added for the new GitHub issue tools, and all tests passed successfully. Manual validation included testing the new workflows and ensuring the documentation accurately reflects the changes made. ``` |