You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
[devicelab][desktop] Add Linux and Windows machines #54295
@stuartmorgan is going to add end-to-end tests of Windows and Linux flutter desktop applications, which will require devicelab machines with the necessary tools. VS 2019 with specific workloads on Windows, clang and make and maybe some system libraries (depending on what's currently there) on Linux. VMs should work.
Here are the overall steps:
(Owner: @stuartmorgan) Create virtual machines at flutter-infra and manually prototype the tests. Please take notes about the commands for provision, they will be very helpful for automating the process later.
(Owner: infra team) Integrate the virtual machines with Cocoon agents and dashboards. We will need to calculate how much capacity is needed.
(Onwer: infra team) Automate the provision in salt.
@godofredoc@digiter The instructions above are out of date now, right? (Sorry I've been so slow to make progress on this.) What would the process be for getting new LUCI-based devicelab Windows and Linux desktop tests running? Would step one be for me to make a new core recipe like https://flutter-review.googlesource.com/c/recipes/+/5901?
What I'd like to do is start with just a bare-minimum test for Windows (which we should be able to use the same image we're using for the flutter/plugins e2e tests) and Linux (not sure if we have a suitable image for this yet; I'll follow up in the Linux-specific sub-bug about that) that just does a flutter create and flutter build of the desktop app template as a baseline to build off of.
If these tests are going to be running from the sdk repo and they will be using phones I'd suggest to create a generic devicelab task.
If they will not use devices I'd suggest a sharded test
With the migration to LUCI the difference between devicelab tests and flutter sharded tests are now minimal(target test bed, and runner). Additionally test bed dependencies are now provisioned at runtime.
If you can create the test and make it run in your local machine with either flutter runner or devicelab runner we can help adding support for any missing dependencies.
Since this is for desktop, the devices are the host machines themselves. But some of the test will actually be launching the application, which I believe is only done with devicelab for mobile. Should we keep that same conceptual division for desktop, with build-only tests being sharded tests, but tests that actually run Flutter apps as devicelab tests?
As a starting point, I've followed up in the sub-issues about Linux and Windows images with a test PR for sharded tests, and the details about what's missing.
Everything looks good for sharded tests now. I'll need to look into getting PoC devicelab tests up next, and see if there are any machine-level issues.
Ah, I see. Trying the wrap with xvfb does seem like the right next thing to try then. I assume that's in the recipes somewhere, but I'm not sure where the recipe code for this set of jobs is exactly.
@cbracken Handing this over to you since it's moved forward enough that I don't think the information I had in my head about current state is relevant any more. I'll monitor in case there are questions about what I had done though.
Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now.
If you find this problem please file a new issue with the same description, what happens, logs and the output of 'flutter doctor -v'. All system setups can be slightly different so it's always better to open new issues and reference the related ones.
Thanks for your contribution.
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of flutter doctor -v and a minimal reproduction of the issue.
Activity
digiter commentedon Apr 8, 2020
/cc @gspencergoog @godofredoc @keyonghan
stuartmorgan-g commentedon Sep 28, 2020
@godofredoc @digiter The instructions above are out of date now, right? (Sorry I've been so slow to make progress on this.) What would the process be for getting new LUCI-based devicelab Windows and Linux desktop tests running? Would step one be for me to make a new core recipe like https://flutter-review.googlesource.com/c/recipes/+/5901?
What I'd like to do is start with just a bare-minimum test for Windows (which we should be able to use the same image we're using for the flutter/plugins e2e tests) and Linux (not sure if we have a suitable image for this yet; I'll follow up in the Linux-specific sub-bug about that) that just does a
flutter createandflutter buildof the desktop app template as a baseline to build off of.godofredoc commentedon Sep 29, 2020
If these tests are going to be running from the sdk repo and they will be using phones I'd suggest to create a generic devicelab task.
If they will not use devices I'd suggest a sharded test
With the migration to LUCI the difference between devicelab tests and flutter sharded tests are now minimal(target test bed, and runner). Additionally test bed dependencies are now provisioned at runtime.
If you can create the test and make it run in your local machine with either flutter runner or devicelab runner we can help adding support for any missing dependencies.
stuartmorgan-g commentedon Oct 1, 2020
Since this is for desktop, the devices are the host machines themselves. But some of the test will actually be launching the application, which I believe is only done with
devicelabfor mobile. Should we keep that same conceptual division for desktop, with build-only tests being sharded tests, but tests that actually run Flutter apps as devicelab tests?stuartmorgan-g commentedon Oct 1, 2020
As a starting point, I've followed up in the sub-issues about Linux and Windows images with a test PR for sharded tests, and the details about what's missing.
stuartmorgan-g commentedon Oct 27, 2020
Everything looks good for sharded tests now. I'll need to look into getting PoC devicelab tests up next, and see if there are any machine-level issues.
stuartmorgan-g commentedon Jan 13, 2021
Devicelab trials started: Linux, Windows
(I expect they will fail due to needing bot configuration changes, as with the initial sharded test trials.)
25 remaining items
godofredoc commentedon Mar 4, 2021
I'm not sure if the running user needs to be logged in for x to be available or if we need some extra configurations.
stuartmorgan-g commentedon Mar 4, 2021
Ah, I see. Trying the wrap with
xvfbdoes seem like the right next thing to try then. I assume that's in the recipes somewhere, but I'm not sure where the recipe code for this set of jobs is exactly.godofredoc commentedon Mar 4, 2021
Here is a successful run using xvfb: https://chromium-swarm.appspot.com/task?id=5217f9307050dd10
godofredoc commentedon Mar 4, 2021
Should we start putting desktop tests in their own group? as they don't depend on devices we may want to use hostonly test beds.
stuartmorgan-g commentedon Mar 9, 2021
@cbracken Handing this over to you since it's moved forward enough that I don't think the information I had in my head about current state is relevant any more. I'll monitor in case there are questions about what I had done though.
godofredoc commentedon May 13, 2022
We are migrating to ubuntu images with x installed. Can you please provide a test to run?
github-actions commentedon Jun 3, 2022
Without additional information, we are unfortunately not sure how to resolve this issue. We are therefore reluctantly going to close this bug for now.
If you find this problem please file a new issue with the same description, what happens, logs and the output of 'flutter doctor -v'. All system setups can be slightly different so it's always better to open new issues and reference the related ones.
Thanks for your contribution.
github-actions commentedon Jun 17, 2022
This thread has been automatically locked since there has not been any recent activity after it was closed. If you are still experiencing a similar issue, please open a new bug, including the output of
flutter doctor -vand a minimal reproduction of the issue.