Skip to content
This repository has been archived by the owner on May 23, 2021. It is now read-only.

nbin should throw an exception when 0 files are written #41

Open
deftdawg opened this issue Jan 24, 2020 · 1 comment
Open

nbin should throw an exception when 0 files are written #41

deftdawg opened this issue Jan 24, 2020 · 1 comment

Comments

@deftdawg
Copy link

Currently trying to package up an arm build and receiving success with 0 files written. (I fully acknowledge that arm is probably not supported, however the issue is I'm reporting with this is a logic flaw that is independent of architecture.)

Expected:

If nbin should ever end up in a scenario were it has written 0 files to the binary it should throw an error message because the resulting binary will be broken. Currently the writeFiles function @ https://github.com/cdr/nbin/blob/master/src/api/bundler.ts#L35 doesn't handle this.

Observed:

$ cd ./scripts && node --max-old-space-size=32384 -r ts-node/register ./build.ts binary 1.41.1 -deftdawg-raspbian-10
[binary] Not running inside VS Code
[binary] rootPath is "/home/pi/code-server"
[binary] outPath is "/home/pi/code-server"
[binary] arch is "arm"
[binary] target is "linux"
[binary] vscodeVersion is "1.41.1"
[binary] codeServerVersion is "-deftdawg-raspbian-10"
✔ Wrote 0 files!
(node:8617) Warning: Setting the NODE_TLS_REJECT_UNAUTHORIZED environment variable to '0' makes TLS connections and HTTPS requests insecure by disabling certificate verification.
[binary] Binary: /home/pi/code-server/binaries/code-server-deftdawg-raspbian-10-vsc1.41.1-linux-arm
Done in 127.70s.

The result is a binary is 15MB and immediately does an illegal instruction upon being invoked because it is an empty self-executing container. A successful build of code-server is ~200+MB.

@deftdawg
Copy link
Author

In my case the condition that caused this was a non-existent build directory.
(I ported a build from a debian machine to a raspbian; the system variables I tagged my build with changed, $VERSION_ID specifically).

Perhaps not throwing an error on a non-existent targetPath should also be a bug.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant