CI: automated incremental build + publish for @agentos-software registry packages

Abierto
  • ¿Algo no está bien?
#162 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
38/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
cmake, github-actions, rust, typescript, wasm
Área
build-system, ci-cd, devops, release

Línea de trabajo

Empieza con registry/Makefile y la detección de cambios existente por paquete mediante .last-publish-hash; después, inspecciona scripts/publish/src/lib/packages.ts y las exclusiones del workflow secure-exec. Sigue los pasos de sysroot, wasi-sdk, LLVM runtime, CMake, Rust wasm y agent-packing antes de diseñar el workflow. Se considera terminado cuando los cambios bajo registry/ o en la toolchain nativa desencadenan builds incrementales y la publicación para ambos árboles de paquetes, con artefactos de toolchain almacenados en caché y un dist-tag distinto de latest.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Problem

The @agentos-software/* registry packages have no automated CI build/publish:

  • Commands live in registry/software/*, agents in registry/agent/*.
  • They are deliberately excluded from the secure-exec preview publish workflow (scripts/publish/src/lib/packages.ts → SECURE_EXEC_WORKSPACE_PACKAGES skips everything under @agentos-software/* except @agentos-software/manifest).
  • The only publish path is a manual registry/Makefile make publish run from a dev machine.

The manual/local path is impractical for contributors: publishing a registry update requires a full local wasm toolchain build:

  • make sysroot → patch-wasi-libc.sh + build-llvm-runtimes.sh (patched wasi-libc with networking, e.g. netdb.h),
  • then the heavy C builds (curl, sqlite3, duckdb — duckdb alone is 20+ min via CMake),
  • then Rust wasm (wasm32-wasip1, ~139 commands) + agent packing.

Realistically 30–60+ min of from-source LLVM/wasi-libc/duckdb builds, fallible, and it pins the machine. So registry updates don't happen reliably.

Ask

A CI workflow that builds and publishes the registry packages automatically on change.

Requirements

  • Incremental — some packages take a long time to build (duckdb, curl, the patched sysroot). Reuse the existing per-package .last-publish-hash change-detection so only changed packages rebuild/republish, and cache the wasm toolchain (patched wasi-libc sysroot, wasi-sdk, LLVM runtimes) across runs. The registry should be updatable incrementally rather than all-or-nothing.
  • Non-latest dist-tag — never move the latest pointer (consistent with the manual path's DIST_TAG=dev).
  • Cover both registry/software/* (commands + meta) and registry/agent/* (agents).
  • Trigger on changes under registry/ (and the native toolchain).

Context

Surfaced while migrating the registry to the { packageDir } + agentos-package.json model (secure-exec #150 / agent-os #1561): every @agentos-software/* package needs republishing with the new shape, but there is no non-manual way to do it.

Lenguaje dominante
TypeScript
Estrellas
1k
Forks
53
Merge medio
2 h 54 min
PR fusionados (30 d)
5

Preparar el entorno

  • Incluye un Dockerfile o un archivo de Docker Compose
  • Sin plantilla de pull request
  • Sin guía de contribución

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de rivet-dev/dynamic-apps

Todos los issues de rivet-dev/dynamic-apps

Issues similares

Más issues de TypeScript

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.