Compilation and caches in the Kotlin Gradle plugin

이 페이지에서 다음 주제에 대해 알아볼 수 있다:

• Incremental compilation
• Gradle build cache support
• Gradle configuration cache support
• The Kotlin daemon and how to use it with Gradle
• Defining Kotlin compiler execution strategy
• Kotlin compiler fallback strategy
• Build reports

Incremental compilation

코틀린 그레이들 플러그인은 증분 컴파일(incremental compilation)을 지원한다. 증분 컴파일은 빌드 간 소스 파일의 변경 사항을 추적하므로 변경 사항의 영향을 받는 파일만 컴파일된다.

증분 컴파일은 코틀린/JVM 및 코틀린/JS 프로젝트에 지원되며 기본적으로 활성화된다.

증분 컴파일을 비활성화하는 방법에는 여러 가지가 있다:

• 코틀린/JVM에서 kotlin.incremental=false를 설정한다.
• 코틀린/JS에서 kotlin.incremental.js=false를 설정한다.
• -Pkotlin.incremental=false 또는 -Pkotlin.incremental.js=false를 커맨드라인 파라미터로 사용한다.

각 후속 빌드에 파라미터를 추가해야 한다.

노트: 증분 컴파일이 비활성화된 모든 빌드는 증분 캐시를 무효화한다. 첫 번째 빌드는 증분되지 않는다.

때때로 증분 컴파일의 문제는 실패가 발생한 후 여러 라운드에서 표시된다. 빌드 보고서를 사용하여 변경 및 컴파일 기록을 추적한다. 이를 통해 재현 가능한 버그 리포트를 제공할 수 있다.

A new approach to incremental compilation

증분 컴파일에 대한 새로운 접근 방식은 그레이들 빌드 시스템에서 JVM 백엔드용 코틀린 1.7.0부터 사용할 수 있다. 코틀린 1.8.20부터는, 기본적으로 활성화된다. 이 접근 방식은 코틀린이 아닌 모듈 내에서 이루어진 변경 사항도 지원하고, 향상된 컴파일 방지 기능을 포함하며, 그레이들 빌드 캐시와 호환된다.

이러한 모든 개선 사항은 증분 빌드가 아닌 빌드의 수를 줄여, 전체 컴파일 시간을 단축시킨다. 빌드 캐시를 사용하거나 코틀린이 아닌 모듈을 자주 변경하는 경우 가장 큰 이점을 얻을 수 있다.

이 새로운 접근 방식을 선택 해제하려면, gradle.properties에서 다음 옵션을 설정하자:

kotlin.incremental.useClasspathSnapshot=false

유트랙(YouTrack)에 기능에 대한 피드백을 보내보자.

이 블로그 게시물에서 내부적으로 증분 컴파일에 대한 새로운 접근 방식을 구현하는 방법을 알아보자.

Precise backup of compilation tasks’ outputs

컴파일 태스크 출력의 정확한 백업은 실험적인 기능이다. 유트랙에 피드백을 보내보자.

코틀린 1.8.20부터, 정확한 백업을 활성화할 수 있으므로, 코틀린이 증분 컴파일에서 다시 컴파일하는 클래스만 백업된다. 전체 백업과 정확한 백업 모두 컴파일 오류 후 빌드를 다시 실행하는 데 도움이 된다. 정확한 백업은 전체 백업에 비해 빌드 시간이 덜 걸린다. 전체 백업은 대규모 프로젝트에서 또는 많은 태스크가 백업을 생성하는 경우, 특히 프로젝트가 느린 HDD에 있는 경우 빌드 시간이 눈에 띄게 더 오래 걸릴 수 있다.

kotlin.compiler.preciseCompilationResultsBackup 그레이들 프로퍼티를 gradle.properties 파일에 추가하여 최적화한다:

kotlin.compiler.preciseCompilationResultsBackup=true

Example of using precise backup at JetBrains

다음 차트에서, 전체 백업과 비교하여 정확한 백업을 사용하는 예를 볼 수 있다:

첫 번째 및 두 번째 차트는 코틀린 프로젝트에서 정확한 백업을 사용하는 것이 코틀린 그레이들 플러그인 빌드에 미치는 영향을 보여준다:

1. ABI를 약간 변경한 후: 많은 모듈이 의존하는 모듈에 새로운 퍼블릭 함수 추가.
2. ABI 이외의 작은 변경을 수행한 후: 다른 모듈이 의존하지 않는 모듈에 프라이빗 함수 추가.

