-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use scratch image and mv from nginx to lighttpd #286
base: master
Are you sure you want to change the base?
Conversation
bdebec3
to
b0e7c5b
Compare
scons \ | ||
&& tar -C /tmp -xf /tmp/lighttpd.tar.gz \ | ||
&& cd /tmp/lighttpd-$LIGHTTPD_VERSION \ | ||
&& scons -j 4 build_fullstatic=1 build_dynamic=0 |
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.
considering build, we might calculate parallel jobs based on available CPUs, like so 🤓 :
jobs=$(( $(cat /proc/cpuinfo | grep processor | wc -l) - 2))
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.
about the mentioned buildcfg you linked:
zlib # zlib ./configure --with-zlib # (default)
-> will the build omit libz it is not present (is it instaslled via pcre2 / build-base?)
I think it will make sense to enable compression for lighttpd for performance reasons (hence I am asking)
also, why not use autogen / configure / make instead of scons? 🤔 . in the end, it is a matter of choice I guess. however, considering scons runs on python, this will likely make the installation heavier compared to autogen + make (if we split into separate build, this is of course even less of a concern)
check archwiki for documentation of enabling compression
@@ -1,4 +1,4 @@ | |||
FROM alpine:latest AS build | |||
FROM alpine:3 as node-builder | |||
|
|||
COPY . /src |
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.
btw, we might link sources rather than cp (I think this will slightly reduce runtime overhead for build; I know this is less relevant otherwise, as we are switching to multistage-build.
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.
could you please elaborate what you refer to exactly when talking about linking in docker files?
COPY --link
would still perform an initial copy and as we do not re-use copied contents (but build results), there is no benefit in doing so 🤔
What this PR does / why we need it:
Which issue(s) this PR fixes:
Fixes #
Special notes for your reviewer:
Release note: