Automate Publishing to Maven Central via CI #29
Merged
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.
Change description
This is a simple setup to publish the SDKs to Mave Central. It automates signing and uploading the release.
Currently it is still necessary to promote the build manually in the Nexus Repository Manager. Open "Staging Repository" and promote the artifact (aka Open, Close and Release).
I set out with these goals while working on this PR:
Goals
See above. I'm still looking for ways to automate promoting the artifact to release
I think this PR does this nicely, by not adding additional constraints between the differnt workflows
I tried solutions that would use worklow logic, and dependend jobs to make the release job fail if the existing build and test CI job failed, but that complicated things to much, so I've opted for running
lint
andtest
tasks inside the publish workflow as sanity checks.My first attempt was setting up the publish as a dependent workflow of the changesets workflow, by using
workflow_call
primitives, but this collided with goal 2. Using theon: release
trigger is much simpler and should work equally well. 🤞It's hard to Gradle transfer build results between jobs (and convince Gradle to not redo the work!). I experimented with having only one
gradle
workflow, that does everything from building, testing and linting to (conditionally) publishing, but all that collided with goal 2.Keeping goal 2 a priority, and considering that SDK release workflows don't run often, I generally opted for not optimizing job runtime, but rather to repeat some of the work.
Current State
I wasn't able to publish the current version using this workflow yet (see steps in testplan), but I hope it's just caused by the fact that version 2.0.0 is already published, and hope that it would work with the next version.
Here's the error, showing that PUT on version 2.0.0 failed.
Test Plan
Tested that the flow runs locally by using
act
and providing the secrets.Important: This assumes you have the full act runner image available, which have Android SDK support.
Type of Change
Guidelines