Skip to content
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

Collapse Mono builds into single builds for Desktop targets #45521

Open
safern opened this issue Dec 3, 2020 · 12 comments
Open

Collapse Mono builds into single builds for Desktop targets #45521

safern opened this issue Dec 3, 2020 · 12 comments

Comments

@safern
Copy link
Member

safern commented Dec 3, 2020

Currently we fan out test legs and build Mono and Libraries in a separate leg. Then put those together in a run test leg and submit to helix. We do similar things for the mono runtime tests.

However this model has proven that reliability issues like networking hiccups, artifacts service outages, etc, bite us and the gain in time for Mono targets is not worth it.

We should be collapsing the Mono desktop targets into single legs that build Mono, Libraries, Tests and submit to helix, similar to how we do it for Android, WASM, iOS. That will reduce the number of legs we have on CI and improve reliability for those legs on infra issues.

I will take care of collapsing the libraries tests legs, @naricc could you help collapsing the runtime ones? I guess this would replace: #43952

cc: @akoeplinger @ViktorHofer

@Dotnet-GitSync-Bot
Copy link
Collaborator

I couldn't figure out the best area label to add to this issue. If you have write-permissions please help me learn by adding exactly one area label.

@Dotnet-GitSync-Bot Dotnet-GitSync-Bot added the untriaged New issue has not been triaged by the area owner label Dec 3, 2020
@ghost
Copy link

ghost commented Dec 3, 2020

Tagging subscribers to this area: @directhex
See info in area-owners.md if you want to be subscribed.

Issue Details

Currently we fan out test legs and build Mono and Libraries in a separate leg. Then put those together in a run test leg and submit to helix. We do similar things for the mono runtime tests.

However this model has proven that reliability issues like networking hiccups, artifacts service outages, etc, bite us and the gain in time for Mono targets is not worth it.

We should be collapsing the Mono desktop targets into single legs that build Mono, Libraries, Tests and submit to helix, similar to how we do it for Android, WASM, iOS. That will reduce the number of legs we have on CI and improve reliability for those legs on infra issues.

I will take care of collapsing the libraries tests legs, @naricc could you help collapsing the runtime ones? I guess this would replace: #43952

cc: @akoeplinger @ViktorHofer

Author: safern
Assignees: naricc
Labels:

area-Infrastructure-mono, untriaged

Milestone: -

@safern safern self-assigned this Dec 3, 2020
@naricc
Copy link
Contributor

naricc commented Dec 3, 2020

Yes. I will help with the runtime ones. So this basically means that all the mono legs should be using the global-build-job.yml?

Also any preference if I fix this at the same time as #43952 or in seperate PRs?

@safern
Copy link
Member Author

safern commented Dec 3, 2020

Yeah, that means they should use the global build template. Just like the Android and Browser runtime tests.

I think it needs to be on a same PR so that we don't have to build coreclr as part of that job.

@safern safern removed the untriaged New issue has not been triaged by the area owner label Dec 17, 2020
@safern safern added this to the 6.0.0 milestone Dec 17, 2020
@ViktorHofer
Copy link
Member

@naricc were you able to look into this?

@naricc
Copy link
Contributor

naricc commented May 5, 2021

@ViktorHofer Sorry, I haven't made any progress on this; its been a lower priority item for me that I keep meaning to get to.

@SamMonoRT SamMonoRT modified the milestones: 6.0.0, 7.0.0 Jun 21, 2021
@SamMonoRT
Copy link
Member

Not going to get to it in 6.0, moving to 7.0.0. We might consider this after RC1 if we have spare cycles.

@SamMonoRT
Copy link
Member

This is nice to have, but pretty low on priority. Closing this issue.

@ViktorHofer
Copy link
Member

@SamMonoRT this will become more important with the upcoming VMR efforts. I don't think we should close this issue.

@SamMonoRT
Copy link
Member

@ViktorHofer @steveisok Re-opening, but not something anyone on my team maybe familiar with.

@steveisok
Copy link
Member

This is done on the official build side at least.

@ViktorHofer
Copy link
Member

And we should probably do this on the PR side as well just for the sake of less legs and reduced resources and time.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Development

No branches or pull requests

8 participants