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-65757] only use pluginFirst classloader when you have no other option (and never for guice!) #151

Merged
merged 7 commits into from
Jun 17, 2021

Conversation

jtnord
Copy link
Member

@jtnord jtnord commented Jun 7, 2021

JENKINS-65757 The dependencies was a mess due to pulling libraries in that where comletely un-needed.

Even plexus could probably be removed with a bit more effort - but at least plexus is safe.

Maven etc was pulling in guva and a misguided attempt to bundle it along with the plugin first classloaded caused all hell to break loose as guice saw things loaded from separate classloaders and it was not happy

Added a proper realistic E2E test (there where not even any semi realistic ones) using RealJenkinsRule to ensure this still works with a FreeStyleProject creating jacoco coverage via maven (a tag of this project)

  • Make sure you are opening from a topic/feature/bugfix branch (right side) and not your main branch!
  • Ensure that the pull request title represents the desired changelog entry
  • Please describe what you did
  • Link to relevant issues in GitHub or Jira
  • Link to relevant pull requests, esp. upstream and downstream changes
  • Ensure you have provided tests - that demonstrates feature works or fixes the issue

FileFilter just joined the passed in excludes as a comma separated list
and added defaults if the list was empty or null, But the code already handles this so just call the Plex util directly
@@ -530,7 +361,6 @@ THE SOFTWARE.
</execution>
</executions>
<configuration>
<pluginFirstClassLoader>true</pluginFirstClassLoader>
Copy link
Member Author

Choose a reason for hiding this comment

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

we do not need this, we are safe with maskClasses now after removing other conflicting libraries

@@ -19,7 +19,6 @@
import org.jacoco.core.data.ExecutionDataReader;
import org.jacoco.core.data.ExecutionDataStore;
import org.jacoco.core.data.SessionInfoStore;
import org.jacoco.maven.FileFilter;
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 caused a whole slew of the maven dependencies and for no real reason.

