Hi Olivier, I opened a PR: https://github.com/jenkinsci/acceptance-test-harness/pull/492
Regarding tools: > 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. I'm really surprised some existing acceptance tests but ours are depending on installing the SonarScanner. Would it be possible to submit a PR removing the file, and see what happen? Is the full test suite executed on PRs? Another issues I faced: it seems the code to configure tools isn't generic enough to support adding more than one tool version. This is because in "recent" Jenkins releases, tool area is collapsed as soon as there is a first entry, so the "Add" button is not visible until you expand. I opened a PR: https://github.com/jenkinsci/acceptance-test-harness/pull/493 Julien Henry | SonarSource Developer https://sonarsource.com Le lun. 11 mars 2019 à 14:43, Oliver Gondža <[email protected]> a écrit : > 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 a topic in the > Google Groups "Jenkins Developers" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/jenkinsci-dev/BNuQMy3lsFY/unsubscribe. > To unsubscribe from this group and all its topics, send an email to > [email protected]. > 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. > -- 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-dev/CAD9wyxHruUVNYfNzgozL_i3ayD1dRF-%3Dobi9zL%3DneTfRbbHK%3DQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
