EAS Build is generating builds with different fingerprint from what it was supposed to #2615
Labels
Comments
giorgiofellipe
added
the
needs review
|
Also the GHA expo/expo-github-action/continuous-deploy-fingerprint does not calculate the same fingerprint as EAS Build does. As you can see on the following images the update was sent using the locally calculated fingerprint. Local calculated fingerprint EAS calculated fingerprint |
Is it possible that you have a dynamic app config that depends on env variables that have different values on GHA and EAS? 🤔 |
szdziedzic
added
eas update
eas build
and removed
needs review
|
@szdziedzic We do not have a dynamic app config, currently using app.json actually. Does EAS consider only EXPO_PUBLIC_ env vars? Our CI pipeline generates a .env file from all EXPO_PUBLIC_ env vars. For reference: |
|
EAS CLI does not work with The one pretty confusing thing is that under the hood EAS Update does So there is a different env vars handling behavior for EAS Update and EAS Build and Expo CLI as of today, which may lead to some issues in some cases, caused by env vars mismatch in different places, what can be the root cause of your problems? We are aware of the issue and are working towards making it better and plan to announce new env variables enhancements really soon. However, until this is done I believe the best thing you can do is to try to get the env vars to be set the same way in all of these places. Let me know if you have any more questions regarding this matter. When it comes to handling fingerprint mismatch we had an internal discussion about it. It feels like creating a successful build with fingerprint coming from either local (from EAS CLI) or remote (from our cloud builder) sources, when there is fingerprint mismatch between these, seems to have disadvantages and may lead users to end up in non-explicit failure state, where it's ultra hard or impossible to get build to receive updates properly. As of today, we are leaning towards always explicitly failing the build when such a mismatch occurs, to make it obvious that something is broken and needs to be fixed. We shall make the change to enforce it soon. I will post updates here when it happens. |
|
@szdziedzic I really appreciate the detailed explanation about the differences between them. However, I'm still confident that there is something else, cuz it does not make sense to be only env var mismatch between environments. - name: Create env file
run: |
> .env
echo '${{ toJson(vars) }}' | jq -r 'to_entries | .[] | select(.key | startswith("EXPO_PUBLIC_")) | "\(.key)=\(.value)"' >> .env
cat .env
- name: Setup EAS
uses: expo/expo-github-action@v8
with:
eas-version: latest
packager: npm
token: ${{ secrets.EXPO_TOKEN }}
- name: Install Dependencies
run: pnpm install
- name: Push .env file to EAS
run: eas secret:push --env-file=.env --scope project --force
- name: Get config file
env:
GOOGLE_SERVICES_BASE64: ${{ secrets.EAS_GOOGLE_PLAY_API_FILE_BASE64 }}
run: |
echo $GOOGLE_SERVICES_BASE64 > google-service-account.json.b64
base64 -d -i google-service-account.json.b64 > google-service-account.json
- name: Build & Generate OTA Update
id: build
uses: expo/expo-github-action/continuous-deploy-fingerprint@main
with:
working-directory: ./monorepo/apps/mobile
profile: ${{ github.ref == 'refs/heads/master' && 'production' || 'staging' }}
branch: ${{ github.ref == 'refs/heads/master' && 'production' || 'staging' }}Also, the real issue is that the EAS Build calculates a different fingerprint and sticks to it instead of using the one calculated locally (on the pipeline), it is exactly the opposite that the fingerprint mismatch warning says on EAS Build. The |
I believe this behavior was correct (I'm not saying that what the annotation was saying was accurate). The true fingerprint value for the cloud build was the one calculated for it in the cloud. It would be like cheating to take the local version (which is different) and say the fingerprint for this version is for sure the local version because in some cases, it wouldn't be compatible. However, the annotation seemed to be definitely wrong. We discussed it and it feels like in such a setup you have broken builds/updates setup even though your CI does not fail. We believe it's better to always explicitly fail on fingerprint mismatch to explicitly notice developers that something is wrong. This is the PR that was merged yesterday to achieve this: expo/eas-build#449.
Yeah, so here we still have an issue with not matching fingerprint on GHA <> EAS cloud and we need to debug it. Can you send me a link to your build? What is the difference between these 2 shown in logs? |
|
@szdziedzic https://expo.dev/accounts/bolddotorg/projects/bold/builds/22e19d9f-80dd-4ce7-940b-d77e0069cc26 The diff: |
|
This issue is stale because it has been open for 30 days with no activity. If there is no activity in the next 7 days, the issue will be closed. |
|
This issue was closed because it has been inactive for 7 days since being marked as stale. Please open a new issue if you believe you are encountering a related problem. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Build/Submit details page URL
No response
Summary
On EAS Build logs it shows me differences between the fingerprint calculated on my local machine (CI pipeline, actually) and the one calculated on EAS. But the message also says it will consider the one my local machine has calculated, but it is NOT true as you can see on the following screenshots.
The message I see on EAS:
The data I see on the generated build:
See that the first line says
Rev.: 93743147which is the first 8 characters of the runtime version got from expo-updates library.This is exactly the same as the runtime calculated on EAS.
But that message on EAS said it would generate it using the fingerprint calculated on my local machine, so it should print there
Rev.: 6157eee1instead.This way my updates will never match the runtime version. I'm basically not able to send any OTA Updates...
Managed or bare?
managed
Environment
expo-env-info 1.2.0 environment info:
System:
OS: macOS 13.5.1
Shell: 5.9 - /bin/zsh
Binaries:
Node: 20.16.0 - /usr/local/bin/node
Yarn: 1.22.19 - /usr/local/bin/yarn
npm: 10.8.1 - /usr/local/bin/npm
Managers:
CocoaPods: 1.15.2 - /opt/homebrew/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 23.2, iOS 17.2, macOS 14.2, tvOS 17.2, visionOS 1.0, watchOS 10.2
Android SDK:
API Levels: 26, 29, 30, 31, 32, 33, 34
Build Tools: 29.0.2, 29.0.3, 30.0.2, 30.0.3, 31.0.0, 32.0.0, 33.0.0, 33.0.1, 33.0.2, 34.0.0
System Images: android-30 | Google APIs ARM 64 v8a, android-33 | Google APIs ARM 64 v8a, android-33 | Google Play ARM 64 v8a, android-34 | Google APIs ARM 64 v8a
IDEs:
Android Studio: 2024.1 AI-241.18034.62.2411.12071903
Xcode: 15.2/15C500b - /usr/bin/xcodebuild
npmPackages:
@expo/metro-config: ~0.17.0 => 0.17.8
babel-preset-expo: ^11.0.8 => 11.0.14
expo: ~51.0.37 => 51.0.37
expo-router: ^3.5.15 => 3.5.23
react: 18.2.0 => 18.2.0
react-dom: 18.2.0 => 18.2.0
react-native: 0.74.1 => 0.74.1
react-native-web: ~0.19.6 => 0.19.12
npmGlobalPackages:
eas-cli: 7.6.2
Expo Workflow: managed
Error output
No response
Reproducible demo or steps to reproduce from a blank project
.
The text was updated successfully, but these errors were encountered: