What you describe nuke_chrome() as doing doesn't make sense to me unless there's some reason why session_manager needs to continue running during testing. Maybe there are no-longer-relevant reasons why it was done that way.

If it works, I agree that you should just do this at the beginning of your test:

  upstart.StopJob(ctx, "ui")
  defer upstart.EnsureJobRunning(ctx, "ui")

If your test times out, the context passed to EnsureJobRunning will be expired, resulting in the job possibly not being started. You may want to pass a slightly-shortened deadline to your test code so there's still time for the job to be restarted at the end.

This is probably a common problem with test cleanup code that I don't have a good general answer for. :-(

For video decode tests to pass an ozone GPU helper needs to be initialized, to set up drm etc. Without this an error will occur: "Check failed: drm. No devices available for buffer allocation."

When "stop ui" is not called, gpu_helper_->Initialize() will hang forever. It would be great if we had another way to do this! Maybe something we can trigger from the test code itself?

https://cs.chromium.org/chromium/src/media/gpu/test/video_player/frame_renderer_dummy.cc?l=56&rcl=58cab433eb7b392854322066d5ac65bcf75f6cf4

I am creating a CL and will upload soon. Thanks derat@ and dstaessens@.

I'm uneasy about replicating any non-trivial bits of ozone's code inside of Tast tests (or related libraries), but building a (hopefully tiny) helper executable from the Chromium tree that performs that initialization work and then calling it from video decode tests may be an option. I don't know enough about ozone to know how feasible that is, though.

I had a chat with Pawel just to verify, and it seems there is indeed no way around killing the entire Chrome process before the test. If we do it from the test binary, there is no guarantee we could restart the ui job when the test crashes.

I think the StopJob/EnsureJobRunning proposed by Dan will works just fine! Is there a way to let the test framework handle this, to avoid the timeout issue? Maybe by creating a dependency on 'no-ui' or something similar?

No, I've pretty much decided that things like this are the framework's job. :-)

The timeout approach should be easy, though. Just import chromiumos/tast/ctxutil and do something like this:

  testCtx, testCancel := ctxutil.Shorten(ctx, 10*time.Second)
  defer testCancel()

  if err := upstart.StopJob(testCtx, "ui"); err != nil {
      s.Fatal("Failed to stop ui job: ", err)
  }
  defer upstart.EnsureJobRunning(ctx, "ui")

  // use testCtx throughout the rest of your test

whoops: s/are/aren't/ the framework's job.

Thanks for the code Dan! It's only used for a few tests, so it sounds reasonable to do this in the test code. We just need to make sure to properly document what is happening! :-)

I forgot cc david and keiichi.
This CL includes this preparation change.
https://chromium-review.googlesource.com/c/chromiumos/platform/tast-tests/+/1351969