Add automated play store uploads #12217
Conversation
…-play-store-uploads
…-play-store-uploads
|
You can trigger optional UI/connected tests for these changes by visiting CircleCI here. |
|
You can test the changes on this Pull Request by downloading the APK here. |
| alpha: true, | ||
| beta: true, | ||
| final: false) | ||
| android_build_preflight() | ||
| build_alpha(skip_prechecks: true, skip_confirm: options[:skip_confirm]) | ||
| build_beta(skip_prechecks: true, skip_confirm: options[:skip_confirm]) | ||
| build_alpha(skip_prechecks: true, skip_confirm: options[:skip_confirm], upload_to_play_store: true) |
There was a problem hiding this comment.
One suggestion just based on the WPiOS and WooAndroid implementations – in those cases we renamed the lanes to build_and_upload_{type} to better communicate what they do, and they always do the upload. Having an upload option on a build lane (which I kinda think of as a method) seems like it'd almost make more sense as its own lane after building?
I think the best way to go here might just be to be consistent with WCAndroid?
There was a problem hiding this comment.
The reason I went this route is to give us the ability to build the alpha or beta without uploading to play store. I followed WCAndroid's example with the main lanes build_and_upload_release & build_and_upload_pre_releases. However, at times I have to try to build the app to fix build errors but I don't want it to be uploaded, so these lanes would be helpful. Having said that, they are not crucial either, I can just run the necessary commands manually. I just prefer this because I know it'll be the same when I run the actual script.
in those cases we renamed the lanes to build_and_upload_{type} to better communicate what they do, and they always do the upload.
In this case, it doesn't always upload the build, so it still does communicate what it does, it just does something different.
What do you think? Should I make the change?
There was a problem hiding this comment.
I'm not set on it – so feel free to merge as-is!
There was a problem hiding this comment.
OK, let's merge it for now, but if you feel strongly about it, we can definitely change the naming.
cc @loremattei - would love to hear your take as well.
I am targeting this PR against the release branch since it doesn't change anything in the actual code and it makes it much easier to test. I also need to release a new alpha/beta, but since it is for a very minor change, I wanted to use the opportunity to test the PR.
P.S: I suggest reviewing this PR with the Hide whitespace changes option enabled. I committed the whitespace changes my editor made to make it easier to work with the file in the future.
To test:
1. In Play Store discard the drafts for both alpha and beta and remove the artifacts forEdit: I removed these, so you can ignore this step.883and884. These were added with the script, so I wanted to keep it as a test instruction.2. Disable this pre-check since it'll prevent the script running on a branch that's not a
releasebranch.3. Run
bundle exec fastlane run configure_applywhich will download the upload credentials4. Run
bundle exec fastlane build_and_upload_pre_releases: This will build and upload alpha and beta builds we deleted inStep 1.No cleanup is necessary since we want to release a new beta and if it turns out to be necessary, I'll take care of it. Also, this will not test the
build_and_upload_releaselane, but it's pretty much the same as the pre-releases with only difference being theproductiontrack.Edit: Cleanup will be necessary since there is a new PR against the release branch, but I can do that.
PR submission checklist:
RELEASE-NOTES.txtif necessary.