refactor: rename flag-source-url to provider-url for consistency

[kriscoleman]

Summary

This PR refactors the CLI flag naming for better consistency and clarity across all commands. The primary change is renaming --flag-source-url to --provider to:

• Use clearer, more intuitive terminology ("provider" vs "flag source url")
• Align better with OpenFeature terminology where flag data comes from a provider
• Maintain backward compatibility with the deprecated flag for existing users
• Unify terminology across pull, push, and init commands

Changes

CLI Flag Changes

• New flag: --provider replaces --flag-source-url across all commands (init, pull, push)
• Backward compatibility: Old --flag-source-url flag still works but shows deprecation warning
• Configuration file: New provider key replaces flagSourceUrl in .openfeature.yaml
  • Backward compatibility: Old config key still works if new one isn't present

Updated Commands

• init (internal/cmd/init.go:27): Uses new --provider flag and generates updated config template
• pull (internal/cmd/pull.go:45): Uses new --provider flag with improved error messages
• push (internal/cmd/push.go:58): Uses new --provider flag with updated examples

Documentation

• Updated all command documentation in docs/commands/ to reference --provider
• Updated config file template with clearer comments and examples
• Added push command example to config template

Testing

• Enhanced test suite with backward compatibility test (internal/cmd/pull_test.go:351-405)
• Updated all existing tests to use new --provider flag
• Verified deprecated flag still functions correctly

Technical Details

The refactoring maintains full backward compatibility through a fallback mechanism:

1. Flag resolution order (in GetFlagSourceUrl):

   • New --provider flag (highest priority)
   • Deprecated --flag-source-url flag
   • New provider config key
   • Legacy flagSourceUrl config key (lowest priority)

2. Configuration handling: Template generation updated to use provider key while maintaining support for legacy configurations

Test Plan

• Verify --provider flag works on all commands (init, pull, push)
• Verify deprecated --flag-source-url still works with deprecation warning
• Verify config file with provider key works correctly
• Verify config file with legacy flagSourceUrl key still works
• Run all unit tests (28 tests updated)
• Verify documentation accuracy for all commands
• Test backward compatibility with existing configurations

[gemini-code-assist]

Summary of Changes

Hello @kriscoleman, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request refactors the OpenFeature CLI to standardize the naming of flag sources/destinations to 'provider'. This change enhances consistency and clarity across the CLI, making it more intuitive for users by aligning with established OpenFeature terminology. The implementation ensures a smooth transition by maintaining full backward compatibility for existing configurations and command-line usages, while guiding users towards the new, preferred naming convention.

Highlights

• CLI Flag Renaming: The --flag-source-url CLI flag has been renamed to --provider across all init, pull, and push commands for improved clarity and alignment with OpenFeature terminology.
• Configuration Key Update: The configuration key flagSourceUrl in .openfeature.yaml has been updated to provider.
• Backward Compatibility: Full backward compatibility is maintained for both the old --flag-source-url CLI flag and the flagSourceUrl configuration key, with deprecation warnings issued when they are used.
• Documentation and Testing: All command documentation has been updated to reflect the new --provider flag, and the test suite has been enhanced with backward compatibility tests and updated to use the new flag.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[gemini-code-assist]

Code Review

This PR is a solid refactoring that improves consistency and clarity by renaming --flag-source-url to --provider. The changes are well-implemented across all commands, documentation, and configuration. The inclusion of backward compatibility with a dedicated test for the pull command is excellent. I've made a couple of suggestions to further improve consistency in the CLI help text and to enhance test coverage. Overall, this is a high-quality contribution.