세 번째 차트는 ABI가 아닌 작은 변경(많은 모듈이 의존하는 코틀린/JS 모듈에 프라이빗 함수 추가) 후 웹 프런트엔드 구축에 스페이스(Space) 프로젝트의 정확한 백업이 어떤 영향을 미치는지 보여준다.

이 측정은 애플 M1 Max CPU가 장착된 컴퓨터에서 수행되었다. 다른 컴퓨터는 약간 다른 결과를 나타낸다. 성능에 영향을 미치는 요인에는 다음이 포함되지만 이에 국한되지는 않는다:

• 코틀린 데몬과 그레이들 데몬의 예열 상태.
• 디스크의 속도 또는 속도.
• CPU 모델 및 사용량.
• 변경 사항의 영향을 받는 모듈과 이러한 모듈의 크기.
• 변경 사항이 ABI인지 비 ABI인지 여부.

Evaluating optimizations with build reports

프로젝트 및 시나리오에 대한 최적화가 컴퓨터에 미치는 영향을 추정하려면, 코틀린 빌드 리포트를 사용할 수 있다. gradle.properties 파일에 다음 프로퍼티을 추가하여 텍스트 파일 형식의 리포트를 활성화한다:

kotlin.build.report.output=file

다음은 정확한 백업을 활성화하기 전에 리포트 관련 부분에 대한 예시다:

Task ':kotlin-gradle-plugin:compileCommonKotlin' finished in 0.59 s <...> Time metrics: Total Gradle task time: 0.59 s Task action before worker execution: 0.24 s Backup output: 0.22 s // 이 <...> 숫자에 주목하자 

다음은 정확한 백업을 활성화한 후 리포트의 관련 부분에 대한 예시다:

Task ':kotlin-gradle-plugin:compileCommonKotlin' finished in 0.46 s <...> Time metrics: Total Gradle task time: 0.46 s Task action before worker execution: 0.07 s Backup output: 0.05 s 
// 시간이 단축됐다: 그레이들 워커에서 컴파일 실행: 0.32초 jar 캐시 삭제: 0.00초 정확한 백업 출력: 0.00초
// 정확한 백업 관련 백업 스태시 정리: 0.00초
// 정확한 백업 관련 <...>

Gradle build cache support

코틀린 플러그인은 다음 빌드에서, 재사용할 수 있도록 빌드 출력을 저장하는 그레이들 빌드 캐시를, 사용한다.

모든 코틀린 태스크에 대한 캐싱을 비활성화하려면, 시스템 프로퍼티 kotlin.caching.enabled를 false(-Dkotlin.caching.enabled=false 아규먼트로 빌드 실행)로 설정한다.

Gradle configuration cache support

그레이들 구성 캐시는 다음 그레이들 플러그인에서만 지원된다:

• org.jetbrains.kotlin.jvm
• org.jetbrains.kotlin.js
• org.jetbrains.kotlin.android

코틀린 플러그인은 구성 단계 결과를 재사용하여 빌드 프로세스 속도를 높이는, 그레이들 구성 캐시를 사용한다.

구성 캐시를 활성화하는 방법은 그레이들 문서를 참조하자. 이 기능을 활성화하면, 코틀린 그레이들 플러그인이 자동으로 이 기능을 사용하기 시작한다.

The Kotlin daemon and how to use it with Gradle

코틀린 데몬:

• 프로젝트를 컴파일하기 위해 그레이들 데몬과 함께 실행.
• 인델리제이 IDEA 내장 빌드 시스템으로 프로젝트를 컴파일할 때 그레이들 데몬과 별도로 실행된다.

코틀린 데몬은 코틀린 컴파일 태스크 중 하나가 소스 컴파일을 시작할 때 그레이들이 실행(Execution) 단계에 시작한다. 코틀린 데몬은 그레이들 데몬과 함께 또는 코틀린 컴파일 없이 2시간의 유휴(idle) 시간 후에 중지된다.

코틀린 데몬은 그레이들 데몬과 동일한 JDK를 사용한다.

Setting Kotlin daemon’s JVM arguments

다음은 아규먼트를 오버라이드하는 방법이다:

