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

ktlintCheck task does not fail on Windows #399

Closed
santelos opened this issue Sep 28, 2020 · 6 comments · Fixed by #400
Closed

ktlintCheck task does not fail on Windows #399

santelos opened this issue Sep 28, 2020 · 6 comments · Fixed by #400
Assignees
Labels

Comments

@santelos
Copy link

santelos commented Sep 28, 2020

Hello Ktlint-Gradle team.

I'm facing the strange issue.
When I'm running the local ktlint check via ./gradlew clean ktlintCheck the "mainSourceSetCheck" task completes successfully.
But when I'm running the same process in docker build environment the result is different and it fails.

I've found the same problem on StackOverflow:
https://stackoverflow.com/questions/63863368/ktlint-check-doesnt-work-locally-anymore-it-works-tho-in-my-docker-image-buil

Versions I'm using:

  • Gradle wrapper 6.6.1-bin.zip
  • OpenJDK 14.0.2
  • Kotlin version 1.4.10
  • Ktlint-gradle plugin 9.4.0

The java --version output in the local and docker environment is the same:

openjdk 14.0.2 2020-07-14 
OpenJDK Runtime Environment (build 14.0.2+12-46) 
OpenJDK 64-Bit Server VM (build 14.0.2+12-46, mixed mode, sharing)

Local environment check outputs the following message [DEBUG] <...>ms / 0 file(s) / 0 error(s)
whereas the docker environment outputs the [DEBUG] <...>ms / 1 file(s) / 1 error(s)

I've also made a minimum reproducible example. You may found it here:
https://github.com/santelos/ktlint-mre


build.gradle.kts

repositories {
    mavenCentral()
}

plugins {
    kotlin("jvm") version "1.4.10"
    id("org.jlleitschuh.gradle.ktlint") version "9.4.0"
}

ktlint {
    debug.set(true)
}

tasks.withType<KotlinCompile> {
    kotlinOptions.jvmTarget = "14"
}

Dockerfile

FROM openjdk:14.0.2
WORKDIR /build
COPY . .
RUN java --version
RUN ./gradlew clean ktlintCheck
@santelos santelos changed the title ktlintMainSourceSetCheck task local run failure ktlintCheck task local run success whereas docker build failure Sep 28, 2020
@Tapchicoma
Copy link
Collaborator

Hi, thank you for the project to reproduce your issue.

I've tried to do it on my machine with openjdk 14, but for me it always fails both locally and in docker image. Maybe there are some additional steps to reproduce?

@santelos
Copy link
Author

santelos commented Sep 28, 2020

Thank you for the response.

Just figured out that this is reproducible only on the Windows OS.
I've tested my scenario on WSL2 based Ubuntu 20.04 and yes, the local build failed as expected.

May be you can try it on Windows OS?


UPD:
It seems like there is no docker issue.
So may be I should simplify the bug mesage like "mainSourceSetCheck works on Linux, but doesn't work on Windows"

@craigatk
Copy link

In case it helps, I am experiencing similar behavior where the source set check tasks are passing on my Windows laptop with plugin 9.4.0 but failing in GitHub actions with Linux. The formatting tasks also have no effect when running on Windows locally - probably the same underlying cause.

Downgrading to the previous version of the plugin I was using (9.1.1) fixes the issue - the format tasks catch and correct the formatting issues on Windows locally.

This is the project I'm using: https://github.com/craigatk/projektor

Other versions:

  • Kotlin 1.4.10
  • Java 11
  • Gradle 6.6.1
  • ktlint 0.39.0

I imagine not everyone has a Windows machine lying around to try to diagnose this :) I'll try out the plugin code locally on my Windows machine and see if I can find out what's happening.

@xetra11
Copy link

xetra11 commented Sep 30, 2020

In case it helps, I am experiencing similar behavior where the source set check tasks are passing on my Windows laptop with plugin 9.4.0 but failing in GitHub actions with Linux. The formatting tasks also have no effect when running on Windows locally - probably the same underlying cause.

Downgrading to the previous version of the plugin I was using (9.1.1) fixes the issue - the format tasks catch and correct the formatting issues on Windows locally.

This is the project I'm using: https://github.com/craigatk/projektor

Other versions:

  • Kotlin 1.4.10
  • Java 11
  • Gradle 6.6.1
  • ktlint 0.39.0

I imagine not everyone has a Windows machine lying around to try to diagnose this :) I'll try out the plugin code locally on my Windows machine and see if I can find out what's happening.

Hey there!
I have a similar issue. Here are my setups and their results:

Setup 1

  • Windows 10
  • Java 11
  • Gradle 6.6.1
  • gradle ktlint plugin 9.3.0
  • Kotlin 1.3.72

Works: ktlintCheck finds the issues

Setup 2

  • Windows 10
  • Java 11
  • Gradle 6.6.1
  • gradle ktlint plugin 9.4.0
  • Kotlin 1.4.10

Fails: The ktlintCheck commands just runs through without any errors even tho the previous setup yielded issues. ktlintFormat has no effect either.

> Task :ktlintTestSourceSetCheck UP-TO-DATE
> Task :ktlintMainSourceSetCheck
> Task :ktlintKotlinScriptCheck
> Task :ktlintCheck

Setup 3 @craigatk your example with plugin 9.1.1

  • Windows 10
  • Java 11
  • Gradle 6.6.1
  • gradle ktlint plugin 9.1.1
  • Kotlin 1.4.10

Fails: Exception in thread "main" java.lang.NoSuchFieldError: FUN_KEYWORD

For me it turns out I can not use Kotlin 1.4.10 with the current build :(

@Tapchicoma Tapchicoma changed the title ktlintCheck task local run success whereas docker build failure ktlintCheck task does not fail on Windows Sep 30, 2020
@Tapchicoma Tapchicoma self-assigned this Sep 30, 2020
@Tapchicoma
Copy link
Collaborator

I could reproduce it on the windows machine using sample project. Looking into it 👀

@santelos
Copy link
Author

santelos commented Oct 5, 2020

Thanks, @Tapchicoma
The Windows community is happy now 😁

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

Successfully merging a pull request may close this issue.

4 participants