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
Fix build issues #6424
Fix build issues #6424
Conversation
Codecov ReportPatch coverage:
Additional details and impacted files@@ Coverage Diff @@
## main #6424 +/- ##
=========================================
Coverage 85.07% 85.07%
- Complexity 4026 4029 +3
=========================================
Files 566 566
Lines 13162 13167 +5
Branches 2363 2364 +1
=========================================
+ Hits 11197 11202 +5
Misses 794 794
Partials 1171 1171
☔ View full report in Codecov by Sentry. |
I was going to ask this in my next PR but I guess it fits here as well. How should I handle changes that will affect the functional tests (such as the removal of the weights and maxIssues). As far as I understood the functional tests use the latest version of detekt. I did change the tests in the PR but then the build failed. |
They should, but they're not in all cases for some reason. I have a POC fix in #6415 which is ugly but works and might be the way forward. We clearly need a reliable solution. |
Updates were missed in detekt#6389 due to lack of properly configured integration tests.
@detekt/maintainers please review. CI should be green going forward, and this should also catch missed updates to Gradle plugin functional test updates in future PRs. |
@@ -21,6 +21,7 @@ class DetektPlugin : Plugin<Project> { | |||
) | |||
|
|||
extension.reportsDir = project.extensions.getByType(ReportingExtension::class.java).file("detekt") | |||
extension.basePath = project.layout.projectDirectory.asFile.absolutePath |
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.
This is an actual fix for recent PRs, right?
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.
It's a fix, but only for tests on Windows.
When TestKit executes tests it starts the daemon from the Gradle plugin project directory but the build under test is in a different directory. That's ok building locally in most cases but on GitHub runner one of those directories is on C: but the other is on D:
There's no way to get a relative file path from one drive to another, which causes build failures. The base path is determined based on a compiled class's resource path which is on one drive, but the absolute path to the file checked by detekt is on another drive.
The CLI defaults base path to user.dir
so adding this line makes it more correct when running from Gradle. Technically it should be rootDir to match current behaviour but still fix the build... I've made that change. It's more correct to use projectDir I think but that's technically a behaviour change so can do that in another PR.
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.
Will the absolute path break cache relocation in Gradle when executed on CI vs Local builds on user's setups?
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.
Hmm yes it will due to the usage of @Input
on that property, I did check the annotation on the task but didn't think of the consequences. I'll submit a PR to fix.
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.
Here's a potentially interesting way to validate this (never tried it myself, just read it somewhere):
https://github.com/gradle/gradle-enterprise-build-validation-scripts/blob/main/Gradle.md#structure
could run on a fully standalone integration test (like this) after the snapshot is published to maven local similar to what you did in this PR?
uses: gradle/gradle-build-action@243af859f8ca30903d9d7f7936897ca0358ba691 # v2 | ||
with: | ||
gradle-home-cache-cleanup: true | ||
arguments: publishToMavenLocal |
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.
Is this better than make the functionalTest
depend on publishToMavebLocal
?
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.
You're right, but I couldn't find a way to do that while the plugin is an included build, so this seemed the next best option.
Skipping this step when running locally may lead to confusion (though that's no different to the current situation) but CI will at least be ok.
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.
Could a similar switcheroo be done here? cashapp/paparazzi#924
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 didn't know there was prior art but there's this draft PR open already to do the same: #6415
I might look at what they did in cashapp org since they often end up setting unofficial standard ways of doing things.
I'll go ahead and merge to unblock other PRs. |
* Remove maxIssues from config in Gradle functional tests See detekt#6408 * Set basepath to project dir by default See detekt#6323 * Fix AbstractClassCanBeInterface violation See detekt#5870 * Fix expected output Updates were missed in detekt#6389 due to lack of properly configured integration tests. * Prioritise Maven Local in repo list for functional tests * Publish artifacts to Maven Local before building detekt * Set root project directory as default base path in DGP
Fix build issues with the Gradle plugin by:
mavenLocal
to the first position in therepositories
block in build files in the functional tests