Open vargajacint opened 1 month ago
Here are some logs from the GitHub Action
... fingerprint generation
{"hash":"4961a8e1e410721c5dca3b1ded6a0e8c49fc9462"}}],"hash":"b1f4f9c5fcf7730b0c212f190c84efacf92bca6f"}
Android fingerprint: 2cffbffcbf2a653286afec2f359d4db392173849 # ✅ -> It's okay, as we see before I already had some builds that fingerprint was this
iOS fingerprint: b1f4f9c5fcf7730b0c212f190c84efacf92bca6f # ✅ -> It's okay, as we see before I already had some builds that fingerprint was this
Looking for builds with matching runtime version (fingerprint)...
/opt/hostedtoolcache/eas-cli/9.1.0/x64/node_modules/.bin/eas build:list --platform android --status finished --buildProfile preview --runtimeVersion 2cffbffcbf2a653286afec2f359d4db392173849 --limit 1 --json --non-interactive
[] # -> 🔴 The problem is that this script looking for **build** with this fingerprint, but somehow the build fingerprint is not same as it was calculated
No existing Android build found for fingerprint, starting a new build...
/opt/hostedtoolcache/eas-cli/9.1.0/x64/node_modules/.bin/eas build --profile preview --platform android --non-interactive --json --no-wait --build-logger-level debug
[
{
...
"id": "cb3bf3c9-ad88-407b-88a5-88d60e8ce116",
"channel": "testpreview",
"distribution": "INTERNAL",
"buildProfile": "preview",
"sdkVersion": "51.0.0",
"appVersion": "0.1.9",
"appBuildVersion": "1",
"runtimeVersion": "4db5b01cb43bc22b8b1ed847d4019db600c5537d", # -> 🔴 WHY?
"gitCommitHash": "f181a8507f134ec947fcbdb9649b1307955ddf48",
"gitCommitMessage": "test: js only change"
}
]
I just experienced the same. The issue (at least in my case) was that the environment variables set in the eas.json were not identical to those set in the update. Before, my GitHub Action contained this command:
EXPO_APP_ENV="preview" eas update --branch preview --auto --non-interactive
Unfortunately, I currently have no idea how to set my environment variable for updates within continuous-deploy-fingerprint. I'll have to look into this deeper or maybe someone can help.
If your issue is different, ignore my solution. Maybe it helps someone else then. :)
Hi @daniel-xyz
I had the exactly same problem (env mismatch). Here is some tips from @Kudo
published
@expo/fingerprint@0.9.0
that supportfingerprint.config.js
to ignore app.json version from fingerprint, you could try adding fingerprint.config.js with the following content
const { SourceSkips } = require('@expo/fingerprint');
/** @type {import('@expo/fingerprint').Config} */
const config = {
sourceSkips: SourceSkips.ExpoConfigRuntimeVersionIfString | SourceSkips.ExpoConfigVersions,
};
module.exports = config;
i didn't update the dependency inside expo-updates, so please try that first by using yarn resolutions or something.
Oh, sorry that I couldn't help, then. 😅 I meant I still have to set the environment variable somehow, anyway. It's not just about fingerprinting. But maybe it's more of a GitHub Actions problem I can figure out (edit: I did, lol).
At least I can confirm that I get the same fingerprints now (if the variables are the same), so I can't reproduce your error.
I can confirm it is still an issue, even forcing to the latest version of the related packages.
"@expo/config-plugins": "^8.0.5",
"@expo/fingerprint": "^0.9.0",
"expo-updates": "~0.25.17",
Reproducible by simply re-running the workflow without any changes, always generate new builds.
I'm also seeing Runtime Version as "file:fingerprint" on dev client, have you experienced it @vargajacint?
Ok, looks like the fingerprint check has been fixed on "@expo/fingerprint": "^0.10.0"
!
Still seeing file:fingerprint
on dev client btw.
Description of the bug
Using the continuous-deploy-fingerprint GitHub Action produces different hash for builds and updates. Moreover, introducing js only changes in the code creates a new EAS build every time, and I think the issue is related.
To Reproduce
diff
).Expected behavior
Do not generate a new EAS build if it's not needed. Generate EAS update only for JS-only change. Match the EAS build runtime-version with the EAS update runtime-version.
Actual behavior
The EAS build is always triggered, even if it's completely unnecessary. The EAS build runtime version is completely different than the EAS update runtime version
As you can see, the update runtime-version is completely different from the build-runtime version (red and blue arrows), even though they were triggered by the same action. As you can see the build runtime-version was always the same per platform. So I don't get why new build was triggered then.