-
-
Notifications
You must be signed in to change notification settings - Fork 177
Add linux-arm64, android-arm and android-arm64 prebuilds #587
Conversation
package.json
Outdated
@@ -14,7 +14,11 @@ | |||
"hallmark": "hallmark --fix", | |||
"dependency-check": "dependency-check . test/*.js bench/*.js", | |||
"prepublishOnly": "npm run dependency-check", | |||
"prebuildify-cross-armv7": "prebuildify-cross --platform=linux --arch=arm --arm-version=7 -- -t 8.14.0 --napi --strip" | |||
"prebuild-arm": "npm run prebuild-linux-arm && npm run prebuild-linux-arm64 && npm run prebuild-android-arm && npm run prebuild-android-arm64", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should we shorten this with e.g. npm-run-all
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, good idea. (TIL about it)
It hits this code branch: https://github.com/ahdinosaur/prebuildify-cross/blob/c4748f7fc5ad3e0e9bbadc6de2304528cf33406a/build#L90 |
Args fixed in prebuild/prebuildify-cross@146cc6c and prebuild/prebuildify-cross@13bcaf2. |
To fix Note:
|
This reverts commit 92bb36e.
@vweevers We got a segmentation fault in https://travis-ci.org/Level/leveldown/jobs/485175594#L1623 which is a bit worrying (nothing to do with the cross compiled stuff). |
Gah. Travis borked of course. Restarting builds. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approving my own changes :D
Can you open an issue? Let's hope we can replicate + fix before 5.0.0 |
I'll review later |
#!/bin/bash | ||
|
||
DOCKER_USER="node" | ||
if [[ "$TRAVIS" == "true" ]]; then DOCKER_USER="travis"; fi |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@ralphtheninja Can you explain the users? I'm guessing the working directory on the host is owned by travis
, and docker must use the same user? Can't we change permissions instead?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm open to suggestions. If we don't do anything about the user (e.g. set USER
in the Dockerfile
) the container will run as root, thus producing binaries owned by root. Which leaves us with two options (as I see it):
- either we do something related to user, i.e. run the container with the correct user
- keep running the container as root, but copy out the binaries from the container, which is done in
prebuildify-cross
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thinking about it some more, I think I prefer 2. since the docker image doesn't need any specific users. This needs some tweaking to the cross-compile
script as well. Also need to look into how prebuildify-cross
does this with output folders etc.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I liked the initial approach of running as the node
user. Why did that not work?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it runs as user with uid 1000 and the jenkins user is 2000.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Because it runs as user with uid 1000 and the jenkins user is 2000.
*travis user? 😉
Alright, I'm fine with both the current solution and the alternative, copying out the binaries. The latter would also remove the ignore me, it's latenpm i
problem (#587 (comment)), because if we copy out the binaries then we don't have to mount any volume.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, travis user. I don't know where jenkins came from. Jenkins! Get out of my head!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a perfect solution, but it works. Lets tweak it as we go?
if [[ "$TRAVIS" == "true" ]]; then DOCKER_USER="travis"; fi | ||
|
||
exec docker run -u ${DOCKER_USER} --rm -it -v $(pwd):/app prebuild/${IMAGE} \ | ||
bash -c "npm i --ignore-scripts && npx prebuildify -t 8.14.0 --napi --strip" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- Seeing as each invocation of this script runs in the same working directory, they all work against the same
node_modules
, and reinstall each time. Can we A) skip that or B) mountnode_modules
as a named volume, so that changes in the docker guest are hidden from the host? - Does
npx
use a locally installed bin if available, or does it always install the latest version ofprebuildify
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we A) skip that
Not sure what you mean by that. Unsure what you mean here, mind writing snippet that explains the changes you want to make?
Afaik, npx
uses a locally installed .bin
if available. If it didn't, we wouldn't be able to use the specific branch of prebuildify
we need to override e.g. platform.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not sure what you mean by that.
npm i
.
Unsure what you mean here, mind writing snippet that explains the changes you want to make?
I'll elaborate. We can either A) skip npm i
in docker. We simply reuse what's already installed on the host. That only works (safely) in Travis though, where both host and guest are Linux. Not when testing things locally (on Mac, Windows or a different Linux flavor). That's also why the current approach is less than ideal, because after npm run prebuild-arm
, you're stuck with a node_modules
meant for a different platform.
So option B is to use a named volume. An anonymous volume may also work. Something like docker run -v $(pwd):/app -v :/app/node_modules
. Initially, Docker will copy the existing /app/node_modules
into the second volume. From then on, any changes to node_modules
(e.g. by npm i
) are applied to the second volume, meaning they don't affect node_modules
on the host.
Afaik,
npx
uses a locally installed.bin
if available. If it didn't, we wouldn't be able to use the specific branch ofprebuildify
we need to override e.g. platform.
👍
I can't approve my own PR so LGTM |
Closes #574, closes #360