Replace unit test usage of Subversion repo resources with Git
Description
Environment
Activity
Brent Putman March 21, 2017 at 2:31 AM
Jenkins tests are passing now that I added explicit version to the java-support test-jar dependency decls in the POMs. I thought java-support was a managed dep in the downstream projects, but I guess not.
Closing this out.
Brent Putman March 21, 2017 at 2:29 AM
Btw, based on the gitweb docs, I was earlier trying to get this to work with the pathinfo style of URL. I couldn't at first get it working, so I didn't do it that way for the tests yet.
However, I did just get it to work, like so:
https://git.shibboleth.net/view/gitweb.cgi/java-opensaml.git/blob_plain/master:/opensaml-core/pom.xml
Had to add in the "/gitweb.cgi/" part.
I always hated the ViewVC query param style, and always turned on the "clean URL" style support. This style I think makes it easier if we ever wanted to use path-based access controls (e.g. via Shib SP) to limit access to any of the web views.
So glad to see that this is already working with out gitweb install.
Brent Putman March 21, 2017 at 1:56 AM
This is done. I did abstract the repo URL behind a helper class and method, in java-support test classpath.
For the IdP Spring parser test XML files, I put some new stuff in the metadata resolver tests base class to allow to supply a PropertySource
when initing the app context. The tests then programmatically build a mock source with the helper method and supply that on the bean call. All the XML files were updated to use properties instead of literal values for the various metadata URLs.
I had to disable a couple of tests for the dynamic resolver in java-opensaml, which were testing validation of the MIME type returned by the server (type supported by the resolver vs not). Unlike ViewVC, gitweb doesn't seem to have any way to request a specific MIME type to be returned, so I can't vary the returned type on the call.
Right now just fighting with Jenkins to get the upstream projects to "see" the java-support test-jar test scope dependency. As soon as that is resolved, I will close this out.
Rod Widdowson March 20, 2017 at 2:24 PM
The test which actually used SVN is fixed to use a local SVN: 95772c3
Brent Putman March 19, 2017 at 8:06 PM(edited)
All I was thinking with the support method comment was a test classpath utility class used something like this:
String url = ProjectRepoSupport.buildResourceURL("java-opensaml", "opensaml-xmlsec-impl/src/test/resources/org/opensaml/xmlsec/signature/support/InCommon-metadata.xml")
So just to centralize all the URL boilerplate details, so if we change repo locations (e.g. GitHub), or if GitWeb's parameters requirements changes, we just update in one place.
But that's only about 6 test classes with direct repo URL usage. The vast majority is in metadata provider XML files. The factory bean idea sounded good... until I realized that all of those are actually custom schema, so we can't just plugin a factory bean, AFAIK. Properties would work, but then we lose a bit of locality of reference. It might be more work to set all that up than to just fix the URL literals in the XML. But that would allow reusing the support method code, I think.
I'll look at in detail tomorrow-ish. Worst case is we don't do anything that fancy, and we just update the URLs in place. That's easy enough. Don't want to make this too complicated.
Various unit tests in the IdP and OpenSAML reference and pull HTTP resources directly from our Subversion repos via web server access like:
http://svn.shibboleth.net/view/java-opensaml/trunk/opensaml-xmlsec-impl/src/test/resources/org/opensaml/xmlsec/signature/support/InCommon-metadata.xml?content-type=text%2Fplain&view=co
Replace with the equivalent Git URLs, such as:
https://git.shibboleth.net/view/?p=java-opensaml.git&a=blob_plain&f=opensaml-xmlsec-impl/src/test/resources/org/opensaml/xmlsec/signature/support/InCommon-metadata.xml&hb=master
Probably hide this behind a helper function somewhere (we should have originally anyway).
However, a lot of usage is actually in src/test/resources XML files, so probably can't avoid hard-coding there.