-
Notifications
You must be signed in to change notification settings - Fork 188
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Should we provide GitHub Actions workflows? #2200
Comments
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. |
Right ... that's the intent. |
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. |
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.
The text was updated successfully, but these errors were encountered: