Add beta-internal and release-internal track ideas

This is so that beta and release versions can be installed side-by-side (using the *-internal versions) on a test device, while when submitting to the app stores, they will all have the same package identifier so you can do the normal one-app with multiple tracks paradigm.

.github/workflows/build-cloud.yml

@@ -27,7 +27,9 @@ on:
                 options:
                     - developer
                     - alpha
+                    - beta-internal
                     - beta
+                    - release-internal
                     - release
 
 jobs:

.github/workflows/build-local.yml

@@ -10,7 +10,9 @@ on:
                 options:
                     - developer
                     - alpha
+                    - beta-internal
                     - beta
+                    - release-internal
                     - release
     workflow_call:
         inputs:

.github/workflows/publish.yml

@@ -33,6 +33,7 @@ on:
                     - alpha # Android's "Internal Test" or iOS "Internal Distribution". Not sure if there's much need for the iOS version of this.
                     - beta # Android's "Open Test" or iOS "TestFlight"
                     - release # self-explanatory
+                    # Definitely no need for beta-internal or release-internal for the publish workflow. The *-internal channels are designed only for device testing
 
     workflow_call:
         inputs:

.gitignore

@@ -16,3 +16,5 @@ node_modules
 *.njsproj
 *.sln
 *.sw?
+
+secrets

.vscode/settings.json

@@ -14,5 +14,11 @@
         "statusBar.noFolderBackground": "#008000",
         "statussBar.prominentBackground": "#008000"
     },
-    "cSpell.words": ["bloombooks", "bloomplayer", "Daiwi", "Ionicons"]
+    "cSpell.words": [
+        "bloombooks",
+        "bloomplayer",
+        "Daiwi",
+        "Ionicons",
+        "bloomreaderlite"
+    ]
 }

packages/mobile/app.config.js

@@ -51,8 +51,10 @@ function getAppName() {
         case "alpha":
             return `${baseAppName} (Alpha)`;
         case "beta":
+        case "beta-internal":
             return `${baseAppName} (Beta)`;
         case "release":
+        case "release-internal":
         case undefined:
             return baseAppName;
         default:
@@ -69,12 +71,27 @@ function getPackageIdentifier() {
     const basePackageIdentifier = "org.sil.bloomreaderlite";
     switch (releaseChannel) {
         case "developer":
+        case "beta-internal":
+        case "release-internal":
+            // The purpose of this is to allow side-by-side installation on test devices,
+            // but when publishing to the app stores (regardless of whether on internal or TestFlight or production),
+            // we want it to all have the same package identifier.
+            // (Well, at least if you want to use the single-app model that the app stores try to point you to.
+            // If you want to have a multi-app model where each track is its own app then obviously they should
+            // all have their own package identifier)
+            return `${basePackageIdentifier}.${releaseChannel.replaceAll(
+                "-",
+                "."
+            )}`; // FYI, android package identifiers cannot contain "-"
         case "alpha":
         case "beta":
-            return `${basePackageIdentifier}.${releaseChannel}`;
         case "release":
         case undefined:
-            return basePackageIdentifier;
+            // Eventually we want it to return basePackageIdentifier when we're ready for the real thing,
+            // but right now we use "org.sil.bloomreaderlite.preview" instead to make sure we don't
+            // accidentally mess anything up on our real desired package identifier
+            //return basePackageIdentifier;
+            return "org.sil.bloomreaderlite.preview";
         default:
             console.warn("Unknown releaseChannel " + releaseChannel);
             return basePackageIdentifier;

packages/mobile/eas.json

@@ -21,18 +21,67 @@
                 "RELEASE_CHANNEL": "alpha"
             }
         },
+        "beta-internal": {
+            // Intended for testing the beta build on a local device (side-by-side OK)
+            "channel": "beta-internal",
+            "env": {
+                "RELEASE_CHANNEL": "beta-internal"
+            }
+        },
         "beta": {
-            // Intended for "TestFlight" (iOS) or "Open test" (Android)  (or "Closed test" is probably fine too)
+            // Intended for "TestFlight" (iOS) or "Open test" (Android)
             "channel": "beta",
             "env": {
                 "RELEASE_CHANNEL": "beta"
             }
         },
+        "release-internal": {
+            // Intended for testing the beta build on a local device (side-by-side OK)
+            "channel": "release-internal",
+            "env": {
+                "RELEASE_CHANNEL": "release-internal"
+            }
+        },
         "release": {
-            "channel": "release"
+            "channel": "release",
+            "env": {
+                "RELEASE_CHANNEL": "release"
+            }
         }
     },
     "submit": {
-        "release": {}
+        // Reference: https://docs.expo.dev/submit/eas-json/
+        "alpha": {
+            "android": {
+                // The service account key was provided directly to Expo. See https://stackoverflow.com/a/77018383
+                "track": "internal" // We picked "internal" instead of "alpha" (Closed Testing) because internal doesn't require waiting for App Review.
+            },
+            "ios": {
+                "appleId": "TODO",
+                "ascAppId": "TODO",
+                "appleTeamId": "TODO",
+                "companyName": "SIL International"
+            }
+        },
+        "beta": {
+            "extends": "alpha",
+            "android": {
+                "track": "beta"
+            },
+            "ios": {
+                // TODO: Figure out how to submit to TestFlight vs submitting to production.
+                // Read https://levelup.gitconnected.com/react-native-how-to-publish-an-expo-app-to-testflight-debug-common-errors-90e427b4b5ea
+            }
+        },
+        "release": {
+            "extends": "alpha",
+            "android": {
+                "track": "production"
+            },
+            "ios": {
+                // TODO: Figure out how to submit to TestFlight vs submitting to production.
+                // Read https://levelup.gitconnected.com/react-native-how-to-publish-an-expo-app-to-testflight-debug-common-errors-90e427b4b5ea
+            }
+        }
     }
 }