fix(cli): un binario instalado con @latest decía ser "dev" - #305
Open
mmonterroca wants to merge 2 commits into
Open
fix(cli): un binario instalado con @latest decía ser "dev"#305mmonterroca wants to merge 2 commits into
@latest decía ser "dev"#305mmonterroca wants to merge 2 commits into
Conversation
`go install go.ziradocs.com/slidelang/v2/cmd/slidelang@latest` produce un binario de un release —`go version -m` lee v2.32.4 adentro— pero `--version` respondía "dev", porque la versión se estampa con ldflags y eso es un paso de goreleaser que `go install` no hace. Y `go install @latest` es lo que la documentación le dice a la gente que use, así que "dev" era la respuesta que recibía la mayoría; es también la respuesta que vuelve inatribuible un reporte de bug. `resolveVersion` cae a `debug.ReadBuildInfo().Main.Version` solo cuando el valor estampado sigue siendo "dev". Un `go build` local sigue diciendo "dev": ahí ReadBuildInfo devuelve "(devel)", que no aporta nada sobre el fallback y se lee peor. Dos copias, una por módulo, en vez de un símbolo nuevo en core: son ocho líneas de stdlib sin semántica compartida que pueda derivar, y meterlo en core ataría este arreglo al bump. Cada módulo trae su test. Verificado: con ldflags, `v2.32.5`; sin ldflags y sin versión de módulo, "dev"; y ningún camino devuelve "(devel)".
Mutar el fallback para que descartara siempre `info.Main.Version` dejaba los cuatro tests en verde, así que una regresión que volviera a mostrar "dev" en una instalación con `@latest` no se habría detectado. La causa es que llamaban a `resolveVersion()` desde adentro de `go test`, donde `ReadBuildInfo` describe al binario de PRUEBA: el resultado dependía del harness, no del arreglo. La decisión se extrae a `pickVersion(stamped, fromBuildInfo)`, pura, y la tabla cubre los seis casos: instalado con @latest, `go build` local que da "(devel)", sin build info, estampado por goreleaser, estampado ganándole a la build info, y pseudo-versión —que se acepta a propósito: es fea pero identifica el commit, que es más de lo que dice "dev". `resolveVersion` queda como el cableado, con un test que solo afirma lo que se puede afirmar sin depender del entorno: que nunca deja escapar "(devel)" ni vacío. Con el fallback mutado, caen dos subtests de la tabla.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
El binario es de un release. La versión se estampa con
-ldflags "-X main.version=…", que es un paso de goreleaser, ygo installno lo hace.Importa porque
go install …@latestes lo que la documentación le dice a la gente que use — la nota de versión deinstallation.mdlo pone al mismo nivel que Homebrew y la página de Releases. Así que "dev" era la respuesta que recibía la mayoría, y es la respuesta que vuelve inatribuible un reporte de bug.El arreglo
resolveVersion()cae adebug.ReadBuildInfo().Main.Versionsolo cuando el valor estampado sigue siendo"dev".Un
go buildlocal sigue diciendo"dev": ahíReadBuildInfodevuelve"(devel)", que no aporta nada sobre el fallback y se lee peor. Los dos tests fijan justamente eso — que un valor estampado gana siempre, y que"(devel)"nunca llega a la salida.Dos copias, una por módulo, en vez de un símbolo nuevo en core: son ocho líneas de stdlib sin semántica compartida que pueda derivar, y meterlo en core ataría este arreglo al bump de
core. Cada módulo trae su test.Verificación
Ningún camino devuelve
"(devel)". Ningún test del repo afirmaba sobre la salida de--version, así que no hay golden que regenerar.La prueba que falta por construcción es la de un binario instalado desde el proxy en un tag: eso solo se puede medir después de cortar
v2.32.5, y va como verificación posterior al release.