bug: pipedv1 deployment store returns newest deployment as head, not oldest
Los mantenedores suelen responder en 2 días
Nadie ha tomado este issue todavía.
- #6921 de @AruneshDwivedi — cerrado sin fusionar
Evaluación
- Dificultad
- 4/5
- Tiempo estimado
- 3-5 días
- Aptitud para principiantes
- 48/100
- Tipo de issue
- Error
- Claridad
- Bastante claro
- Estado de actividad
- Tranquilo
- Stack tecnológico
- go
- Área
- devops, infrastructure
Línea de trabajo
Empieza con ListAppHeadDeployments en pkg/app/pipedv1/apistore/deploymentstore/store.go:125-134 y la implementación correspondiente en pkg/app/piped/apistore/deploymentstore/store.go. Sigue dónde se consume el método para determinar si el head debe ser el deployment no completado más antiguo o más reciente, y después añade la prueba de regresión con dos deployments descrita en el issue para ambos stores. Se considera terminado cuando la implementación y el docstring de Lister coinciden.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
What happened:
While reviewing the deployment store sync logic in pipedv1, the head-deployment selection in pkg/app/pipedv1/apistore/deploymentstore/store.go:125-134 looks inverted relative to the Lister interface's docstring.
The interface promises:
ListAppHeadDeploymentsreturns the map from application ID to its head of deploying deployments.
Head deployment is same with the oldest uncompleted one.
But the implementation writes pendings → planneds → runnings into the same map[string]*model.Deployment, so for an application with both a pending and a running deployment, the running one wins by overwrite order:
for _, d := range pendings { headDeployments[d.ApplicationId] = d }
for _, d := range planneds { headDeployments[d.ApplicationId] = d }
for _, d := range runnings { headDeployments[d.ApplicationId] = d }
A PENDING deployment is logically newer than a RUNNING one for the same application (it was created later, after the running one started), so this code returns the newest uncompleted deployment, not the oldest.
The same inversion exists at the corresponding location in the v0 store (pkg/app/piped/apistore/deploymentstore/store.go).
What you expected to happen:
Either:
- The docstring is updated to match the implementation ("head = newest uncompleted"), or
- The implementation is corrected to match the docstring — either reverse the write order or pick the head explicitly by
created_at.
I don't know which side is correct, since I haven't traced where ListAppHeadDeployments is consumed downstream. Whichever way it ends up, the docstring and the code should agree.
How to reproduce it:
Unit test against the store with two *model.Deployment instances sharing one ApplicationId, one DEPLOYMENT_PENDING and one DEPLOYMENT_RUNNING. Lister.ListAppHeadDeployments()[appID] returns the running one — the opposite of what the docstring promises.
Environment:
pipedversion: master @78fdbeb7c(both v0 and v1 affected)control-planeversion: same- Others: surfaced during self-review of #6727 while writing tests for
ListAppHeadDeployments
- Lenguaje dominante
- Go
- Estrellas
- 1.4k
- Forks
- 391
- Merge medio
- 4 d 1 h
- PR fusionados (30 d)
- 58
Preparar el entorno
- Sin Dockerfile ni archivo de Docker Compose
- Tiene una plantilla de pull request
- Leer la guía de contribución
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 pipe-cd/pipecd
-
Applications at the repository root are not triggered by new commitsPosiblemente ocupada @Daksha1611 la tomó hoy. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
Los mantenedores suelen responder en 2 días
-
pipedv1 kubernetes plugins ignore trafficRouting.istio.host in K8S_TRAFFIC_ROUTINGPosiblemente ocupada @Dhirenderchoudhary la tomó hoy. Abierto
Dificultad 2/5 Medio día Aptitud para principiantes 74/100
pipe-cd/pipecd#7626 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
Los mantenedores suelen responder en 2 días
-
pipectl transfer restore application drops backed-up labelsPosiblemente ocupada @bhavishyajain545 la tomó hace 1 día. Abierto
Dificultad 2/5 1-3 horas Aptitud para principiantes 86/100
pipe-cd/pipecd#7622 · 1 comentario ·
Los mantenedores suelen responder en 2 días
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 83/100
Los mantenedores suelen responder en 2 días
Todos los issues de pipe-cd/pipecd
Issues similares
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 68/100
Los mantenedores suelen responder en 1 día
-
docker-compose: postgres healthcheck should probe TCP (pg_isready -h localhost)Posiblemente ocupada @zezo-mohamed22 la tomó hoy. Abierto
Dificultad 1/5 Menos de una hora Aptitud para principiantes 82/100
OneBusAway/watchdog#305 · 1 comentario ·
Los mantenedores suelen responder en 1 día
-
self-care self-care:agent-discoverability
Dificultad 2/5 1-3 horas Aptitud para principiantes 62/100
githubnext/gh-cao#20928 ·
Los mantenedores suelen responder en 1 día
-
automation documentation
Dificultad 1/5 Menos de una hora Aptitud para principiantes 70/100
Los mantenedores suelen responder en 1 día
-
Dificultad 1/5 Menos de una hora Aptitud para principiantes 85/100
SocialGouv/iterion#3287 ·
Los mantenedores suelen responder en 1 día