Configuration
The template prompts for various configuration options. Many values are auto-detected from your existing project files.
Common Configuration
These options are shared across templates:
| Option | Description | Default |
|---|---|---|
|
Maven artifact ID / service name |
Auto-detected from |
|
Service version number |
Auto-detected from |
|
Docker registry organization prefix |
|
|
Bitbucket project key |
Auto-detected from git remote |
|
Link to issue tracker |
— |
|
Project type |
|
|
Major version prefix |
e.g., |
DevOps-Specific Configuration
| Option | Description | Default |
|---|---|---|
|
Working directory context for Skaffold |
|
|
Include SQL configmap resource |
|
|
YAML list of service dependencies |
Auto-detected from existing |
|
Git base URL for service repositories |
Auto-detected from git remote |
|
Path to kustomize files in service repos |
|
VAEC Cost Allocation Labels
Required for AWS EKS cost attribution via Cloudability CostIQ.
These labels must be present in both metadata.labels and spec.template.metadata.labels as required by the VAEC Tagging Policy.
|
| Option | Description | Example |
|---|---|---|
|
Cost Key ID from ECSO Tenant Registration |
|
|
Tenant ID from ECSO Tenant Registration |
|
|
Product name |
|
|
Product line |
|
|
Service type |
|
|
Application name |
Defaults to |
|
Service short name for Dynatrace labels |
Defaults to |
Label Validation
All VAEC labels are validated to comply with Kubernetes label value rules:
-
1-63 characters
-
Alphanumeric, dashes, underscores, and dots only
-
Must start and end with an alphanumeric character
Dynatrace Integration
VAEC values are used to construct initial Dynatrace labels:
DynatraceDeploymentName: MAP-{product_line}-{service_shortname}-{vasi}-{artifact_id}-{version}
MAP-{product_line}-ServiceName: MAP-{product_line}-{service_shortname}-{vasi}-{artifact_id}-{version}
Example:
MAP-DHAS-ServiceName: MAP-DHAS-SPFS-3443-smart-pgd-fhir-service-v1
Skaffold Profile Selections
Choose which Skaffold profiles to include:
| Profile | Description | Default |
|---|---|---|
|
Local development with service dependencies |
|
|
Sandbox environment deployment |
|
|
Staging environment deployment |
|
|
Production environment deployment |
|
|
Sandbox build and test |
|
|
Staging build and test |
|
|
Debug profile with all services |
|
|
Vault integration testing |
Based on |
Service Dependencies
When using the default profile, which references the dev-with-dependencies overlay, you can specify service dependencies in multiple formats:
Short Format
service_dependencies:
- ckm/service-a:v1.0.0
- ckm/service-b:Release/1.1
- ckm/service-c
- ckm/service-d:v2.0.0:kubernetes/custom/path
Format: {org}/{service}[:{version}][:{custom-path}]
Kustomize Git URL Format
service_dependencies:
- dhsss/oracle-db.git//kubernetes?ref=Release/23.26.1&timeout=60s
Full URL Format
service_dependencies:
- https://coderepo.mobilehealth.va.gov/scm/ckm/service-a.git//kubernetes/components/dev?ref=v1.0.0
Updating Dependencies
To update service dependencies without re-running all prompts:
# Create a data file
cat > .copier-answers/service-dependencies.yaml << EOF
service_dependencies:
- ckm/service-a:v2.0.0
- ckm/service-b:v1.5.0
EOF
# Update with the data file
copier update -a .copier-answers/devops.yaml --data-file .copier-answers/service-dependencies.yaml