A mobile application build for DWR & UDOT for users to submit reports about roadkill.
.env
files in <root>
, src/front
, and src/back
src/front
and src/back
:
npm install
npm start
npm test
Press "j" in console after starting expo project. See Expo Debugging & Profiling docs for more details.
npx uri-scheme open exp://127.0.0.1:19000/--/main --ios
npx uri-scheme open exp://127.0.0.1:19000/--/main --android
git branch | app version | runtime version | deployed | release-channel | expo version |
---|---|---|---|---|---|
dev | 3.0.9 | 3.1.0 | custom dev clients for simulators are in src/front/dev-clients , app has an orange icon (dev clients for for physical devices can be installed directly from the expo build website) |
default | 50 |
staging | 3.0.9 | 3.1.0 | TestFlight and Google Play internal testing separate apps from production with a blue icon | staging | 50 |
production | 3.0.9 | 3.1.0 | App Stores | production | 50 |
These three environments are three separate bundle IDs (see src/front/app.config.js
) and can all be installed on the same device simultaneously.
If you need to change something that requires a new app build (e.g. changes to app.config.js
or any other native code library update), bump the runtimeVersion
prop in app.config.js
to keep it on a new release channel thus preventing conflicts with older app builds. expo-update
will only download updates with matching app version numbers because we are using the "Custom runtimeVersion" runtime policy.
These values are managed in three places: .env.*
files in your local project, GitHub Actions Secrets (for back end deployments), and Expo EAS Secrets.
These values are managed in GCP Secrets Manager. After running the terraform, make sure to populate versions for the secrets that it creates. Also create corresponding secret files in src/back/secrets/<secret_name>/value
for local development.
PROJECT_ID
IDENTITY_PROVIDER
& SERVICE_ACCOUNT_EMAIL
EXPO_USERNAME
/ EXPO_PASSWORD
.env.*
files in their corresponding repo environments as secrets for the back end. Do the same thing for the front end only the secrets go in Expo EAS.
base64 -i GoogleService-Info.plist
)measurementId
config for the FIREBASE_MEASUREMENT_ID
env variable./data
: ./start_cloud_sql_proxy.sh prod
(or dev
) (This need so to be done for each environment per release!)src/front
: npm run update-constants
(may need to update the db connection props in .env
)version
in app.config.js) needs to be bumped. Apple requires it to be bumped after every production release.runtimeVersion
needs to be bumped (if any native code has changed).npm run changelog
release: v3.0.0 (123)
)git tag v3.0.0-123
staging
or production
will push a new image to the cloud run back end.Do one of the following from src/front
:
./scripts/deployNewAppBuild.sh
if a new app build is needed.
or
runtimeVersion
was bumped):
./scripts/deployOTAUpdate.sh
to publish a new over-the-air update.This app uses a custom Expo Dev rather than the old Expo Go app. This means that anytime you install or upgrade a library with native code, you need to create new builds by running ./scripts/buildForDevelopment.sh
.
After testing in dev client...
src/front
: ./scripts/deployNewAppBuild.sh
Because app builds initiate from both the developer's machine (new native builds) and GitHub Actions (over-the-air updates), secrets need to be managed in both places. .env.sample
should be duplicated and populated to .env
, .env.staging
, .env.production
. Corresponding secrets are also stored in environments in the GitHub repository.
Android Devices (Internal Testing): Production | Staging. Accounts need to be added to the "Wildlife-Vehicle Collisions" tester group before they can join the test.
iOS Devices (TestFlight): Production | Staging
Facebook Test Account:
email: open_vboxopy_user@tfbnw.net
password: tester
The back end of this application uses firebase firestore and storage emulators during local development. Go to http://localhost:4000 to see the UI for them.
iOS: Trip Simulator
Initial Database Design Diagram - This has been replaced by data/sql/init.sql as the single source of truth for the design.
Database migrations are managed via knex from the ./data
folder. Run knex migrate:make <migration-name>
to create a new one.
These are the images that show up next to the species/class/order/family names. They are stored in a bucket named ut-dts-agrc-roadkill-[dev|prod]-identification-images
. Members of the gcp-dts-ugrc-roadkill-viewers
Google Group have object admin level access to the bucket. The images should be uploaded with the file extension: .jpg
and sized 150
by 150
pixels.
The file name should match a distinct value from one of the following columns in the species
table:
species_id
species_class
species_order
family
If a matching file in the bucket is not found, a blank gray fallback image is returned.