• 그레이들 데몬 아규먼트 상속
• kotlin.daemon.jvm.options 시스템 프로퍼티
• kotlin.daemon.jvmargs 프로퍼티
• 코틀린 익스텐션(extension)
• 구체적인 태스크 정의

Gradle daemon arguments inheritance

아무 것도 지정하지 않으면 코틀린 데몬은 그레이들 데몬에서 인수를 상속한다. 다음은 gradle.properties 파일의 예시이다:

org.gradle.jvmargs=-Xmx1500m -Xms=500m

kotlin.daemon.jvm.options system property

그레이들 데몬의 JVM 인수에 kotlin.daemon.jvm.options 시스템 프로퍼티가 있는 경우 gradle.properties 파일에서 사용한다.

org.gradle.jvmargs=-Dkotlin.daemon.jvm.options=-Xmx1500m,Xms=500m

아규먼트를 전달할 때, 다음 규칙을 따르자:

• 마이너스 기호 -는 Xmx, XX:MaxMetaspaceSize 및 XX:ReservedCodeCacheSize 아규먼트 앞에서만 사용한다.
• 공백 없이 쉼표(,)로 인수를 구분하자. 공백 뒤에 오는 인수는 코틀린 데몬이 아닌 그레이들 데몬에 사용된다.

그레이들은 다음 조건이 모두 충족되는 경우 이러한 프로퍼티를 무시한다.

• 그레이들은 JDK 1.9 이상을 사용하고 있다.
• 그레이들 버전은 7.0에서 7.1.1 사이다.
• 그레이들이 코틀린 DSL 스크립트를 컴파일 중이다.
• 코틀린 데몬이 실행되고 있지 않다. 이를 극복하려면, 그레이들 버전 7.2 이상으로 업그레이드하거나 kotlin.daemon.jvmargs 프로퍼티을 사용하자. 그리고 다음 장을 참고해보자.

kotlin.daemon.jvmargs property

gradle.properties 파일에 kotlin.daemon.jvmargs 프로퍼티를 추가할 수 있다:

kotlin.daemon.jvmargs=-Xmx1500m -Xms=500m

kotlin extension

코틀린 익스텐션(extension)에서 아규먼트를 지정할 수 있다:

코틀린

  kotlin {
    kotlinDaemonJvmArgs = listOf("-Xmx486m", "-Xms256m", "-XX:+UseParallelGC")
  }

그루비

  kotlin {
    kotlinDaemonJvmArgs = ["-Xmx486m", "-Xms256m", "-XX:+UseParallelGC"]
  }

Specific task definition

특정 태스크에 대한 아규먼트를 지정할 수 있다:

코틀린

  tasks.withType<CompileUsingKotlinDaemon>().configureEach {
    kotlinDaemonJvmArguments.set(listOf("-Xmx486m", "-Xms256m", "-XX:+UseParallelGC"))
  }

그루비

  tasks.withType(CompileUsingKotlinDaemon::class).configureEach { task ->
    task.kotlinDaemonJvmArguments.set(["-Xmx1g", "-Xms512m"])
  }

이 경우 태스큰 실행 시 새 코틀린 데몬 인스턴스를 시작할 수 있다. JVM 아규먼트를 사용한 코틀린 데몬의 동작 자세히 알아보자.

Kotlin daemon’s behavior with JVM arguments

코틀린 데몬의 JVM 아규먼트를 구성할 때 다음 사항에 유의하자:

• 서로 다른 하위 프로젝트 또는 태스크에 서로 다른 JVM 아규먼트 집합이 있는 경우 코틀린 데몬의 여러 인스턴스가 동시에 실행될 것으로 예상된다.
• 새로운 코틀린 데몬 인스턴스는 그레이들이 관련 컴파일 태스크를 실행하고 기존 코틀린 데몬에 동일한 JVM 아규먼트 집합이 없는 경우에만 시작된다. 대부분은 코틀린 데몬을 위한 약간의 힙 메모리가 필요하지만, 어떤 모듈(거의 컴파일되어있지 않음)은 많이 필요하다. 이 경우 해당 모듈에 대해 다른 JVM 아규먼트 집합을 제공해야 힙 크기가 더 큰 코틀린 데몬이 특정 모듈을 만지는 개발자를 위해 시작된다.

컴파일 요청을 처리하기에 충분한 힙 크기를 가진 코틀린 데몬을 이미 실행 중인 경우, 요청된 다른 JVM 아규먼트가 다르더라도 새 데몬을 시작하는 대신 데몬을 재사용한다.

• Xmx 아규먼트를 지정하지 않으면, 코틀린 데몬이 그레이들 데몬에서 아규먼트를 상속한다.

The new Kotlin compiler

새로운 코틀린 K2 컴파일러는 알파(Alpha) 버전이다. 코틀린 JVM, JS 및 네이티브(Native) 프로젝트를 기본적으로 지원한다.

새로운 컴파일러는 새로운 언어 기능의 개발 속도를 높이고, 코틀린이 지원하는 모든 플랫폼을 통합하고, 성능을 개선하고, 컴파일러 확장을 위한 API를 제공하는 것을 목표로 한다.

K2 컴파일러는 코틀린 2.0부터 기본 지원 된다. 지금 프로젝트에서 사용해 보고 성능을 확인하려면 kotlin.experimental.tryK2=true 그레이들 프로퍼티를 사용하거나 다음 명령을 실행하자:

./gradlew assemble -Pkotlin.experimental.tryK2=true

이 그레이들 프로퍼티는 자동으로 기본 언어 버전을 2.0으로 설정하고 현재 컴파일러와 비교하여 K2 컴파일러를 사용하여 컴파일된 코틀린 태스크 수로 빌드 리포트를 업데이트한다.

빌드 리포트는 아직 코틀린/네이티브 태스크에 대한 정보를 제공하지 않는다. 그럼에도 불구하고, 코틀린 2.0을 기본 버전으로 사용하는 것이 좋다.

코틀린 블로그에서 K2 컴파일러의 안정화에 대해 자세히 알아보자.

Defining Kotlin compiler execution strategy

코틀린 컴파일러 실행 전략(execution strategy)은 코틀린 컴파일러가 실행되는 위치와 증분 컴파일이 각각의 경우에 지원되는지를 정의한다.

세 가지 컴파일러 실행 전략이 있다: |전략(Strategy)|코틀린 컴파일러가 실행되는 위치|증분 컴파일|기타 특성 및 참고 사항| |—|—|—|—| |데몬(Daemon)|자체 데몬 프로세스 내부|Yes|기본이며 가장 빠른 전략이다. 다른 그레이들 데몬과 여러 병렬 컴파일 간 공유가 가능하다.| |인프로세스(In process)|그레이들 데몬 프로세스 내부|No|그레이들 데몬과 힙을 공유할 수 있다. “In process” 실행 전략은 “Daemon” 실행 전략보다 느리다. 각 워커는 각 컴파일에 대해 별도의 코틀린 컴파일러 클래스로더를 생성한다.| |아웃오브프로세스(Out of process)|각 컴파일에 대해 별도의 프로세스에서 실행|No|가장 느린 실행 전략이다. “In process”와 유사하지만, 각 컴파일에 대해 그레이들 워커 내에 별도의 자바 프로세스를 추가로 생성한다.|

코틀린 컴파일러 실행 전략을 정의하려면 다음 프로퍼티 중 하나를 사용할 수 있다:

• kotlin.compiler.execution.strategy 그레이들 프로퍼티.
• compilerExecutionStrategy 컴파일 태스크 프로퍼티.

태스크 프로퍼피 compilerExecutionStrategy는 그레이들 프로퍼티 kotlin.compiler.execution.strategy보다 우선한다.

kotlin.compiler.execution.strategy 프로퍼티에 사용할 수 있는 값은 다음과 같다:

1. daemon (default)
2. in-process
3. out-of-process

gradle.properties에서 그레이들 프로퍼티스 kotlin.compiler.execution.strategy를 사용한다:

kotlin.compiler.execution.strategy=out-of-process

compilerExecutionStrategy 태스크 프로퍼티에 사용할 수 있는 값은 다음과 같다:

1. org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy.DAEMON (default)
2. org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy.IN_PROCESS
3. org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy.OUT_OF_PROCESS

빌드 스크립트에서 태스크 프로퍼티 compilerExecutionStrategy 사용방법은 다음과 같다:

코틀린

  import org.jetbrains.kotlin.gradle.tasks.CompileUsingKotlinDaemon
  import org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy

  // ...
  tasks.withType<CompileUsingKotlinDaemon>().configureEach {
    compilerExecutionStrategy.set(KotlinCompilerExecutionStrategy.IN_PROCESS)
  }

