Repository navigation
ci(mobile): publicar en producción de Play y enviar a revisión de App Store al fusionar - #262
Merged
Merged
Conversation
… on merge - ensure-tags dispatches the release with android_track=production; a published GitHub Release defaults to production too (prepare.outputs.track). - google-play-version check looks at the target track first, only skips a completed release and fails on API errors instead of guessing "build". - New check-app-store job skips the iOS build when the build number is already in App Store Connect; new ios-submit job submits the version for review with app-store-submit.mjs (adapted from sacadiez-app / RocStatus). - altool output is checked: an upload Apple rejects now fails the run. - Apple errors include meta.associatedErrors, the real reasons of a 409.
Contributor
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
- ensure-tags dispatches the release on the tag (--ref) whenever the version has no GitHub Release yet, so a failed dispatch is retried on re-run; the web tag step no longer depends on the mobile ones. - release-mobile-app: concurrency group, android_track output name, release notes generated before a Play promote, googleapis installed without the project scripts, release assets found in subfolders. - app-store-submit: answers the age rating questions the owner declared (socialMedia / socialMediaAgeRestricted = false) only where still unanswered, cancels a stale UNRESOLVED_ISSUES submission and resubmits (from RocStatus), checks the version before waiting for the build, treats replaced or removed versions as nothing to submit, renames only an older editable version and defaults BUNDLE_ID to es.deamap.mobile. - Mock App Store Connect check for the script (stale / other-409 / newer-editable). - AGENTS.md describes the automatic release flow.
This branch was successfully deployed
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
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.
Objetivo
Que fusionar en
mainuna versión nueva de la app (mobile/version.json) la publique sola: en producción en Google Play y enviada a revisión en App Store, sin pasos manuales. La web no se toca: sigue desplegando en Vercel.Estado de las tiendas (consultado por API, solo lectura, 3-nov-2026)
production: 1.0.11 (10011)completed. Ficha es-ES y en-USinternal: 1.0.12 (10012)READY_FOR_SALE(enviada el 24-oct, aprobada)VALIDen TestFlightLas dos apps ya están publicadas, así que no hay ningún primer lanzamiento que decidir y el pipeline puede ir directo a producción.
Cambios
ensure-tags.ymlrelease-mobile-app.ymlsobre el tag (--ref mobile@x.y.z) conandroid_track=production. Así la versión y las notas salen del commit del tag, no del HEAD demainen ese momento.create-releaseal empezar). Si el disparo falla, basta relanzar el job; una versión ya publicada no se repite.release-mobile-app.ymlprepare.outputs.android_track). Por defecto esproduction, también si el run viene de un GitHub Release publicado a mano.concurrency: dos runs de la misma versión ya no compiten por subir.check-app-store: si el build number ya está en App Store Connect, no se compila ni se vuelve a subir.ios-submit: genera las notas y llama a.github/scripts/app-store-submit.mjs.altool. Puede salir con código 0 aunque Apple rechace el paquete, y ahora eso pone el run en rojo.promote-androidgenera también las notas de la versión antes de promover.googleapisse instala sin los scripts del proyecto (prisma generate,husky).google-play-version.mjscheckmira primero el track destino y solo daskipsi el release estácompleted.build.promotedescarta el edit también cuando no encuentra la versión.app-store-submit.mjs(adaptado devgpastor/sacadiez-app, en su versión de RocStatus#436 y #437)socialMedia=falseysocialMediaAgeRestricted=falseel 3-nov. La ficha publicada no se puede editar (Apple responde 409, «not editable»), así que el script las escribe en elappInfoeditable que aparece con la versión nueva, y solo si siguen sin contestar. Nunca pisa un cambio hecho a mano en App Store Connect.UNRESOLVED_ISSUESno deja reenviar, lo cancela y abre uno nuevo.meta.associatedErrors, que es donde Apple da el motivo real de un 409.Errores visibles
Una subida o un envío que falle pone el run en rojo con el mensaje de Google (
r0adkll/upload-google-play, ogoogleapisencheckypromote) o el de Apple (salida dealtooly respuesta de la API de App Store Connect con sus errores asociados).Pruebas
actionlintsin errores en todos los workflows.node --checkcorrecto en los scripts.prettier --check .en verde.google-play-version.mjs check --target-track productioncontra Play (solo lectura): 10011 daskip, 10012 dapromotedesdeinternaly 10013 dabuild.app-store-submit.mjs checkcontra App Store Connect (solo lectura): 1.0.12/10012 dauploaded=truey 1.0.13/10013 dauploaded=false..github/scripts/test/app-store-submit.mock.mjscontra una API de Apple simulada, con salida 0 en los tres casos:stale: contesta solosocialMedia, cancela el envío viejo y reenvía.other-409: no cancela nada y falla.newer-editable: no renombra la 1.0.14 y falla al crear la versión.Revisión
Dos revisiones independientes, una de bugs y otra de Clean Code/SOLID, sobre el primer commit. Sus hallazgos están aplicados en el segundo. Lo que no se ha tocado:
--target-track/--to-tracky partir funciones del script de Apple: es API ya existente y no cambia el comportamiento.Pendiente fuera del código
mainpero no en producción: está en Playinternaly en TestFlight, y ya tiene GitHub Release, así que fusionar esta PR no la relanza. Saldrá con el siguiente cambio de versión, o antes si se lanza a manoRelease Mobile Appsobremobile@1.0.12.