Unable to get Log files to generate

[kingargyle]

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.

[sergioboi]

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

[joshafeinberg]

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]

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]

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]

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

[bddckr]

#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:

AffectedModuleDetector/affectedmoduledetector/src/main/kotlin/com/dropbox/affectedmoduledetector/AffectedModuleDetectorPlugin.kt

Lines 41 to 61 in cd343a9

	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]

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

[bddckr]

@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]

@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

[cbruegg]

@joshafeinberg Unfortunately the v0.4.0 release still has the issue that the plugin configuration is ignored entirely :( What was the reason for #245? Was it meant to solve an issue?

[joshafeinberg]

@joshafeinberg Unfortunately the v0.4.0 release still has the issue that the plugin configuration is ignored entirely :( What was the reason for #245? Was it meant to solve an issue?

Yes, we were seeing some users with crashes so we made that change.

Can you test the 0.5.0-SNAPSHOT, I believe that should resolve most these configuration issues

[cbruegg]

@joshafeinberg 0.5.0-SNAPSHOT seems to work. The configuration is applied again, which also restores the log functionality. Many thanks! 🙏

[joshafeinberg]

@joshafeinberg 0.5.0-SNAPSHOT seems to work. The configuration is applied again, which also restores the log functionality. Many thanks! 🙏

Add maven("https://s01.oss.sonatype.org/content/repositories/snapshots") to your repositories in your build files then you can switch the version to 0.5.0-SNAPSHOT

[FilippoVigani]

Facing the same issue with 0.4.0.

Any chance you can release a version with the fix on maven? In my company we have a proxy for repositories so we can't add snapshots versions