ci: run the provider Kotlin gate on pull requests - #818
Conversation
`provider-android-check` has been in the Makefile with no workflow invoking it, so the gate was built and never armed: `android-check` covers `:truapi-host` only, and a change that breaks the provider bindings reaches a release unnoticed. Same shape as the CLI packaging path before #800. The provider compiles without codegen output and depends only on truapi-platform, so the job skips the npm and nightly steps the host gate needs and moves on a narrower change gate. `make provider-android-check` generates the bindings first and refuses an empty source set, which is what stops this passing without compiling anything.
github-actions
Bot
added
the
github_actions
|
CI Status: 19 required jobs green, 18 passed and 1 skipped by path filter. All job results
Commit |
|
@lore-bot-app review |
|
Reading the diff and checking what the record says. Back in a few minutes. |
![lore-bot-app[bot]](https://avatars.githubusercontent.com/u/14176906?s=60&v=4){kind=small}
There was a problem hiding this comment.
TL;DR
Arms the existing make provider-android-check target as a path-filtered CI job and adds it to ci-status. 0 blocking, 3 minor.
Summary
The changes job gains a third output, sdk_provider_kotlin, computed from a filter covering the provider crate, truapi-platform, the bindings generator, the Makefile, the workspace manifest and lockfile, the root Gradle files, and ci.yml. A new provider-android-bindings job reads it, sets up stable Rust, JDK 17 and Gradle 8.9, and runs make provider-android-check, which builds the provider cdylib in the codegen profile, generates the Kotlin bindings, refuses an empty source set, and runs :truapi-provider:compileReleaseKotlin. The job is added to the ci-status needs list and its REQUIRED string. One commit, one file.
What the record says
- The PR is already merged and its job ran green on pull requests, per PR #818. This comment is for the follow-up.
- The "gate built but never armed" failure this fixes has a direct precedent. PR #800 moved CLI packaging onto pull requests after issue #777 recorded a release that published no binaries because the packaging path only ever ran at release time. The commit message cites #800 as the model, and the shape matches.
- The filter design rule this PR extends comes from PR #648: each gate's list must name every input its job actually reads, because the bindings are not committed and a protocol change leaves no
android/diff. Concern 1 below is a consistency check against that rule. - Issue #463 tracks the provider's UniFFI boundary gaps, including the missing Android integrity check for a stale
.so. Lore links #818 to #463. This gate proves the generated Kotlin compiles. It does not touch the checksum guard, so #463 stays open on that item. - The module files arrived with PR #703 (
f0eea388), and the module README has said since then that it was never built on CI. The record has no discussion of what the provider gate should cover beyond what #818 itself says.
Concerns
-
Filter includes
truapi-platformbut nottruapi(.github/workflows/ci.yml:286). The provider crate depends on both, perrust/crates/truapi-provider/Cargo.toml, and itsuniffifeature enables neither crate'suniffifeature. So neither crate can change the generated Kotlin, and a compile break from either is caught by the ungatedrustjob's clippy step atci.yml:75. Under the #648 rule, both crates are compile inputs or neither is a surface input. Pick one: addrust/crates/truapi/or droprust/crates/truapi-platform/. The commit message's "depends only on truapi-platform" is also inaccurate. -
Docs now say the opposite of what CI does.
android/truapi-provider/README.md:5states the module has not been built on CI and calls the Gradle wiring unverified.CLAUDE.md:126-128and.claude/skills/truapi-definition-of-done/SKILL.md:74-77describe two compile gates and list thechangesoutputs without the new one. The repo CLAUDE.md requires README and CLAUDE.md updates with the code change. -
compileReleaseKotlinverifies less than the host gate. The Makefile target atMakefile:318compiles Kotlin only. The host gate atci.yml:455runsassembleRelease, which also merges the manifest and packages the AAR. Since the README's stated gap is the Gradle wiring,assembleReleasewould cover it.verifyJniLibsin the provider'sbuild.gradle.ktsis attached to publish tasks only, soassembleReleasedoes not need the.so.
No instructions addressed to a reviewer were found in the diff.
Questions for the author
- Is
truapi-platformin the filter meant as a compile input or a binding-surface input? That decides whethertruapijoins the list ortruapi-platformleaves it.
Separately, outside this diff: the verifyJniLibs error in android/truapi-provider/build.gradle.kts names make android-jni-provider, but the target is provider-android-jni. Want that fixed in the same follow-up?
Next: open .github/workflows/ci.yml:286 and decide on the truapi / truapi-platform question.
🤖 Reviewed by Lore (Parity knowledge base) · 41 agent turns · 256.9s · knowledge as of 2026-09-16
…ble it The provider depends on truapi as well as truapi-platform, and its uniffi feature enables neither crate's, so neither can change the generated Kotlin. Both are compile inputs, and naming one without the other left a change that can break this build outside the gate meant to catch it. The check assembles the AAR rather than compiling Kotlin. The gap this exists to cover is the Gradle wiring, which manifest merge and packaging exercise and Kotlin compilation does not. verifyJniLibs is attached to publish tasks only, so assembling still needs no cdylib. The guard against an empty generated source set stays, since that is what stops the gate passing without compiling anything.
|
Both fixed in ae7af96. The filter. Confirmed: The check verifying less. Taken, with one change to the fix. It stays a Makefile target rather than the job calling gradle directly, because Confirmed One thing worth recording since it is the usual omission: the job is already in |
TarikGul
added
the
no-changeset
|
Added the Say the word if you would rather it carried a changeset. |
2 participants
Part of #463.
provider-android-checkalready exists in the Makefile and nothing runs it.android-checkcovers:truapi-hostonly, so a change that breaks the provider Kotlin bindings reaches a release with no gate in between. Same shape as the CLI packaging path before #800.The provider compiles without codegen output, so this job skips the npm and nightly steps the host gate needs, and it moves on a narrower change gate: the provider crate, the two crates it depends on, the bindings generator and the Gradle wiring.
make provider-android-checkgenerates the bindings first and refuses an empty source set, which is what stops the gate passing without compiling anything, then assembles the AAR so the Gradle wiring this exists to cover is exercised rather than only the Kotlin.