Install dependencies - Clear up logs - Rebuild pre-built modules #60
Conversation
|
is it necessary to rebuild sharp and grpc here? |
Did you read the commit message? Rebuilding essentially gives you multi-arch support. |
|
Ah right! Yes we actually have to do this step in our snap builds also. Also had to do something similar for my alpine PR for our other image.. 🤔 In this case for libc I wonder if we shouldn't instead have these installed via npm instead of bundled that way always built for the appropriate architecture during npm install instead of having to do this "hack" in multiple ways on multiple distribution methods. @sampaiodiego is that even possible to move from bundled dependency to installed by end user? Looks like grpc (from google vision package) and sharp |
|
Yes, if that's possible then it would be better. Although, it would be good to merge this pull-request in the mean time, as a quick win. Happy to help you work on the enduring solution too if that's required. |
@geekgonecrazy I don't know 😞 the directory |
|
Penny for your thoughts guys? |
|
Any updates on this please? It's been a long time since I submitted this. |
|
@lag-linaro sorry for the delay we are actually hung up by #57 please see conversation there. But basically at the moment would do no good to merge because would not be able to be published :( |
|
Looks like #57 is now closed. |
|
Yes the dockerfile has changed some so might require a sync and test to make sure works still. Would gladly merge though if we can get in sync |
The 'slim' base variants do not provide adequate tooling to build this Docker image. We need to install it before running `npm install` and ensure proper clean-up once we're finished. Signed-off-by: Lee Jones <[email protected]>
This ensures each command is printed out before it is executed, which leads to a much friendlier log for debugging and the like. Signed-off-by: Lee Jones <[email protected]>
There is no need to print out the name of every file as it is extracted. This only serves to cloud the log making it unusable. Signed-off-by: Lee Jones <[email protected]>
Rocket.Chat comes with some modules pre-compiled. Unfortunately only x86_64 modules are supplied. By rebuilding them locally it ensures Rocket.Chat Docker images can be built/run on all platforms. Signed-off-by: Lee Jones <[email protected]>
lag-linaro
force-pushed
the
deps-log-modules
branch
from
1a0b88e to
830ba49
Compare
|
Rebased, moved back over to using |
There was a problem hiding this comment.
Just putting here to block merging. Rocket.Chat isn't currently compatible with Node.js 8.16.0 which is why we were forced to use a debian base.
So unfortunately we won't be able to merge with that node.js version.
See other PR's here were we discussed the moving over to debian image
If node.js keeps dropping versions off before meteor updates and then we have a chance to test the new meteor version and include in a release... we might not be able to goto the nodejs base image.
|
What if I dropped that patch? Is the rest still acceptable? |
lag-linaro
force-pushed
the
deps-log-modules
branch
from
830ba49 to
3c33007
Compare
|
Okay Aaron (@geekgonecrazy), I have added the hack back in. Please re-consider this pull-request. |
|
@Sing-Li please take a look at this pull-request. It should provide support for AArch64. |
|
We've put considerable work into making this work with It would be a real shame to see it go to waste. Could someone @Sing-Li, @geekgonecrazy please take a look at this? |
|
Lee Jones seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account. You have signed the CLA already but the status is still pending? Let us recheck it. |
Fixes arm build see #54