--cli-ext-path Flag Ignored

[100tomer]

Hasura CLI --cli-ext-path Ignored Bug Report

Version Information

Server Version: v2.48.1
CLI Version (for CLI related issue): v2.48.0

---

Environment

OSS / self-hosted
node:22.16.0-alpine3.22

What is the current behaviour?

Passing --cli-ext-path to the Hasura CLI is acknowledged in logs, but the CLI still attempts to execute cli-ext from a generated subdirectory under/root/.hasura/cli-ext/v2.48.0/cli-ext-*/cli-ext. instead of the provided path.

---

What is the expected behaviour?

When specifying --cli-ext-path /usr/local/bin/cli-ext, the CLI should execute that path instead of trying to access /root/.hasura/cli-ext/v2.48.0/cli-ext-*/cli-ext.

---

How to reproduce the issue?

1. Build and run a custom cli-ext binary.
2. Run the following command:

   hasura metadata apply --cli-ext-path /usr/local/bin/cli-ext --log-level DEBUG

3. Observe the logs showing the CLI tries to use a path like /root/.hasura/cli-ext/v2.48.0/cli-ext-1730425712/cli-ext instead.

---

Screenshots or Screencast

DEBU cli-ext: setting up using --cli-ext-path binary
...
error: error in converting sdl to metadata: fork/exec /root/.hasura/cli-ext/v2.48.0/cli-ext-1730425712/cli-ext: no such file or directory

---

Please provide any traces or logs that could help here.

DEBU cli-ext: setting up using --cli-ext-path binary
...
error: error in converting sdl to metadata: fork/exec /root/.hasura/cli-ext/v2.48.0/cli-ext-1730425712/cli-ext: no such file or directory

Full logs

it says it uses the flag but at the same time go to different path
/hasura-migration-folder # hasura-cli  metadata apply --cli-ext-path /usr/local/bin/cli-ext --log-level DEBUG
DEBU global config file exists, verifying contents
DEBU global config is pre-set to &cli.GlobalConfig{UUID:"9500cfc7-2635-48de-908f-92d9d203c9c8", EnableTelemetry:true, ShowUpdateNotification:true, CLIEnvironment:"default"}
DEBU global config: uuid: 9500cfc7-2635-48de-908f-92d9d203c9c8
DEBU global config: enableTelemetry: true
DEBU global config: showUpdateNotification: true
DEBU global config: cliEnvironment: default
DEBU versions: cli: [v2.48.0] server: [v2.48.1]
DEBU compatibility check: [true] compatible CLI and Server
DEBU graphql engine endpoint: http://host.docker.internal:9081
DEBU graphql engine admin_secret: ‹×›
DEBU server: uuid: 71cfd471-cf42-4c98-8570-6b92ae7fc4d6
DEBU cli-ext: setting up using --cli-ext-path binary
DEBU output:                                       command="sdl from"
DEBU telemetry: beamed                             fields.time=332.366833ms isError=true
DEBU error applying metadata
cannot build actions from project: error parsing metadata
object: actions
file: actions.yaml
error: error in converting sdl to metadata: fork/exec /root/.hasura/cli-ext/v2.48.0/cli-ext-1730425712/cli-ext: no such file or directory:   kind="bad input" location="file: /workdir/cli/internal/metadataobject/actions/cli_extension/cli_extension.go, line: 107" ops="[command: hasura metadata apply.RunE commands.MetadataApplyOptions.Run commands.metadataModeDirectoryHandler.Apply commands.errorApplyingMetadata projectmetadata.Handler.V2ApplyMetadata projectmetadata.Handler.BuildJSONMetadata projectmetadata.Handler.buildMetadata projectmetadata.Handler.buildMetadataMap actions.ActionConfig.Build cliextension.Config.ConvertSDLToMetadata]"
FATA[0000] error applying metadata
cannot build actions from project: error parsing metadata
object: actions
file: actions.yaml
error: error in converting sdl to metadata: fork/exec /root/.hasura/cli-ext/v2.48.0/cli-ext-1730425712/cli-ext: no such file or directory:

---

Any possible solutions/workarounds you're aware of?

None. The number in the path is randomly generated on each execution, so it is not feasible to predict or symlink to it ahead of time.

---

Keywords

hasura cli, cli-ext, metadata apply, --cli-ext-path ignored, bug, plugin path, fork/exec error

[100tomer]

Quick update after some further research: it looks like the Hasura CLI attempts to copy either the provided or embedded cli-ext binary (still unclear which) to a custom path, for example:
/root/.hasura/cli-ext/v2.48.0/cli-ext-1730425712/cli-ext — which includes a randomly generated folder in the path.

For some reason, this operation fails in the Alpine-based image but works correctly in the hasura/graphql-engine:v2.48.0.cli-migrations-v3.ubuntu image.

[100tomer]

Another update: while listening for file changes, I ran
hasura-cli metadata apply --cli-ext-path /usr/local/bin/cli-ext --log-level DEBUG

It seems that the CLI does copy the cli-ext to a custom location:

