Attempting Java port of selenium tests

[Kohsuke Kawaguchi]

I've promoted our selenium test harness [1] a lot in the last few months on my trips to various places, as well as in Jenkins Scalability Summit. I see a great opportunity in this, in that:

 - when large users write their acceptance tests on the same format and share it in the community, it creates a larger pool of test cases that we can reuse.

 - the harness acquired ability to launch complex fixtures (external systems) through docker, allowing us to test more interesting scenarios that are hard to do in the unit tests. For example, I'm not testing JIRA plugin with real JIRA.

 - we want to start doing more non-functional tests, like creating a Jenkins master with 100 slaves, put some load on it for a few hours and make sure it works all right.

Wherever I show it, I see people agree with the ideas. I talked to my colleague Vivek offline, and he is interested in helping me make this happen --- he has developed a plugin in the very early days, and he's well versed in Java and Ruby!

One of the common feedbacks I've heard from people during my pitch of this effort is that this project being in Ruby creates a cognitive disconnect, given that Jenkins developers are primarily Java people. The toolchain involved in running is also little bit alien to them, and so is the environment for writing tests. So I can see why there's the question of "why Ruby just in this project?"

I've been hesitent to spend time porting harness to Java, because it didn't feel like the best way to spend our precious time. Over time I think I've managed to learn enough of the Ruby hacking and the tooling, to be reasonably productive with it, too. But nonetheless I felt like it's always an option that I can come back to.

But as Vivek and I were talking about implementing some missing functionalities to achieve these goals, I realized that once we start adding more code to it, it'll become very difficult to do the porting. So suddenly I started seeing selenium-tests being in Ruby as a risk (to the potential adoption), and the opportunity to correct it is now or never.

