The last open task from #204. Both GraalVM examples (storm-example-kotlin-spring-boot-4-graalvm and storm-example-kotlin-ktor-graalvm) build and pass their end-to-end suites, but neither repo has any CI workflow, so a native build is never exercised automatically and a regression in the AOT/native path would go unnoticed until someone builds by hand.
Add a workflow to each example repo that runs the native build and the e2e suite (on a schedule or on push; native builds are too slow for every-PR of the framework repo). Building against the latest release keeps it simple; building against a framework snapshot would catch regressions before release, at the cost of wiring mavenLocal or a snapshot repository into the workflow.
Note: the value of this CI on the Java side is currently limited by #377 (the type index never records Java entities, so hints no-op for Java projects); both examples are Kotlin, which is the path that works today.
The last open task from #204. Both GraalVM examples (
storm-example-kotlin-spring-boot-4-graalvmandstorm-example-kotlin-ktor-graalvm) build and pass their end-to-end suites, but neither repo has any CI workflow, so a native build is never exercised automatically and a regression in the AOT/native path would go unnoticed until someone builds by hand.Add a workflow to each example repo that runs the native build and the e2e suite (on a schedule or on push; native builds are too slow for every-PR of the framework repo). Building against the latest release keeps it simple; building against a framework snapshot would catch regressions before release, at the cost of wiring mavenLocal or a snapshot repository into the workflow.
Note: the value of this CI on the Java side is currently limited by #377 (the type index never records Java entities, so hints no-op for Java projects); both examples are Kotlin, which is the path that works today.