Conversation
| { | ||
| "platforms": [ | ||
| { | ||
| "dockerfile": "src/cbl-mariner/2.0/helix/amd64", |
There was a problem hiding this comment.
we already have plain mariner 2 machines, why do it in docker?
There was a problem hiding this comment.
There was a problem hiding this comment.
do you have msquic on it @MattGal ? It feels like the docker is easer to manage for us.
There was a problem hiding this comment.
Why is the docker easier to manage? We are about to delete all these files and docker is going to use the same architecture our other VM's have.
There was a problem hiding this comment.
one more note that containers are super easy for developers for testing and investigations. Going through the helix-repro lab no so much.
There was a problem hiding this comment.
@wfurt currently the "regular" helix machines running mariner 2 on them don't have msquic, that's true, but the same "install a Centos 7 version of it" workaround could be easily applied there. I thought we had tried this as part of dotnet/arcade#10253 and determined it didn't work at runtime.
I'm not blocking this PR but I still think it's strange to do mariner testing in docker when we made specific efforts to have dedicated IaaS Mariner 2 test machines. Running the tests as docker has the downsides of the per-machine cost of downloading the images on every machine as well as the bottlenecking effect of running in the same queue with all the other docker-ified linux scenarios.
There was a problem hiding this comment.
noted @MattGal. Let's revisit this when the linked MsQuic issue is fixed e.g. we have packages for Mariner.
Also new version of MsQuic is coming out soon so we may see some more turn than usually.
based on Mariner 1.0
Request for Mariner packages is tracked by microsoft/msquic#3376
The build runs with warning
I'm wondering if we should install the python craft after we add
helixbotuser @MattGal.I would assume this is not only one distributions where we bend the recommendation.
cc: @ManickaP