[HOLD for payment 2024-06-20] [HOLD for payment 2024-06-18] [HOLD for payment 2024-06-13] [HybridApp] Problem #5: Deploy the HybridApp more regularly

[AndrewGable]

Problem

We ship changes to the New experience much faster than we ever had for the Old experience. This means that bugs are fixed much faster and we need to deploy the HybridApp on a faster cadence than we have historically deployed the Expensify iOS/Android app.

We should deploy the HybridApp on the same cadence (daily on Monday-Friday) as we deploy the New Expensify app. Every time we deploy the New Expensify app to web and desktop, we should also run the same deploy to the Expensify HybridApp on iOS and Android.

As discussed in the predesign, for the V1 we’ll automatically deploy HybridApp to staging with every NewDot staging deploy. However, for now we’ll only deploy HybridApp to production manually on an ad-hoc/weekly basis. Once we have some stable releases done, we’ll likely reopen the conversation for how to automatically deploy HybridApp to production on a daily basis.

Solution

Mobile-Deploy Background

For some background, the existing deploy workflow for the Expensify Classic mobile app lives in the Mobile-Deploy repo. Like all GitHub Workflows, it’s triggered by events:

• workflow_dispatch – this allows you to manually trigger the workflow from the GitHub Actions console (open-source example). Furthermore, it allows you to specify some inputs to the workflow

• schedule – this uses cron syntax to specify a cadence at which the workflow should run

More specifically, the Expensify Classic deploy workflow is set up to run every day at 6pm UTC, and when run manually it accepts 4 optional inputs.

Making Mobile-Deploy callable

In order to hook this up with the NewDot deploy cycle, the first thing we’ll need to do is make the Mobile-Deploy GitHub Workflow a callable workflow. This will enable it to be triggered programmatically from other workflows. Fortunately, this is simple to achieve:

1. First, add the workflow_call event trigger to the workflow

2. Duplicate all the inputs of workflow_dispatch for the workflow_call trigger. (no, the inputs cannot be shared between these two event triggers)

Calling Mobile-Deploy from E/App

Next, we’ll need to call the Mobile-Deploy workflow from within the existing New Expensify deploy workflows. The simplest way to do this will be to just add one more job to the existing platformDeploy workflow (for staging deploys only, for now).

Note that in order to call a workflow from another repo, we need to use the full repo slug instead of a relative path.

Deployer permissions

In order for this to work, we’ll need to give OSBotify access to the Mobile-Deploy repo, or else he won’t be able to trigger callable workflows in Mobile-Deploy.

Furthermore, we should also add some basic validation to verify that any caller of the Mobile-Deploy workflow is indeed a mobile deployer. To do this, we can:

1. Extract the existing validateActor job into a callable workflow within E/App.

2. Call that workflow from Mobile-Deploy as the first job in the workflow, and if the user is not found to be a mobile deployer, skip all subsequent jobs.

Syncing versions

In order to make bug tracking easier across HybridApp and NewDot, we’ll keep the versions in-sync. In order to do this, we’ll first create a PR to update the HybridApp version to 9.0.0.0 in order to make it clear we have a major update. Then we will manually update the NewDot version to match the current HybridApp version (9.0.0.0).

Then, we’ll update Mobile-Deploy’s deploy.yml workflow to accept a version string as an input, and pass that to Mobile-Expensify’s shell script to bump the app version. Then when triggering the HybridApp deploy from NewDot, we’ll pass the current NewDot version.
That way, the versions of HybridApp and NewDot will always be in sync, and it’s easy to reconcile bug reports coming from either app (though generally, most bug reports should be coming from HybridApp, while the bulk of the source code comes from NewDot).

Issue Owner

Current Issue Owner: @AndrewGable

[roryabraham]

haven't jumped into this yet, but I'm adding something to this issue which we discussed in slack:

My thought was we should run automation to keep the submodule hash in sync with the current App hash. So whenever the commit hash is updated on main, staging or production on App, we have automation that updates the hash in Mobile-Expensify/react-native to that hash

[roryabraham]

One way to do this, rather than some kind of GitHub Action, would be to use git hooks

edit: nah, don't think it's a great idea because it's less configurable for local workflows. It would make it difficult to checkout whatever combination of branches you want

[AndrewGable]

I think the nice thing about storing the latest commit hash of main automatically in the submodule is it will be treated like any other file tracked in git.

Additionally, we can get rid of the npm run submodule-update script

[melvin-bot]

This issue has not been updated in over 15 days. @roryabraham eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!