Added commands to upload push notification credentials in non interactive mode

[mymattcarroll]

trafficstars

Checklist

• [ ] I've added an entry to CHANGELOG.md if necessary. You can comment this pull request with /changelog-entry [breaking-change|new-feature|bug-fix|chore] [message] and CHANGELOG.md will be updated automatically.

Why

Please describe the motivation for this PR, and link to relevant GitHub issues, forums posts, or feature requests.

https://github.com/expo/eas-cli/issues/1286

We would like to be able to fully automate the creation of new app for both android and ios. This is the only command that we require that is not available in non-interactive mode.

How

How did you build this feature or fix this bug and why?

Test Plan

Please describe how you tested this change and how a reviewer could reproduce your test, especially if this PR does not include automated tests! If possible, please also provide terminal output and/or screenshots demonstrating your test/reproduction.

[mymattcarroll]

/changelog-entry new-feature commands to upload push notification credentials in non interactive mode

[brentvatne]

hey @mymattcarroll, thanks for the PR!

i'd like to get a better understanding of how this fits in to your internal processes to grok the use case - we haven't had anyone else ask for this yet, and so we're just trying to wrap our heads around the flows that it would enable and assess how useful it would be more broadly.

how are you automating the other credentials? is this done completely hands-off, without any human intervention? (including fcm configuration?). if there is human intervention, why not run eas credentials or upload via the website at that time? does each customer app have its own expo account and apple id/google developer account? is there anything else you can share that is relevant?

[mymattcarroll]

No problem, thank you for considering the PR :)

Our company provides a service which allows our customers to have their own Android and iOS app. The app is built from the same code base but the content that is displayed is configurable in each customers CMS. Our implementation staff work with the customer to gather all of the credentials required for iOS and Android and upload these credentials in a system we host. It is similar to your Expo dashboard but it is a lot less technical and aimed at users that are not comfortable with developer facing tools e.g. CLIs. After we have the required credentials and configuration, the customer is able to customise a few other things within the app around theming and content. When the customer has reviewed all of this, we trigger a background process that runs the required Expo CLI commands to create the app in Expo and build both the iOS and Android apps. From there, if the customer wants to make changes to any configuration, we allow them to trigger background processes to run expo publish with new config.

Our process is currently using the following commands:

expo publish
expo webhooks:add
expo build:android 
expo build:ios
eas submit

These will be migrated to the following when moving to the EAS CLI for builds:

eas update
eas webhook:create
eas build
eas submit

Unfortunately, we cannot train our implementation staff to use the eas credentials command because they not developers and would not be comfortable using a CLI. The eas credentials command seems like the perfect tool if we were simply maintaining a single app. However, we require a GUI for our implementation staff to manage credentials for multiple apps, and we want the same GUI to also allow management of the custom configuration we support in our app. This is the reason we cannot ask our implementation staff to manage credentials in the Expo dashboard because they would still have to log into our system to manage custom configuration for each app.

We are currently using a single Expo account for all the apps but each customer has there own Apple and Android/Firebase accounts.

[brentvatne]

thanks for explaining that @mymattcarroll! i'll discuss a bit more with my team to figure it out if we want to commit to the maintenance that comes along with exposing this as a command in the cli. of course, please feel free to use your eas-cli fork in your process, or use the graphql api directly if that is easier.

[mymattcarroll]

@brentvatne Do you offer any kind of guide for using the graphql api directly? Using the fork as a dependency in our system is proving to be quite difficult.

[brentvatne]

we don't have any public documentation for our graphql api because we don't typically want people to use it, however i think in this case it's a good option for you. i'd refer to the usage in this codebase as a reference. one possible approach here would be to take your fork and delete everything from this codebase that you don't need, and turn it into a single purpose cli tool that just uploads push credentials