@@ -122,9 +121,8 @@ private IBundleCoverage analyzeStructure() throws IOException {
excludes = ITEM_ZERO;
Copy link
Member Author

@jtnord jtnord Jun 7, 2021

Choose a reason for hiding this comment

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

so this is the default exclude - but I have no idea why. the default in maven in the empty String, but here we use "{0}" 🤷

public class E2ETest {

@Rule
public RealJenkinsRule rjr = new RealJenkinsRule();
Copy link
Member Author

Choose a reason for hiding this comment

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

}

private static List<Builder> createJacocoProjectBuilders() {
String[] commands = { "git clone --branch jacoco-3.2.0 https://github.com/jenkinsci/jacoco-plugin.git .",
Copy link
Member Author

Choose a reason for hiding this comment

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

whilst running maven inside a test is not the best, we are using this project as the test (and a tag) so we at least have most of the dependencies already local.

It will diverge over time, so we may want to try and keep this somewhat in sync

Copy link
Member

Choose a reason for hiding this comment

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

So binaries "git" and "mvn" need to be available on the CI node for this to work, right?

Copy link
Member Author

@jtnord jtnord Jun 8, 2021

Choose a reason for hiding this comment

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

yes, but maven already is as it is what runs the build that runs this test :)

as for git the CI could have cloned using jgit rather than the git CLI so it may not be available, but ci.jenkins.io is not setup like that.
A developer could work exclusively with IntelliJ or Eclipse (again jgit) but I am not convinced that is likely.

Copy link
Member

Choose a reason for hiding this comment

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

For a more reproducible environment:

  • store a small test project in src/test/resources/sampleproj/
  • use dependency:copy to unpack a specific release of Maven into target/test-classes/

but still use the Java in path I guess.

JDK11 and JDK8 compilers generate different bytecode and so asserting
the bytecode instruction coverage would need to be different on
potentially different compilers (e.g eclipse vs jdk 8 vs jdk11 vs ...)
@jtnord jtnord closed this Jun 7, 2021
@jtnord jtnord reopened this Jun 7, 2021
the shade plugin was bound to a phase that did not exist in the hpi
packaging type.

even if it did it would be completely unclear what it did as the shade
plugin does not play nicely with hpis.
@jtnord jtnord closed this Jun 7, 2021
@jtnord jtnord reopened this Jun 7, 2021
@MarkEWaite
Copy link
Contributor

I loaded the PR build https://ci.jenkins.io/job/Plugins/job/jacoco-plugin/job/PR-151/4/ into my Jenkins instance and confirmed that it reports JaCoCo coverage as expected for the platformlabeler plugin test job that uses it. Thanks so much for your work on this @jtnord !

@batmat batmat requested review from basil and centic9 June 8, 2021 08:45
@centic9
Copy link
Member

centic9 commented Jun 8, 2021

Thanks for the suggested simplification, would be nice to be able to merge this. Some of these dependencies were necessary to make "validate" succeed and not complain about mismatched versions, did you try running that maven target as well?

e.g. the following needs to succeed to be able to release:
mvn clean package && mvn validate

Also some tests seem to be failing in CI, is this caused by some of the changes?

@jtnord jtnord mentioned this pull request Jun 8, 2021
6 tasks
@jtnord
Copy link
Member Author

jtnord commented Jun 8, 2021

validate is one of the first phases and is run before the test phase, so this is covered by existing Jenkins jobs and yes there are no upperBounds errors.

@jtnord
Copy link
Member Author

jtnord commented Jun 8, 2021

Also some tests seem to be failing in CI, is this caused by some of the changes?

@centic9 any link? - all the statuses are green after 40f5613 and the failures I saw on ci.jenkins.io (which caused me to retrigger the build) where due to agent infrastructure issues and not test failures.
Please let me know if I missed something.

Copy link
Member

@centic9 centic9 left a comment

Choose a reason for hiding this comment

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

Ok, thanks for confirming, I was looking at CI-results of 91837c8 which showed some failing tests, it seems some newer build now succeeds fully again.

}

private static List<Builder> createJacocoProjectBuilders() {
String[] commands = { "git clone --branch jacoco-3.2.0 https://github.com/jenkinsci/jacoco-plugin.git .",
Copy link
Member

Choose a reason for hiding this comment

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

So binaries "git" and "mvn" need to be available on the CI node for this to work, right?

@MarkEWaite
Copy link
Contributor

So binaries "git" and "mvn" need to be available on the CI node for this to work, right?

@centic9 yes, the ci.jenkins.io agents used for buildPlugin must include mvn and git. The git plugin, the git-client plugin, and many others rely on that assumption. It is safe to rely on that in the jacoco plugin as well.

<maven.version>3.8.1</maven.version>
<powermock.version>2.0.7</powermock.version>
<!-- until the plugin-pom picks up a newer version -->
<jenkins-test-harness.version>1589.vc23fca066d5c</jenkins-test-harness.version>
Copy link
Member

Choose a reason for hiding this comment

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

}

private static List<Builder> createJacocoProjectBuilders() {
String[] commands = { "git clone --branch jacoco-3.2.0 https://github.com/jenkinsci/jacoco-plugin.git .",
Copy link
Member

Choose a reason for hiding this comment

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

For a more reproducible environment:

  • store a small test project in src/test/resources/sampleproj/
  • use dependency:copy to unpack a specific release of Maven into target/test-classes/

but still use the Java in path I guess.

Copy link
Member

@basil basil left a comment

Choose a reason for hiding this comment

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

Much nicer!

maven-hpi-plugin output before
[INFO] --- maven-hpi-plugin:3.17:hpi (default) @ jacoco ---
[INFO] Generating src/jenkinsci/jacoco-plugin/target/jacoco/META-INF/MANIFEST.MF
[INFO] Checking for attached .jar artifact ...
[INFO] Generating jar src/jenkinsci/jacoco-plugin/target/jacoco.jar
[INFO] Building jar: src/jenkinsci/jacoco-plugin/target/jacoco.jar
[INFO] Exploding webapp...
[INFO] Copy webapp webResources to src/jenkinsci/jacoco-plugin/target/jacoco
[INFO] Assembling webapp jacoco in src/jenkinsci/jacoco-plugin/target/jacoco
[WARNING] Bundling transitive dependency guice-4.2.1.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency javax.inject-1.jar (via jacoco-maven-plugin)
[INFO] Bundling direct dependency httpcore-4.4.13.jar
[WARNING] Bundling transitive dependency maven-reporting-api-3.0.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-resolver-api-1.6.2.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-resolver-impl-1.6.2.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-resolver-spi-1.6.2.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-resolver-util-1.6.2.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency file-management-1.2.1.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-shared-io-1.1.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-shared-utils-3.2.1.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency wagon-provider-api-1.0-alpha-6.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-artifact-manager-2.0.2.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-builder-support-3.8.1.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-core-3.8.1.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-model-builder-3.8.1.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-repository-metadata-3.8.1.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-resolver-provider-3.8.1.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency maven-settings-builder-3.8.1.jar (via jacoco-maven-plugin)
[INFO] Bundling direct dependency plexus-utils-3.2.1.jar
[WARNING] Bundling transitive dependency org.eclipse.sisu.inject-0.3.4.jar (via jacoco-maven-plugin)
[INFO] Bundling direct dependency jacoco-maven-plugin-0.8.7.jar
[WARNING] Bundling transitive dependency org.jacoco.agent-0.8.7.jar (via jacoco-maven-plugin)
[WARNING] Bundling transitive dependency org.jacoco.core-0.8.7.jar (via org.jacoco.report)
[INFO] Bundling direct dependency org.jacoco.report-0.8.7.jar
[WARNING] Bundling transitive dependency asm-analysis-9.1.jar (via org.jacoco.report)
[WARNING] Bundling transitive dependency asm-commons-9.1.jar (via org.jacoco.report)
[WARNING] Bundling transitive dependency asm-tree-9.1.jar (via org.jacoco.report)
[WARNING] Bundling transitive dependency asm-9.1.jar (via org.jacoco.report)
[INFO] Bundling direct dependency xml-apis-1.4.01.jar
[INFO] Generating hpi src/jenkinsci/jacoco-plugin/target/jacoco.hpi
[INFO] Building jar: src/jenkinsci/jacoco-plugin/target/jacoco.hpi
maven-hpi-plugin output after
[INFO] --- maven-hpi-plugin:3.17:hpi (default-hpi) @ jacoco ---
[INFO] Generating src/jenkinsci/jacoco-plugin/target/jacoco/META-INF/MANIFEST.MF
[INFO] Checking for attached .jar artifact ...
[INFO] Found attached .jar artifact: src/jenkinsci/jacoco-plugin/target/jacoco.jar
[INFO] Exploding webapp...
[INFO] Copy webapp webResources to src/jenkinsci/jacoco-plugin/target/jacoco
[INFO] Assembling webapp jacoco in src/jenkinsci/jacoco-plugin/target/jacoco
[INFO] Bundling direct dependency plexus-utils-3.2.1.jar
[WARNING] Bundling transitive dependency org.jacoco.core-0.8.7.jar (via org.jacoco.report)
[INFO] Bundling direct dependency org.jacoco.report-0.8.7.jar
[WARNING] Bundling transitive dependency asm-analysis-9.1.jar (via org.jacoco.report)
[WARNING] Bundling transitive dependency asm-commons-9.1.jar (via org.jacoco.report)
[WARNING] Bundling transitive dependency asm-tree-9.1.jar (via org.jacoco.report)
[WARNING] Bundling transitive dependency asm-9.1.jar (via org.jacoco.report)
[INFO] Generating hpi src/jenkinsci/jacoco-plugin/target/jacoco.hpi
[INFO] Building jar: src/jenkinsci/jacoco-plugin/target/jacoco.hpi

I noticed we are still bundling ASM 9:

[WARNING] Bundling transitive dependency asm-analysis-9.1.jar (via org.jacoco.report)
[WARNING] Bundling transitive dependency asm-commons-9.1.jar (via org.jacoco.report)
[WARNING] Bundling transitive dependency asm-tree-9.1.jar (via org.jacoco.report)
[WARNING] Bundling transitive dependency asm-9.1.jar (via org.jacoco.report)

This also seems to be the reason for maskClasses. This is unnecessary since 2.274, which bundles ASM 9 in the WAR via jnr-posix (formalized in the core BOM in jenkinsci/jenkins#5525). I suggest updating jenkins.version to 2.277.1 or later, then excluding the ASM dependencies as is done in token-macro. Then maskClasses wouldn't be needed at all and this plugin would be slimmer as well.

@jtnord
Copy link
Member Author

jtnord commented Jun 9, 2021

@centic9 would you be able to merge and release this sometime this week please?

@batmat
Copy link
Member

batmat commented Jun 9, 2021

@basil to be clear, I suppose you mean we should do this in general, not necessarily in this PR right? Thanks
(I am strongly in general in favor to have separate PRs when possible, easier to review and land, etc. :-))

@jtnord
Copy link
Member Author

jtnord commented Jun 9, 2021

This also seems to be the reason for maskClasses. This is unnecessary since 2.274, which bundles ASM 9 in the WAR via jnr-posix (formalized in the core BOM in jenkinsci/jenkins#5525). I suggest updating jenkins.version to 2.277.1 or later, then excluding the ASM dependencies as is done in token-macro. Then maskClasses wouldn't be needed at all and this plugin would be slimmer as well.

using an unshaded ASM is core is probably a mistake and it should not really happen. Jenkins core should not be pulling moar libraries into Jenkins core, and ASM specifically is known to not be compatible between versions, so this plugin could break at a moments notice if we updated jnr-posix to a version that say included ASM10 and where not providing our own ASM. Seems risky.

@MRamonLeon
Copy link
Contributor

@centic9 , @ognjenb do you consider merging and releasing this change please? Thank you!

@batmat
Copy link
Member

batmat commented Jun 16, 2021

@centic9 hi, can you please consider merging & relasing?
As users mentioned on the linked jira, this issue even prevents Jenkins from starting, so it looks like a release would be good :-).

We can help on this if you need it. Just let us know.

Thanks a lot!

@centic9
Copy link
Member

centic9 commented Jun 16, 2021

Sorry, I was not aware of the impact of the changes as there was no mentioning in the PR.

Unfortunately in general I can not spend much time on this plugin, only the bare minimum to keep it alive :(

I can roll a release today or tomorrow.

If there is someone who is interested in the plugin enough to step in and spend time on general maintenance, please contact me or simply apply for access rights!

Otherwise it will probably soon go towards "unmaintained" state as there are other alternatives by now anyway...

@centic9 centic9 merged commit e54a545 into jenkinsci:master Jun 17, 2021
@centic9
Copy link
Member

centic9 commented Jun 17, 2021

I pushed out 3.3.0 now with these changes.

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

Successfully merging this pull request may close these issues.

8 participants