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-44892] CustomDescribableModel can address SCMSourceRetriever.scm.id problem #65

Merged

Conversation

jglick
Copy link
Member

@jglick jglick commented Apr 9, 2019

@jglick jglick requested a review from dwnusbaum June 20, 2019 19:15
if (scm instanceof UninstantiatedDescribable) {
UninstantiatedDescribable scmUd = (UninstantiatedDescribable) scm;
Map<String, Object> scmArguments = new HashMap<>(scmUd.getArguments());
scmArguments.remove("id");
Copy link
Member

Choose a reason for hiding this comment

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

So IIUC, the problem is that we don't want this ID to be part of the model, since it should be unique to each instance?

Copy link
Member Author

Choose a reason for hiding this comment

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

Right. SCMSource does a weird trick that does not work like your typical Describable: it generates a random id each time you instantiate it, but also lets the ID be customized.

@dwnusbaum
Copy link
Member

Rebuilding because the Windows agent had connectivity issues.

@dwnusbaum dwnusbaum closed this Jun 20, 2019
@dwnusbaum dwnusbaum reopened this Jun 20, 2019
<workflow-cps-plugin.version>2.69</workflow-cps-plugin.version>
<git-plugin.version>3.6.4</git-plugin.version>
<scm-api-plugin.version>2.2.7</scm-api-plugin.version>
<git-plugin.version>4.0.0-rc</git-plugin.version>
Copy link
Member

Choose a reason for hiding this comment

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

PR looks good, but I want to wait for a stable release of git 4.x before merging the change (Commenting so I don't forget about this later). What would happen if we merged this as-is and released to the non-experimental update center? Broken instances for everyone because they can't satisfy the git dependency?

Copy link
Member Author

Choose a reason for hiding this comment

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

git is only a test-scoped dep, but git-client is a problem because it is in dependencies as compile scope:

Plugin-Dependencies: workflow-cps:2.69,workflow-scm-step:2.4,workflow-step-api:2.19,workflow-support:3.3,cloudbees-folder:6.1.0,credentials:2.1.14,git-client:3.0.0-rc,git-server:1.7,scm-api:2.3.0,script-security:1.58,structs:1.18

I suspect it is only there to satisfy RequireUpperBoundsDeps, in which case it would better be moved to dependencyManagement and then would not appear in the release at all. Would that suffice from your PoV?

Copy link
Member

Choose a reason for hiding this comment

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

Oops, I totally missed git being test-scope. Yeah if moving git-client into dependencyManagement gets it out of compile scope but tests still pass then I'd be fine to merge the change at that point.

Copy link
Member Author

Choose a reason for hiding this comment

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

OK, will try that.

Copy link
Member

Choose a reason for hiding this comment

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

Ok, merged this a bit prematurely because I did not actually run mvn dependency:tree. This library has a compile-scope dependency on git-server which itself has a compile-scope dependency on git-client, so moving git-client to dependencyManagement does not fix the problem, and so the plugin currently has an experimental release as a compile-scope dependency. I'm not sure to what extent git-server uses git-client or if there is an easy fix for this. Maybe safest to revert the merge for now?

Copy link
Member Author

Choose a reason for hiding this comment

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

moving git-client to dependencyManagement does not fix the problem

It does because it does not have a direct dependency on git-client, so it does not appear in the manifest.

mvn -DskipTests clean package
unzip -p target/workflow-cps-global-lib.hpi META-INF/MANIFEST.MF | perl -p -0777 -e 's/\r?\n //g' | fgrep Plugin-Dependencies

Plugin-Dependencies: workflow-cps:2.69,workflow-scm-step:2.4,workflow-step-api:2.19,workflow-support:3.3,cloudbees-folder:6.1.0,credentials:2.1.14,git-server:1.7,scm-api:2.3.0,script-security:1.58,structs:1.18

Copy link
Member

@dwnusbaum dwnusbaum Jun 27, 2019

Choose a reason for hiding this comment

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

Ok makes sense, in an actual instance the version of git-client required by the plugin will be whatever git-server 1.7 requires because of how Jenkins resolves plugin dependencies.

Copy link
Member Author

@jglick jglick Jun 27, 2019

Choose a reason for hiding this comment

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

Well it will be whatever version of git-client the user happens to have installed. git-server only requires 1.11.0, which is quite old. The current version offered on the general UC is 2.8.0.

Lots of other deps could probably be moved to dependencyManagement too;
would be useful to have a tool which does this automatically based on source/bytecode scans.
@jglick jglick requested a review from dwnusbaum June 21, 2019 17:34
@dwnusbaum
Copy link
Member

GrapeTest.var failed in the CI build because of a script-security issue, not sure offhand how/if it relates to the changes in this PR:

Scripts not permitted to use method org.apache.commons.math3.FieldElement add java.lang.Object. Administrators can decide whether to approve or reject this signature.

@jglick
Copy link
Member Author

jglick commented Jun 21, 2019

Reproducible. Not dealing with it here, but someone is going to need to bisect this stuff to find out why.

@dwnusbaum
Copy link
Member

someone is going to need to bisect this stuff to find out why.

The problem is the jenkins-test-harness 2.50 update. Using plugin-pom 3.45 with jenkins-test-harness 2.49 the test passes. Looks like the issue is that jenkinsci/jenkins-test-harness#135 added a dependency on jmh-core, which has a transitive dependency on commons-math3, which is the library grabbed in the test, so it breaks things (because it comes from the wrong class loader?). I guess the simplest fix would be to make the test @Grab some other library that is not already on the classpath somewhere to make the test work again.

mvn dependency:tree for jenkins-test-harness master:

[INFO] +- org.openjdk.jmh:jmh-core:jar:1.21:compile
[INFO] |  +- net.sf.jopt-simple:jopt-simple:jar:4.6:compile
[INFO] |  \- org.apache.commons:commons-math3:jar:3.2:compile

@dwnusbaum dwnusbaum merged commit 95ebc4c into jenkinsci:master Jun 25, 2019
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.jenkins-ci.plugins</groupId>
Copy link
Member

Choose a reason for hiding this comment

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

Lots of other deps could probably be moved to dependencyManagement too; would be useful to have a tool which does this automatically based on source/bytecode scans.

I realize that the Jenkins community is fairly Maven-centric, but FYI Netflix's Gradle Lint Plugin has this feature (c.f. Unused Dependency Rule).

Copy link
Member Author

Choose a reason for hiding this comment

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

I think it is likely there is a Maven equivalent, I just have not looked for it yet.

Copy link
Member

Choose a reason for hiding this comment

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

I think it is likely there is a Maven equivalent, I just have not looked for it yet.

Looks like the Maven Dependency Plugin can list unused declared dependencies, though (just like the Gradle version) there seem to be too many false positives for it to be usable as part of any kind of automated enforcement.

Copy link
Member Author

Choose a reason for hiding this comment

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

The problem of false positives is compounded by the heavy use of reflection, Groovy views, etc. etc. in Jenkins sources.

@jglick jglick deleted the CustomDescribableModel-JENKINS-44892 branch June 25, 2019 16:55
@jglick
Copy link
Member Author

jglick commented Jun 25, 2019

Note that as described in JIRA, this will not magically fix things for configuration-as-code, which unfortunately does not use DescribableModel but reimplements a similar reflection system.

@dwnusbaum dwnusbaum changed the title CustomDescribableModel can address SCMSourceRetriever.scm.id problem [JENKINS-44892] CustomDescribableModel can address SCMSourceRetriever.scm.id problem Jun 25, 2019
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.

3 participants