[Exanite]

Summary of the PR

This PR contains the first half of the changes related to implementing a PR comment-based native/bindings workflow. Specifically, this expands the PowerShell scripts to handle command parsing, job matrix generation, dependency calculation, and reminder comment generation. It also includes a workflow that triggers on pull_request synchronize that checks the PR for changes to native builds or bindings and posts a reminder comment whenever the PR makes changes that might affect them.

• I confirm that I am the author of this code and release it to the Silk.NET project under the MIT license. This contribution does not contain code from other sources, including code generated by a Large Language Model ("AI").

Related issues, Discord discussions, or proposals

This should be merged before the second half of this PR: #2634

Further Comments

Testing Fork

This PR was tested in my fork here:
Exanite-Dev#5
Exanite-Dev#3
Exanite-Dev#2

Tasks

Copied from elsewhere

Native/bindings regeneration workflows (from tracker):

• Prevent native builds from triggering unnecessarily when the PR description is edited
  • Native builds should only trigger once. If the last commit in the PR is from the native builds workflow, it should not run again.
  • Old task: Not really relevant with this new implementation. This made more sense with the pull_request trigger
• Figure out how to make our CI workflows work with forks.
  • I did some testing here and got a proof-of-concept working: https://github.com/Exanite-Dev/GithubActionTesting
  • Note that we need to be careful about security here. This involves escalation of privileges.

Native/bindings regeneration workflows (from #2628; may duplicate with above):

• Snapshot the commit hash and ensure all jobs use the same one
• Trigger using PR comment instead of workflow dispatch
• Ensure works for forks

Added during this PR

• Add contributor documentation explaining the new bindings regeneration and native build workflows.
• Move Setup dependencies from main branch native/bindings workflows to a script here to be merged into develop/3.0.

[Exanite]

Note to self: There's no point splitting the job here since this workflow uses the workflow file from the PR branch anyway. Ideally we find some other way of retrieving the PR number, but I kinda doubt it when GitHub's own examples show this pattern.

Edit: Really don't like letting untrusted code decide the PR number so I'll fallback to calling the gh api in the trusted workflow instead if I can't find anything else.

https://docs.github.com/en/actions/reference/workflows-and-actions/events-that-trigger-workflows#workflow_run:

[Exanite]

I ended up keeping the job separate due to a different reason (the matrix strategy means there are two jobs for generating the comment now, so the separate job avoids uploading it twice).

I also added some additional validation on the workflow_run end to verify that the number is in fact a number and that the PR's head commit is the expected commit. This means this is now secure.

[Perksey]

Basically approved, just one teeny comment

[Perksey]

Same feedback as other PR wrt matrices to deduplicate.

[Exanite]

Matrix has been implemented

[Perksey]

I have no qualms other than the Silk.NET instead of Silk thing discussed in the Discord.