acceptance-test-harness questions
36 views
Skip to first unread message
Julien HENRY
Mar 7, 2019, 4:46:51 PM3/7/19
to Jenkins Developers
Hi folks,
In the SonarQube plugin, we have developed our own WebDriver based framework to test our plugin, including many Jenkins UI utility methods (create job, configure tools, ...). I discovered only "recently" the official 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 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.
I will try to submit a PR with some improvements, except if you told me I missed something.
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 when the JUT starts (and uses a very old copy). So the real update center 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?
Thanks for any insight
Julien
Oliver Gondža
Mar 11, 2019, 9:43:46 AM3/11/19
to jenkin...@googlegroups.com
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
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>
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
> 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
> job, configure tools, ...). I discovered only "recently" the official
> acceptance-test-harness
> 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>
> 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
> 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
> 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.
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
> 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>
> center
> 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
>
> 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?
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
Julien HENRY
Mar 17, 2019, 4:49:46 PM3/17/19
to jenkin...@googlegroups.com
Hi Olivier,
I opened a PR:
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:
--
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 jenkinsci-de...@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.
Oliver Gondža
Mar 19, 2019, 2:20:17 PM3/19/19
to Julien HENRY, jenkin...@googlegroups.com
On 19/03/2019 17.26, Julien HENRY wrote:
> My tests are green when executed with Jenkins 2.164.1! That's already
> great news, thanks for your help.
>
> But with the oldest Jenkins version we are supporting (2.89.4), all
> pipeline related tests are failing. I wonder if this could be an issue
> with the update center.
Quite likely, see[1] to check for which LTS lines we still distribute
update centers. 2.89 is the latest we have dropped the UC for to this
day. The infra falls back to UC for latest weekly and it is not able to
satisfy plugin dependencies given the ancient core.
You might want to setup and maintain you own UC for releases you support
to prevent this from happening (as upstream UCs are rotated
(a)periodically) if you have not already.
[1] https://updates.jenkins-ci.org/
> @WithPlugins("workflow-aggregator")
>
> In logs, I can see:
>
> *16:27:41* INFO: workflow-aggregator is not installed
>
> [...]
>
> *16:27:41* Mar 19, 2019 4:27:41 PM org.jenkinsci.test.acceptance.junit.WithPlugins$RuleImpl$1 installPlugins
> *16:27:41* INFO: Installing plugins for test: [workflow-aggregator, sonar, filesystem_scm, plain-credentials]
>
> [...]
>
> *16:28:27* master57755|INFO: Adding dependent install of pipeline-model-definition for plugin workflow-aggregator
>
> [...]
>
> *16:28:27* master57755|INFO: Adding dependent install of workflow-cps-global-lib for plugin pipeline-model-definition
>
> [...]
>
> *16:28:35* master57755|INFO: Starting the installation of Pipeline: Shared Groovy Libraries on behalf of anonymous
> *16:28:35* Mar 19, 2019 4:28:35 PM org.jenkinsci.test.acceptance.update_center.MockUpdateCenter lambda$ensureRunning$3
> *16:28:35* INFO: serving /home/ssjenka/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-cps-global-lib/2.13/workflow-cps-global-lib-2.13.hpi
> *16:28:36* master57755|Mar 19, 2019 4:28:35 PM hudson.model.UpdateCenter$UpdateCenterConfiguration download
> *16:28:36* master57755|INFO: Downloading Pipeline: Shared Groovy Libraries
> *16:28:36* master57755|Mar 19, 2019 4:28:35 PM hudson.PluginManager dynamicLoad
> *16:28:36* master57755|INFO: Attempting to dynamic load /home/ssjenka/cix/workspace/sonar-scanner-jenkins-qa/4adbdb2c/its/target/jenkins1486774028372987495home/plugins/workflow-cps-global-lib.jpi
> *16:28:36* master57755|Mar 19, 2019 4:28:36 PM hudson.model.UpdateCenter$DownloadJob run
> *16:28:36* master57755|SEVERE: Failed to install Pipeline: Shared Groovy Libraries
> *16:28:36* master57755|java.io.IOException: Failed to dynamically deploy this plugin
> *16:28:36* master57755| at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1893)
> *16:28:36* master57755| at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1651)
> *16:28:36* master57755| at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> *16:28:36* master57755| at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> *16:28:36* master57755| at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:110)
> *16:28:36* master57755| at java.lang.Thread.run(Thread.java:748)
> *16:28:36* master57755|Caused by: java.io.IOException: Failed to install workflow-cps-global-lib plugin
> *16:28:36* master57755| at hudson.PluginManager.dynamicLoad(PluginManager.java:882)
> *16:28:36* master57755| at hudson.PluginManager.dynamicLoad(PluginManager.java:821)
> *16:28:36* master57755| at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1889)
> *16:28:36* master57755| ... 5 more
> *16:28:36* master57755|Caused by: java.io.IOException: Pipeline: Shared Groovy Libraries v2.13 failed to load.
> *16:28:36* master57755| - You must update Jenkins from v2.89.4 to v2.107.3 or later to run this plugin.
> *16:28:36* master57755| at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:626)
> *16:28:36* master57755| at hudson.PluginManager.dynamicLoad(PluginManager.java:872)
> *16:28:36* master57755| ... 7 more
>
>
> Do you know why is workflow-cps-global-lib plugin 2.13 selected to be
> installed if it is not compatible with Jenkins 2.89.4? Shouldn't it
> always select the latest compatible version?
>
>
>
> Julien Henry | SonarSource
>
> Developer
>
> https://sonarsource.com <https://sonarsource.com/>
>
>
> Le mar. 19 mars 2019 à 14:01, Julien HENRY <julien...@sonarsource.com
> <mailto:julien...@sonarsource.com>> a écrit :
>
> You got it right :)
>
> I have tested removing the sha1 only and it works fine, I will open
> a PR.
>
> Julien Henry | SonarSource
>
> Developer
>
> https://sonarsource.com <https://sonarsource.com/>
>
>
> Le mar. 19 mars 2019 à 10:05, Oliver Gondža <ogo...@gmail.com
> <mailto:ogo...@gmail.com>> a écrit :
>
> Hey, let me see if I understand that.
>
> Your ATH version is new enough to correctly spoof the checksum
> so it
> works (for latest Jenkins versions, at least). Where it does not
> work is
> older versions of Jenkins, from before the sha512 was
> introduced, since
> the other checksums are not modified.
>
> Provided this is correct, I would be more than welcome to
> propose a fix
> to add them in the spirit of[1]. BTW, I might not be remembering
> this
> correctly, but older versions of Jenkins was accepting metadata
> with no
> checksum at all[2] so removing the sha1 _might_ work equally well.
>
> Hope that helps!
>
> [1]
> https://github.com/jenkinsci/acceptance-test-harness/commit/240e438e2a3ab719a7301ab112de470fd503572e#diff-e5a5651006d379f437e8f02dfa5866deR133
> [2]
> https://github.com/jenkinsci/acceptance-test-harness/commit/240e438e2a3ab719a7301ab112de470fd503572e#diff-e5a5651006d379f437e8f02dfa5866deL129
>
> On 19/03/2019 09.31, Julien HENRY wrote:
> > Hi Olivier,
> >
> > New question today. Tests are passing locally on my box. But
> I have some
> > errors when trying to run them on our CI.
> >
> > The error is:
> >
> > *16:14:32* master60888|INFO: Starting the installation of
> SonarQube Scanner on behalf of anonymous
> > *16:14:32* Mar 18, 2019 4:14:31 PM
> org.jenkinsci.test.acceptance.update_center.MockUpdateCenter
> lambda$ensureRunning$3
> > *16:14:32* INFO: serving
> /home/ssjenka/cix/workspace/sonar-scanner-jenkins-qa/4bfcaa4d/its/sonar-2.9.0.2184.hpi
> > *16:14:32* master60888|Mar 18, 2019 4:14:31 PM
> hudson.model.UpdateCenter$UpdateCenterConfiguration download
> > *16:14:32* master60888|INFO: Downloading SonarQube Scanner
> > *16:14:32* master60888|Mar 18, 2019 4:14:32 PM
> hudson.model.UpdateCenter$DownloadJob run
> > *16:14:32* master60888|SEVERE: Failed to install SonarQube
> Scanner
> > *16:14:32* master60888|java.io <http://java.io>.IOException:
> Downloaded file
> /home/ssjenka/cix/workspace/sonar-scanner-jenkins-qa/4bfcaa4d/its/target/jenkins5732199865628847180home/plugins/sonar.jpi.tmp
> does not match expected SHA-1, expected
> 'Eus1cNBamti/4FOVkn3XRwCvvKc=', actual
> 'yfMPBYKO2mBfTUzsaVdgGB3l0KI='
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter.verifyChecksums(UpdateCenter.java:1810)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter.access$1100(UpdateCenter.java:149)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$InstallationJob.replace(UpdateCenter.java:1963)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$UpdateCenterConfiguration.install(UpdateCenter.java:1194)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:1680)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1874)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1651)
> > *16:14:32* master60888| at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> > *16:14:32* master60888| at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > *16:14:32* master60888| at
> hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:112)
> > *16:14:32* master60888| at
> java.lang.Thread.run(Thread.java:748)
> > *16:14:32* master60888|
> > *16:14:32* master60888|Mar 18, 2019 4:14:32 PM
> hudson.model.UpdateCenter$DownloadJob run
> >
> >
> > I'm "installing" our plugin under test using:
> > export LOCAL_JARS=$PWD/sonar-$CURRENT_VERSION.hpi
> >
> > and I have checked earlier logs and the MockUpdateCenter
> seems to work fine:
> >
> > *16:13:38* INFO: Installing plugins for test: [sonar,
> filesystem_scm, plain-credentials]
> > *16:13:38*
> Downloadinghttps://updates.jenkins-ci.org/update-center.json?version=2.107.3
> <http://updates.jenkins-ci.org/update-center.json?version=2.107.3>
> to /tmp/update-center-2.107.3.jsonp
> > *16:13:40* Overriding sonar 2.8.1 with local build of 2.9.0.2184
> >
> > [...]
> >
> > *16:13:40* Mar 18, 2019 4:13:40 PM
> org.jenkinsci.test.acceptance.update_center.MockUpdateCenter
> updating
> > *16:13:40* INFO: for sonar updating version from 2.8.1 to
> 2.9.0.2184
> > *16:13:40* Mar 18, 2019 4:13:40 PM
> org.jenkinsci.test.acceptance.update_center.MockUpdateCenter
> updating
> > *16:13:40* INFO: for sonar updating gav from
> org.jenkins-ci.plugins:sonar:2.8.1 to
> org.jenkins-ci.plugins:sonar:2.9.0.2184
> >
> >
> > I have looked at the code and I found that MockUpdateCenter
> is only
> > replacing the sha512:
> >
> https://github.com/jenkinsci/acceptance-test-harness/blob/9551635b62f9a6456d1fae8d2c02dfd0f4cfe2c8/src/main/java/org/jenkinsci/test/acceptance/update_center/MockUpdateCenter.java#L135
> >
> > Then I discovered that support of sha512 was only added
> "recently":
> >
> https://github.com/jenkinsci/jenkins/commit/6dc32977fc6772a2e18452672d69b8b93ea3e832
> >
> > In our ITs we are testing a matrix including the older
> supported Jenkins
> > version and the more recent LTS. What about changing the
> > MockUpdateCenter to also support overriding sha1 to support
> older
> > Jenkins versions?
> >
> > ++
> >
> > Julien Henry | SonarSource
> >
> > Developer
> >
> > https://sonarsource.com <https://sonarsource.com/>
> >
> >
> > Le lun. 18 mars 2019 à 08:05, Oliver Gondža
> <ogo...@gmail.com <mailto:ogo...@gmail.com>
> > <mailto:ogo...@gmail.com <mailto:ogo...@gmail.com>>> a écrit :
> to cause a
> > problem somewhere, but yes, why not.
> >
> > Thanks for the 2 PRs. One was merged right away, the
> other one needs
> > some polishing but looks good as well.
> >
> > --
> > oliver
> >
>
>
> --
> oliver
>
--
oliver
> My tests are green when executed with Jenkins 2.164.1! That's already
> great news, thanks for your help.
>
> But with the oldest Jenkins version we are supporting (2.89.4), all
> pipeline related tests are failing. I wonder if this could be an issue
> with the update center.
Quite likely, see[1] to check for which LTS lines we still distribute
update centers. 2.89 is the latest we have dropped the UC for to this
day. The infra falls back to UC for latest weekly and it is not able to
satisfy plugin dependencies given the ancient core.
You might want to setup and maintain you own UC for releases you support
to prevent this from happening (as upstream UCs are rotated
(a)periodically) if you have not already.
[1] https://updates.jenkins-ci.org/
> @WithPlugins("workflow-aggregator")
>
> In logs, I can see:
>
> *16:27:41* INFO: workflow-aggregator is not installed
>
> [...]
>
> *16:27:41* Mar 19, 2019 4:27:41 PM org.jenkinsci.test.acceptance.junit.WithPlugins$RuleImpl$1 installPlugins
> *16:27:41* INFO: Installing plugins for test: [workflow-aggregator, sonar, filesystem_scm, plain-credentials]
>
> [...]
>
> *16:28:27* master57755|INFO: Adding dependent install of pipeline-model-definition for plugin workflow-aggregator
>
> [...]
>
> *16:28:27* master57755|INFO: Adding dependent install of workflow-cps-global-lib for plugin pipeline-model-definition
>
> [...]
>
> *16:28:35* master57755|INFO: Starting the installation of Pipeline: Shared Groovy Libraries on behalf of anonymous
> *16:28:35* Mar 19, 2019 4:28:35 PM org.jenkinsci.test.acceptance.update_center.MockUpdateCenter lambda$ensureRunning$3
> *16:28:35* INFO: serving /home/ssjenka/.m2/repository/org/jenkins-ci/plugins/workflow/workflow-cps-global-lib/2.13/workflow-cps-global-lib-2.13.hpi
> *16:28:36* master57755|Mar 19, 2019 4:28:35 PM hudson.model.UpdateCenter$UpdateCenterConfiguration download
> *16:28:36* master57755|INFO: Downloading Pipeline: Shared Groovy Libraries
> *16:28:36* master57755|Mar 19, 2019 4:28:35 PM hudson.PluginManager dynamicLoad
> *16:28:36* master57755|INFO: Attempting to dynamic load /home/ssjenka/cix/workspace/sonar-scanner-jenkins-qa/4adbdb2c/its/target/jenkins1486774028372987495home/plugins/workflow-cps-global-lib.jpi
> *16:28:36* master57755|Mar 19, 2019 4:28:36 PM hudson.model.UpdateCenter$DownloadJob run
> *16:28:36* master57755|SEVERE: Failed to install Pipeline: Shared Groovy Libraries
> *16:28:36* master57755|java.io.IOException: Failed to dynamically deploy this plugin
> *16:28:36* master57755| at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1893)
> *16:28:36* master57755| at hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1651)
> *16:28:36* master57755| at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> *16:28:36* master57755| at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> *16:28:36* master57755| at hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:110)
> *16:28:36* master57755| at java.lang.Thread.run(Thread.java:748)
> *16:28:36* master57755|Caused by: java.io.IOException: Failed to install workflow-cps-global-lib plugin
> *16:28:36* master57755| at hudson.PluginManager.dynamicLoad(PluginManager.java:882)
> *16:28:36* master57755| at hudson.PluginManager.dynamicLoad(PluginManager.java:821)
> *16:28:36* master57755| at hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1889)
> *16:28:36* master57755| ... 5 more
> *16:28:36* master57755|Caused by: java.io.IOException: Pipeline: Shared Groovy Libraries v2.13 failed to load.
> *16:28:36* master57755| - You must update Jenkins from v2.89.4 to v2.107.3 or later to run this plugin.
> *16:28:36* master57755| at hudson.PluginWrapper.resolvePluginDependencies(PluginWrapper.java:626)
> *16:28:36* master57755| at hudson.PluginManager.dynamicLoad(PluginManager.java:872)
> *16:28:36* master57755| ... 7 more
>
>
> Do you know why is workflow-cps-global-lib plugin 2.13 selected to be
> installed if it is not compatible with Jenkins 2.89.4? Shouldn't it
> always select the latest compatible version?
>
>
>
> Julien Henry | SonarSource
>
> Developer
>
> https://sonarsource.com <https://sonarsource.com/>
>
>
> Le mar. 19 mars 2019 à 14:01, Julien HENRY <julien...@sonarsource.com
> <mailto:julien...@sonarsource.com>> a écrit :
>
> You got it right :)
>
> I have tested removing the sha1 only and it works fine, I will open
> a PR.
>
> Julien Henry | SonarSource
>
> Developer
>
> https://sonarsource.com <https://sonarsource.com/>
>
>
> Le mar. 19 mars 2019 à 10:05, Oliver Gondža <ogo...@gmail.com
> <mailto:ogo...@gmail.com>> a écrit :
>
> Hey, let me see if I understand that.
>
> Your ATH version is new enough to correctly spoof the checksum
> so it
> works (for latest Jenkins versions, at least). Where it does not
> work is
> older versions of Jenkins, from before the sha512 was
> introduced, since
> the other checksums are not modified.
>
> Provided this is correct, I would be more than welcome to
> propose a fix
> to add them in the spirit of[1]. BTW, I might not be remembering
> this
> correctly, but older versions of Jenkins was accepting metadata
> with no
> checksum at all[2] so removing the sha1 _might_ work equally well.
>
> Hope that helps!
>
> [1]
> https://github.com/jenkinsci/acceptance-test-harness/commit/240e438e2a3ab719a7301ab112de470fd503572e#diff-e5a5651006d379f437e8f02dfa5866deR133
> [2]
> https://github.com/jenkinsci/acceptance-test-harness/commit/240e438e2a3ab719a7301ab112de470fd503572e#diff-e5a5651006d379f437e8f02dfa5866deL129
>
> On 19/03/2019 09.31, Julien HENRY wrote:
> > Hi Olivier,
> >
> > New question today. Tests are passing locally on my box. But
> I have some
> > errors when trying to run them on our CI.
> >
> > The error is:
> >
> > *16:14:32* master60888|INFO: Starting the installation of
> SonarQube Scanner on behalf of anonymous
> > *16:14:32* Mar 18, 2019 4:14:31 PM
> org.jenkinsci.test.acceptance.update_center.MockUpdateCenter
> lambda$ensureRunning$3
> > *16:14:32* INFO: serving
> /home/ssjenka/cix/workspace/sonar-scanner-jenkins-qa/4bfcaa4d/its/sonar-2.9.0.2184.hpi
> > *16:14:32* master60888|Mar 18, 2019 4:14:31 PM
> hudson.model.UpdateCenter$UpdateCenterConfiguration download
> > *16:14:32* master60888|INFO: Downloading SonarQube Scanner
> > *16:14:32* master60888|Mar 18, 2019 4:14:32 PM
> hudson.model.UpdateCenter$DownloadJob run
> > *16:14:32* master60888|SEVERE: Failed to install SonarQube
> Scanner
> > *16:14:32* master60888|java.io <http://java.io>.IOException:
> Downloaded file
> /home/ssjenka/cix/workspace/sonar-scanner-jenkins-qa/4bfcaa4d/its/target/jenkins5732199865628847180home/plugins/sonar.jpi.tmp
> does not match expected SHA-1, expected
> 'Eus1cNBamti/4FOVkn3XRwCvvKc=', actual
> 'yfMPBYKO2mBfTUzsaVdgGB3l0KI='
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter.verifyChecksums(UpdateCenter.java:1810)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter.access$1100(UpdateCenter.java:149)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$InstallationJob.replace(UpdateCenter.java:1963)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$UpdateCenterConfiguration.install(UpdateCenter.java:1194)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$DownloadJob._run(UpdateCenter.java:1680)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$InstallationJob._run(UpdateCenter.java:1874)
> > *16:14:32* master60888| at
> hudson.model.UpdateCenter$DownloadJob.run(UpdateCenter.java:1651)
> > *16:14:32* master60888| at
> java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> > *16:14:32* master60888| at
> java.util.concurrent.FutureTask.run(FutureTask.java:266)
> > *16:14:32* master60888| at
> hudson.remoting.AtmostOneThreadExecutor$Worker.run(AtmostOneThreadExecutor.java:112)
> > *16:14:32* master60888| at
> java.lang.Thread.run(Thread.java:748)
> > *16:14:32* master60888|
> > *16:14:32* master60888|Mar 18, 2019 4:14:32 PM
> hudson.model.UpdateCenter$DownloadJob run
> >
> >
> > I'm "installing" our plugin under test using:
> > export LOCAL_JARS=$PWD/sonar-$CURRENT_VERSION.hpi
> >
> > and I have checked earlier logs and the MockUpdateCenter
> seems to work fine:
> >
> > *16:13:38* INFO: Installing plugins for test: [sonar,
> filesystem_scm, plain-credentials]
> > *16:13:38*
> Downloadinghttps://updates.jenkins-ci.org/update-center.json?version=2.107.3
> <http://updates.jenkins-ci.org/update-center.json?version=2.107.3>
> to /tmp/update-center-2.107.3.jsonp
> > *16:13:40* Overriding sonar 2.8.1 with local build of 2.9.0.2184
> >
> > [...]
> >
> > *16:13:40* Mar 18, 2019 4:13:40 PM
> org.jenkinsci.test.acceptance.update_center.MockUpdateCenter
> updating
> > *16:13:40* INFO: for sonar updating version from 2.8.1 to
> 2.9.0.2184
> > *16:13:40* Mar 18, 2019 4:13:40 PM
> org.jenkinsci.test.acceptance.update_center.MockUpdateCenter
> updating
> > *16:13:40* INFO: for sonar updating gav from
> org.jenkins-ci.plugins:sonar:2.8.1 to
> org.jenkins-ci.plugins:sonar:2.9.0.2184
> >
> >
> > I have looked at the code and I found that MockUpdateCenter
> is only
> > replacing the sha512:
> >
> https://github.com/jenkinsci/acceptance-test-harness/blob/9551635b62f9a6456d1fae8d2c02dfd0f4cfe2c8/src/main/java/org/jenkinsci/test/acceptance/update_center/MockUpdateCenter.java#L135
> >
> > Then I discovered that support of sha512 was only added
> "recently":
> >
> https://github.com/jenkinsci/jenkins/commit/6dc32977fc6772a2e18452672d69b8b93ea3e832
> >
> > In our ITs we are testing a matrix including the older
> supported Jenkins
> > version and the more recent LTS. What about changing the
> > MockUpdateCenter to also support overriding sha1 to support
> older
> > Jenkins versions?
> >
> > ++
> >
> > Julien Henry | SonarSource
> >
> > Developer
> >
> > https://sonarsource.com <https://sonarsource.com/>
> >
> >
> > Le lun. 18 mars 2019 à 08:05, Oliver Gondža
> <ogo...@gmail.com <mailto:ogo...@gmail.com>
> > <mailto:ogo...@gmail.com <mailto:ogo...@gmail.com>>> a écrit :
> >
> > On 17/03/2019 21.49, Julien HENRY wrote:
> >
> > > 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?
> >
> > Extra cere must be taken to make sure this is not going
> > On 17/03/2019 21.49, Julien HENRY wrote:
> >
> > > 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?
> >
> to cause a
> > problem somewhere, but yes, why not.
> >
> > Thanks for the 2 PRs. One was merged right away, the
> other one needs
> > some polishing but looks good as well.
> >
> > --
> > oliver
> >
>
>
> --
> oliver
>
--
oliver
Julien HENRY
Mar 20, 2019, 11:48:10 AM3/20/19
to Oliver Gondža, jenkin...@googlegroups.com
Hi Olivier,
Any suggestion on how to achieve this? Basically I would like to take a copy of the update center corresponding to the oldest version of Jenkins we support, and use it in our ITs. This page give several ways to control plugin versions, but I haven't found a way to point the update center to a local json file for example.
Oliver Gondža
Mar 25, 2019, 8:48:22 AM3/25/19
to Julien HENRY, jenkin...@googlegroups.com
On 20/03/2019 16.47, Julien HENRY wrote:
> Hi Olivier,
>
> Hi Olivier,
>
> Any suggestion on how to achieve this? Basically I would like to take a
> copy of the update center corresponding to the oldest version of Jenkins
> we support, and use it in our ITs. This page
> <https://github.com/jenkinsci/acceptance-test-harness/blob/master/docs/SUT-VERSIONS.md>
> copy of the update center corresponding to the oldest version of Jenkins
> we support, and use it in our ITs. This page
> give several ways to control plugin versions, but I haven't found a way
> to point the update center to a local json file for example.
You would have to assemble update center for that Jenkins version is
> to point the update center to a local json file for example.
some way. By assemble I mean identify plugin versions that does not
require newer Jenkins core while still having dependencies satisfied.
The idea with modified json file is clever, but I am not sure if someone
has ever tried that. I have just tested that it can be injected in via
`-Dupdate_center_url=file:update-center.json` java property property,
but it misbehaves in case the url got cached earlier. To fix that, [1]
needs to be updated not to cache custom `update_center_url`.
[1]
https://github.com/jenkinsci/acceptance-test-harness/blob/master/src/main/java/org/jenkinsci/test/acceptance/update_center/CachedUpdateCenterMetadataLoader.java#L38
--
oliver
Reply all
Reply to author
Forward
0 new messages