← Back to team overview

unity-api-bugs team mailing list archive

[Bug 1376423] [NEW] There is no easy and future-proof way of starting an app in a clean environment

 

Public bug reported:

For manual and automated testing we generally need to be able to start
the applications in a clean environment, in a way that the tests are not
affected by existing files and configurations. And as the tests should
be easily runnable on the devs development machines, the changes made
while running the tests should not affect the real environment.

In the past we were able to get a reasonably clean environment setting
the value of $HOME to a temporary directory.

Now this is not enough by a variety of reasons, like a hierarchy of dirs
in HOME needed by app armor, apps being launched by upstart, and
services that keep listening to the previous value of HOME.

Every test suite has solved this on it's own why, some use the real
environment but backup the existing files (which is really bad), some
patch the HOME and keep adding details every time something changes, and
some others just pollute the real environment and can't be run on a dev
machine. This is what has been causing failures on the majority of
autopilot tests for the last month.

Instead of keep doing these multiple solutions, and keep adjusting them
every time they stop working; I think we need to find one single way
that works for all the apps. And we need to add automated tests for this
single way to make sure that no new releases will break it. I'm
currently thinking of a testability helper in ubuntu-app-launch that we
call to launch an app and it will make sure that it will start all the
needed XDG vars pointing to a clean temporary environment. We might
still need to restart some services, and we might hit some other
problems, but this is just an idea. Feel free to propose alternatives.

** Affects: ubuntu-app-launch
     Importance: Undecided
         Status: New

-- 
You received this bug notification because you are a member of Unity API
bugs, which is subscribed to Ubuntu Application Launcher.
https://bugs.launchpad.net/bugs/1376423

Title:
  There is no easy and future-proof way of starting an app in a clean
  environment

Status in Ubuntu Application Launcher:
  New

Bug description:
  For manual and automated testing we generally need to be able to start
  the applications in a clean environment, in a way that the tests are
  not affected by existing files and configurations. And as the tests
  should be easily runnable on the devs development machines, the
  changes made while running the tests should not affect the real
  environment.

  In the past we were able to get a reasonably clean environment setting
  the value of $HOME to a temporary directory.

  Now this is not enough by a variety of reasons, like a hierarchy of
  dirs in HOME needed by app armor, apps being launched by upstart, and
  services that keep listening to the previous value of HOME.

  Every test suite has solved this on it's own why, some use the real
  environment but backup the existing files (which is really bad), some
  patch the HOME and keep adding details every time something changes,
  and some others just pollute the real environment and can't be run on
  a dev machine. This is what has been causing failures on the majority
  of autopilot tests for the last month.

  Instead of keep doing these multiple solutions, and keep adjusting
  them every time they stop working; I think we need to find one single
  way that works for all the apps. And we need to add automated tests
  for this single way to make sure that no new releases will break it.
  I'm currently thinking of a testability helper in ubuntu-app-launch
  that we call to launch an app and it will make sure that it will start
  all the needed XDG vars pointing to a clean temporary environment. We
  might still need to restart some services, and we might hit some other
  problems, but this is just an idea. Feel free to propose alternatives.

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu-app-launch/+bug/1376423/+subscriptions


Follow ups

References