Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

Support pre-built Docker images in dependency spec to avoid redundant builds

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

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
58/100
Tipo de issue
Nueva funcionalidad
Claridad
Bastante claro
Estado de actividad
Tranquilo
Stack tecnológico
docker, github-actions, shell
Área
build-system, ci-cd, devops

Línea de trabajo

Comienza en el workflow reutilizable build.yml, especialmente en la etapa build-dep y en el manejo de su JSON de dependencias. Traza cómo se clonan, compilan y pasan las dependencias de código fuente a la imagen quickstart final, y luego verifica que una dependencia de imagen utilice el mismo mecanismo COPY --from=, mientras que las dependencias basadas en código fuente permanezcan sin cambios. Valida ambas formas de dependencia mediante el workflow.

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

Descripción

Problem

The reusable build.yml workflow currently only accepts repo + ref for each dependency, which means every caller must build their dependency from source. For projects that already build a release binary in their own CI pipeline, this results in a redundant ~9 minute build.

For example, in stellar-experimental/henyey, our CI workflow already produces a release binary via cargo build --release. The quickstart workflow then clones the same commit and builds it again from scratch. This makes the quickstart workflow take ~19 minutes when it could take ~10 minutes.

Proposal

Add an optional image field to the dependency JSON spec. When image is provided, the build-dep stage would pull the pre-built Docker image instead of cloning and building from source.

Current usage (build from source):
{
  "name": "core",
  "repo": "stellar-experimental/henyey",
  "ref": "abc123"
}
Proposed addition (pre-built image):
{
  "name": "core",
  "image": "ghcr.io/stellar-experimental/henyey-core:abc123"
}

When image is set, the workflow would:

  1. Skip the clone + build step for that dependency
  2. Pull the image from the specified registry
  3. Use it in the final quickstart image build via the same COPY --from= mechanism

When image is not set, behavior is unchanged (build from source as today).

Expected Impact

  • Callers that already build their binary in CI can cut ~9 minutes off their quickstart workflow
  • No change for callers that don't use this field
  • The final quickstart image is identical either way — only the source of the dependency image changes

Alternatives Considered

  • Callers duplicate the test orchestration locally: Works but duplicates the test matrix logic that build.yml already handles well
  • Cache-only approach: The existing cache helps on repeat runs of the same SHA, but doesn't help when the same SHA is already built by the caller's own CI
Lenguaje dominante
Shell
Estrellas
224
Forks
237
Merge medio
1 d 2 h
PR fusionados (30 d)
7

Preparar el entorno

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 stellar/quickstart

Todos los issues de stellar/quickstart

Issues similares

Más issues de Shell/Bash

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.