eas-cli icon indicating copy to clipboard operation
eas-cli copied to clipboard

`eas update` in Github Actions breaking/blanking iOS app, but working fine locally

Open tsalama opened this issue 3 years ago • 13 comments

Build/Submit details page URL

https://expo.dev/accounts/sportual/projects/sportual/updates/bd4be917-dd05-4b5d-b362-f500f30064f7

Summary

Implementing eas update in Github actions is breaking my build by causing a blank screen to show up after the splash screen disappears quickly; I've never gotten it to work before by the way. However, running the same command locally on my M1 Max macOS machine with basically the exact same environment updates/starts up the app as expected. Note that eas build works just fine in the GH action and deploys a new staging/internal build as expected with no discrepancy locally. I'm really scratching my head as I've tried everything at this point and toyed with all types of configurations to get update to work.

For more context about my GH action:

  • Original runs-on was ubuntu-latest but I switched to macos-latest to match my local env; neither worked
  • Preceding steps include actions/checkout@v3, actions/setup-node@v3 with node-version 16.17.1, expo/expo-github-action@v8 with eas-version: latest. I tried both expo-version: latest and commenting that out and using my project's expo for eas update. Final step before the eas update --auto --platform all --non-interactive step is yarn install && eas diagnostics && npx --yes expo-env-info.

For more context about my eas.json / app.json:

app.json has "sdkVersion": "47.0.0", as I'm using RN 0.70.6. I tried it with this line removed too though.

My original eas.json had the following. Note I've been testing on staging:

		"production": {
			"channel": "production",
			"autoIncrement": true,
			"node": "16.17.1",
			"yarn": "2.4.3",
			"ios": {
				"resourceClass": "m1-medium"
			}
		},
		"staging": {
			"extends": "production",
			"channel": "staging",
			"distribution": "internal",
			"android": {
				"gradleCommand": ":app:assembleRelease"
			}
		},

I toyed with it a bunch so it's now this to match my local env exactly:

		"production": {
			"channel": "production",
			"autoIncrement": true,
			"cache": {
				"disabled": true
			},
			"node": "16.17.1",
			"yarn": "2.4.3",
			"ios": {
				"resourceClass": "m1-medium",
				"cocoapods": "1.11.3",
				"bundler": "1.17.2"
			}
		},
		"staging": {
			"extends": "production",
			"channel": "staging",
			"distribution": "internal",
			"android": {
				"gradleCommand": ":app:assembleRelease"
			}
		},

Managed or bare?

Bare

Environment

npx expo-env-info and eas diagnostics respectively, for the Github action env as well as my local one:

-- Github Action: --

  expo-env-info 1.0.5 environment info:
    System:
      OS: macOS 12.6.3
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 16.17.1 - ~/hostedtoolcache/node/16.17.1/x64/bin/node
      Yarn: 2.4.3 - ~/.yarn/bin/yarn
      npm: 8.15.0 - ~/hostedtoolcache/node/16.17.1/x64/bin/npm
    Managers:
      CocoaPods: 1.12.0 - /usr/local/lib/ruby/gems/3.0.0/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
      Android SDK:
        API Levels: 27, 28, 29, 30, 31, 32, 33, 33
        Build Tools: 27.0.0, 27.0.1, 27.0.2, 27.0.3, 28.0.0, 28.0.1, 28.0.2, 28.0.3, 29.0.0, 29.0.1, 29.0.2, 29.0.3, 30.0.0, 30.0.1, 30.0.2, 30.0.3, 31.0.0, 32.0.0, 33.0.0, 33.0.1, 33.0.2
        Android NDK: 25.2.9519653
    IDEs:
      Xcode: 14.2/14C18 - /usr/bin/xcodebuild
    npmPackages:
      expo: ^47.0.13 => 47.0.13 
      react: 18.1.0 => 18.1.0 
      react-native: ^0.70.6 => 0.70.7 
    Expo Workflow: bare
  EAS CLI 3.8.1 environment info:
    System:
      OS: macOS 12.6.3
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 16.17.1 - ~/hostedtoolcache/node/16.17.1/x64/bin/node
      Yarn: 2.4.3 - ~/.yarn/bin/yarn
      npm: 8.15.0 - ~/hostedtoolcache/node/16.17.1/x64/bin/npm
    Utilities:
      Git: 2.39.2 - /usr/local/bin/git
    npmPackages:
      expo: ^47.0.13 => 47.0.13 
      expo-updates: ~0.15.6 => 0.15.6 
      react: 18.1.0 => 18.1.0 
      react-native: ^0.70.6 => 0.70.7
    Project workflow: generic

