MOBILE-0000: Релиз-преп должен двигать mindbox-common вместе с mobile-sdk - #222
Merged
Merged
Conversation
…prep The wrapper takes mindbox-common compileOnly because mobile-sdk keeps it an implementation dependency, so the release tooling has to move both lines at once — otherwise the compile classpath keeps the old common while the runtime one comes transitively from the new mobile-sdk.
sergeysozinov
approved these changes
Sep 9, 2026
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
2 participants
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.
Причина
В
android/build.gradleобёртка берётmindbox-commonкакcompileOnly(появилось в #220): нативный SDK держит егоimplementation-зависимостью, поэтому@InternalMindboxApi— аннотация, которой помечены хуки встроенных блоков — не попадает на compile-classpath потребителя. В Gradle-метаданныхmobile-sdkэто видно прямо:mindbox-commonперечислен только вreleaseVariantReleaseRuntimePublication, в api-варианте его нет.Но релизная автоматика бампает версию натива только в
api-строке. То есть на следующем релизеmobile-sdkуехал бы на новую версию, аmindbox-commonостался бы на2.15.4.Ломается это молча и неприятно:
compileOnlyне участвует в резолве рантайм-графа, конфликта версий Gradle не увидит, и обёртка скомпилируется против старого common, а поедет с новым (его притащит транзитивноmobile-sdk). Если в common переедет или сменит сигнатуру что-то из используемого — получим либоunresolved referenceна релизной ветке, либоNoSuchMethodErrorуже у клиента. Заметно станет только в момент релиза.Что сделано
Обе точки, которые готовят релизную ветку, теперь двигают обе строки:
.github/workflows/manual-prepare_release_branch.yml— шаг «Create branch & apply bumps»git-release-branch.sh— локальный аналогВерсия намеренно остаётся литералом в обеих строках, а не выносится в переменную: на формат этих строк завязаны оба sed'а и
extractVersion.shв репозитории приложения (он читает версию дляversionName/CFBundleShortVersionString). Любой будущий рефакторинг в переменную обязан править все три места.Как проверено локально
bumpвытащен из воркфлоу дословно и выполнен в одноразовом клоне ветки сVERSION=2.16.0и пустымиandroid_sdk_version/ios_sdk_version(проверился и фолбэк на RN-версию). Результат:mobile-sdkиmindbox-commonоба на2.16.0, podspec,package.json, CHANGELOG — как раньше, веткаrelease/2.16.0,release_branchвGITHUB_OUTPUT.git-release-branch.shпрогнан во втором клоне — обе строки переезжают.sed -iподменялся на BSD-форму. Проверены регулярки и порядок шагов; сама GNU-конструкцияsed -i "expr"в этом шаге была и до изменения и уже прошла через релизы.Тикета на это нет — отсюда
MOBILE-0000в имени ветки.🤖 Generated with Claude Code