Skip to content
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

Unable to get Log files to generate #205

Open
kingargyle opened this issue Mar 8, 2023 · 9 comments
Open

Unable to get Log files to generate #205

kingargyle opened this issue Mar 8, 2023 · 9 comments

Comments

@kingargyle
Copy link

kingargyle commented Mar 8, 2023

I'm having problems getting the log file to generate. I set up the entry as follows:

affectedModuleDetector {
baseDir = "${project.rootDir}"
logFilename = "affectedmodules.log"
logFolder = "${project.rootDir}/build/reports"
}

The log file is never created and running with --info or --debug doesn't seem to give me any more info.

Using 0.2.1 version, but tried with 0.1.2 as well with same results.

@sboishtyan
Copy link

The same is actual and for me. Without logs I can't check the correctness of this plugin.

@joshafeinberg
Copy link
Member

Is this on CI or locally? I am able to generate fine so curious if you have any issues with write permissions.

Perhaps try a different directory

@kingargyle
Copy link
Author

Is this on CI or locally? I am able to generate fine so curious if you have any issues with write permissions.

Perhaps try a different directory

Both. CI and Local

@ffluk3
Copy link

ffluk3 commented Apr 5, 2024

I am having this same issue, where I'm unable to get the logfile to be written regardless of my configuration values. Here is my Gradle environment:

------------------------------------------------------------
Gradle 8.1.1
------------------------------------------------------------

Build time:   2023-04-21 12:31:26 UTC
Revision:     1cf537a851c635c364a4214885f8b9798051175b

Kotlin:       1.8.10
Groovy:       3.0.15
Ant:          Apache Ant(TM) version 1.10.11 compiled on July 10 2021
JVM:          11.0.16 (Eclipse Adoptium 11.0.16+8)
OS:           Mac OS X 13.4 aarch64

@bddckr
Copy link

bddckr commented May 18, 2024

It looks like this isn't working for the sample either.

@bddckr
Copy link

bddckr commented May 18, 2024

#245 is the issue, AFAICS. However, the issue is bigger than just the log file not getting created - the whole configuration isn't applied.
The config is retrieved from the project's extensions before the consuming project's build script runs. As such, the consumer of this plugin is currently unable to set the config.

Moving AffectedModuleDetector.configure(project) back down into the start of the block passed to project.gradle.projectsEvaluated here resolves the issue:

override fun apply(project: Project) {
require(
value = project.isRoot,
lazyMessage = {
"Must be applied to root project, but was found on ${project.path} instead."
}
)
registerSubprojectConfiguration(project)
registerMainConfiguration(project)
AffectedModuleDetector.configure(project)
registerCustomTasks(project)
registerTestTasks(project)
project.gradle.projectsEvaluated {
filterAndroidTests(project)
filterJvmTests(project)
filterCustomTasks(project)
}
}

Downgrading to 0.3.0 also resolves the issue for me.

@dptsolutions
Copy link

Confirming what @bddckr said above, #245 seems to have broken configuration entirely. This is bigger than just log files

@bddckr
Copy link

bddckr commented Aug 22, 2024

@joshafeinberg Sorry for the ping. Feel free to ignore. Pinging you since you handled #245, which seems to be the issue here.

What's the path forward here? I could raise a PR for the simple change I mentioned above, but I assume I'm missing something behind the goals of #245.

Due to this issue, I've downgraded to 0.3.0, but I will soon require #257 to work with Gradle 8.10. I'm assuming that would be available in a new release/snapshot, and as such I'd be forced to choose between one or another issue. (Or maintaining a fork.)

@joshafeinberg
Copy link
Member

@joshafeinberg Sorry for the ping. Feel free to ignore. Pinging you since you handled #245, which seems to be the issue here.

What's the path forward here? I could raise a PR for the simple change I mentioned above, but I assume I'm missing something behind the goals of #245.

Due to this issue, I've downgraded to 0.3.0, but I will soon require #257 to work with Gradle 8.10. I'm assuming that would be available in a new release/snapshot, and as such I'd be forced to choose between one or another issue. (Or maintaining a fork.)

Hey there, we haven't upgraded internally to Gradle 8.10 so we haven't been able to test this out. I am currently in the process of looking for a better resolution than #245 but if you have thoughts and a PR I am happy to take a look. No timeline on those updates, I've moved into management so don't have all the time in the world to code nowadays, but hoping that I can get a good fix in soon

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

6 participants