[Feature request] Declarative / headless bootstrap configuration for automated deployments

[bjelac]

Hi,

we deploy GADS automatically through Jenkins and Docker Compose and would like
the GADS database to be disposable.

Currently some initial configuration has to be created manually through the
Admin UI, for example:

• Secret Keys
• Appium Client Credentials
• Provider configuration

This makes fully automated/reproducible deployments difficult and also couples
deployment automation to the GADS MongoDB schema if we try to seed those
records ourselves.

Would it be possible to provide an officially supported bootstrap mechanism for
GADS?

For example:

GADS Hub starts
      |
      v
reads bootstrap configuration
      |
      v
creates missing persistent configuration
      |
      v
normal startup

The configuration could be provided through one of:

• YAML/JSON configuration file
• environment variables
• CLI command
• bootstrap/init command

The exact mechanism is not important; the main requirement would be that it is
a supported public interface and does not require directly manipulating MongoDB.

Example use case

We would like to be able to deploy:

MongoDB (empty)
    |
    v
GADS bootstrap
    |
    +-- Secret Key: jenkins-wda
    |
    +-- Appium Client Credential: jenkins-appium
    |
    +-- Provider: mac-provider-1
    |
    +-- Provider: mac-provider-2
    |
    v
GADS Hub
    |
    v
Providers start and discover connected devices

without opening the GADS Admin UI.

Idempotency

The bootstrap should ideally be idempotent.

Running it multiple times should not create duplicate configuration.

For example:

ensure secret key "jenkins-wda"
ensure client credential "jenkins-appium"
ensure provider "mac-provider-1"

Existing matching configuration should simply be reused.

Externally managed secrets

A particularly useful feature would be support for externally managed secrets.

For example our secrets are stored in HashiCorp Vault.

We would like to supply:

GADS_WDA_UPLOAD_SECRET=<secret>
GADS_APPIUM_CLIENT_SECRET=<secret>

during bootstrap.

This is important for Appium Client Credentials.

Currently GADS normally generates the Client Credential secret itself.
For automated infrastructure it would be useful to optionally supply an
existing secret so an empty database can be recreated from an external secret
store.

The normal Admin UI behavior could continue generating secrets as it does
today.

This would only be an optional bootstrap/deployment feature.

Provider bootstrap

It would also be useful to declaratively create provider configurations, for
example:

providers:
  - nickname: mac-provider-1
  - nickname: mac-provider-2

The providers could then start normally using their nickname and discover the
devices connected to them.

Device runtime state should NOT need to be part of bootstrap configuration.

Why this would help

This would make GADS easier to use with:

• Docker Compose
• Kubernetes
• Jenkins
• GitLab CI
• Ansible
• Terraform
• ephemeral/test environments

and would allow the MongoDB database to be treated as disposable deployment
state.

It would also prevent deployment scripts from depending directly on internal
MongoDB collection schemas.

Version independence

One important reason for requesting a public bootstrap interface is version
independence.

We want deployment automation to be able to switch between GADS versions, for example:
GADS_VERSION=5.x and GADS_VERSION=6.x

without Jenkins scripts having to know whether MongoDB collections or document
structures changed between versions.

If GADS owns the bootstrap implementation, the deployment interface could stay
stable even if the internal persistence model changes.

Possible interface

Something like:
GADS hub --bootstrap-config=/config/bootstrap.yaml
or:
GADS bootstrap --config=/config/bootstrap.yaml
could be sufficient.

Example concept:

secretKeys:
  - origin: jenkins-wda
    secretEnv: GADS_WDA_UPLOAD_SECRET

clientCredentials:
  - name: jenkins-appium
    description: Jenkins/Appium automated test sessions
    secretEnv: GADS_APPIUM_CLIENT_SECRET

providers:
  - nickname: mac-provider-1
  - nickname: mac-provider-2

The actual schema/API can of course be designed differently.

The important requirements for us are:

• no manual Admin UI setup
• idempotent
• supported across GADS versions
• secrets can come from an external secret store
• no direct MongoDB manipulation required
• provider configuration can be created automatically
• runtime device/session state remains managed by GADS

Would something like this fit the direction of GADS?