EMB-627 Added support for publishing, closing and releasing sonatype repositories #282
Conversation
1- run Pre-Release for Smoke -> this step will run tests, it will publish to sonatype staging repo and it will close the repo. Now we are able to do some smoking testing 2- run Release -> once smoking test gets green light, we can release. This workflow performs the actual release to maven central. It will then set next version and push it remotely. It also generates documentation and pushes it to our docs repo.
There was a problem hiding this comment.
Nice, this should make our lives easier. For releasing, I like your idea of a pre-release workflow (that creates a snapshot we can test against) and a release workflow (that closes the snapshot).
Before we merge this I think it'd also be good to compare the POM + other artefacts this generates and check they are the same as what the old solution generates. This could be achieved by getting the files from maven local (~/.m2/repository/io) and eyeballing if there are any differences. I've been bitten in the past by POM files changing or artefacts going missing on upgrades like this.
| # measure-sdk-size: | ||
| # uses: embrace-io/android-size-measure/.github/workflows/analyze-sdk-size.yml@main | ||
| # needs: release | ||
| # with: | ||
| # sdk_version: ${{ github.event.inputs.current_version }} | ||
| # token: ${{ secrets.CD_GITHUB_TOKEN }} | ||
| # | ||
| # measure-startup-time: | ||
| # uses: embrace-io/android-sdk-benchmark/.github/workflows/macrobenchmark.yml@main | ||
| # needs: release | ||
| # with: | ||
| # sdk_version: ${{ github.event.inputs.current_version }} | ||
| # token: ${{ secrets.CD_GITHUB_TOKEN }} |
There was a problem hiding this comment.
If these are unused they can be deleted
|
I compared all poms (okhttp, fcm, compose, sdk) and they're identical |
|
I did a quick testing on android-test-suite with the version generated by nexus-plugin and it seems to work fine |
There was a problem hiding this comment.
Looks good to me as long as the way we are passing the token is a acceptable way of doing so. I know we typically want to avoid putting credentials in plain text in the URL but if this is a one off use thing or one of those that can't be reused in other contexts, then it's fine.
| run: | | ||
| git config --global user.name 'embrace-ci[bot]' | ||
| git config --global user.email '[email protected]' | ||
| git config --global url."https://${{ secrets.CD_GITHUB_USER }}:${{ secrets.CD_GITHUB_TOKEN }}@github.com".insteadOf "https://github.com" |
There was a problem hiding this comment.
is this the accepted way of passing a token around for git to consume?
There was a problem hiding this comment.
I will create a ticket so we can revisit this
Goal
Added the ability to:
Modified workflow so we now have:
Testing
Release Notes
WHAT:
WHY:
WHO: