Přeskočit na obsah
cd /languages
  • Skriptování na JVM
  • Programování
  • Podpora AST a symbolů

Groovy v Maguyva: grafy kódu pro Gradle a Jenkins

Maguyva podporuje Groovy s AST, symboly a grafem, takže AI agenti sledují třídy, closures a volání v aplikacích Groovy, buildech Gradle a souborech Jenkinsfile.

Kde Groovy podráží povrchní AI nástroje

Groovy se často čte jako konfigurace. V buildu Gradle je dependencies { implementation ... } řetězec volání metod s closures a deklarativní Jenkinsfile je na tom stejně. Buildery dělají z libovolných jmen volání a GDK přidává každému objektu metody jako each a collect. Nástroj, který zaznamená každé volání, se v tom šumu utopí.

Maguyva vrstvu DSL a GDK odfiltruje, aby vynikly vaše vlastní metody a třídy.

Co Maguyva v Groovy extrahuje

Maguyva pokrývá soubory .groovy a .gradle a také Jenkinsfile. Extrahují se třídy, funkce a metody a importy normalizují aliasy import static a as. Názvy volání se čistí od koncových bloků closures a operátoru bezpečné navigace ?., takže repo?.save(order) { ... } se zaznamená jako volání save. Volání bez příjemce uvnitř třídy se rozliší na vlastní metodu dané třídy.

Šum se filtruje ve vrstvách:

  • Asi 140 názvů ze standardní knihovny, Gradle a Spocku, například dependencies, implementation, task, given, when, then a Mock.
  • Asi 260 metod GDK, například each, collect, inject a eachLine.
  • Názvy DSL builderů, včetně kroků Jenkinsu jako pipeline, stage, steps a sh, pokud se používají ve stylu builderu, a ne jako volání se závorkami.
  • Anotace transformací AST a frameworků jako @CompileStatic, @Immutable a @Autowired, které se nikdy nezaznamenávají jako volání.

Graf zaznamenává také dědičnost, vytváření instancí a čtení a zápisy.

Ukázkové prompty pro agenty

  • „Kdo volá deployToStaging a z kterých pipeline?“ (find_symbol, pak dependency_search incoming)
  • „Které třídy dědí z BaseIntegrationSpec?“ (dependency_search)
  • „Vysvětli, jak úloha release sestavuje a publikuje artefakty.“ (get_task_context)

Známá omezení

  • Metody a volné funkce v Groovy sdílejí jeden syntaktický uzel, takže preset methods v structural_search nic nevybere. Použijte místo něj preset functions nebo find_symbol.
  • Vaše metoda se stejným názvem jako metoda GDK nebo DSL, například collect nebo stage, se může odfiltrovat spolu s nimi. Když se zdá, že nějaké volání chybí, použijte text_pattern_search.

Další kroky

Připojte repozitář podle rychlého startu a pak si prohlédněte matici podpory na stránce kompatibility. Pro kód JVM, který vaše buildy kompilují, si přečtěte průvodce jazykem Java a průvodce jazykem Kotlin.

Nejlépe se hodí pro

  • > Buildy Gradle psané v Groovy, kde sdílená logika buildu žije v mnoha souborech `.gradle`.
  • > Pipeline Jenkinsu a sdílené knihovny, které musí agenti přečíst před změnou CI.
  • > Aplikace v Groovy a testovací sady Spock na JVM.

Workflow agentů

  • > Najít všechna volání kroku sdílené knihovny před změnou jeho argumentů.
  • > Vysledovat, které skripty buildu volají pomocnou funkci definovanou ve společném souboru `.gradle`.
  • > Před refaktoringem zmapovat, které třídy dědí ze základní třídy.

Podrobnosti enginu

  • > Podpora Groovy pokrývá `.groovy`, `.gradle` a `Jenkinsfile`. Názvy volání ztrácejí bloky closures a bezpečnou navigaci `?.`.
  • > Asi 140 názvů ze standardní knihovny, Gradle a Spocku a asi 260 metod GDK se z relací odfiltruje.
  • > Názvy DSL builderů, včetně kroků Jenkinsu jako `stage` a `sh`, se ve stylu builderu odfiltrují a anotace se nikdy nezaznamenávají jako volání.

Užitečné vstupní body MCP

  • find_symbol

    Použijte ho pro krok sdílené knihovny, pomocnou funkci buildu nebo třídu, když potřebujete definici a volající.

  • dependency_search

    Použijte incoming procházení na pomocné funkci buildu, abyste viděli, které skripty a pipeline ji volají.

  • text_pattern_search

    Použijte ho pro volání DSL a metody GDK, které se z grafu odfiltrují.