Add doc on OS onboarding #112026
Add doc on OS onboarding #112026
Conversation
|
Tagging subscribers to this area: @dotnet/area-meta |
Co-authored-by: Copilot <[email protected]>
docs/project/os-onboarding.md
Outdated
|
|
||
| ## Mechanics | ||
|
|
||
| Most of our testing is done in container images. New images need to be created for each new version in the [dotnet/dotnet-buildtools-prereqs-docker](https://github.com/dotnet/dotnet-buildtools-prereqs-docker) repo. The repo is self-service and largely self-explanatory. One typically creates a new image using the pattern demonstrated by the previous version. |
There was a problem hiding this comment.
I wouldn't say most - I think it's a mix between Helix queues and docker images.
There was a problem hiding this comment.
| Most of our testing is done in container images. New images need to be created for each new version in the [dotnet/dotnet-buildtools-prereqs-docker](https://github.com/dotnet/dotnet-buildtools-prereqs-docker) repo. The repo is self-service and largely self-explanatory. One typically creates a new image using the pattern demonstrated by the previous version. | |
| Much of our testing is done in container images. New images need to be created for each new version in the [dotnet/dotnet-buildtools-prereqs-docker](https://github.com/dotnet/dotnet-buildtools-prereqs-docker) repo. The repo is self-service and largely self-explanatory. One typically creates a new image using the pattern demonstrated by the previous version. | |
There was a problem hiding this comment.
What about helix queues? The most recent ask for Server 2025 was delayed for so long because we didn't have queues. I think we need to call that out as a prerequisite - unless there was a miss here and testing could have been unblocked with containers all along.
docs/project/os-onboarding.md
Outdated
| @@ -0,0 +1,53 @@ | |||
| # OS Onboarding Guide | |||
|
|
|||
| Adding support for new operating systems (largely just new versions) is a frequent need. This guide describes how we do that, including policies we use. | |||
There was a problem hiding this comment.
Does this apply for new OS families, distros, architectures too, or just new versions of existing distros of the same architecture? Seems to me like you are trying to write a general document but it's only covering a narrow scenario.
There was a problem hiding this comment.
Most of what we do is add support for new versions. When we added new architectures, we followed the same pattern. For example, when we added support for Azure Linux, it was the same pattern. While that example is a bit cheating (since it was Mariner re-branded), we still have to do all the things we'd do if it was completely new to us.
There was a problem hiding this comment.
Adding new RIDs is no longer a thing, but pretty sure we have more to do here around new versions of apple, new distros, architecture, mobile / wasm, etc. I'm fine with this doc not covering that - just call out what is out of scope.
There was a problem hiding this comment.
This doc is intented to cover the typical cases. I think you'll find that there is very little we have to do beyond testing. Perhaps I'm mistaken.
There was a problem hiding this comment.
I think that the doc title should make it clear that this doc really only covers new OS versions.
https://github.com/dotnet/runtime/pull/112026/files#r1938542342
If somebody from the community wanted to onboard actual new OS, this doc would not be applicable.
docs/project/os-onboarding.md
Outdated
|
|
||
| For whatever the reason, we should update references to EOL OSes if we have them. | ||
|
|
||
| ## Mechanics |
There was a problem hiding this comment.
What about builds and changing the platform we build on?
There was a problem hiding this comment.
Builds are not affected by OS onboarding and use a different process. We only build on x64.
We've documented the process we use for Linux: https://github.com/dotnet/runtime/blob/main/docs/project/linux-build-methodology.md. Windows is simpler.
There was a problem hiding this comment.
My point is that we should also cover how new platforms apply to build and what we need to do to update the versions of build agents.
There was a problem hiding this comment.
It depends what you mean. In practice, we don't do this. The last one of these that I am aware of is Apple Arm64. That was a massive project (as you recall) and no doc could cover that.
Do you have another example?
There was a problem hiding this comment.
Perhaps @sbomer @jkoritzinsky can think of some examples.
| ## Mechanics | ||
|
|
||
| Most of our testing is done in container images. New images need to be created for each new version in the [dotnet/dotnet-buildtools-prereqs-docker](https://github.com/dotnet/dotnet-buildtools-prereqs-docker) repo. The repo is self-service and largely self-explanatory. One typically creates a new image using the pattern demonstrated by the previous version. | ||
|
|
There was a problem hiding this comment.
New versions of Apple OSes, Android and Browser have its own mechanics. Should they be covered as well?
|
Great feedback! I'm going to (try to) expand the doc to cover the broader set of scenarios. |
Co-authored-by: Jan Kotas <[email protected]>
|
I significantly expanded the scope of the doc. You may find that I've got a better grasp of some areas than others. In particular, I don't have a good grasp on what we do for Windows and Apple. My discussion of that may not be good enough and I may need help filling in those gaps. |
No description provided.