madecoste / swarming

Automatically exported from code.google.com/p/swarming
Apache License 2.0
0 stars 1 forks source link

Provide debugging environment to make it easier for users to debug failing tests #20

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
When tests that run through Swarm fail, the user of those tests will most 
likely want to debug those failures.  Moreover, the user may not have easy 
access to the particular machine configuration on which the failure manifests.

There's a great opportunity here to make things really easy for the user.  
Suppose that Swarm automatically requests a machine instance from the machine 
provider that has the relevant configuration, then sets up that instance with 
the associated test data, so the tests are all ready to be run.  Then Swarm can 
provide the machine connection details to the user (e.g., the IP address of the 
instance), and the user can simply log into the machine and immediately start 
running the tests to repro/debug the failure.

This could be a compelling advantage of Swarm for configuration testing - 
making it really easy to debug failures on different configs that the user may 
not otherwise have easy access to.  However, there are important considerations 
to be made, such as whether there are enough machines available to be used for 
this purpose in the machine provider, how long a user should have access to a 
machine, and how to release the machine back to the provider when the user is 
done.

Original issue reported on code.google.com by dennisjeffrey@chromium.org on 4 Aug 2011 at 5:36

GoogleCodeExporter commented 9 years ago
It's orthogonal to Swarming's purpose. a user can request a slave out of band 
and hack on it. The command is embedded in the .isolated file.

Original comment by maruel@chromium.org on 23 Jul 2013 at 1:00