eas build with gitignored google-services.json file. #228
Comments
|
It'd be nice to extend |
|
I have a similar issue, I'm using aws amplify which downloads a file |
|
Hi guys, You don't need to commit the gitignored files to the repo. Here's a workaround (assuming you want your build to have access to google-service.json):
|
|
@dsokal is this still the recommended way to handle this situation? I'm using amplify and also have the aws-exports.js file someone else mentioned above. This file changes based on changes we make to the backend so it's somewhat dynamic so we'd need to update it's eas secret value often. I would much rather prefer to be able to include the latest version of this file in the build vs it being ignored by eas because it's in the .gitignore. Thank you! |
|
Hey @diegoconcha, |
|
@diegoconcha If you are using default git workflow (you don't have Note that if easignore is present, gitingore files are not respected(even in subdirectories) and there can only be one |
Thanks @wkozyra95 for your reply. The challenge with this approach is now we have to keep two ignore files up-to-date ( |
Hi @diegoconcha or @everyone here! I am currently on the process of |
|
If it's a secret it should be passed via EAS Secrets (base64 route), but if I understand correctly |
Hey @AllanBengco we went the .easignore route. Ours is a copy of our .gitignore without the aws-exports.js so that the aws-exports.js is included in the build. This file only has routes and high level config of our backend so mostly stuff that's already easy to figure out by analyzing network traffic on the device or using our app. Essentially nothing we're worried about exposing but take a detailed look yourself. Like @wkozyra95 said, the aws-exports.js is part of the js bundle after the app is built. As a result, it can also be replaced via an OTA update (eas update or expo updates). We updated our app via eas update and accidentally pointed our prod users to our dev backend for a short period of time so heads up @AllanBengco. |
Thank you @diegoconcha for your inputs! I experimented with the base64 route, and was able to build my app successfully. Based on your comment, I realized that the one good thing about encoding |
@AllanBengco when the app is built, the base64 method creates the aws-exports.js file so you still have the same issue if you do an expo or eas update since the file is still created and part of the js bundle. EAS Secrets is really only protecting build-time secrets and it isn't used at run-time which is when the aws-exports.js is used and where it can be modified by doing an over-the-air update. By using the base64 + EAS Secrets approach now you have to remember to update the secret if anything on your amplify backend changes like the userpool id. So you're adding an extra step but don't have the protection you think you have. |
What I did was to manually create the base64 file and save this in Secrets. Then, add a pre-build script so that what is stored in Secrets is decoded and saved as
I was under the impression that this would basically decode what is already in the Secrets and save it as |
You're correct but you are missing my point. As part of the build process, the aws-exports.js gets created and is present in the built bundle. More precisely it lives in the JS bundle which can be overwritten by an OTA update (this is the magic of OTA updates replacing the JS bundle). If you don't do or plan to do OTA updates then you're fine but most people using expo do OTA updates to get hot fixes out quickly without waiting for app store approval in which case you can accidentally overwrite the aws-exports.js that was built from the secret with whatever you have locally when you create the OTA update. |
I Don't know if this is expected behavior but if I have my app.json{
"expo": {
"name": "Ping for Gitlab",
"owner": "zaniluca",
"slug": "ping4gitlab",
"version": "1.0.0",
"orientation": "portrait",
"icon": "./assets/icon.png",
"splash": {
"image": "./assets/splash.png",
"resizeMode": "contain",
"backgroundColor": "#ffffff"
},
"updates": {
"fallbackToCacheTimeout": 0
},
"assetBundlePatterns": ["**/*"],
"ios": {
"bundleIdentifier": "con.zaniluca.ping4gitlab",
"googleServicesFile": "./GoogleService-Info.plist",
"supportsTablet": false
},
"android": {
"googleServicesFile": "./google-services.json",
"package": "con.zaniluca.ping4gitlab",
"adaptiveIcon": {
"foregroundImage": "./assets/adaptive-icon.png",
"backgroundColor": "#FFFFFF"
}
},
"plugins": ["@react-native-firebase/app"]
}
}EAS Error message when building ios› Copying ios/PingforGitlab/Supporting/Expo.plist ➜ ./Expo.plist
› Compiling PingforGitlab » SplashScreen.storyboard
› Copying ios/PingforGitlab/GoogleService-Info.plist ➜ ./GoogleService-Info.plist
❌ error: Build input file cannot be found: '/Users/expo/workingdir/build/ios/PingforGitlab/GoogleService-Info.plist' (in target 'PingforGitlab' from project 'PingforGitlab')The solution I adopted is this: echo $GOOGLE_SERVICES_ANDROID_BASE64 | base64 --decode > ./android/app/google-services.json && echo $GOOGLE_SERVICES_IOS_BASE64 | base64 --decode > ios/PingforGitlab/GoogleService-Info.plistIs there anything that I'm doing wrong |
|
@zaniluca app.json values that configure native code are ignored if you are ejected. I checked your last few builds and they are all bare workflow, if ejecting was not intentional you can just delete or gitiingore android and ios directories |
Oh really? I'm using a custom development client, I didn't know it was the same as ejecting. Thanks for pointing it out😅 |
It's not the same, you can use a custom dev client without ejecting. Most likely you ejected by running |
Yea I had to run |
|
I've tried following both versions of how to upload the secrets and am still getting errors, and am wondering if anyone has succeeded in fixing them, or could provide some extra help. When trying the .easignore version I created a base level .easignore and set its contents to the same as my .gitignore, but with the aws-exports and google services files negated as below This didn't fix the original issue or change anything at all in the built, and gave the same results as not doing this, getting then, during the gradlew and fastline build processes in android and iOS respectively So I moved onto the secrets route After base64'ing my aws-exports and google-services.json, creating eas secrets from them named GOOGLE_SERVICES and AWS_EXPORTS with that output via eas secret:create, then adding the following pre-install script in package.json
I am now getting this error in both the Xcode Logs for iOS, and in the gradlew logs for Android
Seems to me like it now recognizes that the files exist, but isn't able to read from them and I am unsure as to why. Obviously const is a valid kwarg in js, and the first thing appearing in aws-exports. I would love any direction on how to fix if anyone has suggestions, thanks in advance! |
|
Lots of comments, it'd be great to have a mini tutorial how to handle this situation in the Expo's docs. |
@ShepSims in js yes, but you created json file
@danieldanielecki It works the same as in every other CI service
|
|
Not completely related, but in case this helps anyone who is struggling with multiple amplify envs I have been doing this:
Which runs the following node script: In summary, you still have to update the secrets as your backend changes but at least you can build for multiple envs as required. For referenece - I was initially running the following script - but had issues with it not working for Play store builds (it works fine for iOS), probably not escaping some variable or something?
|
|
This should probably be upstreamed in amplify react native repo |
|
I have a related case - I use tailwind-rn for styles, so I constantly have unexpected changes to cc/ @diegoconcha as you mentioned having to keep two files up to date. tl;dr: generate your
|
|
In my project, I have decided to include .psd, .ai and mockups inside my assets folder, just to include all the extra files in my git’s monorepo. It has no sense to include .psd, .ai, or assets that are not displayed in the frontend, inside the native build. If I include all the relative paths to the unused assets in my .easignore file… Will those files be included by EAS build? ———————- Also, I have seen that in app.json we can include a list of glob patterns for assets (assetBundlePatterns). What’s the purpose for that field if we can ignore assets using .easignore? |
|
@VictorioMolina assetBundlePatterns defines what assets are bundled inside the app for classic builds and it's not doing anything for eas build. |
|
The following stackoverflow answer helped me resolve the issue: https://stackoverflow.com/questions/70906207/eas-build-fails-unable-to-resolve-module-aws-exports. |
|
The build hook links have been updated |
|
Surely the better solution these days is using eas file secrets https://docs.expo.dev/build-reference/variables/ e.g. add secret with name |
Just change the file from aws-exports.js to aws-exports.tsx and it will build It's okay if they are in the JS bundle if you're using AWS authenticator with cognito because it only allows authenticated users to hit the apis. Just make your storage is set for only signed in users to upload, edit and delete |
eas secret:create --scope project --name GOOGLE_SERVICES_JSON --type file --value ./path/to/google-services.json
✔ Created a new secret GOOGLE_SERVICES_JSON on project @user/myproject.export default {
android: {
googleServicesFile: process.env.GOOGLE_SERVICES_JSON,
},
}; |
|
I gave up and just commited to the repo. This "service" never worked |
|
I used the eas secrets, but I only had app.json config file. So I manually had to create a app.config.js file. And then painstakingly, export all its variables in a js format from the json format, and was able to run the build after that. I did not delete the app.json file though. For example: The new app.config.js |
|
Here's what I'm using For cloud build (
For local build ( |
|
@anhtuan219 This works well for Another casualty of #2392 |
|
@melyux Yeah, after a while I noticed that this way doesn't work for That means we can set it like this right? or like this (absolute path version)? But sadly, none of those works, it always fails at the step Prebuild. When checking this carefully, I discovered that the native project (result of the prebuild step) isn't created in the project's root directory. Instead, eas created it in another directory. So, to fix this, we need to export the path that is relative to the directory where the prebuilds happen. You can use the parent directory selector ( equal to With those changes, my prebuild was successful, and my eas local build works. Here's the complete command that I'm using when running eas build local for android on linux And now you want to know exactly the directory where the prebuil step happens, after fixing this issue, I found that eas does log it to the console in the first steps (specifically step Hope this help!! |
|
@anhtuan219 I was able to get the files working with EAS Build |
|
Does the google-services.json file even need to be gitignored? The expo documentation says yes, but there are several posts on google groups and stack overflow that indicate that there's nothing sensitive in the file, and that it's included in the final build and can easily be extracted. |
and others
Hello, Great tool! enjoying using it a lot.
At the moment I am having to commit my
google-services.json&GoogleService-Info.plistfiles in order to allow the cloud-build to work properly but this seems a bit of a security risk?Ideally, I'd have these files reference in my
.gitignoreIs there any workaround to this scenario/issue?
Thank you!
The text was updated successfully, but these errors were encountered: