Hamburger Cross Icon
Linter Configured
+
Kotlin Collector

Linter Configured + Kotlin Collector

Guardrail Collector Beta Devex Build And Ci

Enforce Linter Configured using data collected by Kotlin Collector. Automatically check devex build and ci standards on every PR.

Guardrail: Ensures a Kotlin static-analysis / formatting tool is configured — detekt (`detekt.yml`) or ktlint. These enforce consistent code quality and formatting and are the de facto standard for Kotlin. Informational.
Data Source: Analyze Kotlin projects to collect project metadata, dependencies, CI/CD command tracking, and test coverage. Supports Gradle (Kotlin & Groovy DSL) and Maven. Detects the Kotlin version, JVM/Android/Multiplatform targets, test frameworks (JUnit, Kotest, MockK), and detekt/ktlint.

How Kotlin Collector Powers This Guardrail

The Kotlin Collector gathers metadata from your languages, build systems. This data flows into Lunar's Component JSON, where the Linter Configured guardrail evaluates it against your standards.

When enabled, this check runs automatically on every PR and in AI coding workflows, providing real-time enforcement with actionable feedback.

1
Kotlin Collector Gathers Data Collector
Extracts metadata from code, configs, and tool outputs
2
{ } Component JSON
Data centralized in structured format for evaluation
3
Linter Configured Checks Guardrail
Pass/fail result with actionable feedback in PRs

Quick Start Configuration

Add both the collector and policy to your lunar-config.yml to enable this guardrail.

📄 lunar-config.yml
# Step 1: Enable the Kotlin Collector
collectors:
  - uses: github://earthly/lunar-lib/collectors/kotlin@v1.0.5
    # with: ...

# Step 2: Enable the Kotlin Project Guardrails
policies:
  - uses: github://earthly/lunar-lib/policies/kotlin@v1.0.5
    include: [linter-configured]
    # with: ...

What Kotlin Collector Collects

This collector gathers the following data that the Linter Configured guardrail evaluates.

Collector code

project

Analyzes Kotlin project structure by detecting build.gradle.kts, build.gradle (Groovy DSL applying a Kotlin plugin), settings.gradle(.kts), pom.xml (with kotlin-maven-plugin), gradle/libs.versions.toml (version catalog), gradle.lockfile, the Gradle wrapper, detekt/ktlint config, and the test source directory. Parses the Kotlin compiler version (from the Gradle kotlin(...) plugin, pom <kotlin.version>, or the version catalog), project name/version, Gradle version, detected test frameworks, framework flags (Ktor, Spring, Compose, Coroutines), and the JVM / Android / Multiplatform target. Skips when no *.kt / *.kts source files are present. Writes project metadata to .lang.kotlin.

Collector code

dependencies

Extracts direct dependencies from build.gradle.kts / build.gradle (dependencies block, including libs. version-catalog references), pom.xml, or gradle/libs.versions.toml. When gradle.lockfile is present, also extracts resolved transitive versions. Writes dependency data to .lang.kotlin.dependencies.

Collector ci-before-command

cicd

Records every kotlinc / kotlin command executed in CI pipelines along with the compiler version. Writes command strings and version info to .lang.kotlin.cicd for audit trails and build reproducibility analysis. Gradle and Maven invocations are already tracked by the java collector's gradle-cicd / maven-cicd sub-collectors, so this focuses on direct Kotlin-compiler usage.

Collector ci-after-command

test-coverage

Extracts coverage percentage from Kover XML reports (build/reports/kover/report.xml) after a Gradle test / koverXmlReport run. Kover is the Kotlin-native coverage tool; JaCoCo is intentionally left to the java collector's test-coverage sub-collector — matching the per-language convention (scala→scoverage, java→jacoco, kotlin→kover) and avoiding a double-write to the normalized .testing.coverage path. Writes to .lang.kotlin.tests.coverage and .testing.coverage.

Example Data Flow

Here's an example of the data that Kotlin Collector writes to the Component JSON, which Linter Configured then evaluates.

{ } component.json From Kotlin Collector
{
  "lang": {
    "kotlin": {
      "version": "1.9.22",
      "build_systems": ["gradle"],
      "build_gradle_kts_exists": true,
      "build_gradle_exists": false,
      "settings_gradle_exists": true,
      "pom_xml_exists": false,
      "version_catalog_exists": true,
      "gradlew_exists": true,
      "lockfile_exists": false,
      "detekt_configured": true,
      "ktlint_configured": false,
      "test_directory_exists": true,
      "project_name": "my-service",
      "project_version": "0.1.0",
      "gradle_version": "8.5",
      "target": "jvm",
      "is_multiplatform": false,
      "is_android": false,
      "test_frameworks": ["junit", "kotest", "mockk"],
      "frameworks": ["ktor", "coroutines"],
      "source": { "tool": "gradle", "integration": "code" },
      "cicd": {
        "cmds": [
          { "cmd": "kotlinc src -include-runtime -d app.jar", "version": "1.9.22" }
        ]
      },
      "tests": {
        "coverage": {
          "percentage": 81.3,
          "source": { "tool": "kover", "integration": "ci" }
        }
      },
      "dependencies": {
        "direct": [
          { "path": "io.ktor:ktor-server-core", "version": "2.3.7" },
          { "path": "org.jetbrains.kotlinx:kotlinx-coroutines-core", "version": "1.7.3" }
        ],
        "transitive": [
          { "path": "org.jetbrains.kotlin:kotlin-stdlib", "version": "1.9.22" }
        ],
        "source": { "tool": "gradle", "integration": "code" }
      }
    }
  },
  "testing": {
    "coverage": {
      "percentage": 81.3,
      "source": { "tool": "kover", "integration": "ci" }
    }
  }
}

Configuration Options

Kotlin Project Guardrails Inputs

Input Required Default Description
min_kotlin_version Optional 1.8 Minimum required Kotlin compiler version (e.g., "1.8", "1.9", "2.0"). Compared with semantic-version semantics — "1.8" matches 1.8.x and above, but rejects 1.7.x.

Ready to Automate Your Standards?

See how Lunar can turn your AGENTS.md, engineering wiki, compliance docs, or postmortem action items into automated guardrails with our 200+ built-in guardrails.

Works with any process
check AI agent rules & prompt files
check Post-mortem action items
check Security & compliance policies
check Testing & quality requirements
Automate Now
Paste your AGENTS.md or manual process doc and get guardrails in minutes
Book a Demo