Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[JENKINS-57653] Introduce JMH benchmarks to Jenkins Test Harness #135

Merged
merged 17 commits into from
Jun 13, 2019

Conversation

AbhyudayaSharma
Copy link
Member

@AbhyudayaSharma AbhyudayaSharma commented Jun 3, 2019

Introduces Java Microbenchmark Harness benchmarks to the test harness to allow JMH benchmarks to be run from everywhere with Jenkins instance available in JMH forks.

This was first implemented in the Role Strategy Plugin. Demo from the May 31st meeting: https://www.youtube.com/watch?v=sr28UADG1AE

Part of Google Summer of Code 2019.

Downstream PRs:

@jenkinsci/gsoc2019-role-strategy

@oleg-nenashev oleg-nenashev self-requested a review June 3, 2019 12:35
@@ -85,8 +85,7 @@ THE SOFTWARE.
<dependency>
<groupId>org.jenkins-ci.main</groupId>
<artifactId>jenkins-war</artifactId>
<!--to have access to User.getById-->
<version>1.651.2</version>
<version>2.60.3</version>
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

As discussed in Gitter, I am about submitting a wider thread about dropping Java 7 support in our devtools

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

pom.xml Outdated Show resolved Hide resolved
pom.xml Outdated Show resolved Hide resolved
@AbhyudayaSharma
Copy link
Member Author

AbhyudayaSharma commented Jun 4, 2019

I can confirm the same test failure happens by upgrading Jenkins core on the latest master.

@oleg-nenashev
Copy link
Member

My bad about the matrix auth suggestion. Let's stick to 2.60.3 if possible. If you already spent some time on Matrix Auth benchmarks, we can definitely suggest them in Matrix Auth plugin later

@AbhyudayaSharma
Copy link
Member Author

My bad about the matrix auth suggestion. Let's stick to 2.60.3 if possible. If you already spent some time on Matrix Auth benchmarks, we can definitely suggest them in Matrix Auth plugin later

Since Role Strategy and Matrix auth both have some issues, what plugin should I go with here just to verify that Configuration as Code is working?

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The code looks good to me, just few minor comments.

I think we could proceed with documentation for the change:

  • Benchmarking documentation could be put directly into the repository (e.g. under docs/), no specific need to keep it elsewhere. JUnit was outside due to historical reasons
  • Polish Javadoc a bit so that new classes have some documentation and annotations (maybe with a link to documentation in the repo)

.gitignore Outdated
@@ -13,3 +13,6 @@ out
.classpath
.project
build

# reports produced from benchmarks
jmh-benchmark-report.json
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it might be better to move the default output to target/jmh-reports/* or so so that it follows the convention used in the Maven Surefire Plugin

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done though I had to create the directory from the test method itself.

src/main/java/jenkins/jmh/BenchmarkFinder.java Outdated Show resolved Hide resolved
src/main/java/jenkins/jmh/BenchmarkFinder.java Outdated Show resolved Hide resolved
@oleg-nenashev
Copy link
Member

Incrementals do not seem to work anymore, I will try to figure out the reason.
CC @jglick

[2019-06-04T06:27:31.476Z] Skipping deployment as no artifacts were found with the expected path, typically due to a PR merge build not up to date with its base branch: https://ci.jenkins.io/job/Core/job/jenkins-test-harness/job/PR-135/3/artifact/**/*-rc*.eaa538d48663/*-rc*.eaa538d48663*/*zip*/archive.zip

@jglick
Copy link
Member

jglick commented Jun 4, 2019

typically due to a PR merge build not up to date with its base branch

check this ^^^

@AbhyudayaSharma
Copy link
Member Author

Unrelated failure:

java.io.IOException: Failed to run image 'maven:3.6.1-jdk-8'. Error: docker: Error response from daemon: mkdir /var/lib/docker/overlay2/c35038806833e92d002ad312b4f1335cea820816633af081832183018be2ad78-init: no space left on device.

pom.xml Outdated Show resolved Hide resolved
Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good to me overall, but we need a decision w.r.t inclusion JCasC code here: https://groups.google.com/d/msg/jenkinsci-dev/cgbYEB3c_Vc/dmV6x0oQAgAJ

docs/jmh-benchmarks.adoc Outdated Show resolved Hide resolved
docs/jmh-benchmarks.adoc Show resolved Hide resolved
@oleg-nenashev
Copy link
Member

Retriggerring the build

jglick
jglick previously requested changes Jun 7, 2019
Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see discussion on dev list

pom.xml Outdated Show resolved Hide resolved
@AbhyudayaSharma
Copy link
Member Author

Sorry, I missed it while doing a cleanup of Configuration as code from this pull request.

@oleg-nenashev oleg-nenashev requested a review from jglick June 7, 2019 14:24
@jglick jglick dismissed their stale review June 7, 2019 14:27

addressed

Copy link
Member

@oleg-nenashev oleg-nenashev left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @AbhyudayaSharma ! I discovered one binary compatibility breakage which should be restored imho.

Maybe it also worth moving new static methods from JenkinsRule to a new static class like JenkinsTestHelper , but this is an implementation detail. I do not require changing it

