Guider

Kotlin og Gradle i sandkassen

Det du trenger for at Gradle-bygg og tester skal virke når agenten kjører i cplt.

brew update
brew upgrade navikt/tap/nav-pilot navikt/tap/cplt
copilot update    # Copilot CLI
opencode upgrade  # hvis du bruker opencode

Oppsett som dekker de fleste

Et vanlig Kotlin-prosjekt trenger to innstillinger. Gradle starter en daemon som snakker med bygget over en tilfeldig port på localhost, og cplt stenger localhost (også med --no-daemon). MockK, Mockito og ByteBuddy kobler seg til JVM-en mens testene kjører, og den socketen stenger cplt på macOS.

cplt config set sandbox.allow_localhost_any true
cplt config set sandbox.allow_jvm_attach true

Med allow_localhost_any når agenten alle tjenester som lytter på localhost, også en lokal database, og på Linux åpner den mer, se Tjenester på localhost. allow_jvm_attach åpner bare socketene /tmp/.java_pid<PID>, ingen andre.

Gjelder det ett prosjekt, legg innstillingene i repoet, så får hele teamet dem:

cplt config set --repo sandbox.allow_localhost_any true
cplt config set --repo sandbox.allow_jvm_attach true
git add .cplt.toml && git commit -m "chore: cplt-oppsett for Gradle"
cplt trust accept --all

Hvordan .cplt.toml og godkjenningen virker, står i Sett opp cplt i et repo. cplt init foreslår både allow_jvm_attach og allow_localhost_any for et Gradle-bygg. På Linux trenger du ikke allow_jvm_attach, for der stenger ikke cplt socketen.

Wrapperen og en liste over tillatte hoster

I standardoppsettet stopper cplt bare kjente skadelige hoster og hoster med private adresser. Da laster ./gradlew ned Gradle og avhengigheter som vanlig.

Maven Central og Gradle-plugins er med både i proxy.default_allowlist og i fila nav-pilot skriver, se Pakkeregistre og en liste over tillatte hoster.

Selve Gradle-distribusjonen som wrapperen laster ned, er ikke med. Den kommer fra services.gradle.org, som sender videre til github.com og release-assets.githubusercontent.com. Uten disse stopper ./gradlew før bygget starter, og proxyloggen viser BLOCKED-ALLOWLIST. Legg til hostene:

cplt config set allow.domains services.gradle.org
cplt config set allow.domains github.com
cplt config set allow.domains release-assets.githubusercontent.com

Copilot har github.com på lista fra før, så med Copilot kan du hoppe over den linja.

Sjekk en host uten å kjøre bygget:

cplt check net services.gradle.org

Pakker fra GitHub Packages

Mange navikt-biblioteker ligger i GitHub Packages. Speilet er den enkleste måten å hente dem på i sandkassen.

Navs speil, uten token

github-package-registry-mirror.gc.nav.no er et åpent speil av de offentlige pakkene i GitHub Packages. Det krever ingen token, så agenten trenger ikke tilgang til noen hemmeligheter:

repositories {
    mavenCentral()
    maven("https://github-package-registry-mirror.gc.nav.no/cached/maven-release")
}

Speilet står ikke på cplts liste over tillatte hoster. Bruker du en slik liste, legg det til:

cplt config set allow.domains github-package-registry-mirror.gc.nav.no

Token i ~/.gradle/gradle.properties

maven.pkg.github.com krever token. På macOS stenger cplt ~/.gradle/gradle.properties fordi fila ofte har tokens i seg, og finnes fila, stopper hvert Gradle-bygg i sandkassen med Error when loading properties file. Det tryggeste er å flytte det du trenger over til speilet og ta tokenet ut av fila. Ellers gir du agenten lesetilgang til fila, og dermed alle tokenene i den:

cplt config set allow.read ~/.gradle/gradle.properties

Hva det koster å åpne tokenfilene, og hvordan du åpner alle tre på én gang, står i Pakker fra GitHub Packages.

Leser bygget tokenet fra GITHUB_TOKEN, kommer det an på agenten. Copilot får GITHUB_TOKEN, GH_TOKEN og COPILOT_GITHUB_TOKEN slik de står i skallet ditt, fordi Copilot trenger et GitHub-token. OpenCode og de andre agentene får dem ikke, og det gjør heller ikke cplt exec. Der sender --pass-env GITHUB_TOKEN den med, men da har agenten tokenet ditt.

