Hopp til innhold
cd /languages
  • Skripting på JVM
  • Programmering
  • AST- og symbolstøtte

Groovy i Maguyva: kodegrafer for Gradle- og Jenkins-kode

Maguyva støtter Groovy med AST, symboler og graf, slik at AI-agenter kan følge klasser, closures og kall i Groovy-apper, Gradle-bygg og Jenkinsfiles.

Der Groovy får overfladiske AI-verktøy til å snuble

Groovy leses ofte som konfigurasjon. I et Gradle-bygg er dependencies { implementation ... } en kjede av metodekall med closures, og en deklarativ Jenkinsfile likeså. Builders gjør vilkårlige navn til kall, og GDK legger til metoder som each og collect på alle objekter. Et verktøy som registrerer hvert kall, drukner i den støyen.

Maguyva filtrerer bort DSL- og GDK-laget, slik at dine egne metoder og klasser trer frem.

Hva Maguyva henter ut i Groovy

Maguyva dekker .groovy- og .gradle-filer og Jenkinsfile. Klasser, funksjoner og metoder hentes ut, og importer normaliserer import static- og as-aliaser. Kallnavn renses for avsluttende closure-blokker og safe-navigation-operatoren ?., så repo?.save(order) { ... } registreres som et kall til save. Et kall uten mottaker inne i en klasse slås opp til klassens egen metode.

Støy filtreres i lag:

  • Rundt 140 navn fra standardbiblioteket, Gradle og Spock, som dependencies, implementation, task, given, when, then og Mock.
  • Rundt 260 GDK-metoder, som each, collect, inject og eachLine.
  • Builder-DSL-navn, inkludert Jenkins-steg som pipeline, stage, steps og sh, når de brukes i builder-stil i stedet for å kalles med parenteser.
  • AST-transformasjons- og rammeverksannotasjoner som @CompileStatic, @Immutable og @Autowired, som aldri registreres som kall.

Grafen registrerer også arv, instansiering og lesinger og skrivinger.

Eksempler på prompter for agenter

  • «Hvem kaller deployToStaging, og fra hvilke pipelines?» (find_symbol, deretter dependency_search incoming)
  • «Hvilke klasser arver fra BaseIntegrationSpec?» (dependency_search)
  • «Forklar hvordan release-tasken bygger og publiserer artefakter.» (get_task_context)

Kjente begrensninger

  • Groovy-metoder og frie funksjoner deler én syntaksnode, så presetet methods i structural_search velger ingenting. Bruk i stedet presetet functions eller find_symbol.
  • En egen metode med samme navn som en GDK- eller DSL-metode, som collect eller stage, kan bli filtrert bort sammen med dem. Bruk text_pattern_search når en kaller ser ut til å mangle.

Neste steg

Koble til et repositorium med hurtigstarten, og se deretter støttematrisen på kompatibilitetssiden. For JVM-koden som byggene dine kompilerer, bør du lese veiledningen for Java og veiledningen for Kotlin.

Best egnet

  • > Gradle-bygg skrevet i Groovy, der delt byggelogikk ligger i mange `.gradle`-filer.
  • > Jenkins-pipelines og shared libraries som agenter må lese før CI endres.
  • > Groovy-applikasjoner og Spock-testsuiter på JVM.

Agent-arbeidsflyter

  • > Finne alle kallere av et steg i et shared library før argumentene endres.
  • > Spore hvilke byggeskript som kaller en hjelpefunksjon definert i en felles `.gradle`-fil.
  • > Kartlegge hvilke klasser som arver fra en baseklasse før en refaktorering.

Motordetaljer

  • > Groovy-støtten dekker `.groovy`, `.gradle` og `Jenkinsfile`. Kallnavn mister closure-blokker og `?.`-safe-navigation.
  • > Rundt 140 navn fra standardbiblioteket, Gradle og Spock og rundt 260 GDK-metoder filtreres bort fra relasjonene.
  • > Builder-DSL-navn, inkludert Jenkins-steg som `stage` og `sh`, filtreres i builder-stil, og annotasjoner registreres aldri som kall.

Nyttige MCP-inngangspunkter

  • find_symbol

    Bruk det for et steg i et shared library, en byggehjelper eller en klasse når du trenger definisjonen og kallerne.

  • dependency_search

    Bruk incoming-traversering på en byggehjelper for å se hvilke skript og pipelines som kaller den.

  • text_pattern_search

    Bruk det for DSL-kall og GDK-metoder, som filtreres bort fra grafen.