2023-09-15 22:15:50 +02:00
|
|
|
name: Upload blueRelease to Google Play
|
|
|
|
|
|
|
|
|
|
on:
|
|
|
|
|
workflow_dispatch:
|
|
|
|
|
|
|
|
|
|
jobs:
|
|
|
|
|
build:
|
|
|
|
|
name: Build
|
|
|
|
|
runs-on: ubuntu-latest
|
|
|
|
|
steps:
|
|
|
|
|
- name: Checkout
|
2024-03-21 13:10:59 +01:00
|
|
|
uses: actions/checkout@b4ffde65f46336ab88eb53be808477a3936bae11 # v4
|
2023-09-15 22:15:50 +02:00
|
|
|
|
2024-04-15 15:24:07 +02:00
|
|
|
- uses: ./.github/actions/setup-build-env
|
2023-09-15 22:15:50 +02:00
|
|
|
with:
|
2024-04-15 15:24:07 +02:00
|
|
|
gradle-cache-encryption-key: ${{ secrets.GRADLE_ENCRYPTION_KEY }}
|
2023-09-15 22:15:50 +02:00
|
|
|
|
feat: Periodically check for updates and alert user (#236)
Users can inadvertently get stuck on older versions of the app; e.g., by
installing from one F-Droid repository that stops hosting the app at
some later time.
Analytics from the Play Store also shows a long tail of users who are,
for some reason, on an older version.
On resuming `MainActivity`, and approximately once per day, check and
see if a newer version of Pachli is available, and prompt the user to
update by going to the relevant install location (Google Play, F-Droid,
or GitHub).
The dialog prompt allows them to ignore this specific version, or
disable all future update notifications. This is also exposed through
the preferences, so the user can adjust it there too.
A different update check method is used for each installation location.
- F-Droid: Use the F-Droid API to query for the newest released version
- GitHub: Use the GitHub API to query for the newest release, and check
the APK filename attached to that release
- Google Play: Use the Play in-app-updates library
(https://developer.android.com/guide/playcore/in-app-updates) to query
for the newest released version
These are kept in different build flavours (source sets), so that e.g.,
the build for the F-Droid store can only query the F-Droid API, the UI
strings are specific to F-Droid, etc. This also ensures that the update
service libraries are specific to that build and do not
"cross-contaminate".
Note that this *does not* update the app, it takes the user to either
the relevant store page (F-Droid, Play) or GitHub release page. The user
must still start the update from that page.
CI configuration is updated to build the different flavours.
2023-11-08 08:42:39 +01:00
|
|
|
- name: Build GitHub APK
|
|
|
|
|
run: ./gradlew assembleBlueGithubRelease --stacktrace
|
2023-09-15 22:15:50 +02:00
|
|
|
|
feat: Periodically check for updates and alert user (#236)
Users can inadvertently get stuck on older versions of the app; e.g., by
installing from one F-Droid repository that stops hosting the app at
some later time.
Analytics from the Play Store also shows a long tail of users who are,
for some reason, on an older version.
On resuming `MainActivity`, and approximately once per day, check and
see if a newer version of Pachli is available, and prompt the user to
update by going to the relevant install location (Google Play, F-Droid,
or GitHub).
The dialog prompt allows them to ignore this specific version, or
disable all future update notifications. This is also exposed through
the preferences, so the user can adjust it there too.
A different update check method is used for each installation location.
- F-Droid: Use the F-Droid API to query for the newest released version
- GitHub: Use the GitHub API to query for the newest release, and check
the APK filename attached to that release
- Google Play: Use the Play in-app-updates library
(https://developer.android.com/guide/playcore/in-app-updates) to query
for the newest released version
These are kept in different build flavours (source sets), so that e.g.,
the build for the F-Droid store can only query the F-Droid API, the UI
strings are specific to F-Droid, etc. This also ensures that the update
service libraries are specific to that build and do not
"cross-contaminate".
Note that this *does not* update the app, it takes the user to either
the relevant store page (F-Droid, Play) or GitHub release page. The user
must still start the update from that page.
CI configuration is updated to build the different flavours.
2023-11-08 08:42:39 +01:00
|
|
|
- name: Build Google AAB
|
|
|
|
|
run: ./gradlew :app:bundleBlueGoogleRelease --stacktrace
|
2023-09-15 22:15:50 +02:00
|
|
|
|
2024-03-21 13:10:59 +01:00
|
|
|
- uses: r0adkll/sign-android-release@dbeba6b98a60b0fd540c02443c7f428cdedf0e7f # v1.0.4
|
feat: Periodically check for updates and alert user (#236)
Users can inadvertently get stuck on older versions of the app; e.g., by
installing from one F-Droid repository that stops hosting the app at
some later time.
Analytics from the Play Store also shows a long tail of users who are,
for some reason, on an older version.
On resuming `MainActivity`, and approximately once per day, check and
see if a newer version of Pachli is available, and prompt the user to
update by going to the relevant install location (Google Play, F-Droid,
or GitHub).
The dialog prompt allows them to ignore this specific version, or
disable all future update notifications. This is also exposed through
the preferences, so the user can adjust it there too.
A different update check method is used for each installation location.
- F-Droid: Use the F-Droid API to query for the newest released version
- GitHub: Use the GitHub API to query for the newest release, and check
the APK filename attached to that release
- Google Play: Use the Play in-app-updates library
(https://developer.android.com/guide/playcore/in-app-updates) to query
for the newest released version
These are kept in different build flavours (source sets), so that e.g.,
the build for the F-Droid store can only query the F-Droid API, the UI
strings are specific to F-Droid, etc. This also ensures that the update
service libraries are specific to that build and do not
"cross-contaminate".
Note that this *does not* update the app, it takes the user to either
the relevant store page (F-Droid, Play) or GitHub release page. The user
must still start the update from that page.
CI configuration is updated to build the different flavours.
2023-11-08 08:42:39 +01:00
|
|
|
name: Sign GitHub APK
|
2023-09-15 22:15:50 +02:00
|
|
|
id: sign_app_apk
|
|
|
|
|
with:
|
feat: Periodically check for updates and alert user (#236)
Users can inadvertently get stuck on older versions of the app; e.g., by
installing from one F-Droid repository that stops hosting the app at
some later time.
Analytics from the Play Store also shows a long tail of users who are,
for some reason, on an older version.
On resuming `MainActivity`, and approximately once per day, check and
see if a newer version of Pachli is available, and prompt the user to
update by going to the relevant install location (Google Play, F-Droid,
or GitHub).
The dialog prompt allows them to ignore this specific version, or
disable all future update notifications. This is also exposed through
the preferences, so the user can adjust it there too.
A different update check method is used for each installation location.
- F-Droid: Use the F-Droid API to query for the newest released version
- GitHub: Use the GitHub API to query for the newest release, and check
the APK filename attached to that release
- Google Play: Use the Play in-app-updates library
(https://developer.android.com/guide/playcore/in-app-updates) to query
for the newest released version
These are kept in different build flavours (source sets), so that e.g.,
the build for the F-Droid store can only query the F-Droid API, the UI
strings are specific to F-Droid, etc. This also ensures that the update
service libraries are specific to that build and do not
"cross-contaminate".
Note that this *does not* update the app, it takes the user to either
the relevant store page (F-Droid, Play) or GitHub release page. The user
must still start the update from that page.
CI configuration is updated to build the different flavours.
2023-11-08 08:42:39 +01:00
|
|
|
releaseDirectory: app/build/outputs/apk/blueGithub/release
|
2023-09-15 22:15:50 +02:00
|
|
|
signingKeyBase64: ${{ secrets.SIGNING_KEY }}
|
|
|
|
|
alias: ${{ secrets.SIGNING_KEY_ALIAS }}
|
|
|
|
|
keyStorePassword: ${{ secrets.KEY_STORE_PASSWORD }}
|
|
|
|
|
keyPassword: ${{ secrets.KEY_PASSWORD }}
|
|
|
|
|
env:
|
|
|
|
|
BUILD_TOOLS_VERSION: "34.0.0"
|
|
|
|
|
|
2024-03-21 13:10:59 +01:00
|
|
|
- uses: r0adkll/sign-android-release@dbeba6b98a60b0fd540c02443c7f428cdedf0e7f # v1.0.4
|
feat: Periodically check for updates and alert user (#236)
Users can inadvertently get stuck on older versions of the app; e.g., by
installing from one F-Droid repository that stops hosting the app at
some later time.
Analytics from the Play Store also shows a long tail of users who are,
for some reason, on an older version.
On resuming `MainActivity`, and approximately once per day, check and
see if a newer version of Pachli is available, and prompt the user to
update by going to the relevant install location (Google Play, F-Droid,
or GitHub).
The dialog prompt allows them to ignore this specific version, or
disable all future update notifications. This is also exposed through
the preferences, so the user can adjust it there too.
A different update check method is used for each installation location.
- F-Droid: Use the F-Droid API to query for the newest released version
- GitHub: Use the GitHub API to query for the newest release, and check
the APK filename attached to that release
- Google Play: Use the Play in-app-updates library
(https://developer.android.com/guide/playcore/in-app-updates) to query
for the newest released version
These are kept in different build flavours (source sets), so that e.g.,
the build for the F-Droid store can only query the F-Droid API, the UI
strings are specific to F-Droid, etc. This also ensures that the update
service libraries are specific to that build and do not
"cross-contaminate".
Note that this *does not* update the app, it takes the user to either
the relevant store page (F-Droid, Play) or GitHub release page. The user
must still start the update from that page.
CI configuration is updated to build the different flavours.
2023-11-08 08:42:39 +01:00
|
|
|
name: Sign Google AAB
|
2023-09-15 22:15:50 +02:00
|
|
|
id: sign_app_aab
|
|
|
|
|
with:
|
feat: Periodically check for updates and alert user (#236)
Users can inadvertently get stuck on older versions of the app; e.g., by
installing from one F-Droid repository that stops hosting the app at
some later time.
Analytics from the Play Store also shows a long tail of users who are,
for some reason, on an older version.
On resuming `MainActivity`, and approximately once per day, check and
see if a newer version of Pachli is available, and prompt the user to
update by going to the relevant install location (Google Play, F-Droid,
or GitHub).
The dialog prompt allows them to ignore this specific version, or
disable all future update notifications. This is also exposed through
the preferences, so the user can adjust it there too.
A different update check method is used for each installation location.
- F-Droid: Use the F-Droid API to query for the newest released version
- GitHub: Use the GitHub API to query for the newest release, and check
the APK filename attached to that release
- Google Play: Use the Play in-app-updates library
(https://developer.android.com/guide/playcore/in-app-updates) to query
for the newest released version
These are kept in different build flavours (source sets), so that e.g.,
the build for the F-Droid store can only query the F-Droid API, the UI
strings are specific to F-Droid, etc. This also ensures that the update
service libraries are specific to that build and do not
"cross-contaminate".
Note that this *does not* update the app, it takes the user to either
the relevant store page (F-Droid, Play) or GitHub release page. The user
must still start the update from that page.
CI configuration is updated to build the different flavours.
2023-11-08 08:42:39 +01:00
|
|
|
releaseDirectory: app/build/outputs/bundle/blueGoogleRelease
|
2023-09-15 22:15:50 +02:00
|
|
|
signingKeyBase64: ${{ secrets.SIGNING_KEY }}
|
|
|
|
|
alias: ${{ secrets.SIGNING_KEY_ALIAS }}
|
|
|
|
|
keyStorePassword: ${{ secrets.KEY_STORE_PASSWORD }}
|
|
|
|
|
keyPassword: ${{ secrets.KEY_PASSWORD }}
|
|
|
|
|
env:
|
|
|
|
|
BUILD_TOOLS_VERSION: "34.0.0"
|
|
|
|
|
|
|
|
|
|
- name: Upload APK Release Asset
|
|
|
|
|
id: upload-release-asset-apk
|
2024-03-21 13:10:59 +01:00
|
|
|
uses: actions/upload-artifact@5d5d22a31266ced268874388b861e4b58bb5c2f3 # v4
|
2023-09-15 22:15:50 +02:00
|
|
|
with:
|
|
|
|
|
name: app-release.apk
|
|
|
|
|
path: ${{steps.sign_app_apk.outputs.signedReleaseFile}}
|
2023-09-19 12:05:06 +02:00
|
|
|
|
|
|
|
|
- name: Generate whatsnew
|
|
|
|
|
id: generate-whatsnew
|
|
|
|
|
run: |
|
|
|
|
|
mkdir -p googleplay/whatsnew
|
|
|
|
|
cp $(find fastlane/metadata/android/en-US/changelogs | sort -n -k6 -t/ | tail -n 1) googleplay/whatsnew/whatsnew-en-US
|
|
|
|
|
|
|
|
|
|
- name: Upload AAB to Google Play
|
|
|
|
|
id: upload-release-asset-aab
|
2024-03-21 13:10:59 +01:00
|
|
|
uses: r0adkll/upload-google-play@935ef9c68bb393a8e6116b1575626a7f5be3a7fb # v1.1.3
|
2023-09-19 12:05:06 +02:00
|
|
|
with:
|
|
|
|
|
serviceAccountJsonPlainText: ${{ secrets.PLAY_SERVICE_ACCOUNT_KEY }}
|
|
|
|
|
packageName: app.pachli
|
|
|
|
|
releaseFiles: ${{steps.sign_app_aab.outputs.signedReleaseFile}}
|
|
|
|
|
track: internal
|
|
|
|
|
whatsNewDirectory: googleplay/whatsnew
|
|
|
|
|
status: completed
|
feat: Periodically check for updates and alert user (#236)
Users can inadvertently get stuck on older versions of the app; e.g., by
installing from one F-Droid repository that stops hosting the app at
some later time.
Analytics from the Play Store also shows a long tail of users who are,
for some reason, on an older version.
On resuming `MainActivity`, and approximately once per day, check and
see if a newer version of Pachli is available, and prompt the user to
update by going to the relevant install location (Google Play, F-Droid,
or GitHub).
The dialog prompt allows them to ignore this specific version, or
disable all future update notifications. This is also exposed through
the preferences, so the user can adjust it there too.
A different update check method is used for each installation location.
- F-Droid: Use the F-Droid API to query for the newest released version
- GitHub: Use the GitHub API to query for the newest release, and check
the APK filename attached to that release
- Google Play: Use the Play in-app-updates library
(https://developer.android.com/guide/playcore/in-app-updates) to query
for the newest released version
These are kept in different build flavours (source sets), so that e.g.,
the build for the F-Droid store can only query the F-Droid API, the UI
strings are specific to F-Droid, etc. This also ensures that the update
service libraries are specific to that build and do not
"cross-contaminate".
Note that this *does not* update the app, it takes the user to either
the relevant store page (F-Droid, Play) or GitHub release page. The user
must still start the update from that page.
CI configuration is updated to build the different flavours.
2023-11-08 08:42:39 +01:00
|
|
|
mappingFile: app/build/outputs/mapping/blueGoogleRelease/mapping.txt
|