그루비

  import org.jetbrains.kotlin.gradle.tasks.CompileUsingKotlinDaemon
  import org.jetbrains.kotlin.gradle.tasks.KotlinCompilerExecutionStrategy

  // ...
  tasks.withType(CompileUsingKotlinDaemon)
    .configureEach {
        compilerExecutionStrategy.set(KotlinCompilerExecutionStrategy.IN_PROCESS)
    }

Kotlin compiler fallback strategy

코틀린 컴파일러의 폴백 전략(fallback strategy)은 데몬이 실패하는 경우 코틀린 데몬 외부에서 컴파일을 실행하는 것이다. 그레이들 데몬이 켜져 있으면 컴파일러는 “인프로세스(In process)” 전략을 사용한다. 그레이들 데몬이 꺼져 있으면, 컴파일러는 “Out of process” 전략을 사용한다.

이 폴백(fallback)이 발생하면, 그레이들의 빌드 출력에 다음과 같은 경고 라인이 표시된다:

Failed to compile with Kotlin daemon: java.lang.RuntimeException: Could not connect to Kotlin compile daemon
[exception stacktrace]
Using fallback strategy: Compile without Kotlin daemon
Try ./gradlew --stop if this issue persists.

그러나, 다른 전략으로 자동 폴백은 많은 시스템 리소스를 소비하거나 비결정적(non-deterministi) 빌드로 이어질 수 있다. 이 YouTrack 이슈에서 이에 대해 자세히 알아보자. 이를 방지하기 위해 기본값이 true인 그레이들 프로퍼티 kotlin.daemon.useFallbackStrategy가 있다. 값이 false이면, 데몬의 시작 또는 통신 문제로 인해 빌드가 실패한다. gradle.properties에서 이 프로퍼티를 선언한다:

kotlin.daemon.useFallbackStrategy=false

여기에는 코틀린 컴파일 태스크의 useDaemonFallbackStrategy 프로퍼티도 있다. 둘 다 사용하는 경우 그레이들 프로퍼티보다 우선한다.

코틀린

  tasks {
    compileKotlin { 
      useDaemonFallbackStrategy.set(false)
    }
  }

그루비

  tasks.named("compileKotlin").configure {
    useDaemonFallbackStrategy = false
  }

컴파일을 실행하기에 메모리가 부족하면, 로그에서 이에 대한 메시지를 볼 수 있다.

Build reports

빌드 리포트는 실험적 기능이다. 언제든지 삭제되거나 변경될 수 있다. 옵트인(Opt-in)이 필요하다(자세한 내용은 아래 참조). 평가 목적으로만 사용하자. YouTrack에 의견을 보내보자.

빌드 리포트에는 다양한 컴파일 단계(compilation phases)의 지속 시간과 컴파일을 증분할 수 없는 이유가 포함된다. 빌드 리포트를 사용하여 컴파일 시간이 너무 길거나 동일한 프로젝트에 대해 다른 경우 성능 문제를 조사한다.

코틀린 빌드 리포트는 세분화 단위로 단일 그레이들 태스크가 있는 그레이들 빌드 스캔보다 더 효율적으로 빌드 성능 문제를 조사하는 데 도움이 된다.

느린 컴파일 실행에 대한 빌드 리포트를 분석하면 문제를 해결하는 데 도움이 되는 두 가지 일반적인 경우가 있다.

• 빌드가 증분되지 않았다. 원인 분석 및 근본적인 문제 해결이 필요하다.
• 빌드는 증분식이었지만 시간이 너무 많이 걸렸다. 소스 파일 재구성 - 큰 파일 분할, 다른 파일에 별도의 클래스 저장, 큰 클래스 리팩터링, 다른 파일에서 최상위 함수 선언 등을 시도해보자.

빌드 리포트에는 프로젝트에 사용된 코틀린 버전도 표시된다. 또한 코틀린 1.9.0부터 그레이들 빌드 스캔에서 코드를 컴파일하는 데 현재 또는 K2 컴파일러가 사용되었는지 확인할 수 있다.

빌드 리포트를 읽는 방법과 젯브레인이 빌드 리포트를 사용하는 방법에 대해 알아보자.

Enabling build reports

빌드 리포트를 활성화하려면, gradle.properties에 빌드 보고서 출력을 저장할 위치를 선언한다.

