Mastodon
/
pachli-android
mirror of https://github.com/pachli/pachli-android.git
1
0
Fork 0
Code Issues Packages Projects Releases Wiki Activity
pachli-android/.github/workflows/upload-orange-release-googl...

78 lines
2.7 KiB
YAML
Raw Normal View History

ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
name: Upload orangeRelease to Google Play
on:
workflow_dispatch:
jobs:
build:
name: Build
runs-on: ubuntu-latest
steps:
- name: Checkout
chore(deps): update actions/checkout digest to 692973e (#747) [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/checkout](https://togithub.com/actions/checkout) | action | digest | `a5ac7e5` -> `692973e` | --- > [!WARNING] > Some dependencies could not be looked up. Check the Dependency Dashboard for more information. --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/pachli/pachli-android). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4zOTMuMCIsInVwZGF0ZWRJblZlciI6IjM3LjM5My4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
2024-06-13 23:40:28 +02:00
uses: actions/checkout@692973e3d937129bcbf40652eb9f2f61becf3332 # v4
ci: Fetch all revisions to calculate correct versionCode (#147) Previous configuration only fetched the most recent revision. Since the `orangeRelease` `versionCode` is calculated from the number of previous revisions this always set the `versionCode` to 1. Fetch all revisions to avoid this.
2023-10-09 17:49:15 +02:00
with:
fetch-depth: 0
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
ci: Simplify and improve CI speed (#615) Abstract common CI setup tasks (setting up Java, Gradle, etc) in to a single action that can be used by all CI workflows. Run the lint, test, and assemble CI tasks in parallel for each variant rather than in series, which cuts ~ 7 minutes (approx. 50%) off the CI runtime. Update code in checks and core/navigation to fix new tests.
2024-04-15 15:24:07 +02:00
- uses: ./.github/actions/setup-build-env
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
with:
ci: Simplify and improve CI speed (#615) Abstract common CI setup tasks (setting up Java, Gradle, etc) in to a single action that can be used by all CI workflows. Run the lint, test, and assemble CI tasks in parallel for each variant rather than in series, which cuts ~ 7 minutes (approx. 50%) off the CI runtime. Update code in checks and core/navigation to fix new tests.
2024-04-15 15:24:07 +02:00
gradle-cache-encryption-key: ${{ secrets.GRADLE_ENCRYPTION_KEY }}
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
- name: Test
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
run: ./gradlew app:testOrangeGoogleReleaseUnitTest --stacktrace
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
- name: Build APK
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
run: ./gradlew assembleOrangeGoogleRelease --stacktrace
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
- name: Build AAB
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
run: ./gradlew :app:bundleOrangeGoogleRelease --stacktrace
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
chore(deps): pin dependencies (#549) [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/checkout](https://togithub.com/actions/checkout) | action | pinDigest | -> `b4ffde6` | | [actions/github-script](https://togithub.com/actions/github-script) | action | pinDigest | -> `60a0d83` | | [actions/setup-java](https://togithub.com/actions/setup-java) | action | pinDigest | -> `99b8673` | | [actions/upload-artifact](https://togithub.com/actions/upload-artifact) | action | pinDigest | -> `5d5d22a` | | [gradle/actions](https://togithub.com/gradle/actions) | action | pinDigest | -> `417ae3c` | | [gradle/wrapper-validation-action](https://togithub.com/gradle/wrapper-validation-action) | action | pinDigest | -> `699bb18` | | [myrotvorets/set-commit-status-action](https://togithub.com/myrotvorets/set-commit-status-action) | action | pinDigest | -> `3730c0a` | | [r0adkll/sign-android-release](https://togithub.com/r0adkll/sign-android-release) | action | pinDigest | -> `dbeba6b` | | [r0adkll/upload-google-play](https://togithub.com/r0adkll/upload-google-play) | action | pinDigest | -> `935ef9c` | | [reviewdog/action-suggester](https://togithub.com/reviewdog/action-suggester) | action | pinDigest | -> `3d7fde6` | | [xt0rted/pull-request-comment-branch](https://togithub.com/xt0rted/pull-request-comment-branch) | action | pinDigest | -> `d97294d` | | [ytanikin/PRConventionalCommits](https://togithub.com/ytanikin/PRConventionalCommits) | action | pinDigest | -> `b7be921` | --- > [!WARNING] > Some dependencies could not be looked up. Check the Dependency Dashboard for more information. --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/pachli/pachli-android). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yNjEuMCIsInVwZGF0ZWRJblZlciI6IjM3LjI2MS4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
2024-03-21 13:10:59 +01:00
- uses: r0adkll/sign-android-release@dbeba6b98a60b0fd540c02443c7f428cdedf0e7f # v1.0.4
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
name: Sign app APK
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/orangeGoogle/release
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +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"
chore(deps): pin dependencies (#549) [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/checkout](https://togithub.com/actions/checkout) | action | pinDigest | -> `b4ffde6` | | [actions/github-script](https://togithub.com/actions/github-script) | action | pinDigest | -> `60a0d83` | | [actions/setup-java](https://togithub.com/actions/setup-java) | action | pinDigest | -> `99b8673` | | [actions/upload-artifact](https://togithub.com/actions/upload-artifact) | action | pinDigest | -> `5d5d22a` | | [gradle/actions](https://togithub.com/gradle/actions) | action | pinDigest | -> `417ae3c` | | [gradle/wrapper-validation-action](https://togithub.com/gradle/wrapper-validation-action) | action | pinDigest | -> `699bb18` | | [myrotvorets/set-commit-status-action](https://togithub.com/myrotvorets/set-commit-status-action) | action | pinDigest | -> `3730c0a` | | [r0adkll/sign-android-release](https://togithub.com/r0adkll/sign-android-release) | action | pinDigest | -> `dbeba6b` | | [r0adkll/upload-google-play](https://togithub.com/r0adkll/upload-google-play) | action | pinDigest | -> `935ef9c` | | [reviewdog/action-suggester](https://togithub.com/reviewdog/action-suggester) | action | pinDigest | -> `3d7fde6` | | [xt0rted/pull-request-comment-branch](https://togithub.com/xt0rted/pull-request-comment-branch) | action | pinDigest | -> `d97294d` | | [ytanikin/PRConventionalCommits](https://togithub.com/ytanikin/PRConventionalCommits) | action | pinDigest | -> `b7be921` | --- > [!WARNING] > Some dependencies could not be looked up. Check the Dependency Dashboard for more information. --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/pachli/pachli-android). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yNjEuMCIsInVwZGF0ZWRJblZlciI6IjM3LjI2MS4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
2024-03-21 13:10:59 +01:00
- uses: r0adkll/sign-android-release@dbeba6b98a60b0fd540c02443c7f428cdedf0e7f # v1.0.4
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
name: Sign app AAB
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/orangeGoogleRelease
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +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
chore(deps): update actions/upload-artifact digest to 0b2256b (#843) [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/upload-artifact](https://togithub.com/actions/upload-artifact) | action | digest | `6546280` -> `0b2256b` | --- > [!WARNING] > Some dependencies could not be looked up. Check the Dependency Dashboard for more information. --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 🔕 **Ignore**: Close this PR and you won't be reminded about this update again. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR was generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View the [repository job log](https://developer.mend.io/github/pachli/pachli-android). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy40NDAuNyIsInVwZGF0ZWRJblZlciI6IjM3LjQ0MC43IiwidGFyZ2V0QnJhbmNoIjoibWFpbiIsImxhYmVscyI6W119--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
2024-07-31 15:56:22 +02:00
uses: actions/upload-artifact@0b2256b8c012f0828dc542b3febcab082c67f72b # v4
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
with:
name: app-release.apk
path: ${{steps.sign_app_apk.outputs.signedReleaseFile}}
ci: Don't compress APK files when uploading release artifacts (#496) They're already compressed, and it slows down the workflow step.
2024-03-04 14:53:34 +01:00
compression-level: 0
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
- name: Generate whatsnew
id: generate-whatsnew
run: |
mkdir -p googleplay/whatsnew
git log -1 --pretty=format:"%s" > googleplay/whatsnew/whatsnew-en-US
- name: Upload AAB to Google Play
id: upload-release-asset-aab
chore(deps): pin dependencies (#549) [![Mend Renovate](https://app.renovatebot.com/images/banner.svg)](https://renovatebot.com) This PR contains the following updates: | Package | Type | Update | Change | |---|---|---|---| | [actions/checkout](https://togithub.com/actions/checkout) | action | pinDigest | -> `b4ffde6` | | [actions/github-script](https://togithub.com/actions/github-script) | action | pinDigest | -> `60a0d83` | | [actions/setup-java](https://togithub.com/actions/setup-java) | action | pinDigest | -> `99b8673` | | [actions/upload-artifact](https://togithub.com/actions/upload-artifact) | action | pinDigest | -> `5d5d22a` | | [gradle/actions](https://togithub.com/gradle/actions) | action | pinDigest | -> `417ae3c` | | [gradle/wrapper-validation-action](https://togithub.com/gradle/wrapper-validation-action) | action | pinDigest | -> `699bb18` | | [myrotvorets/set-commit-status-action](https://togithub.com/myrotvorets/set-commit-status-action) | action | pinDigest | -> `3730c0a` | | [r0adkll/sign-android-release](https://togithub.com/r0adkll/sign-android-release) | action | pinDigest | -> `dbeba6b` | | [r0adkll/upload-google-play](https://togithub.com/r0adkll/upload-google-play) | action | pinDigest | -> `935ef9c` | | [reviewdog/action-suggester](https://togithub.com/reviewdog/action-suggester) | action | pinDigest | -> `3d7fde6` | | [xt0rted/pull-request-comment-branch](https://togithub.com/xt0rted/pull-request-comment-branch) | action | pinDigest | -> `d97294d` | | [ytanikin/PRConventionalCommits](https://togithub.com/ytanikin/PRConventionalCommits) | action | pinDigest | -> `b7be921` | --- > [!WARNING] > Some dependencies could not be looked up. Check the Dependency Dashboard for more information. --- ### Configuration 📅 **Schedule**: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined). 🚦 **Automerge**: Disabled by config. Please merge this manually once you are satisfied. ♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox. 👻 **Immortal**: This PR will be recreated if closed unmerged. Get [config help](https://togithub.com/renovatebot/renovate/discussions) if that's undesired. --- - [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check this box --- This PR has been generated by [Mend Renovate](https://www.mend.io/free-developer-tools/renovate/). View repository job log [here](https://developer.mend.io/github/pachli/pachli-android). <!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzNy4yNjEuMCIsInVwZGF0ZWRJblZlciI6IjM3LjI2MS4wIiwidGFyZ2V0QnJhbmNoIjoibWFpbiJ9--> Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
2024-03-21 13:10:59 +01:00
uses: r0adkll/upload-google-play@935ef9c68bb393a8e6116b1575626a7f5be3a7fb # v1.1.3
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
with:
serviceAccountJsonPlainText: ${{ secrets.PLAY_SERVICE_ACCOUNT_KEY }}
packageName: app.pachli.current
releaseFiles: ${{steps.sign_app_aab.outputs.signedReleaseFile}}
ci: Upload Pachli Current to the production track (#142)
2023-10-07 14:59:20 +02:00
track: production
ci: Upload orangeRelease to Google Play (internal track) (#134) Start building infrastructure to automatically build and deploy the `orangeRelease` variant to Google Play. The variant needs an automatically incrementing `versionCode`. That is derived from the count of all commits. Change the separator between the version and the build metadata in the `versionName` from `-` to `+` to be consistent with semantic versioning. This is still an experiment, so the workflow is triggered manually and only uploads to the internal track
2023-09-28 13:50:02 +02:00
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/orangeGoogleRelease/mapping.txt