@@ -434,7 +428,15 @@ public void before() throws Throwable {
* Configures the update center setting for the test.
* By default, we load updates from local proxy to avoid network traffic as much as possible.
*/
protected void configureUpdateCenter() throws Exception {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Protected methods can be overridden in other libraries. This change breaks binary compatibility from what I see

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This method did exist but was not doing anything. Thanks for letting me know!

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

AFAICT it was not fixed, right?
Usage:

@AbhyudayaSharma
Copy link
Member Author

Protected methods can be overridden in other libraries. This change breaks binary compatibility from what I see

@oleg-nenashev The method was there but it wasn't being used anywhere so overriding would have made no difference. Thanks a lot for letting me know!

AbhyudayaSharma and others added 2 commits June 10, 2019 21:01
Co-Authored-By: Oleg Nenashev <o.v.nenashev@gmail.com>
@AbhyudayaSharma
Copy link
Member Author

Force pushed to rebase and enable incrementals

@oleg-nenashev
Copy link
Member

@jenkinsci/jenkins-test-harness-developers I would like to merge it if nobody is against

@oleg-nenashev
Copy link
Member

And CC @jenkinsci/core, because the group above is empty

@oleg-nenashev
Copy link
Member

My plan is to merge it by EoD if there is no negative feedback. I checked with @jglick offline, he is fine if I do so (it is a development tool at the end of the day, and its versions can be easily pinned if something goes wrong)

@jglick
Copy link
Member

jglick commented Jun 12, 2019

My general preference is for things like this to live in their own components. Is there a particular reason this needs to be part of jenkins-test-harness? I see some existing classes being patched but it looks like that is just about opening up access to some Java members for reusability.

Copy link
Member

@jglick jglick left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I do not care much about code quality of the benchmark stuff (it is experimental new code after all); focusing on code that was changed in normal JenkinsRule usage.


jenkins.setCrumbIssuer(new TestCrumbIssuer()); // TODO: Move to _configureJenkinsForTest after JENKINS-55240
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I asked for information in JIRA and got none. What is the issue?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

When we use configuration as code to setup the Jenkins instance with TestCrumbIssuer, it was refused to be marshaled. This was happening when the code was in the Role Strategy Plugin.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

use configuration as code to setup the Jenkins instance

So, TestCrumbIssuer not being loaded from the usual location I suppose? Normally it works because of this clause.

src/main/java/org/jvnet/hudson/test/JenkinsRule.java Outdated Show resolved Hide resolved
src/main/java/org/jvnet/hudson/test/JenkinsRule.java Outdated Show resolved Hide resolved
src/main/java/org/jvnet/hudson/test/JenkinsRule.java Outdated Show resolved Hide resolved
@AbhyudayaSharma
Copy link
Member Author

@jglick I have used addSuppressed() for the recording the ignored exceptions. However, I just wanted to let you know that they were part of JenkinsRule. Please see the current master:

jettyLevel(Level.WARNING);
try {
server.stop();
} catch (Exception e) {
// ignore
} finally {
jettyLevel(Level.INFO);
}
for (LenientRunnable r : tearDowns)
try {
r.run();
} catch (Exception e) {
// ignore
}

Thanks for the review! I hope I have answered your comments.

@AbhyudayaSharma
Copy link
Member Author

[2019-06-13T04:29:32.713Z] [ERROR] /home/jenkins/workspace/Core_jenkins-test-harness_PR-135/src/main/java/org/jvnet/hudson/test/JenkinsRule.java:[762,20] non-static variable localPort cannot be referenced from a static context

I don't know what is happening here. Lines 762 and 763 from the latest commit don't even contain the localPort variable.

if (System.getProperty("port")!=null)
connector.setPort(Integer.parseInt(System.getProperty("port")));
server.addConnector(connector);
server.start();

@AbhyudayaSharma
Copy link
Member Author

AbhyudayaSharma commented Jun 13, 2019

It's a merge conflict with #132

@oleg-nenashev
Copy link
Member

@jglick

My general preference is for things like this to live in their own components. Is there a particular reason this needs to be part of jenkins-test-harness? I see some existing classes being patched but it looks like that is just about opening up access to some Java members for reusability.

It allows adding features to plugin POM and Pipeline library, see downstream PRs (will add them to the description). Basically the intention here is to make it easily accessible to plugin developers. We could have created a new "jenkins-performance-test-harness" library ofc, but it would be just another component which would be hard to discover. JMH is built on the top of JUnit, so for me it looks better to just keep the functionality as a part of JTH.

Side Note: There is a PR to JCasC: jenkinsci/configuration-as-code-plugin#921. If the request is to split this code, we will likely need to discuss splitting code there as well. JCasC test automation will be in all major plugins soon, so splitting framework here and keeping it single on the JCasC side would defeat the purpose of splitting.

@jglick
Copy link
Member

jglick commented Jun 13, 2019

let you know that they were part of JenkinsRule

Missed that, sorry. A lot of times when code gets moved around I wind up commenting on things that were actually years old!

@oleg-nenashev
Copy link
Member

Thanks @jglick !

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants