HelixReproVMs DTL for runtime repro needs
- Dominant language
- C#
- Stars
- 729
- Forks
- 397
- Avg merge
- 3d 15m
- Merged PRs (30d)
- 149
Description
Migrated from https://github.com/dotnet/core-eng/issues/13466
@lukas-lansky wrote:
We should find out whether the current HelixReproVMs DTL setup works for runtime as it is, or something more needs to be done. To reiterate, the intended usecase for the DTL is "my build/test is failing on a particular OSOB-provided Ubuntu 16.04 only and I need a VM that is matching the CI configuration as close as possible".
Ideally, people won't need to this in the future for acquiring native build dependencies as we are going to fix Native Toolset Acquisition. They are still going to need that to troubleshoot other problems related to the precise OS and its configuration being used.
We already [started documenting that DTL](https://github.com/dotnet/core-eng/issues/12957) as a part of other epic. We also [made sure it actually provides current images](https://github.com/dotnet/core-eng/issues/12665) recently. It very well might be the case that the only thing that needs to be done is to enhance that docs with "how to connect from home using the DDFun proxy" info.
Contributor guide
Research direction
Start with the DTL documentation tracked in dotnet/core-eng#12957 and the current-image work in #12665; compare the existing HelixReproVMs setup with the runtime CI configuration described here. Verify whether runtime users can connect through the DDFun proxy, then document any missing steps and confirm the images match the intended troubleshooting environment.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- ubuntu
- Domain
- documentation, infrastructure
- Issue type
- Documentation
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100