-
Notifications
You must be signed in to change notification settings - Fork 123
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
[JENKINS-44892] CustomDescribableModel can address SCMSourceRetriever.scm.id problem #65
Conversation
Resolved conflicts with jenkinsci#67.
if (scm instanceof UninstantiatedDescribable) { | ||
UninstantiatedDescribable scmUd = (UninstantiatedDescribable) scm; | ||
Map<String, Object> scmArguments = new HashMap<>(scmUd.getArguments()); | ||
scmArguments.remove("id"); |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
Rebuilding because the Windows agent had connectivity issues. |
<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> |
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, will try that.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
moving
git-client
todependencyManagement
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
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
|
Reproducible. Not dealing with it here, but 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
|
<dependencyManagement> | ||
<dependencies> | ||
<dependency> | ||
<groupId>org.jenkins-ci.plugins</groupId> |
There was a problem hiding this comment.
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).
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
Note that as described in JIRA, this will not magically fix things for |
Downstream of jenkinsci/structs-plugin#43.