Preventing IE10 regressions

[Kapil Thangavelu]

On Wed, Jan 30, 2013 at 10:04 AM, Benji York <benji.york at canonical.com>wrote:

> On Wed, Jan 30, 2013 at 3:20 PM, Gary Poster <gary.poster at canonical.com>
> wrote:
> > Thanks, Benji.  A couple of comments inline.
> >
> >
> > On 01/30/2013 09:58 AM, Benji York wrote:
> >>
> >> Goal
> >>
> >> Keep IE10 fixes from regressing (once we get the GUI running on IE10)
> >
> >
> > FF as well.
>
> Yep.
>
> >> Since we do not regularly develop or run the tests on IE10 (and that is
> >> unlikely to materially change) we would benefit from some form of
> >> continuous integration (CI) for (at a minimum) IE10.
> >
> >
> > same for FF
>
> Yep again.
>
> >> Plan
> >>
> >> We will write browser tests that can be run via Sauce Labs
> >> (saucelabs.com) on IE10 against the Juju GUI charm.
> >>
> >> We will have one or more tests written in Python, using the Sauce Labs
> >> remote Selenium/Web Driver interface.  Those tests will operate against
> >> the Juju GUI charm running in EC2 (initially).  The tests will be
> >> triggered a hosted Jenkins instance (i.e., http://www.cloudbees.com/).
> >
> >
> > People will also be able to run this automation on their own developer
> > machines, right?  As long as the branch they want to test has been
> pushed,
> > I'd guess.
>
> Right, it will be easy to pass a non-trunk branch through to the charm
> which will let us run the tests against that branch instead.
>


> > Would you deliver the developer tool first, and then the Jenkins
> integration
> > separately?
>
> I am inclined to do so.
>
> > Do you plan for Jenkins to trigger tests on trunk landing, or daily, do
> you
> > think?  If it's just as easy, I would prefer trunk landing.
>
> According to Diogo Matsubara setting up tarmac to be a gatekeeper is
> easy, so that is another option as well.  Does anyone object to using
> tarmac to run these tests and ensure they pass before a branch can land?
> It would probably mean not using lbox submit any more (but we can still
> use lbox propose as before).
>
>
two thought on tarmac integration, its significantly more process on
merging then we have now (setup commit messages on mp, mark mps approved,
wait for tarmac and success or on failure rinse lather repeat).  i'd rather
we could just submit build jobs to jenkins via its api perhaps as part of
lbox check depending on the speed of the test running there. second
thought, tarmac adds alot of noise to the commit log which lbox helps keep
clean.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/juju-gui/attachments/20130130/d92f3d87/attachment.html>