CICD automation fails with "node:internal/streams/readable:705" due to lack of stdin

[PvanHengel]

Hi,

We are using the webpack5 plugin, and build's run fine locally, as well as locally in docker image, but when running via bitbucket cloud automation we get the below error. Ive spent a huge amount of time trying to debug this issue to no avail. It may have something to do with the std out/err or maybe file system, but its a bit of a black block.

as an aside ive tried webpack (4) as well as parcel, but i cant get either to work locally for other unrelated reasons.

ℹ [0003] Finding the version of "piral-native,piral,piral-core,piral-base" in "/app".
ℹ [0003] Finding the version of "piral-native,piral,piral-core,piral-base" in "/app".
ℹ [0003] Used versions: "0.15" and "0.15".

• Starting emulator build ...
  ℹ [0003] Removing the directory "/app/dist/emulator" ...
  ℹ Bundle emulator ...
  node:internal/streams/readable:705
  dest.end();
  ^
  TypeError: dest.end is not a function
  at onend (node:internal/streams/readable:705:10)
  at process.processTicksAndRejections (node:internal/process/task_queues:77:11)
  Node.js v18.12.1
  error Command failed with exit code 1.

[PvanHengel]

Intersting i get the same error with webpack4 as well now:

• "piral-cli-webpack5": "0.15.5",

• "piral-cli-webpack": "0.15.2",

What happens immediately after ℹ Bundle emulator ...

[FlorianRappl]

Is there a MWE? Otherwise, we cannot look into this.

(Also please make sure to use the bug template - there are crucial pieces of information missing in the OP, e.g., the OS, used versions, ...)

[PvanHengel]

• [Y] Can you reproduce the problem in a MWE?
  see here: https://bitbucket.org/PvHIvz/piralmwe/pipelines/results/1/steps/%7B32b7886c-62a8-4af8-a667-71d9e2b0645b%7D

• [Y] Are you running the latest version?
  see package versions here: https://bitbucket.org/PvHIvz/piralmwe/src/main/package.json

• [Y] Did you perform a search in the issues?

[Package Version, OS, Browser, ...]
Interestingly, it works when building locally using docker image, but not when building from cloud...

Description

With a shell Piral application I am able to build locally but not via CICD pipeline in the cloud, get an odd error, which looks like it may be related to something specific with the streams, perhaps stdin being piped?

You can view the exact logs here: https://bitbucket.org/PvHIvz/piralmwe/pipelines/results/1

I am a little suspect of this:

piral/src/tooling/piral-cli/src/build/bundler-calls.ts

Line 118 in 517f274

ps.stdin.pipe(process.stdin);

causing issues

Just some more research seems like others have had this issue with an unrelated package but worth digging:
cypress-io/cypress#2181
and in particular: cypress-io/cypress#2181 (comment)

and check out their fix:
https://github.com/CodingGardenCommunity/app-frontend/pull/13/files

[PvanHengel]

Fixed with a patch:
https://bitbucket.org/PvHIvz/piralmwe/commits/0593647fba67f37f60e1932ec720da4f390036c2

https://bitbucket.org/PvHIvz/piralmwe/src/0593647fba67f37f60e1932ec720da4f390036c2/patches/piral-cli+0.15.5.patch

prob a better way then just commenting out since that will break other stuff i'm sure on desktop, but needs a think about how to put this into the piral-cli tooling.

[FlorianRappl]

Yes, thanks for the MWE, the investigation, and the proposed fixed. Indeed, it seems that under certain circumstances stdin (or other streams) might be undefined.

The fix in the referenced repo works on this condition, e.g., they do

child.stdin && child.stdin.pipe(process.stdin);
child.stdout && child.stdout.pipe(process.stdout);

I think we should do the same.

[PvanHengel]

Hi I think there is a missing check stdin here, as I just upgraded our CI, and encountered it again:

https://github.com/smapiot/piral/blob/develop/src/tooling/piral-cli/src/build/bundler-calls.ts#L118

[FlorianRappl]

Right - it was only changed in the dynamic part which is used, e.g., for debugging (there, actually, it is quite unlikely to occur anyway).

Build is currently running - you can then check with the preview version of piral-cli in 0.15.7 (will be available via next tag on npm).

[gitisz]

Giving next a try as I also saw the same from Jenkins...

21:52:48  Step 2/25 : COPY . .
21:52:48   ---> c4d63a1d7c79
21:52:48  Step 3/25 : RUN npm install && npx piral build
21:52:48   ---> Running in 50e312f05b41
21:52:48  
21:52:48  > cr-oneui-static-content@1.0.0 postinstall
21:52:48  > piral declaration
21:52:48  
21:52:48  🦋  piral-cli v0.15.7-beta.5146
21:52:48  - Reading configuration ...
21:52:48  - Bundling declaration file ...
21:52:48  - Writing declaration file ...
21:52:48  ✔ Declaration created successfully in "./dist"!
21:52:48  
21:52:48  added 557 packages in 11s
21:52:48  
21:52:48  66 packages are looking for funding
21:52:48    run `npm fund` for details
21:52:48  🦋  piral-cli v0.15.7-beta.5146
21:52:48  - Reading configuration ...
21:52:48  - Starting emulator build ...
21:52:48  ℹ Bundle emulator ...
21:52:48  node:internal/streams/readable:705
21:52:48      dest.end();
21:52:48           ^
21:52:48  
21:52:48  TypeError: dest.end is not a function
21:52:48      at onend (node:internal/streams/readable:705:10)
21:52:48      at process.processTicksAndRejections (node:internal/process/task_queues:77:11)
21:52:48  
21:52:48  Node.js v18.12.1
21:52:48  The command '/bin/sh -c npm install && npx piral build' returned a non-zero code: 1

Seems like issue still prevails.

[gitisz]

Likely the problem is that from a CI server, there is no TTY, and so the stdin fails.

I was able to workaround by:

FROM node as BUILD-ENV
COPY . .
RUN npm install
RUN echo yes | npx piral build --type release

Not sure how much user input is required in CLI outside of selecting the bundler, but most will probably configure from local and package-lock.json retains user selection for CI. Still though, IMHO a CLI shouldn't ever require TTY.

[FlorianRappl]

Please make sure you indeed use the next version. If your patch worked beforehand, then the real next has to work, otherwise either your patch did not work either or you indeed do not use next.

[gitisz]

@FlorianRappl I am not the OP here, but just jumping on a thread for having the same issue. From above, isn't piral-cli v0.15.7-beta.5146 in the log evidence of next?

[FlorianRappl]

@gitisz My comment is quite independent of that - it essentially states that either the next version is not correctly applied or the patch posted by the OP is not working. If you know for sure that the current version was applied then the latter must be the case (simple logic).

Independent of that we still require a reproducible of the issue. There is a new preview version out, but without a reproducible it will be hard to verify the fix.

[PvanHengel]

Hi, sorry been super buys, I can confirm that using the next version solves the issue for us. @gitisz if it does not for you make sure you are pulling the latest version, also check your lock files to be sure they are not pinned. Also make sure you have one and only one bundler there, otherwise it fails back to the CLI input, which for obvious reasons will not work through automation.

P

[FlorianRappl]

Closing for now as the OP issue seems to be resolved - if we get a reproducible / this happens again in another environment we should have a new / separate issue for tracking purposes.