-
Notifications
You must be signed in to change notification settings - Fork 442
Add VMR unified build pipelines #18409
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
Conversation
5791eeb
to
cb1d852
Compare
cb1d852
to
2df04fe
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you please link to sample runs.
src/SourceBuild/content/eng/pipelines/templates/stages/vmr-scan.yml
Outdated
Show resolved
Hide resolved
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
This comment was marked as outdated.
I've incorporated the feedback and here's the suggested pipeline setup that we discussed on Teams (let me know if I transcribed that correctly into the .yml):
I removed vmr-build-internal.yml since it is only used by the dotnet-installer-source-build-internal pipeline and I think that can be 8.0-only ? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks great 💯
/azp run installer-unified-build |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run installer-unified-build |
Azure Pipelines successfully started running 1 pipeline(s). |
Can you trigger a full source-build run? |
Hmm I triggered https://dev.azure.com/dnceng/internal/_build/results?buildId=2370500&view=results (manual run of the vmr-vertical-pipeline branch) but it didn't trigger the full scope even though it should based on how I see the if/elseif/else. Will take a look. |
Ok, found the reason: variables are strings and casting to bool uses empty/non-empty as false/true so you need to explicitly compare to "true" Here's the new source-build "full" run: https://dev.azure.com/dnceng/internal/_build/results?buildId=2370535&view=results |
The full VMR build is green and doesn't show any new regressions compared to the last scheduled build. @MichaelSimons any more feedback? Otherwise I would like to get this in so that we can test some other PRs with the new pipeline. |
Nope - the should build test runs passed. I will sign off. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all your work on this @akoeplinger!
… log (#18501) Noticed in dotnet/installer#18409 that errors aren't propagated which resulted in builds not to fail. The fix here is to use `OnError` in the correct target (but only when using the minimal console log feature) and not set `IgnoreStandardErrorWarningFormat=true` on the Exec task that invokes the repo build script. I also cleaned targets up as those introduced unnecessary complexity and logged in cases when they shouldn't (i.e. in dotnet.proj or package-source-build.proj). This affected runtime which errors after 30s of building because of RuntimeOS and BaseOS being passed in in-correctly. Regressed with dotnet/installer@a265140#diff-86602308e6bb519266bc2f224ea65e39589d273804d40ad0f9c6e0eea2a263dc. Fixed that in runtime.proj. Kudos to Alexander who made the fix. I just copied it in form his CI PR.
… log (#18501) Noticed in dotnet/installer#18409 that errors aren't propagated which resulted in builds not to fail. The fix here is to use `OnError` in the correct target (but only when using the minimal console log feature) and not set `IgnoreStandardErrorWarningFormat=true` on the Exec task that invokes the repo build script. I also cleaned targets up as those introduced unnecessary complexity and logged in cases when they shouldn't (i.e. in dotnet.proj or package-source-build.proj). This affected runtime which errors after 30s of building because of RuntimeOS and BaseOS being passed in in-correctly. Regressed with dotnet/installer@37ddec7#diff-86602308e6bb519266bc2f224ea65e39589d273804d40ad0f9c6e0eea2a263dc. Fixed that in runtime.proj. Kudos to Alexander who made the fix. I just copied it in form his CI PR.
Contributes to dotnet/source-build#3823