4e3426c8f3
* refactor(docker): Enhance Zebra configuration options and entrypoint logic - Introduced multiple methods for configuring Zebra, including custom config file paths and automatic generation from environment variables. - Updated entrypoint script to handle configuration more robustly, checking for existing files and generating defaults as needed. - Improved documentation in `docker.md` to clarify configuration options and their precedence. - Adjusted environment variable handling in `docker/.env` for better clarity and functionality. - Refactored `prepare_conf_file` to create a complete configuration based on environment variables, streamlining the setup process. * fix(docker): remove non-essential variables and set correct defaults * feat(ci): Centralize zebra configuration testing with Docker - Replace multiple separate test jobs with a single comprehensive matrix-based test - Create a new ADR documenting the design decision for centralizing Docker tests - Move all test scenarios from both CI and CD pipelines into a single reusable workflow - Define extensive test matrix covering network, RPC, directory, feature configurations - Improve workflow readability with descriptive test names and clear organization - Simplify workflow inputs to only require the Docker image identifier * chore(ci): cleanup jobs that already don't exist |
||
|---|---|---|
| .. | ||
| devops | ||
| README.md | ||
| template.md | ||
README.md
Decision Log
We capture important decisions with architectural decision records.
These records provide context, trade-offs, and reasoning taken at our community & technical cross-roads. Our goal is to preserve the understanding of the project growth, and capture enough insight to effectively revisit previous decisions.
To get started, create a new decision record using the template:
cp template.md NNNN-title-with-dashes.md
For more rationale for this approach, see Michael Nygard's article.
We've inherited MADR ADR template, which is a bit more verbose than Nygard's original template. We may simplify it in the future.
Evolving Decisions
Many decisions build on each other, a driver of iterative change and messiness in software. By laying out the "story arc" of a particular system within the application, we hope future maintainers will be able to identify how to rewind decisions when refactoring the application becomes necessary.