Inject classpath for Gradle plugin functional tests #5149
Conversation
There was a problem hiding this comment.
Thanks for looking into this @3flex, this is great!
I have some thoughts on how to possibly make it work, but it's complex and might be better explored in a future PR.
As you said, it looks a bit brittle :/ Should we touch base with someone at Gradle and ask for some support here?
As a workaround, having the CI fake a version publishing on CI would catch the same kind of issues (i.e. bump the version number, run publishToMavenLocal, run build). Agree that is suboptimal, but is more maintanaible.
I actually didn't say the solution in this PR was brittle, I was suggesting it might not be so easy to make the dependencies directly available to the build under test, so that next step would be more complex. Though it can be done manually in the meantime, as you see in this POC. What part of this do you see as being brittle? I said "reverse engineered" but should have said "adapted the code Gradle is using", namely the So there's nothing novel about this solution. It needs a little refactoring (and I realise the extension is pointless as there's only a single task, so I'll remove that to simplify), but this should work just as reliably as the TestKit plugin classpath injection that TestKit itself uses. |
This avoids using the dependencies from the included build
Maybe is just my personal taste, but having to inject the classpath using string manipulation and populating the I understand that this aligns to what TestKit is doing internally, so I'm fine with it. I would have preferred to have an official solution to this problem provided by Gradle, but seems like this is the best we can do so far. As a side note: please leave comments around on why this is needed, as it's not straightforward from reading the code, especially if you have no idea about how Gradle works internally |
|
This PR is stale because it has been open 90 days with no activity. Please comment or this will be closed in 7 days. |
|
I'll reopen when I come back to this |
An alternative to #4905
I took the approach of reverse engineering the Gradle functionality that allows plugin classpaths to be injected when using TestKit. This custom solution can't yet go as far as making the injected classpath directly accessible in the build under test, as the TestKit plugin classpath injection uses some code in TestKit itself to make that seamless, which we can't take advantage of. I have some thoughts on how to possibly make it work, but it's complex and might be better explored in a future PR.
I will likely tweak the DSL and add a little more functionality into
InjectedDependenciesPluginbut I think this is good enough for an initial review.