Libraries live live ci #71
Conversation
|
/cc @trylek |
trylek
left a comment
trylek
left a comment
There was a problem hiding this comment.
Overall looks good as a checkpoint even though I probably need for the change to expand a bit further to see more clearly the live live support unfold. In particular, for "live-live libraries CI sub-pipeline" (as standalone live live libraries CI pipeline doesn't make sense to me) I would expect the most important bit to be a way to propagate the location of live-live built System.Private.Corelib to use for building CoreFX / libraries and I don't yet see that.
On top of that, I was under the impression that we discussed maximizing reuse of YAML code between "subrepo pipelines" and the "live-live global pipeline" and I don't see any of that, I see just some new YAML getting added without any relationship to the existing pipelines / scripts.
Yeah. This was just like the first progress that I made on Friday and this isn't even close to the design we discussed but it starts getting corefx's build logic to get closer to it and to be able to use xplat and platform matrix templates. The first step was to separate the build and tests steps as right now we're building sources and tests as part of the same step and build, but yeah, what you describe is the plan forward! Thanks for taking a look and sharing your thoughts, really valuable. |
Since this System.Private library depends on Console (and exists solely because CoreLib cannot reference System.Console), placing this in the libs partition. I'm not actually porting all of System.Private.DeveloperExperience.Console - the dependency on System.Private.StackTraceGenerator was annoying so I removed it. I'm deleting System.Private.StackTraceGenerator - this only works on Windows systems that have DIA registered machine wide - that's not the case (by default) since VS 2017.
ghost
locked as resolved and limited conversation to collaborators
5 participants
Not yet ready. Haven't even tested it.
cc: @jashook @sbomer