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
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.
USAGE
$ eas env:COMMAND
COMMANDS
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.
eas secret
Create an environment secret on the current project or owner account.
USAGE
$ eas secret:COMMAND
COMMANDS
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
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
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.
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 SOME_ENV_VAR in env in eas.json? (Only for environment variables that are already defined in eas.json, presumably)?
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?