`functions build` via the action drops custom endpoints (satellite_extension.did → `service : {}`)

[AntonioVentilii]

Summary

Running functions build inside junobuild/juno-action@full produces a satellite_extension.did of service : {} — i.e. a satellite with none of its custom endpoints (defineQuery / defineUpdate). Running the same CLI version locally (or npm i -g @junobuild/cli@… against the project’s own node_modules in CI) builds the full, correct interface.

Because the build still "succeeds", the action goes green and functions upgrade / functions publish then ship a satellite whose custom methods are simply missing. The only symptom is runtime "method not found" errors that only reproduce via CI, never locally — which makes this quite hard to diagnose.

Impact

• upgrade.yml / publish.yml style workflows using the action silently deploy a satellite with no custom endpoints.
• CI is green; the breakage only surfaces at runtime against the deployed canister.
• The generated satellite_extension.did is service : {} instead of listing the endpoints.

Likely root cause

The runtime image bundles its own toolchain that does not match the consuming project’s dependencies:

1. Stale @icp-sdk/bindgen. kit/setup/addons pins npm i -g @icp-sdk/bindgen@0.3.0. Projects on a current @junobuild/functions (we’re on 0.9.0) pin @icp-sdk/bindgen@^0.4.0. The build appears to use the image’s global bindgen 0.3.0, which is too old to enumerate the defineQuery / defineUpdate exports → it emits an empty service. When the build instead runs against the project’s node_modules (with bindgen ^0.4.0), the interface is generated correctly. This is the decisive difference.
2. Sputnik compiled from main, not a release. docker/download/juno-source uses BRANCH=main, so the Sputnik runtime baked into the image is whatever juno main HEAD was at image-build time — non-reproducible and free to drift from the released @junobuild/functions the project imports.

Reproduction

1. A satellite with TS serverless functions that exports custom endpoints via defineQuery / defineUpdate from @junobuild/functions@0.9.0, with @icp-sdk/bindgen@^0.4.0 in devDependencies.
2. Build via the action:

   - uses: junobuild/juno-action@full
     with:
       args: functions build

3. Inspect the generated src/satellite/satellite_extension.did.

Expected: the service lists the defineQuery / defineUpdate endpoints (matching a local juno functions build --lang ts).

Actual: service : {} — every custom endpoint is dropped.

Workaround

Don’t let the action build. Install the pinned CLI in CI and build against the project’s own node_modules:

- run: npm ci
- run: npm i -g @junobuild/cli@0.15.4
- run: juno functions build --lang ts

The action is then only used for steps that don’t build a wasm (e.g. functions publish for its OIDC token exchange, hosting deploy).

Suggested fix

• Make functions build use the project’s installed @icp-sdk/bindgen (and other juno deps from node_modules) rather than the image’s global pins, or bump the bundled @icp-sdk/bindgen in kit/setup/addons to match the current CLI / @junobuild/functions line.
• Pin docker/download/juno-source to a released tag instead of BRANCH=main so the bundled Sputnik runtime is reproducible and matches a published @junobuild/functions.

Environment

• Action ref: junobuild/juno-action@full → image docker://junobuild/action:0.7.3
• Bundled in image: @junobuild/cli@0.15.4 (kit/setup/tools), @icp-sdk/bindgen@0.3.0 (kit/setup/addons), Sputnik from juno@main (docker/download/juno-source)
• Project: @junobuild/functions@0.9.0, @icp-sdk/bindgen@^0.4.0, local CLI 0.15.4
• Runner: ubuntu-latest

[peterpeterparker]

Thanks for the issue. I could replicate it in https://github.com/peterpeterparker/juno-action-issue-108.

Summary: the Sputnik WASM built and published using GitHub Actions does not include the custom endpoints - i.e. it does not include the Rust code generated from the TypeScript code.

I could assert that the Rust code seems to be generated (sputnik_index.rs is present in https://github.com/peterpeterparker/juno-action-issue-108/actions/runs/27017058623/job/79734753820), therefore the issue is likely that the build function instructing Cargo to use the generated module is not defined.

I traced this back to the CLI Rust build and patched it in junobuild/cli#515.

Hard to assert the fix without releasing - which I'll do now. 🤞

[AntonioVentilii]

@peterpeterparker thank you very much for this!!! We can test it on the field: if you want I test it right away after the release, in my repo, and come back here to give feedbacks.

[peterpeterparker]

The new GitHub Action version v0.15.5 should resolve the issue - i.e. it seems that the CLI patch shipped here in #/110 does the trick for the sample project. I cannot replicate the issue anymore.

Can you double check and let me know if it solves it for you as well?

[peterpeterparker]

Closing it. If it ain't resolve on your hand @AntonioVentilii please ping me, happy to reopen it and revisit. Thanks for the help!

[AntonioVentilii]

All good and perfect! Thank you @peterpeterparker !