-
Notifications
You must be signed in to change notification settings - Fork 0
Open
Description
Starkit Configuration Format RFC
Introduction
Starkit currently provides a simple command-line configuration, which is insufficient for advanced and real-world CI/CD scenarios. This RFC proposes a new configuration format to support complex configurations and outlines the requirements and expected behavior.
Configuration Requirements
The following features should be supported by the Starkit configuration:
- Base configurations:
- Region(s) (multiple region support to be added)
- Service(s)
- Format(s) (multiple format support and HTML report to be added)
- Failure conditions specification using service:criticality pairs to determine pass/fail status of runtime tests
- Exclusion of specific instances from services (e.g., a specific S3 bucket, EC2 instance, or App Runner instance)
Configuration Format
- Multiple configuration formats should be supported, with JSON and YAML as first-class citizens.
- Internal validation will use JSON format powered by zod.
- Configurations should use snake_case.
Proposed format:
Configuration Management
- File naming:
.starkit.{json,yaml} - Config location priority:
- CLI specified path
- Current directory
- User home directory
- Environment variable
STARKIT_CONFIG_PATH
Version Control
- Use
compatibility_dateto manage backward compatibility and config versioning.
Considerations
- Determine the depth of configuration allowed (e.g., "region:service:instance" or just "region:service").
- Evaluate the impact of introducing complex configurations on the user experience and documentation.
- Consider the scalability and performance implications of the proposed configuration format.
Implementation
- Implement support for JSON and YAML configuration formats.
- Integrate zod for internal JSON validation.
- Update the CLI to read and validate configurations based on the defined location priority.
- Implement the proposed configuration structure and default behaviours.
- Add support for multiple regions, formats, and HTML reporting.
- Update documentation and examples to reflect the new configuration format.
Rollout Plan
- Develop and test the new configuration format in a separate branch.
- Gather feedback from the development team and selected users.
- Address feedback and make necessary adjustments.
- Merge the configuration format changes into the main branch.
- Release a new version of Starkit with the updated configuration format.
Conclusion
Implementing a comprehensive configuration format will enable Starkit to support advanced and real-world CI/CD scenarios. By following the proposed format and requirements, Starkit can offer greater flexibility and customization options to its users.
Reactions are currently unavailable
Metadata
Metadata
Assignees
Labels
No labels
{ // Used to mark the configuration format and backward compatibility "compatibility_date": "2025-01-03", "clouds": [ { "provider": "aws", "regions": ["us-east-1", "us-west-2"], "services": ["s3", "ec2"], "allow_failures": [ // Allow all failures for a service { "service": "s3", "criticality": "critical" }, // Allow high failures for all services { "service": "*", "criticality": "high" }, // Allow failures for an an ARN { "arn": "arn:aws:s3:::my_bucket", "criticality": "high" } ] } // Similar configs for other providers ], "iac": [ { "type": "terraform", "dir": "path/to/terraform", "exclude": ["module1", "module2"] } ] }