So Vivek and I are trying the time-bounded approach to this problem; we are going to spend one day (today) to try to port it over to Java. If at the end of the day we don't think it's doable, or if we hear back from the community that it's an insanity, we'll stand corrected and keep on the selenium-tests project. So please share your thoughts (and my apologies in advance that I didn't float this idea sooner in the list.)

The repository where I'm doing this is https://github.com/jenkinsci/acceptance-test-harness. The plan is to rewrite page objects, step definitions, and JenkinsController in Java, swap Capybara with WebDriver, but keep all the cucumber features intact.

[1] https://github.com/jenkinsci/selenium-tests
--
Kohsuke Kawaguchi

[oliver gondža]

Mostly same story here with the exception I have never felt comfortable or
productive working in ruby.

Btw, you have expressed dislike towards Cucumber/BDD style features in the
past. Can we take this opportunity to get rid of it as well? It should not
mean significantly more work and if it can bring new people in, I think it
might be worth to try.

--
oliver

[Jesse Glick]

On Fri, Feb 28, 2014 at 2:06 PM, oliver gondža <ogo...@gmail.com> wrote:
> Can we take this opportunity to get rid of [Cucumber] as well?

FWIW I also threw in my vote for plain old JUnit (4) tests. Maybe this
just comes “for free”?

[Kohsuke Kawaguchi]

Stephen made a point to me in a dev meet-up at FOSDEM that he likes Cucumber in that tests are more readable (even to developers), even though he was sympathetic to the overhead for authors of tests.

So I think I am going to leave them alone. Cucumber has another nice characteristic that tests that depend on not-yet-ported steps will be marked as pending, so I can see how far off I am from getting back to the parity.

And yes, you will get the ability to write tests in plain-old JUnit4 tests (which I consider the porting from writing tests in rspec.) Personally, I'd be writing tests in plain-old JUnit4 tests on Groovy. 

I'm curious to hear from other users on their take on BDD/Cucumber vs JUnit.

 

--
Kohsuke Kawaguchi

[Stephen Connolly]

On Friday, 28 February 2014, Kohsuke Kawaguchi <k...@kohsuke.org> wrote:

Stephen made a point to me in a dev meet-up at FOSDEM that he likes Cucumber in that tests are more readable (even to developers), even though he was sympathetic to the overhead for authors of tests.

So I think I am going to leave them alone. Cucumber has another nice characteristic that tests that depend on not-yet-ported steps will be marked as pending, so I can see how far off I am from getting back to the parity.

And yes, you will get the ability to write tests in plain-old JUnit4 tests (which I consider the porting from writing tests in rspec.) Personally, I'd be writing tests in plain-old JUnit4 tests on Groovy. 

I'm curious to hear from other users on their take on BDD/Cucumber vs JUnit.

 

I said I like how they are more readable ... Didn't say I like them at all

Good junit4 test names give the same effect... Just nobody stops you calling a junit test "smokes" and stuffing chock full of asserts.

A good junit test should limit itself to 1-2 asserts...

When you hit integration tests, the need to control execution order with "method per assertion" favours testng...

I suspect that java8 syntax improvement may free us more though

If I have a failing cucumber test to debug when trying to understand how a change of mine elsewhere has resulted in the side effect of the test failing... The descriptive nature of cucumber makes it easier to determine if the break is intended or not.... Does not help me fix the test if an intended break though

2014-02-28 11:06 GMT-08:00 oliver gondža <ogo...@gmail.com>:

Mostly same story here with the exception I have never felt comfortable or productive working in ruby.

Btw, you have expressed dislike towards Cucumber/BDD style features in the past. Can we take this opportunity to get rid of it as well? It should not mean significantly more work and if it can bring new people in, I think it might be worth to try.

--
oliver

--
Kohsuke Kawaguchi

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.
To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-de...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

--
Sent from my phone

[Dominik Bartholdi]

I think this is an great idea!

Personally I would probably stick to JUnit too (the overhead of writing Cucumber/easyB/… is just too not what I like), but the reports of BDD tools are a lot better to understand and therefore a user/developer can see more clearly what actually has been tested and what might be missing or need another test. UseCases are better documented and published BDD Reports are also good documentation (when published).

John Smart (the guy who wrote the Jenkins Definitive Guide - [1], cc'd) is quite into BDD and also the author Thucydides [2] - maybe he would be interested in proving BDD to be helpful  for the jenkins community (speak “convince").

Domi 

[1] http://www.wakaleo.com/books/jenkins-the-definitive-guide

[2] http://www.wakaleo.com/index.php/resources/thucydides

[Kohsuke Kawaguchi]

Vivek and I have ported all the lower layers of the test harness. This includes JenkinsController, Docker support, Guice-based object world, Cucumber integration, and JUnit integration.

I can run tests from IDEs individually for both Cucumber and JUnit, although I just realized that I haven't added glue to make all cucumber tests run from "mvn test". JUnit portion obviously does run with "mvn test".

We kept the configuration mechanism backward compatible, but I also added a configuration mechanism based on Guice-binding [1].

I've added a set of classes to mimic Capybara methods that we use regularly on top of WebDriver. This made the porting process fairly straight-forward.

Page objects and step definitions were ported by using test cases as the driver (I rely on IntelliJ's auto-fix functionality to generate steps one at a time.) So far I have only fully ported freestyle_project.feature, then ant_plugin.feature to JUnit test format. There are still many more steps and page objects to complete, although at this point I feel the rest of the process is fairly mechanical --- so any help in porting feature files would be appreciated. Just claim your feature file, and push your changes.

So far, I'm hearing people favoring JUnit tests, including Oliver who is the most active in this project. So I'm starting to think that maybe I'd port other cucumber tests into JUnit format. I continue to welcome feedbacks from others in this area.

I need to document a lot of things, and I still intend to, but I have to hack this coming week on something else. I plan on coming back to this in the next weekend. In the mean time, hopefully the code is not too large and simple enough for you everyone to see.

[1] http://kohsuke.org/2014/03/01/potd-application-configuration-via-guice-binding-groovy/

--
Kohsuke Kawaguchi

[Ulli Hafner]

That sound very exciting!

I just cloned the repository and tried to run the tests, however, none of them succeeds. Maybe I’m missing still a part on my side.

What I’ve done (environment OS X 10.9.2):

a) command line

- clone of your repository

- started mvn test with path to war file

b) IntelliJ JUnit

- Run of BuildHistoryTest 

c) IntelliJ 

- Run of freestyle_build.feature

I always get an exception:

----------------------------------------------------------------------------------------------------------------------------------------

com.google.inject.ProvisionException: Guice provision errors:

