ci: refactor manual deployment CI config into 1 workflow #264
Conversation
Codecov Report
@@ Coverage Diff @@
## main #264 +/- ##
=========================================
Coverage 50.84% 50.84%
Complexity 249 249
=========================================
Files 108 108
Lines 2779 2779
Branches 361 361
=========================================
Hits 1413 1413
Misses 1249 1249
Partials 117 117 |
Sample app builds 📱Below you will find the list of the latest versions of the sample apps. It's recommended to always download the latest builds of the sample apps to accurately test the pull request.
|
|
Build available to test |
| @@ -125,10 +133,22 @@ jobs: | |||
| deploy-sonatype: | |||
| name: Deploy SDK to Maven Central | |||
| needs: [deploy-git-tag] | |||
There was a problem hiding this comment.
I don't think it will work in the case of manual workflow because it always needs a needs: [deploy-git-tag] job to work first.
There was a problem hiding this comment.
Great question. I understand how this can be confusing. This CI configuration would still work, but it might be confusing how.
needs specifies order of steps in the configuration. When a manual deployment is performed, the deploy-git-tag will indeed not create a new tag. It will run, see there is no tag needing to be made, then quit.
This PR works because of the modified if statement which says that deploy-sonatype step needs to wait for deploy-git-tag to run first, yes, but it will still run if a git tag is made or the deployment was manual.
The iOS SDK has the same needs and if statement as this PR and manual deployments work on that configuration.
Here is an example CI run of a manual deployment I did with this CI workflow. deploy-git-tag did run and it didn't create a tag. deploy to cocoapods checked out the git tag specified in the manual workflow input form and then proceeded to deploy to cocoapods.
Would it help if there were some comments added to the deploy-sdk.yml config file explaining this?
There was a problem hiding this comment.
Thank you for the clarification Levi, I thought deploy-git-tag would fail hence leading up to deploy-sonatype not working. But seems like it triggers and skips and doesn't fail so it will not stop the deployment job from failing.
A couple of more things, in the case of manual workflow, if inputs.existing-git-tag is empty, it would result in using the ref branch as the source of checkout right? just want to make sure we have the latest version. in the manual script, I would fetch the latest tag in case none was mentioned while dispatching the workflow.
Secondly,
uses: ./.github/actions/setup-android
- name: Push to Sonatype servers
run: MODULE_VERSION=${{ needs.deploy-git-tag.outputs.new_release_version }} ./scripts/deploy-code.sh
This script is dependent on needs.deploy-git-tag.outputs.new_release_version but if the deploy-git-tag is skipped, would it populate this variable? i wouldn't believe so.
There was a problem hiding this comment.
Good catch. I did not consider that since the iOS SDK doesn't update the version at compile-time.
Until we can test deployment CI workflows before merging PRs, I think this PR is not worth merging. Some copy/pasted code in the short-term is OK for now. I will close this PR to do the refactor another time.
From a recent PR, the CI server can now do manual deployments. Great addition to this project!
The iOS SDK also has this ability to manually deploy with all configuration in 1 CI workflow file instead of 2 files. This PR implements the same logic the iOS SDK has of re-using 1 CI workflow file to do automatic and manual deployments to prevent some copy/paste in CI configuration files.