2a57aa6823fa:~#  inotifywait -m -r -e create -e delete --format '%e %w%f' ./
Setting up watches.  Beware: since -r was given, this may take a while!
Watches established.
CREATE,ISDIR ./.hasura/cli-ext/v2.37.0/cli-ext-528476253
CREATE ./.hasura/cli-ext/v2.37.0/cli-ext-528476253/cli-ext
DELETE ./.hasura/cli-ext/v2.37.0/cli-ext-528476253/cli-ext
DELETE,ISDIR ./.hasura/cli-ext/v2.37.0/cli-ext-528476253

However, I still get the following error:

error: error in converting sdl to metadata: fork/exec /root/.hasura/cli-ext/v2.37.0/cli-ext-528476253/cli-ext: no such file or directory:  

[100tomer]

Okay, I believe the issue isn’t related to the --cli-ext-path flag, but rather to the fact that I’m using Alpine.
Is there any way to get the Hasura CLI working with cli-ext on Alpine?
Any help would be greatly appreciated.

[robertjdominguez]

Hi, @100tomer — thanks for the question and extensive detail in investigating it 🙏

I'm acknowledging we've received this and will make an effort to get back to you be Friday with more information. This is in the queue 👍

[100tomer]

Hi, @100tomer — thanks for the question and extensive detail in investigating it 🙏

I'm acknowledging we've received this and will make an effort to get back to you be Friday with more information. This is in the queue 👍

Thanks, I appreciate that! I'll update here if I have any more info.

[robertjdominguez]

Hey @100tomer — have you tried to build the binary for Alpine? Sorry, I see in Step 1 above you mention building the custom binary, but I want to make sure we're on the same page first 👇

We've these docs here that reference supported architectures for the npm package used, including Alpine.

[100tomer]

Hey @100tomer — have you tried to build the binary for Alpine? Sorry, I see in Step 1 above you mention building the custom binary, but I want to make sure we're on the same page first 👇

We've these docs here that reference supported architectures for the npm package used, including Alpine.

Yes, I did try to build it — I probably got something wrong.

Here’s the Dockerfile I’m using to test things on my MacBook m1:

# -------------------- CLI-EXT Build Stage --------------------
FROM node:22.16.0-alpine3.22 AS cli-ext-builder

WORKDIR /cli-ext

# Install build tools and git
RUN apk add --no-cache python3 make g++ curl git

# Clone only cli-ext part of Hasura repo
RUN git clone --depth=1 --filter=blob:none --sparse https://github.com/hasura/graphql-engine.git . && \
    git sparse-checkout add cli-ext

WORKDIR /cli-ext/cli-ext

# Install NPM dependencies and transpile
RUN npm install && npm run transpile

# Install pkg and build standalone binary
RUN npm install -g pkg && \
    pkg build/command.js --targets node16-linux-arm64 --output /cli-ext-bin/cli-ext

# -------------------- Final Image --------------------
FROM node:22.16.0-slim

# Install inotify-tools for watching file/folder changes
RUN apt-get update && apt-get install -y inotify-tools && apt-get clean

COPY --from=cli-ext-builder /cli-ext-bin/cli-ext /usr/local/bin/cli-ext
COPY /hasura-metadata-for-test /hasura-metadata-for-test

ENTRYPOINT [ "sh" ]

When I run the exact same build stage but change the final image base to FROM hasura/graphql-engine:v2.48.0.cli-migrations-v3.ubuntu, it works, the cli-ext binary built in the Alpine stage runs fine.

[robertjdominguez]

Got it — thanks for clarifying!

[robertjdominguez]

I don't believe there are any workarounds; I've raised this internally, and we'll get someone from the CLI team who can provide better input for you, @100tomer.

[100tomer]

I don't believe there are any workarounds; I've raised this internally, and we'll get someone from the CLI team who can provide better input for you, @100tomer.

Thank you, I will wait for their input.

[100tomer]

@robertjdominguez just following up in case this might have been missed, totally understand if the team is busy.

I also wanted to share a bit more context: the reason I went with Alpine and built the cli-ext manually is that I’m aiming to create a more secure image with zero known vulnerabilities. With Alpine, I was able to achieve that. On top of that, the image size is significantly smaller, which really helps speed up our deployments.

Let me know if there’s anything else I can do in the meantime.

[robertjdominguez]

Thanks for your patience, @100tomer 🙏

While this hasn't gotten lost, it's definitely a lower priority. However, I have this sitting on my board in Linear and won't let it get away 😉

The additional context is helpful; I've shared it with the team in our internal ticket.

[100tomer]

Thanks for your patience, @100tomer 🙏

While this hasn't gotten lost, it's definitely a lower priority. However, I have this sitting on my board in Linear and won't let it get away 😉

The additional context is helpful; I've shared it with the team in our internal ticket.

Thanks keeping this in mind @robertjdominguez, I really appreciate it.
Just wanted to confirm that I am still happy to help test any potential fix or workaround from the CLI team. I understand it is a lower priority, but if there is anything I can do to assist or verify on my end, feel free to tag me.

Thanks again