Skip to content

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

Merged
merged 46 commits into from
Feb 6, 2024
Merged

Add VMR unified build pipelines #18409

merged 46 commits into from
Feb 6, 2024

Conversation

akoeplinger
Copy link
Member

@akoeplinger akoeplinger commented Jan 26, 2024

Contributes to dotnet/source-build#3823

  • Removes and consolidates vmr-cross-build.yml/ci-cross-build.yml POC into vmr-build.yml/ci.yml
  • Add stage for building vertical/unified build legs into vmr-build.yml
  • Adds Windows build and handling for Windows/Unix differences

@akoeplinger akoeplinger force-pushed the vmr-vertical-pipeline branch 7 times, most recently from 5791eeb to cb1d852 Compare January 26, 2024 13:32
@akoeplinger akoeplinger force-pushed the vmr-vertical-pipeline branch from cb1d852 to 2df04fe Compare January 26, 2024 13:34
@dotnet dotnet deleted a comment from azure-pipelines bot Jan 26, 2024
@dotnet dotnet deleted a comment from azure-pipelines bot Jan 26, 2024
@akoeplinger akoeplinger marked this pull request as ready for review January 26, 2024 14:44
@akoeplinger akoeplinger requested a review from a team as a code owner January 26, 2024 14:44
Copy link
Member

@MichaelSimons MichaelSimons left a 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.

@ViktorHofer

This comment was marked as outdated.

This comment was marked as outdated.

@akoeplinger
Copy link
Member Author

akoeplinger commented Feb 1, 2024

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):

ultralite = 1 leg for smoke tests
lite = several legs e.g. win/linux/mac for basic testing
full = everything

## Public pipelines

installer-source-build (vmr-build.yml)
 - PR (release/* and main, ultralite build)

installer-unified-build (vmr-build.yml)
 - PR (release/* and main, lite build)

dotnet-source-build (ci.yml)
 - PR (ultralite build)
 - CI (release/* only, every batched commit, full build)
 - Schedule (main only, full build)

dotnet-unified-build (ci.yml)
 - PR (lite build)
 - CI (release/* only, every batched commit, full build)
 - Schedule (main only, full build)


## Internal pipelines

dotnet-source-build (ci.yml)
 - PR (ultralite build)
 - CI (release/* and internal/release/* only, every batched commit, full build)
 - CI (main only, every batched commit, lite build)
 - Schedule (main only, full build)

dotnet-source-build-lite (ci-lite.yml)
 - PR (release/* and main, lite build)
 - CI (main only, every batched commit, lite build)

dotnet-unified-build (ci.yml)
 - PR (lite build)
 - CI (release/*, internal/release/* and main, every batched commit, full build)

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 ?

Copy link
Member

@ViktorHofer ViktorHofer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great 💯

@ViktorHofer
Copy link
Member

/azp run installer-unified-build

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@akoeplinger
Copy link
Member Author

/azp run installer-unified-build

Copy link

Azure Pipelines successfully started running 1 pipeline(s).

@MichaelSimons
Copy link
Member

Triggered internal builds with these changes:

Can you trigger a full source-build run?

@akoeplinger
Copy link
Member Author

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.

@akoeplinger
Copy link
Member Author

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

@ViktorHofer
Copy link
Member

ViktorHofer commented Feb 5, 2024

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.

@MichaelSimons
Copy link
Member

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.

Copy link
Member

@MichaelSimons MichaelSimons left a 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!

@akoeplinger akoeplinger merged commit 28012e7 into main Feb 6, 2024
@akoeplinger akoeplinger deleted the vmr-vertical-pipeline branch February 6, 2024 08:57
akoeplinger added a commit that referenced this pull request Feb 6, 2024
@ViktorHofer ViktorHofer mentioned this pull request Feb 6, 2024
3 tasks
v-wuzhai pushed a commit to dotnet/sdk that referenced this pull request Apr 22, 2024
… 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.
ViktorHofer added a commit to dotnet/sdk that referenced this pull request May 7, 2024
… 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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants