We have tried different ways to use environments variables in
app.config.js. Like described in switching-configuration-based-on-the-environment. But we cannot make it work with EAS Build. Following command fails on expo build server. Because our app.config cannot find the
process.env.APP_ENV env variable.
npx cross-env APP_ENV='qa' VERSION_CODE=20 eas build --platform android
Minimal example of eas config that fails on EAS Build
the same env you are setting locally needs to be also set on eas worker either
Amazeballs! Updating eas.json with env records worked. This is great for choosing
How do we then dynamic change android
We usually let our CI handle that. But with a static
eas.json file we don’t have a clear path?
A workaround could be to
VERSION_CODE record in
env on CI system
- git commit (would like to avoid this on our CI system)
- execute the
eas build command
Is there a better way (we also need to update releaseChannel dynamic)?
It’s possible that in the future we will provide a way to specify some envs dynamically, but we don’t plan to support dynamic values in eas.json, it still is possible to do it with workarounds, but it’s not sth we are recommending.
To address specific cases you mentioned, the recommended approach would be:
- VERSION_CODE seems like a value that should be committed to repo
- release channel for classic updates has to be generated in some cases, but new updates service will introduce concepts e.g runtimeVersion that will make it unnecessary and you won’t need more than a fixed number of channels, so you can create separate profile in eas.json for that.
- for iOS updating version/buildNumber on ios you can use
autoIncrement option, it’s problematic when running on ci because you would need to push changes back to your repo and it’s supported only for ios, so it’s probably not a good approach for your case
If you want to keep your current workflow, the only workaround I see is to modify eas.json on the fly and commit changes before build.
If you want to avoid
git commit at all costs you can run build with
EAS_NO_VCS=1, but I don’t recommend that, it may result in a larger upload because only top level .gitignore is respected and it’s problematic to use in monorepo
Thank you for your insightful answers and help. It is much appreciated!
We use the VERSION_CODE as a build number for android, and that is the reason it is a bit tedious to keep track of in our git repo. It is so easy to forget
I like your ideas about
autoIncrement. But you’re right. It is not a good solution when we use CI system.
We will go back to your recommendation, and change the VERSION_CODE on each commit to our release branch.
Would be nice, if we could update it the environment like the concepts of EAS Secrets you mentioned.
Secrets just needs an update command (i couldn’t find it). Maybe sth like:
Manage an environment variable on the current project or owner account.
$ eas env:COMMAND
env:create Create an environment variable on the current project or owner account.
env:update Update an environment variable on the current project or owner account.
env:delete Delete an environment variable by ID.
env:list Lists environment variables available for your current current project or owner account.
Create an environment secret on the current project or owner account.
$ eas secret:COMMAND
secret:create Create an environment secret on the current project or owner account.
secret:delete Delete an environment secret by ID.
secret:list Lists environment secrets available for your current app
How do i update a secret?
Delete and then create again?
My example above was a wish for how it could look like for defining environment variables. But I am aware that this almost the same as secrets. Secrets just have another purpose IMO
yup, you can delete and re-create to update it
Not being able to do this is a huge pain when it comes to automating builds. It took me FOREVER to figure out that it was the environment variables not being passed to EAS. I’d LOVE to be able to pass environment variables to EAS via the command line.
I ended up writing a script to manually update my app.json from env variables and went with the EAS_NO_VCS=1 flag. I don’t use a monorepo approach (everything’s in its own repo), so this works well for me.
env filed in eas.json that you can use, those envs will be both available on the remote builder and when evaluating app.config.js locally Configuring EAS Build with eas.json - Expo Documentation
Is there any chance that in future doing something like this:
SOME_ENV_VAR="something" eas build
could do the usual shallow clone, and then set the value of
eas.json? (Only for environment variables that are already defined in
I have been facing a similar issue around dynamically adding preview
API_URL for each app build on the CI. We have an API backend architecture in which a separate & dynamic API_URL is created for each PR’s CI process which needs to be the fed through environment variables in the app build. I would have imagined
API_URL="https:/dynamic-api-url" eas build --profile preview --platform all --non-interactive would have solved the issue and added API_URL into the build as an env var, but after reading this and trying to implement it, that doesn’t seem to be the case.
I am going to give the custom script/EAS_NO_VCS thing a go but seeing as mine is a monorep, I’m not that hopeful.
I was hoping if “environment variables through command prompt” can be implemented into eas cli as it would such a huge help?
I still facing the same problem in here, eas build is not reading environment variables from eas.json when it is triggered from gitlab-ci.yml
So it works for you if you run the command manually instead of via
What command is being run?