Should we provide GitHub Actions workflows?

[richlander]

CI feedback is provided by Azure DevOps pipelines for the various lab projects in this repo.

For example: https://github.com/dotnet/runtimelab/tree/feature/NativeAOT/eng/pipelines

It is difficult for us to extend our Azure DevOps pipelines to meet broad community needs. Also, it isn't clear that Azure DevOps is what people want to use.

We could provide GitHub Actions workflows that provided analogous build logic and validation. That would enable contributors to be more independent of the Microsoft team. We would craft these workflows to be more minimal so that they used as few Actions minutes as possible while still being useful.

The intent is that these workflows would be run in the context of forks to make contributors more productive, while the Azure DevOps pipelines would be the final arbiters of upstream quality. This approach seems like a pragmatic tradeoff.

We will gauge developing this idea based on your feedback. Is this a useful direction? If this idea proves useful in this repo, we would consider implementing it in other repos.

[yowl]

This sound useful if I understand it correctly. As a part time contributor I often take advantage of the DevOps pipelines for testing rather than a final check of "is my PR good to go". There's a lot of CPU used on jobs that I'm not that interested on in the course of working through a PR, e.g. MacOS or Linux jobs - I don't work on those areas, not to say I don't break them from time to time, its just not something I need to run all the time. So if there was a shorter - and for NativeAOT-LLVM, that would at the moment by just the browser-wasm windows jobs, that was set up in GitHub actions that would run on my own fork, I think that would be useful.

[richlander]

Right ... that's the intent.

[SingleAccretion]

I would - personally - not find use for fork-based CI in the context of NativeAOT-LLVM, since I do not tend to use CI for ad-hoc testing.