ci: darwin release builds are uncached — port rivet sccache/cache-mount Dockerfile pattern
Los mantenedores suelen responder en 1 día
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 55/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- docker, github-actions, rust
- Área
- build-system, ci-cd, performance
Línea de trabajo
Compara docker/build/darwin.Dockerfile con rivet's docker/build/darwin-{arm64,x64}.Dockerfile y, después, inspecciona el trabajo build-sidecar-darwin en .github/workflows/publish.yaml y los archivos denominados builder-base. Verifica que la compilación de release de darwin resultante y con caché activo use la caché remota, evite una configuración redundante de rustup y recurra correctamente a la alternativa disponible cuando el secreto de caché no esté disponible.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
The "Build darwin binaries" jobs are the critical path for Publish npm in publish.yaml (~10.5 min per release) and rebuild ~388 crates from scratch every run.
Current state
docker/build/darwin.DockerfileusesFROM ghcr.io/rivet-dev/rivet/builder-base-osxcross:0e33ceb98— the same prebaked base rivet uses (osxcross + MacOSX 11.3 SDK + both apple Rust targets + sccache preinstalled) — but uses none of its caching affordances:- re-installs the rust toolchain/targets the base already has
- no
RUSTC_WRAPPER=sccache, no cache backend, no BuildKit cache mounts - plain
docker buildwith no--cache-from/--cache-to
- Measured on the 0.2.5 stable run (28801821648): base image pull ~1 min, rustup ~1 min,
cargo build --releaseof 388 crates = 7m52s, every run, forever. - By contrast the linux sidecar/plugin jobs use Swatinem/rust-cache and finish in 1–5 min warm.
Fix: port the rivet consumer pattern
Rivet already solved this for the identical build in rivet-dev/rivet:
docker/build/darwin-{arm64,x64}.Dockerfile:RUSTC_WRAPPER=sccache+SCCACHE_WEBDAV_ENDPOINT=https://cache.depot.dev,--mount=type=secret,id=DEPOT_TOKEN,env=SCCACHE_WEBDAV_TOKENwith a graceful health-check fallback that disables sccache when the token/backend is unavailable, plus--mount=type=cachefor cargo registry/git/target.- Base image build/push lives in
docker/builder-base/osxcross.Dockerfile+scripts/docker-builder-base/build-push.sh.
Port notes for agentos:
- agentos builds on GitHub-hosted runners (not Depot builders), so BuildKit cache mounts alone will not persist across runs — the cross-run win is the sccache remote backend. Either:
- (a) add a
DEPOT_TOKENsecret and reuse rivet's Depot cache config verbatim (preferred: byte-for-byte port of a production pattern), or - (b) use sccache's native GHA backend (
SCCACHE_GHA_ENABLED=on).
- (a) add a
- Drop the redundant rustup toolchain/target install from
darwin.Dockerfile(already in the base). - Pass the secret through in the
build-sidecar-darwinjob in.github/workflows/publish.yaml(docker buildx build --secret id=DEPOT_TOKEN).
Expected: darwin job drops from ~10 min to ~2–3 min warm, cutting release npm-publish latency roughly in half.
Related smaller wins (same investigation, can be separate PRs)
Publish crates.iojob: give it its own concurrency group (or workflow) so a slow crates tail (crates.io new-crate rate-limit backoff can sleep for many minutes) doesn't queue the next release's npm path behind it (concurrency: publish-${{ github.ref }},cancel-in-progress: falsecaused the 0.2.6 dispatch to sit pending behind 0.2.5's crates job). Also surface the "rate limited, retrying at " sleep as a::notice::so the job doesn't look hung.- Release rust-cache eviction: linux jobs key caches by
<target>-<trigger>, so-releasecaches are only warmed by prior release runs and get LRU-evicted during quiet stretches while-previewstays warm; consider a shared key or a scheduled warm job. - WASM Commands (~8.6 min): cache
packages/runtime-core/commandskeyed onhashFiles('registry/native/**')and skipmakeon hit.
- Lenguaje dominante
- Rust
- Estrellas
- 4.8k
- Forks
- 272
- Merge medio
- 13 h 24 min
- PR fusionados (30 d)
- 49
Preparar el entorno
Este proyecto no incluye contenedor de desarrollo, Dockerfile ni guía de contribución, así que la configuración corre por tu cuenta: empieza por su README y consulta nuestra guía para la primera contribución para los pasos generales.
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de rivet-dev/agentos
-
Dificultad 3/5 Medio día Aptitud para principiantes 32/100
rivet-dev/agentos#2020 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Inline JavaScript resolves dynamic import() from / instead of the working directoryPosiblemente ocupada @mittal-parth la tomó hace 35 días. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 48/100
rivet-dev/agentos#1973 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
Dificultad 4/5 3-5 días Aptitud para principiantes 52/100
Los mantenedores suelen responder en 1 día
-
Guest-execution slot counter has no near-threshold warningPosiblemente ocupada @SparshSunilNaik la tomó hace 56 días. Abierto
Dificultad 3/5 1-2 días Aptitud para principiantes 78/100
Los mantenedores suelen responder en 1 día
Todos los issues de rivet-dev/agentos
Issues similares
-
area/backends bug session-analysis
Dificultad 2/5 1-3 horas Aptitud para principiantes 69/100
Los mantenedores suelen responder en 1 día
-
docs good first issue
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
-
crash
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
Los mantenedores suelen responder en 2 días
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 65/100
aaif-goose/goose#13125 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 74/100
Los mantenedores suelen responder en 1 día