I wrote a blog post on Optimizing CI for Meteor. It shows what should be cached, what cache keys to use, and other optimizations to speed up installing dependencies and building Meteor. For medium size projects these can save up to a few minutes each time the CI job is run.
I really like the part about remove-client-js
Nice post! Perhaps it would be interesting for people to post their app build times?
Ours on Github Actions:
meteorengineer/setup-meteor@v1 22 s installing node modules 37 s Build meteor 11m 7s
i read your blog and this is really good…
I applied most of the advice provided in your blog post to this GitHub workflow. I managed to reduce the time of the test job from roughly 3 minutes to roughly 2 minutes. Took me a while to get it right…
I just published a (composite) GitHub action at
that you can easily reuse with
- uses: meteor-actions/install@v1. Note that the use of
if inside a composite action has been recently made possible by add conditional execution of action steps · Issue #834 · actions/runner · GitHub. I am open to improvements. Maybe split the different layers of caching into multiples actions?
@zodern I have a question regarding caching the artifacts of
meteor build ../dist inside a GitHub workflow: What’s the proper way to do it? By that I mean caching so that next builds execute faster.
I am afraid, those github actions will not be supported in the future, because they use
curl https://install.meteor.com/ | sh
Which is not maintained anymore (according to According to docs/source/install.md):
The above comment from @scharf also breaks any older versions of Meteor.
For example v1.8.1 is now dead because it uses the same server.
I really find it strange the there hasn’t been any marketing on this from the Meteor team. No mention of deprecation for older version.
Seem to me like the team did a major legacy breaking change and didn’t talk about it enough. Happy to be proven otherwise.
Hello! Meteor hasn’t removed or deprecated any legacy version from our servers. You might be referring to let’s encrypt certificate change referred here Expired Certificates | Meteor API Docs which is not a change introduced by Meteor Team.
I would also like to highlight that even if we are “deprecating” the old install method, it will still be online and you can use it as you please, as we don’t have any plans to remove it. It’s just that using NPM is better for newcomers and has a lot of advantages in the question of approaching meteor to the node ecosystem.
You can still use the install.meteor script in your CI, without issues, as it is feature-complete in our point of view, and won’t be removed in the foreseeable future.
@renanccastro Thanks for the reply! I’ll look into that.
The action looks nice. Handling everything adds a lot of complexity, so having a reusable action for that would be helpful. Once it is finished, I could mention it in the blog post.
If the previous build exists,
meteor build deletes it before building. I am not aware of any additional caching that would help with
Something new since I wrote the article that could be tried is setting the env var
true. It makes loading build plugins up to a few seconds faster. It is disabled by default since I was worried about issues when the reify cache becomes too large, but in CI that won’t be an issue. The reify cache files are stored in
I published v2 of
meteor-actions/install. Some notable changes:
- All environment variables that were defined before have changed names (check the sources).
meteor-actions/install@v2allows to specify an
executable_versioninput to select the version of the
meteorexecutable that will be installed (this can be the same as the version in
.meteor/release, or it can be different). Either specify a version, or
latestfor the latest Meteor release, or
localto use the same version as defined in
.meteor/release. The default is
meteor-actions/install@v2does not cache
.meteor/localanymore: there is a new
meteor-actions/cache-build@v2that does cache
.meteor/localand accepts an optional
keyinput to avoid distinct builds to overwrite each-other’s caches.
You should now be able to exploit these actions on parallel jobs and workflows. For instance with
meteortesting:mocha you can run
TEST_SERVER=0 --full-app in parallel. They will share the cache for the Meteor executable installation. They will not share the cache for the
.meteor/local folder (unless you really want to) but should be able to restore the cache from each other in case of a cache-miss.
You should make this announcement in a new thread with all the fanfare it deserves.
@storyteller Thanks! Before doing that I would like to figure out the proper way to order parts of the cache key of
meteor-actions/cache-build. Here is the current state:
I think the current key is bad. The commit hash should be in there but I am not sure where. The custom key part should probably have precedence. Someone help? @zodern ?