On 07/03/2019 22.46, Julien HENRY wrote:
Hi folks,
Hey, I am sorry to hear you have come such a long way without
discovering what is already available. (my replies inline)
In the SonarQube plugin
<https://github.com/SonarSource/sonar-scanner-jenkins>, we have
developed our own WebDriver based framework
<https://github.com/SonarSource/sonar-scanner-jenkins/blob/sonar-2.8.1/its/src/test/java/com/sonar/it/jenkins/orchestrator/JenkinsOrchestrator.java>
to test our plugin, including many Jenkins UI utility methods (create
job, configure tools, ...). I discovered only "recently" the official
acceptance-test-harness
<https://github.com/jenkinsci/acceptance-test-harness> project that
seems to aim at the same goal. Maybe it was not existing when we started
writing ITs but that's not important.
Today I would like to drop our own code, and use the common
acceptance-test-harness, in order to save us some efforts, but I'm also
ready to contribute. I have started migrating our test suites but so far
I faced two issues:
1) location of the gecko driver
On my box, this code
<https://github.com/jenkinsci/acceptance-test-harness/blob/0973fb5d80f9936e32bdd2387eeeacf2096e4331/src/main/java/org/jenkinsci/test/acceptance/FallbackConfig.java#L168>
looks wrong, since it ends up configuring gecko driver property to:
which: no geckodriver in (<all my path entries>)
Also I tried to force manually the path using the property
-Dwebdriver.gecko.driver=xxx but it doesn't work, since the same code
always override the property, without checking first if it was already
defined. To me it seems the code only work when geckodriver *is* in the
PATH.
Yeah, it appears to be an expectation in the code, but keeping the
property if configured makes sense to me. Please, file that PR.
2) SonarQube Scanner tool automatic installer returns outdated entries
My test was failing because it was not able to configure a SonarQube
Scanner tool. After debugging, I was surprised to discover that the
installer metadata are already cached
<https://github.com/jenkinsci/acceptance-test-harness/blob/master/src/main/tool_installers/updates/hudson.plugins.sonar.SonarRunnerInstaller>
when the JUT starts (and uses a very old copy). So the real update
center
<https://updates.jenkins.io/updates/hudson.plugins.sonar.SonarRunnerInstaller.json>
is never called.
Is there any reason to have
this hudson.plugins.sonar.SonarRunnerInstaller file in the
acceptance-test-harness distribution? Can I simply open a PR to remove
it, or is there a good reason to keep it?
They ware checked in in order to speed things up and IIRC prevent a race
condition of attempting to configure those tools in test before the
updates are fetched. It is hackish as hell but I suspect it will be
quite elaborate to get rid of that. Feel free to just check in a newer
version to keep you going.
--
oliver
--
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+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.com/d/msgid/jenkinsci-dev/5d7cc7ff-1049-54d0-3026-ca58fd1a85e1%40gmail.com.
For more options, visit https://groups.google.com/d/optout.
