Stanisław Chmiela

I’m really happy we got to this point! Thank you for all your help debugging and squashing problems one by one.

If you encounter any issues in the future I’ll be more than happy to help!

Woot woot woot!! 🎉

We’ve also released eas-cli 15.0.13 today which should no longer remove `.git` if only you have an `.easignore`. In other words you shouldn’t see “fatal: not a git repository” anymore!

The fix landed! Again, thank you.

Curious what we need to do yet to get a successful submission... haha

This is awesome!! I was dismissing the idea a single asterisk could match subdirectories. Thank you!! I'll let you know when the fix lands.

Woooow, it helped!!

Looks like now a mix of `plutil | xpath` is failing to parse `Info.plist` for `CFBundleIdentifier`. Looking into why (it works with another IPA I have at hand)…

github.com/expo/eas-bui...

Set up EAS Build with a monorepo Learn how to set up EAS Build with a monorepo.

We're working on adding an `eas/submit` function so you can some day do:

```
- uses: eas/checkout
- ... build packages
- uses: eas/submit
```

In the meantime would you consider moving the building of packages to `postinstall` like described here? docs.expo.dev/build-refere...

Wow, ok, that was helpful! Turns out it was *not* the Node deprecation warning. JQ treats the space after 6-letter word "Failed" as "number literal", hence the error message. TIL!

The following error makes sense. It's hard to resolve app config when some config plugins (live-activity) aren't built!

Also, huge huge thanks for all the help when debugging this. Tomorrow I'm going to waive the charges for all the builds you've used while setting this up and testing things.

test.yml GitHub Gist: instantly share code, notes, and snippets.

Submitted a pull request that will let us see more into why things are failing. Hoping to merge tomorrow.

For now the only thing we could try is a workflow like gist.github.com/sjchmiela/2b...

BTW thanks for the suggestion to add `HOMEBREW_NO_INSTALL_CLEANUP` to Homebrew calls!! Will do too.

I see `NODE_NO_WARNINGS` hasn't helped… I've tried reproducing with the same Node version on another project and I had no issues…

I'll make it so we `EXPO_DEBUG=1` prints more information. Maybe that's not punycode, but something else instead?

Sorry for all the hassle around this.

BTW I think if you remove `.easignore`, `.git` will end up in the tarball which should allow you to

```
BRANCH=$(git rev-parse --abbrev-ref HEAD)
```

to get the branch name. Just noticed a bug in `eas-cli@15` which causes `.git` to be skipped if you have `.easignore`). Will fix today.

Also, a sidenote — `${{ github.* }}` interpolation thingies are only available when a workflow run is triggered from GitHub. If it starts from `eas workflow:run`, `github.*` properties will be empty.

Funny thing is… there already is one.

I'll add `NODE_NO_WARNINGS=1` to the `npx` call, maybe that will help. If you want to try it first, you should be able to add
```
submit:
env:
NODE_NO_WARNINGS: "1"
...
```

Switching to Node 20 must have started triggering the

(node:1699815) [DEP0040] DeprecationWarning: The punycode module is deprecated....

warning. Let me do something about it.

Ugh. Couple words of context—preparing credentials involves running an `eas-cli` command to resolve the credentials based on selected profile and app config / project. We run it with `--json` to later programmatically parse its output piping into `jq`.

[docs] Describe workflow defaults by tchayen · Pull Request #35189 · expo/expo Why Recently I added default.tools. Also noticed that defaults in general are not documented so added that too. How Test Plan Run docs locally if needed. Checklist I added a changelog.md entry ...

I’m excited to provide you a solution for the error though! Yesterday @tchayen.com added ability to set tools versions for all workflow jobs, including submit. github.com/expo/expo/pu...

Try
```
…
on:
push:
branches: …

defaults:
tools:
node: 20.13.1
…

jobs: …
```

Yea, unfortunately we do need the `node_modules` to submit. Submitting is configured by profiles and may depend on dynamic app config (`app.config.ts`) which may require dependencies.

Can you please run
```
npx -y eas-cli@latest build:inspect -p ios -s archive -o ~/sjchmiela-help
```
and check if:
- `.git` is inside
- inside `mobile-mapkit` and `live-activity` there's a podspec file?

So, a couple questions:
- do you have `EAS_NO_VCS` in your env or `.git` in `.easignore`? (This would explain why there's no `.git` in the tarball.)
- do you have `requireCommit` in `eas.json`? (This should always package `.git`.)
- does `mobile-mapkit` have native iOS code? (My guess is yes.)

Sorry for the delay, a mix of RSV and flu in the family made debugging a bit harder than usual haha

This is very strange. It looks to me like:
- there's no `.git` in the project tarball
- `expo-module-scripts` thinks `mobile-mapkit` is an iOS module, but it lacks podspec inside.

Yea, can you please try latest and let me know how it goes for you? If there are issues I need to fix them.

On the other hand, judging by the error, in your `eas.json` you have eas-cli version requirement set to
>= 14.1.0 <= 14.7.1.

I think removing the upper bound should help.

Is there a reason you’ve pinned these versions? FWIW most of the v15 problems the early versions had should be gone now.

Oh yea, sorry, should have read the error in the screenshot better. I think the issue is that in EAS we always use `eas-cli@latest` for anything—like reading build profiles. We’re currently at `eas-cli@15.0.11` if I remember correctly.

That’s surprising! Care to share the build link? I’ll see if there’s something I can find.

We've got this in Workflows now! Just calculated a version string in a `setup` job and then passed it as `env` to a `build_android` job for the dynamic config to say
```
export default ({ config }) => ({
version: process.env.EXPO_VERSION || config.version,
...
```

gist.github.com/sjchmiela/8a...

Yea, that should work if `.env` works like you think (it may, just not sure). This is similar to writing version string into eas.json, just without the commit and push. 👍

Yea, me neither. Let me cook something up real quick.

Adding `env` to workflow jobs, so you can do sth like:

```
setup:
...
steps:
- run: |
set-output version_string "2020.02.02"

build:
needs: [setup]
env:
VERSION_STRING: ${{ needs.setup.outputs.version_string }}
...
```

eas.json Learn about available properties for EAS Build and EAS Submit to configure and override their default behavior from within your project.

So… what you could do is add that version string as build profile environment variable (and then commit and push for the branch to be up-to-date too) using `jq` or any other JSON-manipulating thing on CI. Does that sound right?

docs.expo.dev/eas/json/#env

Haha, what do you know, I've just started working on adding schedule (cron) support to EAS Workflows…

With this + some improvements to workflow interpolation mechanism what you describe should be very doable.

I'll let you know when what you described is ~easy to achieve. Later this week maybe?

How would you like to use it? What do you want to achieve?