1) Error injecting constructor, java.lang.Error: Failed to wait for condition org.jenkinsci.test.acceptance.po.CapybaraPortingLayer$1@51bea01c

  at org.jenkinsci.test.acceptance.po.Jenkins.<init>(Jenkins.java:35)

  at org.jenkinsci.test.acceptance.po.Jenkins.class(Jenkins.java:29)

  while locating org.jenkinsci.test.acceptance.po.Jenkins

    for field at core.BuildHistoryTest.j(BuildHistoryTest.java:19)

  while locating core.BuildHistoryTest

1 error

at com.google.inject.internal.Errors.throwProvisionExceptionIfErrorsExist(Errors.java:451)

at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:65)

at com.google.inject.internal.InjectorImpl.injectMembers(InjectorImpl.java:944)

at org.jenkinsci.test.acceptance.junit.JenkinsAcceptanceTestRule$1.evaluate(JenkinsAcceptanceTestRule.java:30)

at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:271)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:70)

at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:50)

at org.junit.runners.ParentRunner$3.run(ParentRunner.java:238)

at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:63)

at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:236)

at org.junit.runners.ParentRunner.access$000(ParentRunner.java:53)

at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:229)

at org.junit.runners.ParentRunner.run(ParentRunner.java:309)

at org.junit.runner.JUnitCore.run(JUnitCore.java:160)

at com.intellij.junit4.JUnit4IdeaTestRunner.startRunnerWithArgs(JUnit4IdeaTestRunner.java:74)

at com.intellij.rt.execution.junit.JUnitStarter.prepareStreamsAndStart(JUnitStarter.java:202)

at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:65)

at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)

at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)

at com.intellij.rt.execution.application.AppMain.main(AppMain.java:120)

Caused by: java.lang.Error: Failed to wait for condition org.jenkinsci.test.acceptance.po.CapybaraPortingLayer$1@51bea01c

at org.jenkinsci.test.acceptance.po.CapybaraPortingLayer.waitForCond(CapybaraPortingLayer.java:97)

at org.jenkinsci.test.acceptance.po.CapybaraPortingLayer.waitForCond(CapybaraPortingLayer.java:107)

at org.jenkinsci.test.acceptance.po.CapybaraPortingLayer.waitFor(CapybaraPortingLayer.java:70)

at org.jenkinsci.test.acceptance.po.Jenkins.getVersion(Jenkins.java:45)

at org.jenkinsci.test.acceptance.po.Jenkins.<init>(Jenkins.java:30)

at org.jenkinsci.test.acceptance.po.Jenkins.<init>(Jenkins.java:35)

at org.jenkinsci.test.acceptance.po.Jenkins$$FastClassByGuice$$9bbc559e.newInstance(<generated>)

at com.google.inject.internal.cglib.reflect.$FastConstructor.newInstance(FastConstructor.java:40)

at com.google.inject.internal.DefaultConstructionProxyFactory$1.newInstance(DefaultConstructionProxyFactory.java:60)

at com.google.inject.internal.ConstructorInjector.construct(ConstructorInjector.java:85)

at com.google.inject.internal.ConstructorBindingImpl$Factory.get(ConstructorBindingImpl.java:254)

at com.google.inject.internal.ProviderToInternalFactoryAdapter$1.call(ProviderToInternalFactoryAdapter.java:46)

at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1031)

at com.google.inject.internal.ProviderToInternalFactoryAdapter.get(ProviderToInternalFactoryAdapter.java:40)

at org.jenkinsci.test.acceptance.guice.World$1$1.get(World.java:74)

at com.google.inject.internal.InternalFactoryToProviderAdapter.get(InternalFactoryToProviderAdapter.java:40)

at com.google.inject.internal.SingleFieldInjector.inject(SingleFieldInjector.java:53)

at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:110)

at com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.java:75)

at com.google.inject.internal.MembersInjectorImpl$1.call(MembersInjectorImpl.java:73)

at com.google.inject.internal.InjectorImpl.callInContext(InjectorImpl.java:1024)

at com.google.inject.internal.MembersInjectorImpl.injectAndNotify(MembersInjectorImpl.java:73)

at com.google.inject.internal.MembersInjectorImpl.injectMembers(MembersInjectorImpl.java:60)

... 20 more

Caused by: org.openqa.selenium.TimeoutException: Failed to wait for condition org.jenkinsci.test.acceptance.po.CapybaraPortingLayer$1@51bea01c

