chore: exclude adobemedia-3 from 6.0 publish and enable manual publish trigger#739
Conversation
…h trigger The adobemedia-3 kit resolves its Adobe dependencies via a BOM without explicit versions, so the generated POM omits dependency versions and fails Maven Central validation, blocking the entire kits deployment bundle. Exclude it from the publish set until the versions are pinned. Also add workflow_dispatch to Release - Publish so the 6.0.0 kits bundle can be re-published without changing VERSION.
PR SummaryMedium Risk Overview The
Reviewed by Cursor Bugbot for commit e49ae12. Bugbot is set up for automated code reviews on this repo. Configure here. |
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
jamesnrokt
left a comment
jamesnrokt
left a comment
There was a problem hiding this comment.
Think the cursor bot has also called out a valid issue?
The build-kits workflow derives its matrix from kits/matrix.json and runs <kit_project>:testRelease against settings-kits.gradle. Since adobemedia-3 was excluded from settings-kits.gradle, its matrix entry now points at a project that no longer exists, failing the job. Drop it from the matrix to keep the two in sync.
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes using default effort and found 1 potential issue.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, have a team admin enable autofix in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit c6bca7b. Configure here.
… publish Revert the workflow_dispatch trigger on Release - Publish per review: the release flow stays controlled solely by the VERSION file trigger. Remove the adobemedia-3 example from settings-kit-examples.gradle to stay in sync with its exclusion from settings-kits.gradle and the CI matrix. Touch VERSION (still 6.0.0) so merging this re-runs Release - Publish and re-uploads the kits bundle without adobemedia-3.
|
Addressed both pieces of feedback:
|
|
…nclude in publish (#741) adobemedia-3 resolves its Adobe extensions through the sdk-bom, so they were declared without explicit versions and the generated POM listed them with an empty <version>. Maven Central rejects version-less dependencies, which blocked the whole kits bundle, so #739 excluded the kit from the 6.0.0 publish. Add a versionMapping block (scoped to this module) that maps each dependency to the version resolved on the release classpaths, so the published POM carries concrete versions while the build.gradle keeps the sdk-bom range. Re-include the kit in settings-kits.gradle, kits/matrix.json, and settings-kit-examples.gradle so it ships again in the next release.
2 participants
Background
The 6.0.0 publish uploaded the
com.mparticlekits as a single Central Portal deployment bundle. One component,com.mparticle:adobemedia-3:6.0.0, failed validation:adobemedia-3resolves its Adobe dependencies through a BOM (platform('com.adobe.marketing.mobile:sdk-bom:[3.0.0,4.0.0)')) with versionlessapideclarations, so the generated POM omits the dependency versions, which Maven Central rejects. Because a Central Portal deployment is atomic, this single failure blocks the whole kits bundle (includingandroid-rokt-kit, whichcom.rokt:rokt-sdk-plus:6.0.0depends on).What changed
:kits:adobemedia:adobemedia-3fromsettings-kits.gradleuntil its Adobe dependency versions are pinned in the published POM. It will be reintroduced in a follow-up once fixed.workflow_dispatchtoRelease – Publishso the 6.0.0 kits bundle can be re-published without changingVERSION(the version must remain 6.0.0 since the already-published umbrella referencescom.mparticle:*:6.0.0).Test plan
Release – Publishvia workflow_dispatch onmain.com.mparticle:android-rokt-kit:6.0.0and core artifacts resolve on Maven Central, unblockingcom.rokt:rokt-sdk-plus:6.0.0.