-
-
Notifications
You must be signed in to change notification settings - Fork 36
Build Behaviour
This page explains how Docker images are built, and how EmulatorJS assets are refreshed in CI.
The reusable workflow ._github/workflows/_build-docker-images.yml builds and publishes two image variants:
-
standardusingbuild/Dockerfile -
embeddeddbusingbuild/Dockerfile-EmbeddedDB
Both variants are built from a single staged source archive, so any generated content in staging is reused by both matrix jobs.
Both Dockerfiles run:
bash build/scripts/get-ejs-git.sh
This must remain in place so anyone cloning the repository can still build images locally without any extra setup.
The script is idempotent:
- If EmulatorJS cores already exist, it exits quickly without downloading again.
- If
FORCE_EJS_REFRESH=1is set, it refreshes cores from source.
The reusable workflow supports two policy inputs:
-
always_refresh_ejs(boolean, defaultfalse) -
ejs_cache_max_age_days(number, default7)
Nightly builds use:
always_refresh_ejs: falseejs_cache_max_age_days: <configured value>
Behavior:
- Restore cached EmulatorJS assets in staging.
- Read cache metadata timestamp (
.cache-created-at-epoch). - Refresh only when cache age is at or above
ejs_cache_max_age_days. - Save the refreshed cache and archive staging output.
- Build both Docker variants from the same staged artifact.
This avoids downloading EmulatorJS twice in the matrix while still ensuring periodic refreshes.
You can override the age threshold in manual Nightly runs via workflow dispatch input ejs_cache_max_age_days.
Tagged Docker builds use:
always_refresh_ejs: true
Behavior:
- EmulatorJS is always refreshed during staging so release-tagged images include fresh assets.
- Local builds remain self-contained because Dockerfiles always execute the EmulatorJS script.
- Nightly builds reduce repeated network work with age-based cache refresh.
- Pre-release and release builds always refresh EmulatorJS for freshness.