Merge lp://staging/~vila/uci-engine/integration-speed-up into lp://staging/uci-engine

Proposed by Vincent Ladeuil
Status: Rejected
Rejected by: Vincent Ladeuil
Proposed branch: lp://staging/~vila/uci-engine/integration-speed-up
Merge into: lp://staging/uci-engine
Prerequisite: lp://staging/~doanac/uci-engine/integration-speed-up
Diff against target: 190 lines (+29/-20)
8 files modified
tests/deployers.py (+7/-13)
tests/test_image_builder.py (+5/-1)
tests/test_integration.py (+3/-1)
tests/test_ppa_assigner.py (+3/-1)
tests/test_publisher.py (+3/-1)
tests/test_test_runner.py (+4/-1)
tests/test_ticket_system.py (+2/-1)
tests/test_webui.py (+2/-1)
To merge this branch: bzr merge lp://staging/~vila/uci-engine/integration-speed-up
Reviewer Review Type Date Requested Status
PS Jenkins bot (community) continuous-integration Approve
Canonical CI Engineering Pending
Review via email: mp+223065@code.staging.launchpad.net

Commit message

Teach AmuletDeployment() to skip the deployment when one is already available.

Description of the change

This changes lp:~doanac/uci-engine/integration-speed-up to minimize the scope of the workaround.

Andy, we've been talking past each other I think, let me restart the discussion:

1) We are bitten hard by https://bugs.launchpad.net/juju-core/+bug/1200267

IMO, It's the most important issue we face for the current "integration" tests: I thought you had some insight about what was going on hence my question. You don't. Damn. Me neither. Damn damn.

I don't want this issue to get out of our radar hence the comment in setUp() in this proposal. If we kick the can, let's make sure it's still in front of us.

2) We need a workaround in the mean time.

I'm fine with that but I want that workaround to be expressed in the right place: at the test level.

I want (like you), as a dev, to be in charge of the environment where my test run.

I *don't* want to have to tell the test runner about that.

You proposed to use an env var for that, there is no need for a class
attribute to duplicate that information.

bzr diffstat for this proposal is:

  1 file changed, 14 insertions(+), 10 deletions(-)

yours was:

    8 files changed, 26 insertions(+), 31 deletions(-)

I don't want to carry those additional changes.

To post a comment you must log in.
Revision history for this message
PS Jenkins bot (ps-jenkins) wrote :

PASSED: Continuous integration, rev:563
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/860/
Executed test runs:

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/860/rebuild

review: Approve (continuous-integration)

Unmerged revisions

563. By Vincent Ladeuil

Simplify DEPLOYED handling. The only place we care about it is in AmuletDeployment.setUp().

562. By Andy Doan

integration tests: allow re-use of a deployed environment

This allows us to deploy once and then run our integration tests
against a deployed environment. This greatly speeds up local testing.

This is disabled by default, but specifying DEPLOYED=1 in your
environment allows you take advantage of this. I'm running things
at home with:

 DEPLOYED=1 JUJU_REPOSITORY=`pwd`/tmp/charms PATH=$PATH:`pwd`/branches/juju-deployer JUJU_DEPLOYER_DIR=`pwd`/tmp ./tests/test_webui.py

I'm not a huge fan of "DEPLOYED=1" but unittest.main has its own argparse
logic, so we screw that up if we try to accept CLI args. Even if this
idea is terrible, its local to one place so we can easily fix it in
the future w/o touching our other code.

This makes testing the webui go from 76s to 4s when using juju-lxc

Preview Diff

[H/L] Next/Prev Comment, [J/K] Next/Prev File, [N/P] Next/Prev Hunk
The diff is not available at this time. You can reload the page or download it.

Subscribers

People subscribed via source and target branches