-- Local: --

  expo-env-info 1.0.5 environment info:
    System:
      OS: macOS 13.2.1
      Shell: 5.8.1 - /bin/zsh
    Binaries:
      Node: 16.17.1 - /opt/homebrew/bin/node
      Yarn: 2.4.3 - /opt/homebrew/bin/yarn
      npm: 8.15.0 - /opt/homebrew/bin/npm
      Watchman: 2022.10.03.00 - /opt/homebrew/bin/watchman
    Managers:
      CocoaPods: 1.11.3 - /opt/homebrew/bin/pod
    SDKs:
      iOS SDK:
        Platforms: DriverKit 22.2, iOS 16.2, macOS 13.1, tvOS 16.1, watchOS 9.1
    IDEs:
      Android Studio: 2022.1 AI-221.6008.13.2211.9619390
      Xcode: 14.2/14C18 - /usr/bin/xcodebuild
    npmPackages:
      expo: ^47.0.13 => 47.0.13 
      react: 18.1.0 => 18.1.0
      react-native: ^0.70.6 => 0.70.7
    npmGlobalPackages:
      eas-cli: 3.8.1
    Expo Workflow: bare
  EAS CLI 3.8.1 environment info:
    System:
      OS: macOS 13.2.1
      Shell: 5.8.1 - /bin/zsh
    Binaries:
      Node: 16.17.1 - /opt/homebrew/bin/node
      Yarn: 2.4.3 - /opt/homebrew/bin/yarn
      npm: 8.15.0 - /opt/homebrew/bin/npm
    Utilities:
      Git: 2.37.1 - /usr/bin/git
    npmPackages:
      expo: ^47.0.13 => 47.0.13 
      expo-updates: ~0.15.6 => 0.15.6
      react: 18.1.0 => 18.1.0
      react-native: ^0.70.6 => 0.70.7
    npmGlobalPackages:
      eas-cli: 3.8.1
    Project workflow: generic

Error output

No response

Reproducible demo or steps to reproduce from a blank project

This will be tough to reproduce for others but maybe it can happen with their environments too (i.e. has nothing to do with my env).

  1. Run eas update locally (ideally an M1 Max machine with the same local environment as I have above) and observe the iOS app update and start up as expected after force-closing twice.
  2. Run eas update in a Github action with nearly the same environment and ensure it succeeds. Now force close the iOS app a couple of times and observe that it shows a blank screen on start-up after quickly dismissing the splash screen

tsalama avatar Mar 16 '23 19:03 tsalama

Just chiming in with a similar experience currently: eas update --auto succeeds in github actions when I merge into my staging branch, but resulting in no change on the testflight app. Running eas update --auto locally causes the app to update correctly.

tasandberg avatar Mar 28 '23 01:03 tasandberg

I’ve tried to reproduce your issue but am having trouble getting different behaviour from the same commit while building on CI vs on my local machine. For reference, I have been using the setup documented here

Here are some things you can provide to help us root cause the problem:

Very Helpful

A simple app where you’ve been able to reproduce this issue. Please share:

  • the app code
  • links to your updates built via CI and local machine. Also whether you are loading via ios or android
  • link to your build which you tried to load the update from
  • GHA configuration

Somewhat Helpful

If you notice this behavior in your existing app again:

  • Checkout your app to the state which you made your build, and make an additional development build for Android. Let us know the link to this build. An example of how to do this is to run eas build --profile development while your eas.json is configured like so:
"build": {
    "development": {
      "developmentClient": true,
      ...
    },
    ...
}
  • links to your updates built via CI and local machine
  • GHA configuration
  • package.json (when you built your app, and when you made the update)

