Repository navigation
chore(release): skip beta, auto-merge backports and deduplicate CI - #109
Merged
Merged
Conversation
Until a v2, the bot opens a single dev -> main promotion: its version is the last stable bumped by the promoted commits (no -BETA.N tag), and a stable or a hotfix is brought back to dev straight from main. The chain lives in .github/release/lib/flow.mjs (BETA = false); the beta pairs stay accepted by the scripts and workflows, so setting it back to true restores dev -> beta -> main.
… dev The bot enables auto-merge (merge commit, pinned to the head it opened) on each backport it opens, so dev catches up with main as soon as the checks pass instead of waiting for a manual merge. If GitHub refuses it, the PR stays open and its body asks for the manual merge as before.
A push to a branch with an open pull request ran build, test, commitlint and release-scripts twice (push, then pull_request). The four workflows now run on pull requests only, into any base so stacked PRs keep their checks: dev's head is covered by its dev -> main promotion PR, main's by the backport main -> dev, and renovate-merge.yml still dispatches build and test on dev. A new push to a pull request cancels the run it supersedes. The obsolete master branch filter is gone.
1 task done
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.
Pourquoi
Jusqu'à une éventuelle v2, on saute l'étape
beta: les releases passent directement dedevàmain. Les PR de report qui ramènent une release surdevdoivent se fusionner seules, et la CI lançait plusieurs jobs en double (push puis pull_request sur la même branche).Changements
1.
chore(release): promotion directedev→main.github/release/lib/flow.mjs:BETA = falsedécrit la chaîne de promotion (dev → main). Pour réactiver beta, il suffit de remettreBETA = trueet de remettrebetadans les branches de push depromote.yml: les scripts et les conditions des workflows acceptent toujours les paires beta.dev → mainprend le dernier stable incrémenté selon les commits conventionnels (nextDirectStable), sans tag-BETA.N. Prochaine release attendue :v1.2.0. Si une beta plus haute est encore en attente, sa cible est reprise.ready.mjstraitedev → maincomme un stable (bump debuild.gradle.ktssurdev, auto-merge épinglé).publish.mjs: après un stable ou un hotfix, le report se fait directementmain → dev.schedule.mjs: les sorties programmées concernentdev → main.--runprend la cible dansflow.mjs, et--targetne sert plus que de repli : l'ancienne copie derelease-schedule.ymlencore surmain(qui passe--target beta) reste donc correcte jusqu'à la prochaine release.dev → main.promote.yml(push surdevuniquement, cible calculée par le script),release-ready.yml,release-schedule.yml,publish.ymletcommitlint.yml(job ignoré surdev → mainetmain → dev) acceptent la nouvelle paire.2.
chore(release): auto-merge des reports versdevchore(release): backport vX.Y.Z to devcomme sujet. Ce sujet est déjà ignoré par la promotion.allow_auto_mergeest déjà activé sur le dépôt : aucun réglage modifié.3.
ci: moins de jobs en doublebuild,test,commitlintetrelease-scriptsne tournent plus que surpull_request(vers n'importe quelle base, donc les PR empilées gardent leurs checks). Il n'y a plus de triggerpush.devest vérifiée par sa PR de promotiondev → main. Celle demainl'est par le reportmain → dev.renovate-merge.ymlcontinue de lancerbuildettestsurdevparworkflow_dispatch.concurrencyaveccancel-in-progresspour les PR : un nouveau push annule le run qu'il remplace. Les runs lancés à la main ne sont jamais annulés.masterest supprimé.build,test,commitlint,release-scripts) ne changent pas : le ruleset n'a pas été touché.Modules à redémarrer
Modules à redémarrer : aucun (CI uniquement).
À reporter sur
main/ à faire après mergerelease-schedule.ymlest modifié ici. Il arrivera surmainavec la prochaine promotiondev → mainet restera ainsi identique sur les deux branches. Pas besoin de le reporter à la main :mainn'a pas bougé depuis, la fusion sera propre. D'ici là, le cron demainutilise l'ancienne copie, que le script gère.dev → beta,v1.2.0-BETA.1) est désormais obsolète : la fermer après le merge. Le prochain push surdevouvrira la promotiondev → main.beta → dev,v1.1.0) est toujours ouvert. Tant qu'il l'est,ready.mjsrefuse la promotion versmain: le fusionner (commit de merge) ou activer son auto-merge.betapeut rester en place (inutilisée) pour une réactivation éventuelle.