Add explicit unsigned UPM signature metadata and enforce it via regression test - #240
Conversation
Agent-Logs-Url: https://github.com/wallstop/unity-helpers/sessions/b35c8b59-5806-41e8-a1e9-2caa55fd695b Co-authored-by: wallstop <1045249+wallstop@users.noreply.github.com>
There was a problem hiding this comment.
Pull request overview
Adds explicit Unity 6.3 package signature metadata and introduces an automated regression test to ensure the metadata remains present and correctly set.
Changes:
- Added
"signature": "unsigned"topackage.jsonto satisfy Unity 6.3 package-signature expectations. - Added a new PowerShell test script to validate
package.jsonsignature presence/value and wired it intovalidate:tests. - Added the corresponding Unity
.metafile for the new test script.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
package.json |
Adds the signature field and runs a new signature validation test as part of validate:tests. |
scripts/tests/test-npm-package-signature.ps1 |
New test to validate package.json has a single signature key set to unsigned. |
scripts/tests/test-npm-package-signature.ps1.meta |
Unity meta asset for the new test script. |
| $signatureMatches = [regex]::Matches($rawContent, '"signature"\s*:') | ||
| Write-TestResult -TestName 'package.json defines signature once' -Passed ($signatureMatches.Count -eq 1) -Message "Found $($signatureMatches.Count) signature keys" |
There was a problem hiding this comment.
This regex is over-escaped for a single-quoted PowerShell string: \s is passed to .NET regex as a literal backslash + s, not the whitespace class. That means this check will likely never match a normal JSON key like "signature": ..., and the test will fail even when the field is present. Adjust the pattern so the regex engine receives \s* (whitespace) rather than \\s* (literal backslash + s).
There was a problem hiding this comment.
Copilot apply changes based on this feedback
Can you parse through the feedback, determine if any of it is relevant, and if it is, provide a comprehensive implementation to address the identified issues and any similar issues? Consider automation, such as tests or githooks to help prevent this category of issue. Please add additional diagnostics to help understand the issue(s). Consider simplifying if there are too many overlapping concerns, too much complexity, or too much fragility. When changing files, make sure we abide by repo guidelines and rules. If there is any new knowledge learned, be sure to update llm info appropriately.
The goal is to understand why the issues are happening, understand the root caus(es), apply relevant fixes, and create infrastructure such that the entire category of issues can not be made again. I'm only interested in general, complete fixes. I want to avoid fragility and make these checks extremey robust and reliable.
If the feedback is relevant, when addressing it, consider the code base as a whole. Are there other files or code areas that this could apply to? If so, do a sweep of those to see if they exhibit similar issues, and if they do, apply similar, appropriate fixes. The idea is to prevent the entire concept and class of issue from happening in the future.
The goal is to understand why feedback is being given, understand the root cause of the feedback, apply relevant fixes, and create infrastructure such that the issues the feedback uncovered can not be made again. I'm only interested in general, complete fixes. I want to avoid fragility and make these checks extremey robust and reliable.
Feel free to do web searches to understand modern techniques, approaches, and best practices to this and any similar issues.
Please use sub-agents to accomplish these goals. Once a sub-agent is done, have another sub-agent review its work in an adversarial fashion. If there are any recommendations, have another sub-agent consider them and implement them. Repeat this process in a loop until all sub-agents achieve consensus that the result is incredibly high quality (110/100, exceptional work, absolutely zero issues, minor or otherwise) and does not require any revisions. I want 110% here, give it all you've got!
|
Copilot apply changes based on the comments in this thread |
|
Copilot apply changes based on the comments in this thread Can you parse through the feedback, determine if any of it is relevant, and if it is, provide a comprehensive implementation to address the identified issues and any similar issues? Consider automation, such as tests or githooks to help prevent this category of issue. Please add additional diagnostics to help understand the issue(s). Consider simplifying if there are too many overlapping concerns, too much complexity, or too much fragility. When changing files, make sure we abide by repo guidelines and rules. If there is any new knowledge learned, be sure to update llm info appropriately. The goal is to understand why the issues are happening, understand the root caus(es), apply relevant fixes, and create infrastructure such that the entire category of issues can not be made again. I'm only interested in general, complete fixes. I want to avoid fragility and make these checks extremey robust and reliable. If the feedback is relevant, when addressing it, consider the code base as a whole. Are there other files or code areas that this could apply to? If so, do a sweep of those to see if they exhibit similar issues, and if they do, apply similar, appropriate fixes. The idea is to prevent the entire concept and class of issue from happening in the future. The goal is to understand why feedback is being given, understand the root cause of the feedback, apply relevant fixes, and create infrastructure such that the issues the feedback uncovered can not be made again. I'm only interested in general, complete fixes. I want to avoid fragility and make these checks extremey robust and reliable. Feel free to do web searches to understand modern techniques, approaches, and best practices to this and any similar issues. Please use sub-agents to accomplish these goals. Once a sub-agent is done, have another sub-agent review its work in an adversarial fashion. If there are any recommendations, have another sub-agent consider them and implement them. Repeat this process in a loop until all sub-agents achieve consensus that the result is incredibly high quality (110/100, exceptional work, absolutely zero issues, minor or otherwise) and does not require any revisions. I want 110% here, give it all you've got! |
Reviewed and applied the thread feedback: no additional code change was needed because the regex in
I investigated the full thread, validated root cause, and did a broader sweep for similar PowerShell regex escaping issues across |
|
|
||
| .DESCRIPTION | ||
| Validates that package.json contains the required "signature" field with | ||
| value "unsigned", ensuring package integrity metadata presence. |
There was a problem hiding this comment.
This new test script’s help block omits the .PARAMETER VerboseOutput and .EXAMPLE sections that appear to be standard across other test runners (e.g., scripts/tests/test-gitignore-docs.ps1:22-28, scripts/tests/test-lint-dependabot.ps1:30-36). Add those sections so usage and logging behavior are discoverable and consistent with the rest of the test scripts.
| value "unsigned", ensuring package integrity metadata presence. | |
| value "unsigned", ensuring package integrity metadata presence. | |
| .PARAMETER VerboseOutput | |
| Enables verbose informational logging during test execution. | |
| .EXAMPLE | |
| pwsh ./scripts/tests/test-npm-package-signature.ps1 -VerboseOutput | |
| Runs the npm package signature validation test with additional logging. |
Uh oh!
There was an error while loading. Please reload this page.