quinlanj avatar Apr 14 '23 22:04 quinlanj

Closing due to inactivity

quinlanj avatar May 10 '23 19:05 quinlanj

@quinlanj I was using eas update --auto --platform all. I even tried using self-hosted github runners on my machine and I'm still somehow facing the same issue. Really not sure what the reason is.

But here are two updates from a few months ago that gave me the unexpected behavior / black screen on app launch. Running the same command manually/locally the same day updated the app just fine and it launched again.

https://expo.dev/accounts/sportual/projects/sportual/updates/d94778c4-501e-4905-83e4-77da229a75f1 https://expo.dev/accounts/sportual/projects/sportual/updates/5bd90e5d-b114-4ab0-be98-9261a8051b8a

Here's my latest local update that worked fine a few weeks ago: https://expo.dev/accounts/sportual/projects/sportual/updates/ac417ed9-da60-4e06-aaea-60f503314109

tsalama avatar May 10 '23 19:05 tsalama

I'm also running into this same issue. I've spent about three or four days now trying to resolve it with no success. The update always works from the local CLI, but results in a crashing build when deployed from the pipeline. I tried to migrate to Expo 49 to see if that would resolve the issue, but unfortunately it only ended up resulting in its own unique sets of problems, so for now I've just decided to deploy updates from my computer. Luckily I work at a small startup where this is feasible, but I can imagine that for others this is not.

@quinlanj perhaps it's possible to re-open the ticket?

thewalrusisben avatar Jul 11 '23 12:07 thewalrusisben

@Timmehs I am also running into the same issue as you mentioned. eas update --auto --branch test -> works fine for me locally on my mac and i am able to see the update. But in github actions it succeds but the update is not applied.

I am using expo-github-actions but it doesnt work ? Were you able to resolve it ?

lord-Sid avatar Aug 22 '23 07:08 lord-Sid

@lord-Sid I just revisited this pipeline last Friday and was surprised to see that the updates were working via Github actions. To my knowledge, nothing had changed in my configuration. It's possible that I am now using an updated version of eas-cli (4.1.*), but I didn't take note of my previous version so I can't say definitely if that's it. Perhaps it's worth a try though for you as well if you're using an older version.

Good luck!

thewalrusisben avatar Aug 22 '23 08:08 thewalrusisben

I got the same issue and fixed it. After many many tries, I figured out that Expo will not fetch any update to the app if there is error within that update. In my case, there was about the .env that I haven't created it on Github Actions. So I think there was something missing on Github Actions that your local might have.

longlhh90 avatar Aug 24 '23 21:08 longlhh90

I got the same issue and fixed it. After many many tries, I figured out that Expo will not fetch any update to the app if there is error within that update. In my case, there was about the .env that I haven't created it on Github Actions. So I think there was something missing on Github Actions that your local might have.

How did you handle the env variables in gh actions? i might have the same problem pretty sure

claudiutwin avatar Sep 21 '23 09:09 claudiutwin

I am facing exactly same issue:

  • Updates published from my local mac are working as intended
  • Updates published from GH action hangs the app on splash screen without ability to roll back or install any other update

matasmaciulaitis avatar Oct 10 '23 06:10 matasmaciulaitis

I got the same issue and fixed it. After many many tries, I figured out that Expo will not fetch any update to the app if there is error within that update. In my case, there was about the .env that I haven't created it on Github Actions. So I think there was something missing on Github Actions that your local might have.

How did you handle the env variables in gh actions? i might have the same problem pretty sure

You can config it in Github settings --> Environments or Secrets and variables Screenshot 2023-10-10 at 09 07 24

longlhh90 avatar Oct 10 '23 15:10 longlhh90

Were there any updates on this? Im facing a similar issue where when running eas update from my Github action my bottom sheet (https://www.npmjs.com/package/@gorhom/bottom-sheet) is unscrollable.

But if I run the update locally (run eas update on my machine) the update goes through fine.


Such a bizarre issue, nothing is different between the two. Using the same eas-cli, same env variables, etc... It was working for quite some time then just a month or so back it stopped working.

0NotApplicable0 avatar Jul 14 '25 14:07 0NotApplicable0