Then just share your dockerfile bro
1 Like
@truedon thanks bro 
Dockerfile (nothing special):
FROM amazonlinux:latest
# The (rough) equivalent of the build-essential meta-package for yum is: yum install make glibc-devel gcc patch
# https://serverfault.com/questions/204893/aws-ec2-and-build-essential
RUN yum -y install curl tar gzip python3 make glibc-devel gcc patch g++ && yum -y clean all && rm -rf /var/cache
ENV METEOR_ALLOW_SUPERUSER 1
RUN curl https://install.meteor.com/ | sh
CI pipeline:
build:
stage: build
variables:
GIT_STRATEGY: clone
GIT_DEPTH: 1000
# https://docs.meteor.com/environment-variables.html
#METEOR_PROFILE: 100 # Logs Meteor building operations longer than 1000ms
METEOR_DISABLE_OPTIMISTIC_CACHING: 1 #can help improve memory usage during meteor build
image: klaucode/meteor-amazonlinux
artifacts:
paths:
- $CI_PROJECT_NAME-$CI_COMMIT_SHORT_SHA.tar.gz
only:
- master
- tags
except:
- schedules
script:
# Remove local
- if [ -d .meteor/local ]; then rm -rf .meteor/local; fi
# Modify instance file
- sed -i "s/__BUILD_NUMBER__/$BUILD_NUMBER-$(date +%Y%m%d_%H%M%S)/g" both/instanceName.ts
- cat both/instanceName.ts
# Install meteor
- meteor npm install --production
- meteor npm install -D tailwindcss #must be installed manually, because an error occured
#- meteor npx kendo-ui-license activate
#- meteor npx browserslist@latest --update-db
- meteor --allow-superuser build --architecture os.linux.x86_64 --server-only ../new_package && mv ../new_package/*.tar.gz $TAR_FILENAME
# Remove local
- if [ -d .meteor/local ]; then rm -rf .meteor/local; fi
- ls
Docker stats during the building:
CONTAINER ID NAME CPU % MEM USAGE / LIMIT MEM % NET I/O BLOCK I/O PIDS
26292c5***** runner-********** 209.32% 1.898GiB / 251.4GiB 0.75% 270MB / 6.52MB 3.74MB / 424MB 14
HTOP
@truedon …and I tested the building on more prepared docker distributions, but there was not differences in build durations…
The build duration is all down to cpu power bro.
You can try building on a local machine on your lan a gaming rig or a new mac will probably smoke any virtual instance you are using.
1 Like
@truedon bro, thank you and I’m really appreciate your help, I agree with you.
Before I buyed the server, I tried to multiple servers and multiple configurations in Meteor build. I tried AMD Epic, multiple Intel CPUs with combinations of motherboards (and on each of them, I was building the same app and measure the time). It was confirmed to me that building a nodejs app does not optimally use the processor’s performance of all cores and it is more advantageous to have a higher frequency than more CPU cores.
…based on real tests results I decided to buy this concrete HW configuration with (Xeon W-2245) (before 1,5 years).
But what I didn’t expected, that the building inside Docker container will be so slow.
MULTIPLE times slower like directly on host computer. …also I tried build on the mac with M1, situation is same.
And I still don’t know, if this is normal or not 
Welcome bro just trying to help! It’s true about the frequency that’s why a overclocked gaming rig can do so well for compilations. I’m surprised to hear that about the new Mac also, because build speed for other stuff has been hell of a fast on it.
Docker is really slow and resource heavy, have you tried vagrant?
Another point here is you do not need to build inside of docker.
You just can have a mounted directory, build on the host and read from that path. I think doing any compilation inside of docker, or vagrant or any cli pipeline in general is doomed and kind of asinine to be totally honest - unless the build is key to your release which if it’s internal software that you host, is definitely not. Because when you deploy on your servers you won’t need to worry about build issues and if they do occur you can fix them easily enough as you control the servers anyway.
1 Like
we also build meteor apps in gitlab-ci (self-hosted, with runners on kubernetes), the biggest one is 25min (but its not newest meteor).
We do first a meteor build in one job and afterward a docker build that dockerizes the bundle, that takes another 4 min.
meteor build is slow and cpu heavy and memory hungry (because of mininfying and bundling). Of course you can give up continuous delivery and integration and just build locally on your fancy gaming pc, but do you want to go back to that?
There are now faster bundlers and minifizers, but i doubt that meteor will change the bundling anytime soon.
You can try to increase memory (and cpu) available on the runner. is it self-hosted gitlab or gitlab.com ?
1 Like
Hello @macrozone, it’s gitlab.com, runner is my self dedicated high power server. What is interesting:
- building directly on host takes 2minutes,
- building inside docker with enabled
METEOR_DISABLE_OPTIMISTIC_CACHING: 1takes 8minutes, - building without
METEOR_DISABLE_OPTIMISTIC_CACHING: 1takes about 25minutes.
Try in your ci pipeline add METEOR_DISABLE_OPTIMISTIC_CACHING: 1 and you will see, that building will be about 3 times faster.
In our case the docker build is about 40 minutes on gitlab.
1 Like
@bladerunner2020 finally someone confirmed my experience. Thanks a lot. Try to build once outside docker directly on host system and it will takes, Im guessing 8 minutes.
Of course you can give up continuous delivery and integration and just build locally on your fancy gaming pc, but do you want to go back to that?
You don’t need to give up CI you just build locally and mount the drive on your LAN. The alternative is significantly slower and you’re paying Jeff Bezos for another space flight… why would you want to do that?
If you pay employees salaries you need this to execute as fast and as cheaply as possible, that’s why all my clients have CI in house on their LANs and use gaming machines no one pays AWS for this kind of stuff unless they working for a bank.
1 Like
I just build by hand in shell, it takes about 3 mins. Wire that up to a new commit and the new build can be automatically done while you get coffee.
thx for the tip (METEOR_DISABLE_OPTIMISTIC_CACHING) , will try that!
Edit: wow it actually cuts build time in half… seems silly that you have to set this variable explicitly, even the docs said that this is a sane default for meteor build Environment Variables | Meteor API Docs
1 Like
Yes, but by my tests, the difference is only in Docker. On host computer, there is not difference or very low (lower than 5%).
We have a GitHub CI and this vars:
DISABLE_CLIENT_STATS=true METEOR_DISABLE_OPTIMISTIC_CACHING=1 TOOL_NODE_FLAGS=--max-old-space-size=4096 meteor build --architecture=os.linux.x86_64 --server-only ./build
You can try to increase --max-old-space-size
Another useful article Optimizing CI for Meteor thanks @zodern
2 Likes
Build on your local machine and link the files to docker on a shared dir bro, it will fly like a bird on high
2 Likes
Newbie question:
I’m building for Meteor-desktop (Electron), can I use this as well to speed up the build time for my Electron app?
I wanted to try building the app for desktop and mobile, but for desktop I haven’t found any procedure how to do it yet and buildin for Android uses old SDK version, so I can’t upload the app to Google Play 
If you could help me with that, we can try it on my app to see if there will be a difference in the length of the build. But as I wrote, it only affects in Docker, outside of Docker it has minimal effect. I think it’s probably due to file manipulation, but I can’t confirm this definitively yet because I don’t have experience with benchmarking in Linux. But I would like to try it out. If you know or have experience with any benchmark tool for file system and file manipulation, in linux I would appreciate any information in this regard.
@klaucode - check out this repo: GitHub - Meteor-Community-Packages/meteor-desktop: Build a Meteor's desktop client with hot code push.
I’d suggest you maybe start of with the ToDo app first before you try to switch your app to Electron. But building a Windows/macOS/Linux app from the same code base is really an advantage.
The alternative to that is Ionic which uses the latest Electron version (AFAIK) whereas the Meteor Desktop package is very far behind (using Electron 11.5) where Electron has just released version 21 (see Electron's blog | Electron):
Electron 21.0.0 has been released! It includes upgrades to Chromium 106 , V8 10.6 , and Node.js 16.16.0