KarpelesLab / libwallet / 26151523856
22%

DEFAULT BRANCH: master
Ran
Jobs 1
Files 121
Run time 1min
Badge
Embed ▾
README BADGES
x

If you need to use a raster PNG badge, change the '.svg' to '.png' in the link

Markdown

Textile

RDoc

HTML

Rst
coverage: 22.26%. Remained the same
26151523856

push

github

MagicalTux 
test_app/ios: force pods' simulator slice to include arm64

The previous CI run's iOS test launched the app cleanly — the
fresh-sim CoreSimulator-reset commit fixed the infra flake — but
flutter test then crashed in setUpAll with:

  Invalid argument(s): Couldn't resolve native function
  'DOBJC_initializeApi' in 'package:objective_c/objective_c.dylib':
  Failed to load dynamic library 'objective_c.framework/objective_c':
  ... '/.../Runner.app/Frameworks/objective_c.framework/objective_c'
  (fat file, but missing compatible architecture (have 'arm64e',
  need 'arm64'))

The `objective_c` package — pulled in transitively via
flutter_secure_storage_darwin (which our atonline_api dep wires for
device-share storage) — ships an arm64e-only simulator slice in
its CocoaPods framework. On Apple Silicon GitHub runners the
simulator process is plain arm64 (NOT arm64e — pointer
authentication is iOS-device territory), so dlopen rejects the
framework at app launch.

The well-trodden workaround: override the pod post_install hook so
every pod's simulator build pins ARCHS / VALID_ARCHS to "arm64
x86_64" and clears any EXCLUDED_ARCHS[sdk=iphonesimulator*] line.
That forces CocoaPods to compile the simulator slice with arm64
included regardless of what the upstream pod sets.

Doesn't affect device builds (the build settings are gated on
sdk=iphonesimulator*) and doesn't reach beyond the test app — the
override lives in test_app/ios/Podfile, not in any production
pod.

3918 of 17601 relevant lines covered (22.26%)

108.0 hits per line

Jobs
ID Job ID Ran Files Coverage
1 26151523856.1 121
22.26
 GitHub Action Run
Source Files on build 26151523856