8000 feat: Feature flags by daniel-lxs · Pull Request #4226 · RooCodeInc/Roo-Code · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

feat: Feature flags #4226

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.

Sign up for GitHub

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

Jump to bottom
Draft
wants to merge 5 commits into
base: main
Choose a base branch
from
Draft

feat: Feature flags #4226

wants to merge 5 commits into from

Conversation

daniel-lxs
Copy link
Collaborator

Description

This PR implements a comprehensive internal feature flags system that allows the team to test features internally without exposing them to users in the experimental settings UI.

Key implementation details:

  • Added internal and nightlyDefault properties to experiment configs
  • Internal flags are identified by an underscore prefix in their ID (e.g., _INTERNAL_FEATURE)
  • Added filtering in the ExperimentalSettings UI to hide internal flags from users
  • Implemented automatic enabling of flags marked with nightlyDefault: true in nightly builds
  • Added telemetry events to track internal flag usage and errors
  • Created validation script to ensure internal flags follow naming conventions
  • Added CI step in nightly-publish workflow to log active experiments

This implementation allows for a controlled rollout process where features can be tested internally first, then gradually exposed to users when ready.

Test Procedure

  1. Unit Tests: Added comprehensive tests in src/shared/__tests__/experiments.test.ts that verify:

    • Internal flags are properly hidden from UI
    • Nightly defaults are correctly applied
    • Flag naming conventions are enforced

  2. Manual Testing:

    • Create a test flag with internal: true and verify it doesn't appear in settings UI
    • Set ROO_CODE_NIGHTLY=true environment variable and verify nightly defaults are applied
    • Run the validation script to confirm it catches improperly named internal flags

  3. CI Verification:

    • The nightly build workflow now includes a step to enable internal flags
    • Verify the log-experiments.js script outputs the correct enabled experiments

Type of Change

  • 🐛 Bug Fix: Non-breaking change that fixes an issue.
  • ✨ New Feature: Non-breaking change that adds functionality.
  • 💥 Breaking Change: Fix or feature that would cause existing functionality to not work as expected.
  • ♻️ Refactor: Code change that neither fixes a bug nor adds a feature.
  • 💅 Style: Changes that do not affect the meaning of the code (white-space, formatting, etc.).
  • 📚 Documentation: Updates to documentation files.
  • ⚙️ Build/CI: Changes to the build process or CI configuration.
  • 🧹 Chore: Other changes that don't modify src or test files.

Pre-Submission Checklist

  • Issue Linked: This PR is linked to an approved GitHub Issue (see "Related GitHub Issue" above).
  • Scope: My changes are focused on the linked issue (one major feature/fix per PR).
  • Self-Review: I have performed a thorough self-review of my code.
  • Code Quality:
    • My code adheres to the project's style guidelines.
    • There are no new linting errors or warnings (npm run lint).
    • All debug code (e.g., console.log) has been removed.
  • Testing:
    • New and/or updated tests have been added to cover my changes.
    • All tests pass locally (npm test).
    • The application builds successfully with my changes.
  • Branch Hygiene: My branch is up-to-date (rebased) with the main branch.
  • Documentation Impact: I have considered if my changes require documentation updates (see "Documentation Updates" section below).
  • Changeset: A changeset has been created using npm run changeset if this PR includes user-facing changes or dependency updates.
  • Contribution Guidelines: I have read and agree to the Contributor Guidelines.

Screenshots / Videos

N/A - The primary UI change is that internal flags are hidden from the Experimental Settings UI.

Documentation Updates

  • No documentation updates are required for end users.
  • Internal documentation has been added in docs/internal-feature-flags.md for the development team.

Additional Notes

This feature enables a more controlled development process for experimental features, allowing the team to test changes internally before exposing them to users. The validation script ensures consistency in how internal flags are configured.

Get in Touch

Discord: daniel_lxs

daniel-lxs added 4 commits June 1, 2025 12:49
@daniel-lxs
feat: implement internal feature flags system
fd3a0dd 
- Add support for internal-only feature flags that are hidden from users
- Add validation script to ensure internal flags are properly configured
- Add CI validation step in nightly-publish workflow
- Add telemetry tracking for internal flag usage
- Add comprehensive tests for internal flag functionality
- Add documentation explaining the internal flag system
- Filter internal flags from experimental settings UI

This allows the team to test features internally without exposing them
to users in the experimental settings.
@daniel-lxs
feat: update experiment and feature flag handling
138b717
@daniel-lxs
feat: add NightlyTestBanner component and integrate into App
6f58c81
@daniel-lxs
ci: update nightly publish workflow
b2459de
@daniel-lxs daniel-lxs moved this from Triage to PR [Needs Prelim Review] in Roo Code Roadmap Jun 2, 2025
@daniel-lxs daniel-lxs mentioned this pull request Jun 2, 2025
Closed
@daniel-lxs daniel-lxs moved this from PR [Needs Prelim Review] to PR [Draft / In Progress] in Roo Code Roadmap Jun 2, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@mrubens mrubens Awaiting requested review from mrubens mrubens will be requested when the pull request is marked ready for review mrubens is a code owner

@cte cte Awaiting requested review from cte cte will be requested when the pull request is marked ready for review cte is a code owner

At least 1 approving review is required to merge this pull request.

Assignees
No one assigned
Labels
PR - Draft / In Progress
Projects
Roo Code Roadmap
Status: PR [Draft / In Progress]
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@daniel-lxs @hannesrudolph
0