Build info: version: '2.40.0', revision: '4c5c0568b004f67810ee41c459549aa4b09c651e', time: '2014-02-19 11:13:01'

System info: host: 'duckjibe', ip: '10.0.0.107', os.name: 'Mac OS X', os.arch: 'x86_64', os.version: '10.9.2', java.version: '1.7.0_45'

Driver info: driver.version: unknown

at org.jenkinsci.test.acceptance.po.CapybaraPortingLayer.waitForCond(CapybaraPortingLayer.java:95)

... 42 more

----------------------------------------------------------------------------------------------------------------------------------------

 

[Kohsuke Kawaguchi]

It's timing out on trying to access the /about page, which seems to indicate that the Jenkins server didn't start properly.

Let me see if I can make the failure mode more obvious, so that we can see why server failed to start or died in the middle.

--
Kohsuke Kawaguchi

[Ulli Hafner]

Actually a firefox window with Jenkins about screen is showing up, but after that nothing else happens.

For more options, visit https://groups.google.com/d/optout.

[oliver gondža]

Hi,

Here is a CI job for acceptance tests:
https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness/

--
oliver

[Kohsuke Kawaguchi]

Yes, so WebDriver is up, and it's waiting until Jenkins server gets fully running, but for some reason it's not coming online.

--
Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

Actually, maybe this is something more stupid --- like us not starting JenkinsController?

I just pushed a fix that might help.

--
Kohsuke Kawaguchi

[Kohsuke Kawaguchi]

I've spent several hours working on the documentation of this.

https://github.com/jenkinsci/acceptance-test-harness

I'm still trying to make this work on Jenkins, and Ulli reported a
failure to run, so there's still some rough edges, but I think it's
making progress.

My favorite addition is prelaunching Jenkins instance [2], which
drastically reduces the time it takes to iteratively develop a test.


[1] https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness/
[2]
https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/PRELAUNCH.md

> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to jenkinsci-de...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>


--

Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

[Vivek Pandey]

Wow, thats pretty good doc improvements, thanks. I have pushed my changes that enables:

- Pool machine instances and keep it ready for reuse

- Each Machine when returned to pool, all processes owned by the user are killed

- SlaveController.install now returns Future, that is each Slave installation happens in separate thread

Kohsuke,  There seems to be regression and subworld bound classes to not see the field injections. the only way for injections to work is via constructor parameters but that makes no sense for tunable optional params. I swear it was working till cd142f180043dc1b41aaed542f5efd88e9562bad.  something changed somewhere in guice modules?

to jenkinsci-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
Try Jenkins Enterprise, our professional version of Jenkins

--
You received this message because you are subscribed to the Google Groups "Jenkins Developers" group.

To unsubscribe from this group and stop receiving emails from it, send an email to jenkinsci-dev+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

[Ulli Hafner]

Thank you very much! This project really is a good starting point for my student projects. We can help to port existing tests or add new ones for missing areas.

I found the problem with the help of Oliver on my machine: the browser is started with my German locale so the Jenkins driver is waiting forever that „About Jenkins“ is appearing on the screen: on my system the text is „Über Jenkins“…
Maybe we should start the browsers with the English locale (this will improve the portability of all tests, too).

Ulli

> For more options, visit https://groups.google.com/d/optout.

[Richard Lavoie]

What about just changing the selector to rely on html markup instead of actual text ?

This will solve the issue altogether of the I18n problem.

Richard Lavoie

[oliver gondža]

On Sat, 15 Mar 2014 22:34:01 +0100, Richard Lavoie
<lavoie....@gmail.com> wrote:

> What about just changing the selector to rely on html markup instead of
> actual text ?
>
> This will solve the issue altogether of the I18n problem.

In this case probably yes, generally no. There are a lot of elements that
are rather obscure to identify using markup so we rely on text labels
quite often (repeatable elements for instance). Adding meaningful ids to
Jenkins UI elements will have other benefits besides UI tests but I am not
convinced it is a good idea (to avoid reading text labels). Verification
is often based on reading text that is a subject of localization. We can
probably rely exclusively on machine readable information like markup and
REST API but then we no longer have acceptance tests from perspective of a
human using web browser.

--
oliver

[Richard Lavoie]

What I actually do is make an API in front of the web app to make an abstraction and allow a user to do what he is supposed to do in term of actions.

