3 ms·
I went through the doc. Yes, in addition to Dockerfile, there is a way to run tasks in parallel. I'm not sure how killing of a feature that is, when every build
by t0mk 10y ago
I went through the doc. Yes, in addition to Dockerfile, there is a way to run tasks in parallel. I'm not sure how killing of a feature that is, when every build tool lets you pass a job count. And beside that, I can't think of a legit use-case of what to run side by side in a container build. Maybe someone else knows/cares?
I've never built anything with JDK, but is cleanup of build dependencies really a problem in 2017?
For these goodies, you get a nice piece of vendor lock-in.
- skj 10y agoThe difference between including the JDK vs only the JRE in your deployable image can mean hundreds of megabytes saved. If you're trying to roll out this image to hundreds or thousands of nodes, this can save a lot of resources. Additionally, less in your deployable is better from a security standpoint. re lock-in: We're definitely cognizant of lock-in issues, and were trying to make it as friendly as possible. In the end, our service is running a series of containers with your source mounted in. If you really want out, replicating this process is straightforward.
- tracker1 10y agoAgreed, my node builds tend to build to a ./dist including a separate package.json with all test/dev bits completely removed. From there I pretty much use the -onbuild containers from the dist/ path.