From 1d65ab154e35ed923fc7f7ce1e02e4bdf9f2c388 Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Wed, 28 Aug 2024 13:03:07 -0700 Subject: [PATCH 01/12] first draft for auto-approval specification --- doc/spec/auto-approve.md | 62 +++++++++++++++++++++++++++++++++++++++ doc/spec/spec-template.md | 60 +++++++++++++++++++++++++++++++++++++ 2 files changed, 122 insertions(+) create mode 100644 doc/spec/auto-approve.md create mode 100644 doc/spec/spec-template.md diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md new file mode 100644 index 0000000000000..f3b2ffd044281 --- /dev/null +++ b/doc/spec/auto-approve.md @@ -0,0 +1,62 @@ +--- +author: / +created on: +last updated: +issue id: +--- + +# Spec Title + +[comment]: # Link to issue: "For [#1](https://github.com/microsoft/winget-pkgs/issues/1)" + +## Abstract + +[comment]: # Outline what this spec describes +This specification defines criteria for auto-approval of PRs for a subset of packages in an allow list. These auto-approvals will be limited to packages in the allow list only when a limited set of properties have been modified. These would include package version, and package URL (filtered by logic for installer URLs on the same domain and path). + +## Inspiration + +[comment]: # What were the drivers/inspiration behind the creation of this spec. +Several packages have rich metadata and when new versions are added, the only changes are the installer portion of the URL and the package version. + +## Solution Design + +[comment]: # Outline the design of the solution. Feel free to include ASCII-art diagrams, etc. + +## UI/UX Design + +[comment]: # What will this fix/feature look like? How will it affect the end user? + +## Capabilities + +[comment]: # Discuss how the proposed fixes/features impact the following key considerations: + +### Accessibility + +[comment]: # How will the proposed change impact accessibility for users of screen readers, assistive input devices, etc. + +### Security + +[comment]: # How will the proposed change impact security? + +### Reliability + +[comment]: # Will the proposed change improve reliability? If not, why make the change? + +### Compatibility + +[comment]: # Will the proposed change break existing code/behaviors? If so, how, and is the breaking change "worth it"? + +### Performance, Power, and Efficiency + +## Potential Issues + +[comment]: # What are some of the things that might cause problems with the fixes/features proposed? Consider how the user might be negatively impacted. + +## Future considerations + +[comment]: # What are some of the things that the fixes/features might unlock in the future? Does the implementation of this spec enable scenarios? + +## Resources + +[comment]: # Be sure to add links to references, resources, footnotes, etc. \ No newline at end of file diff --git a/doc/spec/spec-template.md b/doc/spec/spec-template.md new file mode 100644 index 0000000000000..fbaa50981b040 --- /dev/null +++ b/doc/spec/spec-template.md @@ -0,0 +1,60 @@ +--- +author: / +created on: +last updated: +issue id: +--- + +# Spec Title + +[comment]: # Link to issue: "For [#1](https://github.com/microsoft/winget-pkgs/issues/1)" + +## Abstract + +[comment]: # Outline what this spec describes + +## Inspiration + +[comment]: # What were the drivers/inspiration behind the creation of this spec. + +## Solution Design + +[comment]: # Outline the design of the solution. Feel free to include ASCII-art diagrams, etc. + +## UI/UX Design + +[comment]: # What will this fix/feature look like? How will it affect the end user? + +## Capabilities + +[comment]: # Discuss how the proposed fixes/features impact the following key considerations: + +### Accessibility + +[comment]: # How will the proposed change impact accessibility for users of screen readers, assistive input devices, etc. + +### Security + +[comment]: # How will the proposed change impact security? + +### Reliability + +[comment]: # Will the proposed change improve reliability? If not, why make the change? + +### Compatibility + +[comment]: # Will the proposed change break existing code/behaviors? If so, how, and is the breaking change "worth it"? + +### Performance, Power, and Efficiency + +## Potential Issues + +[comment]: # What are some of the things that might cause problems with the fixes/features proposed? Consider how the user might be negatively impacted. + +## Future considerations + +[comment]: # What are some of the things that the fixes/features might unlock in the future? Does the implementation of this spec enable scenarios? + +## Resources + +[comment]: # Be sure to add links to references, resources, footnotes, etc. \ No newline at end of file From a3b9b1cc1ecaff05773e4704eeb196ad0b44339f Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Wed, 28 Aug 2024 13:44:16 -0700 Subject: [PATCH 02/12] include hash --- doc/spec/auto-approve.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index f3b2ffd044281..c819a20be7872 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -12,12 +12,12 @@ issue id: ## Abstract [comment]: # Outline what this spec describes -This specification defines criteria for auto-approval of PRs for a subset of packages in an allow list. These auto-approvals will be limited to packages in the allow list only when a limited set of properties have been modified. These would include package version, and package URL (filtered by logic for installer URLs on the same domain and path). +This specification defines criteria for auto-approval of PRs for a subset of packages in an allow list. These auto-approvals will be limited to packages in the allow list only when a limited set of properties have been modified. These would include package version, package URL (filtered by logic for installer URLs on the same domain and path), and the Installer SHA256. ## Inspiration [comment]: # What were the drivers/inspiration behind the creation of this spec. -Several packages have rich metadata and when new versions are added, the only changes are the installer portion of the URL and the package version. +Several packages have rich metadata and when new versions are added, the only changes are the installer portion of the URL, the Installer SHA256 the package version. ## Solution Design @@ -59,4 +59,4 @@ Several packages have rich metadata and when new versions are added, the only ch ## Resources -[comment]: # Be sure to add links to references, resources, footnotes, etc. \ No newline at end of file +[comment]: # Be sure to add links to references, resources, footnotes, etc. From 10427c0cdb3eab90d1b5218c6fd5c5e42315db08 Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Wed, 28 Aug 2024 13:47:13 -0700 Subject: [PATCH 03/12] fields and clarity --- doc/spec/auto-approve.md | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index c819a20be7872..5fff4b1eb1530 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -12,12 +12,16 @@ issue id: ## Abstract [comment]: # Outline what this spec describes -This specification defines criteria for auto-approval of PRs for a subset of packages in an allow list. These auto-approvals will be limited to packages in the allow list only when a limited set of properties have been modified. These would include package version, package URL (filtered by logic for installer URLs on the same domain and path), and the Installer SHA256. +This specification defines criteria for auto-approval of PRs for a subset of packages in an allow list. These auto-approvals will be limited to packages in the allow list only when a limited set of properties have been modified. These would include: +* Package version +* Package URL (filtered by logic for installer URLs on the same domain and path) +* Installer SHA256 +* Product Code ## Inspiration [comment]: # What were the drivers/inspiration behind the creation of this spec. -Several packages have rich metadata and when new versions are added, the only changes are the installer portion of the URL, the Installer SHA256 the package version. +Several packages have rich metadata and when new versions are added, the only changes are the installer metadata and other fields necessary to support the new version. Descriptive fields and other optional values require manual review. ## Solution Design From c0e31578c00e95a5a57ba2fce77f09904f25ccb4 Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Wed, 28 Aug 2024 13:48:58 -0700 Subject: [PATCH 04/12] apps and features --- doc/spec/auto-approve.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index 5fff4b1eb1530..dc90d55b688c2 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -18,6 +18,9 @@ This specification defines criteria for auto-approval of PRs for a subset of pac * Installer SHA256 * Product Code +Package Version should be an exact match to the values written in the registry for Apps & Features data. +Other Apps And Features entries should also be an exact match. + ## Inspiration [comment]: # What were the drivers/inspiration behind the creation of this spec. From dd5b04b5d81c4a0babab8c34ed6a28cf62c65c18 Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Wed, 28 Aug 2024 13:57:47 -0700 Subject: [PATCH 05/12] first pass at solution design --- doc/spec/auto-approve.md | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index dc90d55b688c2..d7b2354138887 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -11,7 +11,6 @@ issue id: ## Abstract -[comment]: # Outline what this spec describes This specification defines criteria for auto-approval of PRs for a subset of packages in an allow list. These auto-approvals will be limited to packages in the allow list only when a limited set of properties have been modified. These would include: * Package version * Package URL (filtered by logic for installer URLs on the same domain and path) @@ -23,12 +22,18 @@ Other Apps And Features entries should also be an exact match. ## Inspiration -[comment]: # What were the drivers/inspiration behind the creation of this spec. -Several packages have rich metadata and when new versions are added, the only changes are the installer metadata and other fields necessary to support the new version. Descriptive fields and other optional values require manual review. +Manual review takes time, and for a subset of packages with rich metadata and only installer/version level metadata is changed. Automation can identify when specific criteria are met, and eliminate the toil of a manual review. This can also reduce the time from when a PR is submitted and it gets approved. This is especially helpful on weekends/holidays and when PRs would normally sit open until the next business day for review. ## Solution Design -[comment]: # Outline the design of the solution. Feel free to include ASCII-art diagrams, etc. +This would be implemented in the Vaidation pipelines. + +### Automated Identification +Evaluate the version for a package to be added. If the version is newer than the latest version of a package in the repository identify which fields have been changed, added, or removed from the previous version. + +### Allow List Management +Two moderators are required to add a package to the allow list. +One moderator can remove a package from the allow list. ## UI/UX Design @@ -62,7 +67,7 @@ Several packages have rich metadata and when new versions are added, the only ch ## Future considerations -[comment]: # What are some of the things that the fixes/features might unlock in the future? Does the implementation of this spec enable scenarios? +The verified publisher feature may require mutual exclusion or modification with this feature. ## Resources From bb9301a0bb2c39dd628ca546a6820220cd886a13 Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Wed, 28 Aug 2024 14:04:22 -0700 Subject: [PATCH 06/12] Update auto-approve.md --- doc/spec/auto-approve.md | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index d7b2354138887..9f613c3b18aab 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -5,7 +5,7 @@ last updated: issue id: --- -# Spec Title +# Auto approve new package versions in an allow list [comment]: # Link to issue: "For [#1](https://github.com/microsoft/winget-pkgs/issues/1)" @@ -37,7 +37,8 @@ One moderator can remove a package from the allow list. ## UI/UX Design -[comment]: # What will this fix/feature look like? How will it affect the end user? +PRs for new package versions of packages in the allow list will not require manual review if specific criteria are met. +One of the bots will comment on PRs for these packages if criteria are met for auto-approval. If criteria are not met for auto-approval, the bot will comment with the fields that prevent auto-approval for PRs against packages in the allow list. ## Capabilities @@ -45,7 +46,7 @@ One moderator can remove a package from the allow list. ### Accessibility -[comment]: # How will the proposed change impact accessibility for users of screen readers, assistive input devices, etc. +No impact expected ### Security @@ -57,10 +58,12 @@ One moderator can remove a package from the allow list. ### Compatibility -[comment]: # Will the proposed change break existing code/behaviors? If so, how, and is the breaking change "worth it"? +No breaking changes are anticipated. ### Performance, Power, and Efficiency +The average time between PR submission and subsequent approval will be reduced on average. + ## Potential Issues [comment]: # What are some of the things that might cause problems with the fixes/features proposed? Consider how the user might be negatively impacted. From 541ab80042798b6b099ca07607d26ccf57fcdd29 Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Wed, 28 Aug 2024 14:09:41 -0700 Subject: [PATCH 07/12] add good example --- doc/spec/auto-approve.md | 3 +++ 1 file changed, 3 insertions(+) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index 9f613c3b18aab..0b91386e3d869 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -28,6 +28,9 @@ Manual review takes time, and for a subset of packages with rich metadata and on This would be implemented in the Vaidation pipelines. +Good example PRs: +* https://github.com/microsoft/winget-pkgs/pull/170290/files + ### Automated Identification Evaluate the version for a package to be added. If the version is newer than the latest version of a package in the repository identify which fields have been changed, added, or removed from the previous version. From 65a6e5d99720a2affadd7bd9cb3ac16a85d6a924 Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Wed, 28 Aug 2024 14:12:53 -0700 Subject: [PATCH 08/12] spelling --- doc/spec/auto-approve.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index 0b91386e3d869..c39fa55fde43c 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -26,7 +26,7 @@ Manual review takes time, and for a subset of packages with rich metadata and on ## Solution Design -This would be implemented in the Vaidation pipelines. +This would be implemented in the Validation pipelines. Good example PRs: * https://github.com/microsoft/winget-pkgs/pull/170290/files From 0d6ce3cac3fd5aac69822745ac94a89c3480f1ca Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Wed, 28 Aug 2024 14:45:19 -0700 Subject: [PATCH 09/12] another example --- doc/spec/auto-approve.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index c39fa55fde43c..33a6315af029f 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -29,7 +29,9 @@ Manual review takes time, and for a subset of packages with rich metadata and on This would be implemented in the Validation pipelines. Good example PRs: +TODO: explain what's going to work or not for each... * https://github.com/microsoft/winget-pkgs/pull/170290/files +* https://github.com/microsoft/winget-pkgs/pull/170388/files ### Automated Identification Evaluate the version for a package to be added. If the version is newer than the latest version of a package in the repository identify which fields have been changed, added, or removed from the previous version. From db3db866ed0671d57c3dab7fc6a92790bf6c7a8b Mon Sep 17 00:00:00 2001 From: Demitrius Nelon Date: Thu, 29 Aug 2024 10:31:04 -0700 Subject: [PATCH 10/12] more fields filled in --- doc/spec/auto-approve.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index 33a6315af029f..caa90002c951c 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -47,7 +47,7 @@ One of the bots will comment on PRs for these packages if criteria are met for a ## Capabilities -[comment]: # Discuss how the proposed fixes/features impact the following key considerations: +This feature enables the validation pipelines to determine if a PR is suitable for merge without manual review. ### Accessibility @@ -55,11 +55,11 @@ No impact expected ### Security -[comment]: # How will the proposed change impact security? +None of the current security controls are expected to be impacted. All security checks associated with the manifest and the package installer will still be in place. ### Reliability -[comment]: # Will the proposed change improve reliability? If not, why make the change? +Reliability is not expected to be impacted in a negative way. By decreasing the average time between a valid PR submission and subsequent approval for merge should decrease. This should increase the reliability of the WinGet user experience by making the latest versions of packages submitted by PR available sooner for customers. ### Compatibility @@ -71,7 +71,7 @@ The average time between PR submission and subsequent approval will be reduced o ## Potential Issues -[comment]: # What are some of the things that might cause problems with the fixes/features proposed? Consider how the user might be negatively impacted. +It's possible users may forgo updates to description, release notes, and other optional metadata in order to get a package merged in more quickly. This could lead to additional PRs to update the metadata after the fact which could get forgotten or delayed. ## Future considerations From 59e81da0279f1b04b01ec988c85cdfa33aa4f046 Mon Sep 17 00:00:00 2001 From: Muhammad Danish <88161975+mdanish-kh@users.noreply.github.com> Date: Fri, 30 Aug 2024 21:17:55 +0500 Subject: [PATCH 11/12] markdown lint --- doc/spec/auto-approve.md | 168 ++++++++++++++++++++------------------- 1 file changed, 86 insertions(+), 82 deletions(-) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index caa90002c951c..bc2ed24351836 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -1,82 +1,86 @@ ---- -author: / -created on: -last updated: -issue id: ---- - -# Auto approve new package versions in an allow list - -[comment]: # Link to issue: "For [#1](https://github.com/microsoft/winget-pkgs/issues/1)" - -## Abstract - -This specification defines criteria for auto-approval of PRs for a subset of packages in an allow list. These auto-approvals will be limited to packages in the allow list only when a limited set of properties have been modified. These would include: -* Package version -* Package URL (filtered by logic for installer URLs on the same domain and path) -* Installer SHA256 -* Product Code - -Package Version should be an exact match to the values written in the registry for Apps & Features data. -Other Apps And Features entries should also be an exact match. - -## Inspiration - -Manual review takes time, and for a subset of packages with rich metadata and only installer/version level metadata is changed. Automation can identify when specific criteria are met, and eliminate the toil of a manual review. This can also reduce the time from when a PR is submitted and it gets approved. This is especially helpful on weekends/holidays and when PRs would normally sit open until the next business day for review. - -## Solution Design - -This would be implemented in the Validation pipelines. - -Good example PRs: -TODO: explain what's going to work or not for each... -* https://github.com/microsoft/winget-pkgs/pull/170290/files -* https://github.com/microsoft/winget-pkgs/pull/170388/files - -### Automated Identification -Evaluate the version for a package to be added. If the version is newer than the latest version of a package in the repository identify which fields have been changed, added, or removed from the previous version. - -### Allow List Management -Two moderators are required to add a package to the allow list. -One moderator can remove a package from the allow list. - -## UI/UX Design - -PRs for new package versions of packages in the allow list will not require manual review if specific criteria are met. -One of the bots will comment on PRs for these packages if criteria are met for auto-approval. If criteria are not met for auto-approval, the bot will comment with the fields that prevent auto-approval for PRs against packages in the allow list. - -## Capabilities - -This feature enables the validation pipelines to determine if a PR is suitable for merge without manual review. - -### Accessibility - -No impact expected - -### Security - -None of the current security controls are expected to be impacted. All security checks associated with the manifest and the package installer will still be in place. - -### Reliability - -Reliability is not expected to be impacted in a negative way. By decreasing the average time between a valid PR submission and subsequent approval for merge should decrease. This should increase the reliability of the WinGet user experience by making the latest versions of packages submitted by PR available sooner for customers. - -### Compatibility - -No breaking changes are anticipated. - -### Performance, Power, and Efficiency - -The average time between PR submission and subsequent approval will be reduced on average. - -## Potential Issues - -It's possible users may forgo updates to description, release notes, and other optional metadata in order to get a package merged in more quickly. This could lead to additional PRs to update the metadata after the fact which could get forgotten or delayed. - -## Future considerations - -The verified publisher feature may require mutual exclusion or modification with this feature. - -## Resources - -[comment]: # Be sure to add links to references, resources, footnotes, etc. +--- +author: / +created on: +last updated: +issue id: +--- + +# Auto approve new package versions in an allow list + +[comment]: # Link to issue: "For [#1](https://github.com/microsoft/winget-pkgs/issues/1)" + +## Abstract + +This specification defines criteria for auto-approval of PRs for a subset of packages in an allow list. These auto-approvals will be limited to packages in the allow list only when a limited set of properties have been modified. These would include: + +* Package version +* Package URL (filtered by logic for installer URLs on the same domain and path) +* Installer SHA256 +* Product Code + +Package Version should be an exact match to the values written in the registry for Apps & Features data. +Other Apps And Features entries should also be an exact match. + +## Inspiration + +Manual review takes time, and for a subset of packages with rich metadata and only installer/version level metadata is changed. Automation can identify when specific criteria are met, and eliminate the toil of a manual review. This can also reduce the time from when a PR is submitted and it gets approved. This is especially helpful on weekends/holidays and when PRs would normally sit open until the next business day for review. + +## Solution Design + +This would be implemented in the Validation pipelines. + +Good example PRs: +TODO: explain what's going to work or not for each... + +* https://github.com/microsoft/winget-pkgs/pull/170290/files +* https://github.com/microsoft/winget-pkgs/pull/170388/files + +### Automated Identification + +Evaluate the version for a package to be added. If the version is newer than the latest version of a package in the repository identify which fields have been changed, added, or removed from the previous version. + +### Allow List Management + +Two moderators are required to add a package to the allow list. +One moderator can remove a package from the allow list. + +## UI/UX Design + +PRs for new package versions of packages in the allow list will not require manual review if specific criteria are met. +One of the bots will comment on PRs for these packages if criteria are met for auto-approval. If criteria are not met for auto-approval, the bot will comment with the fields that prevent auto-approval for PRs against packages in the allow list. + +## Capabilities + +This feature enables the validation pipelines to determine if a PR is suitable for merge without manual review. + +### Accessibility + +No impact expected + +### Security + +None of the current security controls are expected to be impacted. All security checks associated with the manifest and the package installer will still be in place. + +### Reliability + +Reliability is not expected to be impacted in a negative way. By decreasing the average time between a valid PR submission and subsequent approval for merge should decrease. This should increase the reliability of the WinGet user experience by making the latest versions of packages submitted by PR available sooner for customers. + +### Compatibility + +No breaking changes are anticipated. + +### Performance, Power, and Efficiency + +The average time between PR submission and subsequent approval will be reduced on average. + +## Potential Issues + +It's possible users may forgo updates to description, release notes, and other optional metadata in order to get a package merged in more quickly. This could lead to additional PRs to update the metadata after the fact which could get forgotten or delayed. + +## Future considerations + +The verified publisher feature may require mutual exclusion or modification with this feature. + +## Resources + +[comment]: # Be sure to add links to references, resources, footnotes, etc. From 1be85ae2f6cbba49b6a385755de73e20590cf75a Mon Sep 17 00:00:00 2001 From: Muhammad Danish <88161975+mdanish-kh@users.noreply.github.com> Date: Mon, 2 Sep 2024 00:51:03 +0500 Subject: [PATCH 12/12] Draft 02/09 --- doc/spec/auto-approve.md | 30 +++++++++++++++++------------- 1 file changed, 17 insertions(+), 13 deletions(-) diff --git a/doc/spec/auto-approve.md b/doc/spec/auto-approve.md index bc2ed24351836..d52e0b15a21e1 100644 --- a/doc/spec/auto-approve.md +++ b/doc/spec/auto-approve.md @@ -13,13 +13,12 @@ issue id: This specification defines criteria for auto-approval of PRs for a subset of packages in an allow list. These auto-approvals will be limited to packages in the allow list only when a limited set of properties have been modified. These would include: -* Package version -* Package URL (filtered by logic for installer URLs on the same domain and path) -* Installer SHA256 -* Product Code - -Package Version should be an exact match to the values written in the registry for Apps & Features data. -Other Apps And Features entries should also be an exact match. +* PackageVersion +* InstallerUrl (filtered by logic for installer URLs on the same domain and path) +* InstallerSha256 +* ProductCode +* ReleaseDate +* ReleaseNotesUrl (filtered by logic for URLs on the same domain and path) ## Inspiration @@ -27,13 +26,17 @@ Manual review takes time, and for a subset of packages with rich metadata and on ## Solution Design -This would be implemented in the Validation pipelines. +This would be implemented in the validation pipelines. If all existing manifest validation checks succeed, the pipeline would check if the package is in the allow list. If it is, the pipeline would check if the PR meets the criteria for auto-approval. PRs meeting the criteria would be automatically approved and merged. + +Example PRs that would be auto-approved: -Good example PRs: -TODO: explain what's going to work or not for each... +1. [#170290](https://github.com/microsoft/winget-pkgs/pull/170290/files) + * Update to an existing version manifest ✅ + * Updated fields are: PackageVersion, InstallerSha256, ProductCode ✅ -* https://github.com/microsoft/winget-pkgs/pull/170290/files -* https://github.com/microsoft/winget-pkgs/pull/170388/files +2. [#170388](https://github.com/microsoft/winget-pkgs/pull/170388/files) + * New version manifest of an existing PackageIdentifier ✅ + * Updated fields from previous manifest are: PackageVersion, InstallerUrl, InstallerSha256, ReleaseDate, ReleaseNotesUrl ✅ ### Automated Identification @@ -79,7 +82,8 @@ It's possible users may forgo updates to description, release notes, and other o ## Future considerations -The verified publisher feature may require mutual exclusion or modification with this feature. +* The verified publisher feature may require mutual exclusion or modification with this feature. +* For extending allow list to a larger set of packages, validation pipelines would require updates to match ARP manifest fields against their exact registry values. ## Resources