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

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