Deployment Validation

Deployment validators on the Architect Cloud are used to be sure that deployments will function as expected once applied.

All service parameters must contain a value

severity: error

Service parameters not marked as optional must either specify a default value or the value must be provided in the environment config.

# service config
# ...
parameters:
  REQUIRED_PARAM: # This parameter has no default value, therefore a value must be provided in the environment config
  PARAM_WITH_DEFAULT: param_value # This parameter specifies a default value which will be applied if it is not overridden
  OPTIONAL_PARAM:
    required: false # This parameter is marked as optional, so a value is not needed to deploy the service
# ...

All valueFrom params should reference valid dependencies

severity: error

A parameter of a service can reference a parameter of another service, but the referenced service must be specified as a dependency.

# service config
# ...
dependencies:
  org/referenced_service: latest
# ...
parameters:
  PARAM_WITH_VALID_REF: ${ dependencies['org/referenced_service'].parameters.REFERENCED_PARAM }
  PARAM_WITH_INVALID_REF: ${ dependencies['org/unspecified_service'].parameters.INVALID_REFERENCE }
# ...

All environment params should be declared by the service

severity: warning

All required parameters that are specified in the environment config must be declared by the related service config.

# environment config
# ...
services:
  org/example-service:
    # ...
    parameters:
      DECLARED_PARAMETER: param_value
      UNDECLARED_PARAMETER: undeclared_param_value # This parameter will not be applied as it was not declared in the service config
    # ...
# ...
# service config
name: org/example-service
parameters:
  DECLARED_PARAMETER:
# ...

All subdomains must be of valid form

severity: error

All subdomains must be less than 64 characters in length, and can only contain letters, numbers, and dashes. They cannot start or end with a dash.

# environment config
# ...
services:
  org/example-service:
    # ...
    interfaces:
      main:
        subdomain: app # valid interface
      secondary:
        subdomain: app$ # invalid, contains invalid characters ($)
      tertiary:
        subdomain: -app # invalid, contains valid characters but starts with a dash
    # ...
# ...

No two ingresses may contain the same subdomain

severity: error

A deployment cannot be applied if a subdomain is declared more than once. This applies within one service and across services being deployed.

# environment config
# ...
services:
  org/example-service:
    interfaces:
      main:
        subdomain: app # The "app" subdomain is invalid as it is used more than once across the deployment
      secondary:
        subdomain: api # The "api" subdomain is invalid because it is used more than once within the same service being deployed
      tertiary:
        subdomain: api
  org/another-service:
    interfaces:
      main:
        subdomain: app
      secondary:
        subdomain: admin # The "admin" subdomain is valid because it is used only once
  # ...
# ...

An Environment should have at least one ingress

severity: warning

A deployment should have a subdomain specified on at least one interface in order for the services to be reachable by the outside world.

# environment config
# ...
services:
  org/example-service:
    interfaces:
      main:
        subdomain: app # exposes the service org/example-service to the outside world
  # ...
# ...

Kubernetes-only volume mounts. ECS currently not implemented

severity: error

A deployment to ECS cannot have volume mounts applied, as they aren't currently implemented. This is a feature coming soon.

# service config
name: org/example-service
# ...
volumes:
  volume-key: # deployment cannot be applied for the ECS platform type if volumes are specified
    mount_path: /volume-directory
Previous
CLI