Migrate workflow to GitHub Actions

[Sergio0694]

This PR moves the workflow for the build pipeline from Azure DevOps to GitHub Actions.

[michael-hawker]

@Sergio0694 this should be what you need, you have different conditions a bit than we do for when things trigger (we only trigger on specific branches for instance). But otherwise I think this is all setup for you. I don't think it'll run until it's merged though.

This logic does the following:

• Upload build packages as artifacts
• If it's a PR, pushes them to PR feed on ADO Artifacts PullRequests feed
• If it's integration to main, signs and then pushes to ADO Artifacts MainLatest feed
• If it's a rel/* release branch, signs them, pushes to ADO Artifacts MainLatest feed, and then waits for the nuget-release-gate sign-off (this gives you time to check the packages on MainLatest for instance), once approved, it'll push to nuget.org

This is the same setup we have for WCT. @Arlodotexe feel free to take a quick look in case I missed something (as we have matrix vs. single bits).

[echoix]

Some actions here already have newer published versions.

I furthermore reviewed the whole workflow, but not in a dotnet usage point of view, but in a GitHub Actions workflow usage point of view. I have a couple of suggestions, even before using any kind of linter.

[echoix]

Suggested change

	with:
	persist-credentials: false

Since no git push operations are performed, it is a good practice to not have the credentials kept in the git config.

[Sergio0694]

Good points, we should look into all these in a follow up. Same for the other comments below 🙂

[echoix]

Plan a way to keep this tool's version updated. Having it hardcoded to a specific version, beta on top of that, is a little smelly.

In repos that use renovate (not the case here), I would've have seen an env var with that version, and the env var definition having a comment linking back to the source of the project, so updates could be done.

[echoix]

[nit] Potential improvement: define a global permission key with the common base permissions for all jobs explicitly, or clear the default permissions with {}. Then, in each job, explicitly list the permissions needed and wanted.

This helps when changing the workflow later on, like adding a job, to not have too much permissions.

Also, combine this with a review of the repo's GitHub Actions settings. Some older existing repos have more permissive defaults than newer repos/forks, and these will not limit as much the default permissions to read for contents and packages (usually enough as a default). The change happened a couple years ago

https://docs.github.com/en/repositories/managing-your-repositorys-settings-and-features/enabling-features-for-your-repository/managing-github-actions-settings-for-a-repository#configuring-the-default-github_token-permissions