kotlin.build.report.output=files

다음 값과 해당 조합을 출력에 사용할 수 있다.

옵션	설명
file	빌드 리포트를 사람이 읽을 수 있는 형식으로 로컬 파일에 저장한다. 기본적으로 ${project_folder}/build/reports/kotlin-build/${project_name}-timestamp.txt이다.
single_file	객체 형식으로 빌드 리포트를 지정된 로컬 파일에 저장한다.
build_scan	빌드 스캔의 사용자 정의 값 절에 빌드 리포트를 저장한다. 그레이들 엔터프라이스 플러그인은 맞춤 값의 수와 길이를 제한한다. 큰 프로젝트에서 일부 값이 손실될 수 있다.
http	HTTP(S)를 사용하여 빌드 리포트를 게시한다. POST 메서드는 JSON 형식으로 메트릭을 보낸다. 코틀린 리포지터리에서 전송된 데이터의 현재 버전을 확인할 수 있다. 이 블로그 게시물에서 HTTP 엔드포인트 샘플을 찾을 수 있다.

다음은 kotlin.build.report에 사용 가능한 옵션 목록이다:

# 필수 출력. 모든 조합 허용.
kotlin.build.report.output=file,single_file,http,build_scan

# single_file 출력이 사용되는 경우 필수. 보고서를 넣을 위치
# 지원 중단(deprecated)된 `kotlin.internal.single.build.metrics.file` 프로퍼티 대신 사용
kotlin.build.report.single_file=some_filename

# 선택 사항. 파일 기반 리포트의 출력 디렉토리. 기본값: build/reports/kotlin-build/
kotlin.build.report.file.output_dir=kotlin-reports

# 선택 사항. 빌드 보고서를 표시하기 위한 레이블(예: 디버그 파라미터)
kotlin.build.report.label=some_label

옵션, HTTP에만 적용 가능:

# 필수. HTTP(S) 기반 리포트를 게시할 위치
kotlin.build.report.http.url=http://127.0.0.1:8080

# 선택 사항. HTTP 엔드포인트에 인증이 필요한 경우 사용자 및 비밀번호
kotlin.build.report.http.user=someUser
kotlin.build.report.http.password=somePassword

# 선택 사항. 빌드 리포트에 빌드의 깃(Git) 분기 이름 추가
kotlin.build.report.http.include_git_branch.name=true|false

# 선택 사항. 빌드 리포트에 컴파일러 아규먼트 추가
# 프로젝트에 많은 모듈이 포함된 경우, 리포트의 컴파일러 아규먼트가가 매우 무거워 도움이 되지 않을 수 있다.
kotlin.build.report.include_compiler_arguments=true|false

Limit of custom values

빌드 스캔의 통계를 수집하기 위해, 코틀린 빌드 리포트는 그레이들의 커스텀 값을 사용한다. 다른 그레이들 플러그인 모두 커스텀 값에 데이터를 쓸 수 있다. 커스텀 값의 수에는 제한이 있다. 빌드 스캔 플러그인 문서에서 현재 최대 커스텀 값 수를 확인하자.

대규모 프로젝트의 경우, 이러한 커스텀 값의 수가 상당히 클 수 있다. 이 수가 한도를 초과하면 로그에서 다음 메시지를 볼 수 있다:

Maximum number of custom values (1,000) exceeded

코틀린 플러그인이 생성하는 커스텀 값의 수를 줄이려면, gradle.properties에서 다음 프로퍼티를 사용할 수 있다.

kotlin.build.report.build_scan.custom_values_limit=500

Switching off collecting project and system properties

HTTP 빌드 통계 로그에는 일부 프로젝트 및 시스템 프로퍼티가 포함될 수 있다. 이러한 프로퍼티는 빌드의 동작을 변경할 수 있으므로 빌드 통계에 기록하는 것이 유용하다. 이러한 프로퍼티는 암호 또는 프로젝트의 전체 경로와 같은 중요한 데이터를 저장할 수 있다.

gradle.properties에 kotlin.build.report.http.verbose_environment 프로퍼티를 추가하여 이러한 통계 수집을 비활성화할 수 있다.

젯브레인은 이러한 통계를 수집하지 않는다. 보고서를 저장할 위치를 선택한다.

다음은?

다음 내용을 학습해보자:

• Gradle basics and specifics.
• Support for Gradle plugin variants.