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

pre_start hooks: per_replica: true is accepted by the schema but always rejected at runtime

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

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
45/100
Tipo de issue
Nueva funcionalidad
Claridad
Bien especificado
Estado de actividad
Activo
Stack tecnológico
docker, docker-compose, go
Área
cli, devops, tooling

Línea de trabajo

The issue is in pkg/compose/pre_start.go where runPreStart validates hooks. The compose-spec model is in types/hooks.go. To implement, examine the reconciliation-plan work in #14221, specifically planPreStartHookRunners. Need to modify the planning to create one runner per hook per replica, adjust naming/labeling (e.g., com.docker.compose.hook-index), resolve VolumesFrom per replica, and update execution in execPreStartHook. Start by reading the existing validation and the skipped planning logic.

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

Descripción

What this issue is about

pre_start hooks support a per_replica attribute in the compose-spec model (types.PreStartHook.PerReplica, compose-go's types/hooks.go): "runs the hook once per service replica instead of once per service." docker/compose's engine, however, does not implement it: runPreStart (pkg/compose/pre_start.go) validates every declared hook up front and rejects the whole service if any hook sets per_replica: true:

for i, hook := range service.PreStart {
    if hook.PerReplica {
        return fmt.Errorf("service %q pre_start[%d]: per_replica is not yet supported; remove per_replica or set it to false", service.Name, i)
    }
}

So today, per_replica: true is accepted by the loader/schema but always a hard error at runtime — there is no path to actually use it.

Illustration

services:
  app:
    image: alpine
    command: sleep infinity
    deploy:
      replicas: 3
    pre_start:
      - image: alpine
        command: ["sh", "-c", "echo initializing replica"]
        per_replica: true

$ docker compose up -d
service "app" pre_start[0]: per_replica is not yet supported; remove per_replica or set it to false

The only way to get this compose file to run at all today is to drop per_replica: true, at which point the hook runs once for the whole service (against the lowest-numbered replica only, per the current one-hook-one-runner model) instead of once per replica — a different, sometimes unacceptable behavior for hooks that need to prepare per-replica state (e.g. per-replica config files, per-replica volume initialization).

Suggested scope for an implementation

The reconciliation-plan work in #14221 (pre_start hook runners as first-class plan resources) planned one CreateHookContainer operation per declared hook, targeted at a single resolved replica. Supporting per_replica: true would mean planning one runner per hook × per replica instead, with:

  • a deterministic name/label scheme distinguishing replicas (e.g. extending the existing com.docker.compose.hook-index label with a replica index, or a dedicated label),
  • VolumesFrom resolved against that replica rather than the lowest-numbered one,
  • the corresponding execution-phase change in runPreStart/execPreStartHook to run and account for one runner per replica.

This issue only tracks the feature gap; the reconciliation-plan groundwork from #14221 already discussed and worked around it (see its planPreStartHookRunners, which explicitly skips planning entirely for a service with any per_replica: true hook, to avoid orphaning runners that could never execute).

Lenguaje dominante
Go
Estrellas
38.4k
Forks
5.9k
Merge medio
2 d 4 h
PR fusionados (30 d)
73

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 docker/compose

Todos los issues de docker/compose

Issues similares

Más issues de Go

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.