Closed jmarolf closed 7 months ago
@jmarolf - this seems like general goodness. Could you explain a bit more who would look at the results? Is this the kind of thing where Arcade folks should run the tool as a way to keep things clean?
@markwilkie the idea would be that we install this analyzer in the dotnet/arcade repo and work to clean up all warnings. At some point I think we should fail the build if a PR introduces new issues.
Makes sense. Adding to our post //build backlog.
@markwilkie what's the reason behind moving this to a release related epic when the work is to fix PS scripts that reported warnings?
I think the focus here is on running the (cleaned up) scripts. Instead of adding these to the build, it seems better to add them along side the other "checkers" we're running already in the release pipeline.
At some point I think we should fail the build if a PR introduces new issues.
@markwilkie I think this would make more sense as a PR check thing. Looks like @jmarolf has the same point of view.
/cc @chcosta
Perhaps - but keeping PR's fast is important.
Yeah, I would rather fail fast (PR) rather than realize there is a script warning blocking my packages to be published
@markwilkie the idea would be that we install this analyzer in the dotnet/arcade repo and work to clean up all warnings. At some point I think we should fail the build if a PR introduces new issues.
IMO the best place to run this would be in PR builds.. nevertheless, I like the idea proposed by @jmarolf
I'm thinking to move forward with this by adding a new validation job to the post-build
Arcade templates that don't fail the build but just show a warning in case of validation errors. Once people become more aware of the issues we can work to move these checks to PR time. Makes sense?
@jcagme - adding this to evaluate for the validation ring.
As I understand, the suggestion is to use the script analyzer on PS scripts on arcade. If my reading is correct, we cannot do this in the validation ring since by then we are only working with shippable assets (PS are not included) produced by builds on the longest path, arcade doesn't fall in this category. In order to activate this in arcade, we'd need to add a build step, most likely on PR builds so we know when scripts are not correct and/or run this every so often, but again, not as part of the release.
Now with the addition of source code validation this is something we could check but Arcade is not part of the candidate build. I feel this is something we could add to PRs or CI better.
Triage: Should Arcade be included in the validation?
PSScriptAnalyzer is now being injected via 1ES PT. Closing.
We should run PSScriptAnalyzer on this repo as a way to get some basic ci for the powershell changes that we are making.
CC: @jaredpar @tmat
Running this command
over the arcade repo produced these results: