-
Bug
-
Resolution: Fixed
-
Minor
Vivek and I have been able to reliably reproduce test failures in blueocean-plugin when using the plugin-pom:2.28. I also saw these errors using a 2.27 snapshot deployed in support of JENKINS-43411
The tests pass when run in CI, or when individual tests are run locally. But when running a full build locally (mvn clean install) the tests fail 100% of the time. Vivek believes it's related to jenkins-test-harness:2.22.
blueocean-pipeline-api-impl has the following broken tests:
Failed tests:
BranchContainerImplTest.testBranchOrdering:57 expected:<200> but was:<403>
MultiBranchTest.createUserFavouriteMultibranchBranchTest:666 expected:<200> but was:<403>
MultiBranchTest.createUserFavouriteMultibranchTopLevelTest:591 expected:<200> but was:<403>
Tests in error:
CredentialApiTest.createSshCredentialUsingDefaultSshOnMasterInUserStore:250 » Runtime
CredentialApiTest.createSshCredentialUsingDirectSshInUserStore:213 » Runtime c...
CredentialApiTest.createUsingUsernamePasswordInUserStore:186 » Runtime com.mas...
MultiBranchTest.favoritedFromClassicTest:741 » Runtime com.mashape.unirest.htt...
And here's one of the more interesting error details:
{
"message" : "This user 'anonymous' cannot access resource owned by 'alice'",
"code" : 403,
"errors" : [ ]
}; line: 1, column: 1]
at io.jenkins.blueocean.rest.impl.pipeline.PipelineBaseTest$RequestBuilder.build(PipelineBaseTest.java:542)
at io.jenkins.blueocean.rest.impl.pipeline.MultiBranchTest.favoritedFromClassicTest(MultiBranchTest.java:741)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:498)
at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:50)
at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:12)
at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:47)
at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:17)
at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:26)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.jvnet.hudson.test.JenkinsRule$2.evaluate(JenkinsRule.java:547)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:325)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:78)
at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:57)
at org.junit.runners.ParentRunner$3.run(ParentRunner.java:290)
at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:71)
at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:288)
at org.junit.runners.ParentRunner.access$000(ParentRunner.java:58)
at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:268)
at org.junit.rules.ExternalResource$1.evaluate(ExternalResource.java:48)
at org.junit.rules.RunRules.evaluate(RunRules.java:20)
at org.junit.runners.ParentRunner.run(ParentRunner.java:363)
at org.apache.maven.surefire.junit4.JUnit4Provider.execute(JUnit4Provider.java:367)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeWithRerun(JUnit4Provider.java:274)
at org.apache.maven.surefire.junit4.JUnit4Provider.executeTestSet(JUnit4Provider.java:238)
at org.apache.maven.surefire.junit4.JUnit4Provider.invoke(JUnit4Provider.java:161)
at org.apache.maven.surefire.booter.ForkedBooter.invokeProviderInSameClassLoader(ForkedBooter.java:290)
at org.apache.maven.surefire.booter.ForkedBooter.runSuitesInProcess(ForkedBooter.java:242)
at org.apache.maven.surefire.booter.ForkedBooter.main(ForkedBooter.java:121)
- blocks
-
JENKINS-43411 Evaluate yarn
-
- Resolved
-
[JENKINS-44423] Upgrading blueocean to plugin-pom:2.8+ breaks unit tests
cliffmeyers so this needs some of vivek's time to unblock JENKINS-43411? cc michaelneale
When do we need to upgrade that pom? that determines when vivek can chip away at this (likely have to juggled dependencies).
It would be required in order to port the build to yarn. However I'd like the new extensibility system to land first because I think it will obviate the need for a lot of npm publishing, and there is a known bug (w/ slightly tedious workaround) when publishing to npm using yarn with a custom registry.
cliffmeyers right, on top of that, it sounds like npm is upping its game in response to this stuff... so lets keep this one parked. I think will need vivek to take a look at this to resolve it at some point right?
Right, vivek is probably best suited. This is just a little too far outside my area of expertise to productively troubleshoot. Presumably we'll want to upgrade our parent POM at some point for reasons other than yarn, so that's when I opened this ticket so we don't forget it's an issue.
vivek had spent some time investigating but had to shelve the work.
Comment on related PR: https://github.com/jenkinsci/blueocean-plugin/pull/981#issuecomment-302723928
"(Possibly just that you depend on Jenkins 2.x and you were assuming that detached plugins would be loaded implicitly in tests. This is no longer true; there is a TestPluginManager method to explicitly load them, but much better to have all plugins you expect to test against be test-scoped dependencies.)"