You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Dockerfile is split into `runtime-core`, `runtime-r`, and `app` targets so CI can reuse published runtime layers and avoid rebuilding the heavyweight R stage on every app change.
118
+
The Dockerfile keeps `runtime-core` and `runtime-r` as internal build stages, but only the unified `app` image is published for deployment.
76
119
77
120
## Admin Dashboard
78
121
@@ -164,14 +207,13 @@ For comprehensive testing details, see [TESTING.md](docs/TESTING.md).
164
207
165
208
## CI/CD
166
209
167
-
GitHub Actions is split into four workflows:
210
+
GitHub Actions is split into three workflows:
168
211
169
212
- `ci.yml`: PR validation and required checks
170
-
-`runtime.yml`: publish `runtime-core` and `runtime-r` cacheable base images
171
213
- `release.yml`: publish multi-arch app images for `main`, `dev`, and release tags
172
-
-`nightly.yml`: rebuild heavy runtime layers and run slow/full live validation
214
+
- `nightly.yml`: build the app image locally and run slow/full live validation
173
215
174
-
Published images now use native `amd64` and `arm64` builds instead of a single emulated multi-arch build, and the app image can reuse the previously published `runtime-r` layer when runtime inputs have not changed.
216
+
Published images use native `amd64` and `arm64` builds and are exposed as separate stable and dev GHCR packages.
0 commit comments