-
-
Notifications
You must be signed in to change notification settings - Fork 1.5k
chore: Proposal 1 yaml base config inheritance #24563
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: main
Are you sure you want to change the base?
Conversation
|
CLA Signature Action: All authors have signed the CLA. You may need to manually re-run the blocking PR check if it doesn't pass in a few minutes. |
🔍 Smart E2E Test Selection
click to see 🤖 AI reasoning detailsAll changes in this PR are related to CI/CD infrastructure and build configuration management:
None of these changes affect:
These are purely CI/CD and build infrastructure changes that don't require E2E testing validation. The changes are well-isolated to the build/deployment pipeline and don't touch any code paths that would be exercised by E2E tests. |
- Add base.yml with shared configuration (servers, features, common secrets) - Add environment-specific configs (prod, rc, exp) that extend base - Add merge-config.js script to merge base + environment configs - Add set-secrets-from-config.js helper for secret mapping - Add build.yml workflow that uses merged configurations - Add js-yaml dependency for YAML parsing - Add README explaining the configuration structure This proposal uses a base configuration file with inheritance pattern, allowing shared values to be defined once and environment-specific overrides to be minimal and clear. Co-authored-by: tomas.santos <[email protected]>
daa9ce1 to
1f63bc8
Compare
This MVP provides the minimal structure needed to start migrating to the new YAML-based configuration system. Changes: - Keep base.yml with shared configuration - Add prod.yml and rc.yml as example environments - Simplify merge-config.js script - Remove exp.yml (will be added during migration) - Remove set-secrets script (not needed for MVP) - Remove workflow file (will be added during migration) - Update README to explain MVP scope This MVP allows teams to: 1. Test the merge script locally 2. Start migrating configs incrementally 3. Extend with more environments/build types later Next steps during migration: - Add remaining environments (exp, beta, test, dev, e2e) - Add build-types separation (main vs flask) - Add combinations directory - Integrate with GitHub Actions workflows - Add code fencing configuration Co-authored-by: tomas.santos <[email protected]>
Implements the complete hierarchical configuration system: Structure: - base.yml: Universal defaults shared by all builds - build-types/: Common config for main and flask builds (code fencing, OAuth) - environments/: Common config for each environment (prod, beta, rc, test, exp, dev, e2e) - combinations/: Specific overrides for build-type + environment combinations Features: - Hierarchical inheritance: base → build-type → environment → combination - Code fencing centralized in build-type configs - All 12 combinations supported (main-prod, main-rc, flask-prod, etc.) - Enhanced merge-config.js with code fencing resolution - Updated metro.transform.js to use config (with fallback) - GitHub Actions workflow integration - Secret management helper script Benefits: - DRY: Shared configs defined once - Maintainable: Update base to change all environments - Scalable: Easy to add new environments/build types - Single source of truth for all combinations - Removes remapping logic from build.sh - Centralizes code fencing configuration Co-authored-by: tomas.santos <[email protected]>
Description
Changelog
CHANGELOG entry:
Related issues
Fixes:
Manual testing steps
Screenshots/Recordings
Before
After
Pre-merge author checklist
Pre-merge reviewer checklist