EAS Submit config as secrets

Expo Application Services (EAS)
1

Hey!

In the newest version of eas submit, I need to provide information in eas.json I previously let my CI inject, so I wouldn’t have “sensitive” information in my repo.

Example of a command run by my CI:
EXPO_APPLE_APP_SPECIFIC_PASSWORD=$(EXPO_APPLE_APP_SPECIFIC_PASSWORD) eas submit -p ios --latest --apple-id=$(APPLE_USERNAME) --asc-app-id=$(APP_APPLE_ID) --sku=$(SKU)

But the parameters --apple-id, --asc-app-id and --sku are not allowed anymore. And it seems that I have to configure a submit section in my “eas.json” file.

Is it possible to define these values as Secrets or will I have to include these values in my repo now?

2

I have the same issue with

serviceaccountkeypath

It is a file kept on our CI service, so it is not checked in to our repo:

eas submit -p android --latest --key=$(service_account_key.secureFilePath)

Will i have to check it in now?

3

service file does not need to be checked into repo(just path to the file), also you can use envs there
e.g. serviceAccountKeyPath: '$GOOGLE_SERVICE_ACCOUNT_PATH', it’s supported just for that field

as far as I remember eas-cli does not require eas.json to be in repo, but it’s not the workflow we are supporting/testing against. I don’t think any of those values are sensitive, but if you want you can always encrypt that file with git crypt, but if it’s not a public repo I think it’s unnecessary

2 Likes
4

Thanks for your answer!

Great, I will try environment variable in serviceAccountKeyPath and mark your suggestions as solution.

Here is some feedback / my thoughts

I’m not sure about the how sensitive the other values are either. I would just like be able to separate my app code from operations related stuff and I feel like eas.json pushes me more and more towards leaking information related to operations into my app code / repo. Even though this information might not be super sensitive I don’t have much freedom, if I want to use expo’s services.

Some of these could maybe be solved using git crypt. But eas.json also makes it harder to deal with dynamic values, such as release channels and build numbers. Now I have to check these in. Before, my CI could auto-increment build numbers, create release channels based on version etc.

2 Likes
5

you should use runtimeVersion instead of releaseChannel if you want it to be dynamic. runtimeVersion lives in app.config.js. Runtime Versions - Expo Documentation

the same applies for build numbers - these live in app.config.js.

you certainly should not be leaking information in eas.json. anything sensitive should go into secrets. Environment variables and secrets - Expo Documentation

6

This topic was automatically closed 20 days after the last reply. New replies are no longer allowed.