Received status code 401 from server: Unauthorized betyr at forespørselen kom fram, men at tokenet mangler.

Interne Nav-hoster

cplt stopper forbindelser til hoster som peker til en privat IP-adresse. Det gjelder også Gradle, fordi cplt sender JVM-ens nettverkstrafikk gjennom proxyen sin. Når en slik host er et Maven-repo, stopper bygget med Private target blocked by cplt. Det kan gjelde repo.adeo.no på Nav-nettet og hoster under intern.nav.no. Åpne hostene med navn:

cplt config set proxy.allow_private_domains repo.adeo.no
cplt config set proxy.allow_private_domains intern.nav.no

Ett navn dekker alle subdomenene. For ett prosjekt kan du bruke cplt config set --repo proxy.allow_private_domains … og godkjenne med cplt trust accept, slik pensjonsbrev gjør. For én økt holder flagget --allow-private-domain repo.adeo.no.

Står repoet oppført med en IP-adresse i stedet for et navn, for eksempel https://10.20.30.40/repository/, kan ingen innstilling åpne det. Bruk vertsnavnet i byggefila.

JDK-er som Gradle laster ned

Med jvmToolchain(…) og foojay-pluginen laster Gradle ned JDK-en prosjektet ber om, til ~/.gradle/jdks. På macOS kan agenten kjøre JDK-ene som ligger der, men ikke skrive nye dit, så en JDK som mangler, kan ikke lastes ned inne i cplt. På Linux er mappa skrivbar. Under en liste over tillatte hoster må api.foojay.io og hostene JDK-en hentes fra, stå på lista. For Temurin er det de samme som for wrapperen.

Kjør bygget én gang utenfor cplt, så ligger JDK-en klar. Etterpå kan du se hvilke JDK-er Gradle finner:

./gradlew javaToolchains

Vil du at bygget skal feile med en gang i stedet for å prøve å laste ned, sett dette i prosjektets gradle.properties:

org.gradle.java.installations.auto-download=false

Feilmeldingen fra foojay ser ut som et nettverksproblem. Se Unable to download toolchain.

Testcontainers og Docker

cplt stenger Docker, fordi tilgang til Docker i praksis er root på maskinen (se Docker i oppsettguiden). Testcontainers feiler derfor i cplt uten videre. Du har tre muligheter, fra tryggest til minst trygg:

  • Kjør testene som trenger containere, utenfor cplt. La agenten kjøre resten.
  • Start containerne selv, utenfor cplt, og åpne portene. Det passer for en database eller Kafka fra docker compose, men ikke for Testcontainers, som starter containerne selv.
  • Gi agenten Docker. Da virker Testcontainers, også med colima. Agenten kan da gjøre alt Docker kan, og lese ~/.docker med registerinnloggingene dine. Bruk det bare i et repo du stoler på, og helst bare for én økt.

En database på port 5432, startet utenfor cplt:

cplt config set allow.localhost 5432

Slik gir du agenten Docker for én økt eller fast. Testcontainers kobler seg til containerne over tilfeldige porter på localhost, så slå på allow_localhost_any også:

cplt --allow-docker
cplt config set sandbox.allow_docker true --force

Med colima må TESTCONTAINERS_DOCKER_SOCKET_OVERRIDE=/var/run/docker.sock være satt, som utenfor cplt. cplt sender DOCKER_HOST og TESTCONTAINERS_* videre til agenten.

Når bygget feiler

Slå på loggen over blokkerte forbindelser, og kjør bygget i sandkassen selv:

cplt config set proxy.log_level blocked
cplt exec -- ./gradlew build

Linjer med [proxy] og BLOCKED viser hvilken host som ble stoppet og hvorfor. Blokkeringer av filer og localhost står ikke der, se Filer, programmer og localhost. Feilmeldingene fra Gradle og JVM står i Feil i sandkassen. Mer om hvorfor står i known-impacts.md (engelsk).

Kommandoene på denne siden er testet med cplt fra 29. september 2026 på macOS, med et lite Kotlin-prosjekt, Gradle 9.7.0 og 9.8.0 og colima.