-
Notifications
You must be signed in to change notification settings - Fork 68
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
Declare config file provider test dependency #133
Conversation
Tests run successfully without this dependency when executed from the usual Apache Maven command line as in: $ `mvn clean verify` Tests fail when run in the BOM evaluation as in jenkinsci/bom#1633 . They report that a class from the config file provider plugin could not be found. jenkinsci/bom#1633 (comment) provides details. Testing performed: Duplicated the problem by checking out jenkinsci/bom#1633 and compiling the megawar in the bom directory with: ``` PLUGINS=matrix-auth TEST=InjectedTest bash local-test.sh ``` Then built the matrix-auth plugin with this command line ``` BOM_DIR=/home/mwaite/hub/core/bom mvn -Denforcer.skip=true -Djenkins.version=2.381 \ -Djth.jenkins-war.path=$BOM_DIR/target/local-test/megawar.war \ -DoverrideWar=$BOM_DIR/target/local-test/megawar.war \ -DoverrideWarAdditions=true -DuseUpperBounds=true \ -DupperBoundsExcludes=javax.servlet:servlet-api \ -Dtest=ImportTest \ clean verify ``` That shows the failure in the matrix-auth 3.1.6 release. Then modified the matrix-auth pom.xml file as noted in this commit and ran the same code again. The test passed. The additional test dependency does not modify the production code. It will allow the next release of the matrix-auth plugin to be included in the Jenkins plugin bill of materials.
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.
@daniel-beck please release
Why is the fix needed in this plugin and not in whatever upstream component changed? jenkinsci/bom#1435 (comment) looks like an explanation but I don't get it. Wouldn't this apply to all dependencies? Also, nothing about the Not opposed to merging, but I'd like to understand it first given this doesn't look too urgent. (If it is, an explanation why would be nice.) |
I think that the merge is more an effort to keep versions current in the plugin bom than it is anything urgent. I don't think there is any particular urgency to merge it, though not merging it may cause other surprises, since matrix-auth 3.1.6 then won't be tested as part of the plugin bom test suites. The plugin bill of materials will continue to deliver matrix-auth 3.1.5 rather than 3.1.6, but since I've closed the pull request that proposed to update to matrix-auth 3.1.6, maintainers of the plugin bom won't see new pull requests for matrix-auth plugin until the next release of matrix-auth plugin. I don't object to leaving the matrix-auth dependency at 3.1.5 in the plugin bom while more investigation is done. I'm not personally willing to do that further investigation because I think it is simpler to resolve the issue by adding a test dependency than by doing the root cause analysis to identify which specific change introduced the issue. Apologies for my laziness in this case, but a new test dependency seems much easier than bisecting the changes to the matrix-auth plugin to find an upstream root cause. |
Just ran into this issue yet again in another BOM PR. It has been 3 months and 15 days since this PR has been filed; what gives? |
I asked the above question 3 weeks ago. @daniel-beck did not respond. |
For a narrow definition of not responding, sure. #136 and jenkinsci/bom#1911 are a response to the underlying problem. At the moment, I'm looking to integrate changes to justify a release with #136. While I made the nicer DSL in #111 (comment) work, I haven't figured out how to adapt it so the Job DSL CasC looks better (and IMO it doesn't make sense to integrate the YAML DSL change in isolation). Right now, I'm looking at JENKINS-67368 to at least have something. |
Am I understanding correctly that unblocking others in BOM did not justify a release? |
I wouldn't want to block others work, but so far I am unaware that I am blocking anything. AFAIUI, the problem was that |
As I wrote very clearly in …
… this was blocking me in jenkinsci/bom#1908, and I was only able to move forward in that PR by reducing test coverage (disabling |
Declare config file provider test dependency
Tests run successfully without this dependency when executed from the usual Apache Maven command line as in:
Tests fail when run in the BOM evaluation as in jenkinsci/bom#1633 . They report that a class from the config file provider plugin could not be found.
jenkinsci/bom#1633 (comment) provides details.
Testing performed
Duplicated the problem by checking out jenkinsci/bom#1633 and compiling the megawar in the bom directory with:
Then built the matrix-auth plugin with this command line
That shows the failure in the matrix-auth 3.1.6 release.
Then modified the matrix-auth pom.xml file as noted in this commit and ran the same code again. The test passed.
Rationale
The additional test dependency does not modify the production code. It will allow the next release of the matrix-auth plugin to be included in the Jenkins plugin bill of materials.