That makes the distinction between validating the text against validating the web app behavior when a user interact with the webapp.

For example a user could create a new job like the following.

jenkinsPage.createNewJob().setType(freestyleType).setName("toto").save()

This would click on the menu item "new job" and then select the type from the radio button list, set toto in the text field that represents the job name and create the job.

For repeatable objects, What I do when I have those kind of features is that I look at how many instances there are when the user add a new one to then find the new added html markup, then in my object that represents the repeatable, I can set the proper search context and interact with the proper sub html elements. For exemple :

job.addNewBuildStep(shellScriptType).setScript("... bash script goes here ...")

The addNewBuildStep find the current steps, click on the step to add, find the newly added markup by grabbing again all the steps on the page but remove the steps that were ther before it. You are then left with the newly added step markup element that you can pass to a factory method of scriptType to create an object that represents the specific settings for that type where it's search context is limited to that markup.

A user wants to make interaction, everything "markup" related is handled by the API. Making changes to the layout is then validated/handled by the API. Also, if the text or the markup changes and you didnt't make an API to reflect what a user can do on a page/section of page, alot more work will be involved to fix them all where the functionnalities didn't really change but just the look of it did.

I always feel like validating through finding the proper text is wrong in regard to validating through the functionnalities a page provides. A user typically doesn't want to validate that the proper text is there rather than with some given settings the funcionnalities work as expected.

Richard Lavoie

[Richard Lavoie]

And instead of relying on the text I prefer adding css classes that represents the ui component. Solves the problem of i18n .

Richard Lavoie

[Ulli Hafner]

Any idea why there are some arbitrary failures?

See:
https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness/29/testReport/
https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness/28/testReport/

Ulli

[Kohsuke Kawaguchi]

Over the weekend, I've added code to the acceptance test harness so that
it can upload plugins from where the test runs, as opposed to download
plugins from the community update center.

During the interactive test development and individual test execution
from IDE, you normally run Jenkins under test on the same machine you
run tests, so this is a lot faster.

I've set this mechanism on by default, but it can be disabled with a
custom binding declaration of "uploadPlugins = false" in the wiring
config file. See [1] for more details of how to configure these things.


The actual download mechanism reuses Maven.


[1]
https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/WIRING.md

On 02/28/2014 10:38 AM, Kohsuke Kawaguchi wrote:

> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email
> to jenkinsci-de...@googlegroups.com.

[Kohsuke Kawaguchi]

These age=1 errors all appear to be "Could not bring up a Jenkins
server", and the log output from the Jenkins under test appears to
indicate that they are still in the middle of booting.

The timeout is 100 secs, which I think is sufficiently long.

I'll improve the diagnostics to see if we can tell the process is still
running or not.

[Dominik Bartholdi]

Hey this reminds me of an old PullRequest :)
https://github.com/jenkinsci/jenkins/pull/546

> For more options, visit https://groups.google.com/d/optout.

[Kohsuke Kawaguchi]

On 03/14/2014 11:26 PM, Vivek Pandey wrote:
> Wow, thats pretty good doc improvements, thanks. I have pushed my changes that
> enables:
>
> - Pool machine instances and keep it ready for reuse
> - Each Machine when returned to pool, all processes owned by the user are killed
> - SlaveController.install now returns Future, that is each Slave installation
> happens in separate thread

Thanks!

> Kohsuke, There seems to be regression and subworld bound classes to not see the
> field injections. the only way for injections to work is via constructor
> parameters but that makes no sense for tunable optional params. I swear it was
> working till cd142f180043dc1b41aaed542f5efd88e9562bad. something changed
> somewhere in guice modules?

Do you have any test case to reproduce the problem?

>
>
>
>
>
>
> On Fri, Mar 14, 2014 at 7:30 PM, Kohsuke Kawaguchi <kkawa...@cloudbees.com
> <mailto:kkawa...@cloudbees.com>> wrote:
>
>
> I've spent several hours working on the documentation of this.
>

> https://github.com/jenkinsci/__acceptance-test-harness

> <https://github.com/jenkinsci/acceptance-test-harness>
>
> I'm still trying to make this work on Jenkins, and Ulli reported a failure
> to run, so there's still some rough edges, but I think it's making progress.
>
> My favorite addition is prelaunching Jenkins instance [2], which drastically
> reduces the time it takes to iteratively develop a test.
>
>
> [1]

