Repository navigation
ci: upload releases and the store listing to Google Play - #77
Merged
Merged
Conversation
A tagged release now builds the bundle alongside the APK and uploads it to Play's closed testing track with fastlane supply, together with the R8 mapping file and everything under fastlane/metadata/android: the listing text, the graphics, the screenshots and the changelog for the new versionCode as release notes. These are the files F-Droid reads at the same tag, so both stores describe the same build. The upload is its own job in a `play` environment, so a Play failure never holds back the GitHub Release and the service account key is only exposed there. The track comes from the PLAY_TRACK variable and defaults to `alpha`, Play's default closed testing track. A manual workflow pushes the listing alone, for corrections between releases. supply anchors even a listing-only edit to a release on a track, so it is pointed at the testing track and the current versionCode. Release branches now also check the listing against Play's length limits, which would otherwise only fail the upload after the tag. fastlane is pinned in a Gemfile, with its dependencies locked.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
A tagged release now builds the bundle alongside the APK and uploads it to Play's closed testing track with fastlane supply, together with the R8 mapping file and everything under fastlane/metadata/android: the listing text, the graphics, the screenshots and the changelog for the new versionCode as release notes. These are the files F-Droid reads at the same tag, so both stores describe the same build.
The upload is its own job in a
playenvironment, so a Play failure never holds back the GitHub Release and the service account key is only exposed there. The track comes from the PLAY_TRACK variable and defaults toalpha, Play's default closed testing track.A manual workflow pushes the listing alone, for corrections between releases. supply anchors even a listing-only edit to a release on a track, so it is pointed at the testing track and the current versionCode.
Release branches now also check the listing against Play's length limits, which would otherwise only fail the upload after the tag.
fastlane is pinned in a Gemfile, with its dependencies locked.