feat: create new dev-orange variant #855
Conversation
boringcactus
added
deploy to android dev-orange
| - synchronize | ||
| - labeled | ||
| schedule: | ||
| - cron: "13 12 * * MON" |
There was a problem hiding this comment.
question (non-blocking): Why different cron than backend?
There was a problem hiding this comment.
I picked these times arbitrarily, and then I picked the backend times with more attention to normal working hours just in case something goes wrong, and then I did not update these to match that.
| @@ -38,7 +38,7 @@ fun MoreSectionView(section: MoreSection, toggleSetting: ((Settings) -> Unit)) { | |||
|
|
|||
| val note = section.note | |||
|
|
|||
| if (!(section.requiresStaging && appVariant != AppVariant.Staging)) { | |||
There was a problem hiding this comment.
suggestion (non-blocking): Might be worth renaming requiresStaging at this point too. We could invert to requiresProd
| track: 'internal' | ||
| ).max | ||
| rescue Exception => e | ||
| unless e.message == "Google Api Error: Invalid request - Package not found: #{package_name}." |
There was a problem hiding this comment.
question (non-blocking): Is this just temporary handling until the app is added?
There was a problem hiding this comment.
This required a temporary workaround when we created the staging app, it requires a temporary workaround now, and it will require a temporary workaround in the not inconceivable future where we want dev-silver. I don’t think it increases the maintenance burden to leave it in long-term.
| ipa: 'iosApp/build/iosApp.ipa', | ||
| distribute_external: true, | ||
| changelog: '', | ||
| groups: ['Dev Orange Users'] |
There was a problem hiding this comment.
question(non-blocking): Is there a reason we'd want to manage this group separately from our existing groups? Wondering if we only need one group with access to all non-prod apps for simplicity
There was a problem hiding this comment.
It doesn’t look like TestFlight groups carry over from one app to another.
|
I figured separate labels would be easier, but apparently adding two labels to a PR at the same time is simultaneously non-atomic (each workflow runs twice) and atomic (all four runs see both labels as having already been added). If we have a combined label, the logic for the scheduled deploys gets a lot more complicated, so it’s probably easier to make the second runs cancel the first runs. |
boringcactus
removed
deploy to android dev-orange
Summary
Ticket: iOS & Android dev orange apps
I’m really glad we worked on managing the Xcode project first; this was easy.
Deploys to Android won’t work until the Android console listing is created; I’ve filed the infra request for that.
iOS
[ ] If you added any user-facing strings on iOS, are they included in Localizable.xcstrings?[ ] Add temporary machine translations, marked "Needs Review"android
[ ] All user-facing strings added to strings resource in alphabetical order[ ] Expensive calculations are run inwithContext(Dispatchers.Default)where possible (ideally in shared code)Testing
Checked that the new apps have the right name and icon, and that alerts shown in staging are not visible in dev-orange.
Checked that iOS deploys work now and Android deploys will probably work once the Google Play console is set up.