> https://jenkins.ci.cloudbees.__com/job/core/job/acceptance-__test-harness/
> <https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness/>
> [2]
> https://github.com/jenkinsci/__acceptance-test-harness/blob/__master/docs/PRELAUNCH.md

> https://github.com/jenkinsci/__acceptance-test-harness
> <https://github.com/jenkinsci/acceptance-test-harness>. The plan is to

> rewrite
> page objects, step definitions, and JenkinsController in Java, swap Capybara
> with WebDriver, but keep all the cucumber features intact.
>
>

> [1] https://github.com/jenkinsci/__selenium-tests

> <https://github.com/jenkinsci/selenium-tests>
> --
> Kohsuke Kawaguchi
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send
> an email

> to jenkinsci-dev+unsubscribe@__googlegroups.com
> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/__groups/opt_out
> <https://groups.google.com/groups/opt_out>.

>
>
>
> --
> Kohsuke Kawaguchi | CloudBees, Inc. | http://cloudbees.com/
> Try Jenkins Enterprise, our professional version of Jenkins
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an

> email to jenkinsci-dev+unsubscribe@__googlegroups.com
> <mailto:jenkinsci-dev%2Bunsu...@googlegroups.com>.
> For more options, visit https://groups.google.com/d/__optout
> <https://groups.google.com/d/optout>.

>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Jenkins Developers" group.
> To unsubscribe from this group and stop receiving emails from it, send an email

> to jenkinsci-de...@googlegroups.com
> <mailto:jenkinsci-de...@googlegroups.com>.

> For more options, visit https://groups.google.com/d/optout.
>

[Kohsuke Kawaguchi]

There's no downside to adding micro-formats, CSS class names, and so on
to make HTML pages more machine readable in the core, so we should be
doing that whenever we find them. So I just added the version attribute
to <h1> in that spirit.

I should also note that the primary machine readable endpoints on
Jenkins are REST APIs, and for example, the version information of
Jenkins is quite easily available in the response HTTP header.

Also, adding those micro-formats won't really help this test harness any
time soon as we need to be able to test existing releases of Jenkins.


In the mean time, looks like Ulli made the change to launch browser in
the English locale, so we are unblocked.

[Vivek Pandey]

On Mon, Mar 17, 2014 at 11:00 AM, Kohsuke Kawaguchi <kkawa...@cloudbees.com> wrote:

Kohsuke,  There seems to be regression and subworld bound classes to not see the
field injections. the only way for injections to work is via constructor
parameters but that makes no sense for tunable optional params. I swear it was
working till cd142f180043dc1b41aaed542f5efd88e9562bad.  something changed
somewhere in guice modules?

Do you have any test case to reproduce the problem?

Here is excerpt from my ec2.groovy:

slaves = subworld {

    maxMtMachines=300

    maxNumOfMachines=4

    install(common)

    user="ubuntu"

    bind MachineProvider to MultitenancyMachineProvider

    bind MachineProvider named "raw" to Ec2Provider

}

masters = subworld {

    maxMtMachines=3

    maxNumOfMachines=2

    install(common)

    user="ubuntu"

    bind MachineProvider to MultitenancyMachineProvider

    bind MachineProvider named "raw" to Ec2Provider

}

I think the easiest way to reproduce is to run in debugger with ec2.groovy and set a breakpoint in JcloudsMachineProvider constructor, and check maxNumOfMachines field, it shows 1 instead of 2 from ec2.groovy.

[Ulli Hafner]

Seems that the latest changes broke a lot of tests:
https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness/lastCompletedBuild/testReport/

[oliver gondža]

On Tue, 18 Mar 2014 13:30:28 +0100, Ulli Hafner <ullrich...@gmail.com>
wrote:

> Seems that the latest changes broke a lot of tests:
> https://jenkins.ci.cloudbees.com/job/core/job/acceptance-test-harness/lastCompletedBuild/testReport/

I am looking at it. To me it seems that we are using the plugins UI
elements earlier then they are fully available.

--
oliver

[Ulli Hafner]

Sometimes the tests fail due to the fact that the file path-element.hpi has 0 Bytes file size. Is this plug-in installed differently that the plugins under test? Or can we present that if we package that file in the project?

Ulli