Publish PRs for Source-Build Test Results

[ellahathaway]

Closes https://github.com/dotnet/source-build/issues/4093

This PR introduces changes that allow the SDK diff and License scan pipelines to publish PRs updating the artifacts (exclusions and baselines) upon completion of pipeline runs for main, internal/release, and release branches.

SDK diff test sample PR: https://github.com/maestro-auth-test/private-installer/pull/208 License scan sample PR: https://github.com/maestro-auth-test/private-installer/pull/209

[MichaelSimons]

Raising the question on the choice of utilizing scripting to implement the core logic. We are making decisions/investments elsewhere to prefer c# logic (e.g. the SB release pipeline) because of the lower cost of maintenance, better testability, and cross platform friendly. What would a c# implementation look like here?

[ellahathaway]

Raising the question on the choice of utilizing scripting to implement the core logic. We are making decisions/investments elsewhere to prefer c# logic (e.g. the SB release pipeline) because of the lower cost of maintenance, better testability, and cross platform friendly. What would a c# implementation look like here?

While I think a c# implementation would be helpful here for parsing the updated files, it adds extra overhead when trying to create/edit the PR. That is, the script relies heavily on the GitHub CLI and git, and I don't feel that adding the overhead of a c# implementation with a process manager for all the gh and git commands is a better alternative to calling those commands directly in a script.

[MichaelSimons]

While I think a c# implementation would be helpful here for parsing the updated files, it adds extra overhead when trying to create/edit the PR. That is, the script relies heavily on the GitHub CLI and git, and I don't feel that adding the overhead of a c# implementation with a process manager for all the gh and git commands is a better alternative to calling those commands directly in a script.

There are C# libraries for interacting with github and git that should be used instead of utilizing the CLIs.

[MichaelSimons]

e.g. https://github.com/octokit/octokit.net

[ellahathaway]

e.g. https://github.com/octokit/octokit.net

I see. The c# implementation would be much simpler with this library.

We are making decisions/investments elsewhere to prefer c# logic (e.g. the SB release pipeline) because of the lower cost of maintenance, better testability, and cross platform friendly

Is there a tracking issue for using more c# logic in the release pipeline? From what I can tell, the SB release pipeline still utilizes a script for the publishing the release PR (internal Microsoft link).

That said, if the general goal is to use more c# logic for the benefits you describe, then I can see why we'd want to implement this logic in c#.

[ellahathaway]

Given potential time constraints, I've updated this PR with the scripting changes in favor of having this PR ready with scripting changes vs not ready with c# changes. If we decide to go the c# route, I can either continue to develop this PR with those changes, or we can merge this PR with the scripting changes (once ready) and return to the c# implementation later. I an open to either option.

[MichaelSimons]

Is there a tracking issue for using more c# logic in the release pipeline?

https://github.com/dotnet/arcade-services/issues/2673

This is being done incrementally. New logic is being implemented in c# now - see the "Build Release CLI" step.

[MichaelSimons]

A logical place for this logic is in eng/tools next to the BinaryToolKit.

[ellahathaway]

Sounds good, I'll begin working on the c# implementation.

[ellahathaway]

Closing in favor of https://github.com/dotnet/sdk/pull/40753