[0.49.0] loadBaseline loads invalid absolute paths when invoked from separate process/with different working directory

[mateuszkwiecinski]

Expected Behavior

I'd expect loadBaseline to expose relative paths, like 0.48.x did, or have a way to pass a root directory baseline entries should be resolved against (a loadBaseline(path = ..., workingDir = ...))?

Observed Behavior

Baseline#lintErrorsPerFile reference absolute paths pointing at temporary location created by Gradle, which is different than the one passed to KtlineRuleEngine#lint or #format.

+ sample baseline entry:

    <file name="app/src/test/kotlin/io/github/usefulness/sample/OpSpacing.kt">
        <error line="5" column="16" source="standard:op-spacing" />
    </file>

(The screeshot lists result of loadBaseline(...).lintErrorsPerFile.keys and compares it with file paths passed to #lint or #format as Code.fromFile(file)

As far as I understand, loadBaseline creates absolute paths relatively to the place it was called. So when running in process isolation, when gradle try to run stuff safely, loadBaseline is effectively called from i.e. $GRADLE_HOME/workers which results in invalid absolute paths resolved.
0.48.0 returned relative paths, so plugins find absolute location on their own: example1, example2

Offending code: link + the comment that suggests different things than the function does, I guess 👀

Steps to Reproduce

1. Generate non-empty baseline using ktlint --baseline=ktlint-baseline.xml
2. Call loadBaseline() from a process with working directory outside of the directory the baseline was created from? or whatever Gradle Worker with process isolation does here 😬

Your Environment

• Version of ktlint used: 0.49.0
• Relevant parts of the .editorconfig settings - N/A
• Name and version (or code for custom task) of integration used (Gradle plugin, Maven plugin, command line, custom Gradle task): link
• Version of Gradle used (if applicable): N/A
• Operating System and version: N/A

[paul-dingemans]

@mateuszkwiecinski Can you please verify whether the problem is solved for you in latest snapshot build?

[mateuszkwiecinski]

@paul-dingemans Unfortunately I still observe the same behavior. I assume it's because the path passed to loadBaseline is i.e. ~/project/path/app/config/baseline.xml, so when a baseline entry points at src/main/kotlin/CustomClass.kt, the loadBaseline using

val fileName =
    Paths
        .get(getAttribute("name"))
        .absolutePathString()

loads ~/.gradle/workers/src/main/kotlin/CustomClass.kt, which means the newly added removePrefix is a no-op:

since ~/.gradle/workers/src/main/kotlin/CustomClass.kt does not start with ~/project/path/app/config/baseline.xml.

From my observation the absolutePathString resolves paths against the System.getProperty("user.dir") location 👀 But if your intention was to keep using relative paths, then removing absolutePathString should do the trick.

Or maybe I'm using the wrong code. I'm a bit of lost which artifacts are meant to be used by API consumers and which are only needed for CLI. Previously there was just one, now I have to depend on 4 of them

"com.pinterest:ktlint" // needed for `Baseline.kt` only
"com.pinterest.ktlint:ktlint-rule-engine" // core part of ktlint
"com.pinterest.ktlint:ktlint-cli-ruleset-core" // needed for `RuleSetProviderV3`, not sure how to resolve `RuleProvider`s using just `ktlint-rule-engine` 
"com.pinterest.ktlint:ktlint-cli-reporter" // no `-core`?

Baseline.kt I'm referring to comes from ktlint-cli module, so maybe I'm wrong by using it, as it contains CLI-specific implementation? Is there a Baseline.kt implementation for API consumers? 🤔 Is there a single artifact that all API consumers (including CLI) should use?

[paul-dingemans]

I have incorrectly assumed that the baseline file was always stored in the root of the project. Now, the baseline again will return the relative path to the file. But it needed a fix in the Ktlint CLI to retrieve the existing errors from the baseline so that errors in the baseline will not be reported.

The terminology "API Consumer" might be confusing. For me an API Consumer is a project that invokes the KtlintRuleEngine directly. Such API Consumers do not use the Ktlint CLI (and as of that non of the ktlint-cli modules).

Integrators that invoke the Ktlint CLI typically do not invoke the KtlintRuleEngine directly.

I am confused why you have a need for using the Baseline.kt from the Ktlint CLI but also need a direct dependency on ktlint-rule-engine. Do you invoke the Ktlint CLI or the lint/format functions of KtlintRuleEngine directly?

[paul-dingemans]

I missed the last part of your comment:

Baseline.kt I'm referring to comes from ktlint-cli module, so maybe I'm wrong by using it, as it contains CLI-specific implementation? Is there a Baseline.kt implementation for API consumers? 🤔 Is there a single artifact that all API consumers (including CLI) should use?

It looks like that you're (ab)using the Baseline.kt functionality from the Ktlint CLI. The KtlintRuleEngine has absolute no knowledge of the concept of a baseline. So I expect that a part of the baseline functionality of Ktlint CLI also has been 'copied/implementedin your project. If so, it would be best to copy theBaseline.kt` as well.

[paul-dingemans]

New snapshot is available with fix in Baseline.kt to return relative path.