What is the OpenFeature Governance Committee?​

OpenFeature is a CNCF incubating project that defines an open standard for feature flagging. It provides a vendor-neutral API and SDKs so that teams can adopt feature flags without locking themselves into a specific platform.

The Governance Committee is responsible for steering the overall direction of the project — from the evolution of the standard itself to community health, contributor experience, and the long-term vision for the ecosystem. It's the group that makes sure OpenFeature stays open, collaborative, and useful for everyone building with it.

Previously, Thomas was part of the OpenFeature Technical Committee, contributing to the technical direction of the project. Joining the Governance Committee means taking on a broader responsibility: helping shape not just how OpenFeature works, but where it goes.

The 2026-2028 Board​

Thomas is honored to join a strong group of contributors and practitioners. The full board for the 2026-2028 term is:

Newly elected:

• André Silva (LexisNexis Risk Solutions) — maintainer of the OpenFeature .NET SDK and active contributor to OpenTelemetry
• Maks Osowski (Google) — building Google's OpenFeature-first feature flagging platform
• Thomas Poignant (Gens de Confiance) — creator and maintainer of GO Feature Flag
• Jonathan Norris (Dynatrace) — re-elected for a second term; former Co-Founder and CTO of DevCycle

Continuing members (2025-2027):

• Ben Rometsch (Flagsmith)
• Michael Beemer (Dynatrace)
• Pete Hodgson (Independent)

You can read the full announcement on the OpenFeature blog.

What this means for GO Feature Flag​

GO Feature Flag has been committed to the OpenFeature standard since its early days. The project ships native OpenFeature providers, supports OFREP (the OpenFeature Remote Evaluation Protocol), and follows the spec closely to ensure compatibility across the ecosystem.

Being on the Governance Committee means Thomas can contribute to the standard directly — bringing the perspective of a maintainer who runs a feature flagging solution in production, and who hears from users daily about what they need. It's an opportunity to make sure the standard evolves in ways that are practical, implementable, and genuinely useful for the teams building on top of it.

For users of GO Feature Flag, this is a signal of continuity: the project will remain deeply aligned with OpenFeature, and Thomas will be in a position to ensure the standard and the implementation stay in sync.

Let's keep building together​

Open source only works when people show up — as contributors, maintainers, users, and community members. Thank you to everyone who has supported GO Feature Flag and OpenFeature over the years. This role is one more way to give back to that community.

If you have thoughts on the direction of OpenFeature or GO Feature Flag, come share them on GitHub or the CNCF Slack #openfeature channel.

KubeCon + CloudNativeCon Europe 2026 in Amsterdam is behind us, and what a week it was. For GO Feature Flag, it was both an opportunity to represent the project on a big stage and to connect directly with the community in person.

Speaking at the Maintainer Track​

I had the privilege of presenting during the "OpenFeature Update From the Maintainers" session as part of the Maintainer Track on Wednesday. Alongside Lukas Reining, André Silva, and Alexandra Oberaigner, we shared the latest news from the OpenFeature ecosystem — including the OpenFeature MCP server, the new GitHub Action for flag cleanup, and the stable release of OFREP.

The slides from the session are available.

Governance Committee: Shaping the Future of OpenFeature​

As a member of the OpenFeature Governance Committee, a big part of the week was participating in focused in-person discussions with other maintainers and contributors. These conversations covered some of the most important topics on the project's roadmap.

Experimentation was a major theme. The group explored how OpenFeature can better support experimentation use cases — from standardized context fields and evaluation metrics in the SDK, to defining how grouped experiments map to flags. There's real momentum here and we should expect progress on this front through the rest of the year.

OFREP (the OpenFeature Remote Evaluation Protocol) is approaching its 1.0 milestone, targeted for Q2 2026. Discussions covered SSE-based change notifications to replace polling as the default, local caching for client-side SDKs, routing with targeting key hashes, and whether to introduce a tracking event endpoint. There was even a conversation about gRPC definitions for organizations that require it.

Growing the Technical Committee was also on the agenda. The consensus is that the TC needs to grow to at least 5 members (currently 3) to ensure broader representation and sustainable governance. The goal is to bring in contributors who are already active in the project.

You can read the full summary of all discussions in the official OpenFeature KubeCon EU 2026 recap published by the OpenFeature team.

Conversations with the GO Feature Flag Community​

Beyond the sessions and committee work, one of the most valuable parts of the week was simply talking with people. Conferences like KubeCon are a rare opportunity to have direct, unfiltered conversations with users — the folks who are running GO Feature Flag in production every day.

I was able to gather a lot of candid feedback: how people are using the solution, what patterns have emerged organically in the wild, where things work smoothly, and where there are rough edges. That kind of direct input is something you just can't replicate through GitHub issues or async Slack threads.

This is always one of the best parts of attending these events. A 10-minute conversation at a booth often contains more signal than weeks of async feedback. Thank you to everyone who stopped by, introduced themselves, or shared how they're using GO Feature Flag — it genuinely shapes the direction of the project.

See You Next Time​

Amsterdam was a great reminder of why in-person events matter for open-source projects. The OpenFeature ecosystem is growing, the conversations are maturing, and the roadmap ahead is exciting.

If you weren't able to make it to Amsterdam, keep an eye on the GO Feature Flag changelog and the OpenFeature community channels — a lot of what was discussed this week will be landing as issues, ADRs, and PRs over the coming months.

Want to get involved? Join us on the CNCF Slack #openfeature channel or check out the GO Feature Flag repository.

We are excited to introduce in-process evaluation for the GO Feature Flag OpenFeature server providers: Go, Java, .NET, Python, JavaScript, and TypeScript.

This capability is designed to improve evaluation performance and drastically reduce network traffic between your applications and the relay-proxy.

What changes with in-process evaluation?​

Previously, when you used the OpenFeature providers we ship, evaluation used remote evaluation: each flag evaluation triggered a network call to the relay-proxy.

That model fits many setups, but it is not always the most performant or resilient way to evaluate feature flags on hot paths.

That is why we are launching in-process evaluation mode for our most widely used providers.

How it works​

With in-process evaluation, the provider:

1. Periodically fetches the latest flag configuration from the relay-proxy.
2. Stores it locally in memory.
3. Evaluates flags directly inside your application process, using a shared evaluation engine so every provider behaves consistently.

Your flag checks no longer depend on a network round trip on the critical path.

But what about the evaluation data?​

Not calling the relay-proxy to evaluate your flag does not mean you lose observability.

The providers collect evaluation data from local evaluations and send it to the relay-proxy, so you can keep observing evaluations as before. For how events are recorded when evaluation runs in the provider, see flag usage tracking.

Performance gains in practice​

Moving evaluation in-process gives you immediate performance benefits:

• Lower latency: evaluations are local, so there is no request/response overhead per flag check.
• Higher throughput: your app can evaluate more flags with less pressure on the relay-proxy.
• Better resilience: short network hiccups have less impact on runtime flag evaluation.

Fewer network calls​

This is one of the biggest wins.

If your request path evaluates several flags, in-process mode can remove a lot of network calls and reduce infrastructure overhead.

Which providers support it?​

The in-process capability is available in the GO Feature Flag OpenFeature providers for:

• Go
• Java
• .NET
• Python
• JavaScript/TypeScript

How to enable it​

Each provider lets you choose an evaluation mode in-process (evaluate locally after syncing config) or remote (ask the relay-proxy on each evaluation)—through its configuration. The option names differ by language (for example, JavaScript and TypeScript use evaluationType with EvaluationType.InProcess or EvaluationType.Remote; Java and .NET expose evaluationType in their provider options with the same idea).

Use the documentation for your runtime above for exact types, defaults, and examples.

In-process or remote: how to choose?​

Use in-process when you want:

• the best runtime performance
• very low latency
• fewer network calls in hot code paths

Use remote evaluation when you want each evaluation to hit the relay-proxy so decisions are always tied to the latest server-side evaluation. That can be a good fit when network latency to the relay is negligible, for example, in a sidecar deployment where the proxy sits beside your app.

Final thoughts​

In-process evaluation gives you a strong reliability and performance boost while keeping the OpenFeature developer experience you already use today.

If your workload is latency-sensitive, this mode is a great default.

We're excited to announce a new feature in GO Feature Flag that makes API key management easier and more secure: Runtime API Key Updates! 🎉

We've heard from the community that having to restart the relay proxy for every API key update or rotation was a real pain point. Managing API keys is crucial for security, but needing a restart for each change led to unnecessary downtime and interruptions.
With this new feature, you can now update, rotate, and manage API keys on the fly—your relay proxy keeps running, and requests are served continuously, with no need for restarts.

🤔 The Challenge: API Key Management​

API keys are essential for securing access to your GO Feature Flag relay proxy. However, managing them has always been challenging:

• Key rotation required service restarts, causing downtime
• Adding new keys meant taking the service offline
• Removing compromised keys couldn't be done immediately
• No flexibility to respond quickly to security incidents

These limitations made it difficult to follow security best practices like regular key rotation and immediate response to security threats.

✨ Introducing Runtime API Key Updates​

GO Feature Flag starting v1.50.0 supports updating API keys at runtime without requiring a restart of the relay proxy.
This feature works in both default mode and flagset mode, giving you the flexibility to manage keys dynamically.

Key Benefits​

• ✅ Zero Downtime: Update keys without interrupting service
• ✅ Immediate Response: Remove compromised keys instantly
• ✅ Easy Rotation: Rotate keys as soon as you change your configuration file
• ✅ Flexible Management: Add, remove, or update keys as needed
• ✅ Automatic Detection: Changes are detected and applied automatically

🚀 How It Works​

The relay proxy continuously monitors your configuration file for changes. When it detects updates to API keys, it:

1. Validates the new configuration (if invalid your new configuration will be ignored)
2. Updates the internal API key mappings
3. Applies changes immediately
4. Continues serving requests without interruption

All of this happens automatically in the background, with no manual intervention required.

⚙️ Configuration Requirements​

Default Mode​

In default mode, only API keys can be updated at runtime:

• ✅ authorizedKeys.evaluation
• ✅ authorizedKeys.admin
• ❌ All other configuration changes are ignored

📝 Usage Example​

# Initial configuration
authorizedKeys:
  evaluation:
    - "key-1"
    - "key-2"
  admin:
    - "admin-key-1"

# Updated configuration (runtime update - no restart needed!)
authorizedKeys:
  evaluation:
    - "key-1"
    - "key-2"
    - "key-3"  # ✅ New key added
    - "key-4"  # ✅ Another new key
  admin:
    - "admin-key-1"
    - "admin-key-2"  # ✅ New admin key added

Flagset Mode​

In flagset mode:

• ✅ API keys for each flag set can be updated
• ✅ Flag sets must have a name configured
• ❌ Other flagset configuration changes are not supported

📝 Usage Example​

flagSets:
  - name: team-a  # ✅ Name is required for runtime updates
    apiKeys:
      - "team-a-key-1"
      - "team-a-key-2"  # ✅ Can add new keys at runtime
    retrievers:
      - kind: file
        path: /flags/team-a-flags.yaml

  - name: team-b
    apiKeys:
      - "team-b-key-1"
      # ✅ Can remove keys at runtime by removing them from the config
    retrievers:
      - kind: s3
        bucket: team-b-flags

🎯 Real-World Use Cases​

Use Case 1: Multi-Tenant Key Management​

Scenario: Managing API keys for multiple customers in flagset mode.

Solution: Update keys for individual flag sets independently. Each customer's keys can be managed separately without affecting others.

Use Case 2: Scheduled Key Rotation​

Scenario: Your security policy requires rotating API keys every 90 days.

Solution: Update the configuration file with new keys, keep old keys temporarily, migrate clients, then remove old keys—all without downtime.

Use Case 3: Team Onboarding​

Scenario: A new team needs access to a flag set.

Solution: Simply add their API key to the flag set configuration. No restart needed, and they can start using the service immediately.

📚 Learn More​

• 📖 Runtime Configuration Updates Documentation
• 📖 Flag Set Concepts
• 📖 Configuration Guide

🎉 Get Started Today​

Runtime API key updates are available in GO Feature Flag starting version v1.50.0! This feature makes API key management more secure, flexible, and convenient.

Whether you're rotating keys, responding to security incidents, or managing access for multiple teams, runtime updates ensure your feature flag service remains available and secure.

Resources​

• 💬 Community Discussions
• 🐛 Report Issues
• 📚 Full Documentation

We can't wait to see how this feature improves your API key management workflow! 🚀

(Screenshot from Grafana’s go.mod file showing GO Feature Flag)

This is a huge milestone for us. Grafana is one of the most widely used observability platforms in the world, relied upon by countless developers and organizations to monitor and visualize their systems. Seeing such a respected open-source project adopt GO Feature Flag is a strong validation of the reliability, performance, and simplicity of our solution.

A big thank you to our community and contributors for making this possible — and to the Grafana team for trusting our solution. ❤️

Here’s to safer rollouts, faster innovation, and more great open-source collaborations ahead! 🚀

We’re incredibly proud of this milestone, but it’s only the beginning. GO Feature Flag continues to evolve, and we’re committed to making it even easier for teams of all sizes to roll out new features with confidence.

If you’re curious about how GO Feature Flag can fit into your projects, check out our documentation or join our community. We’d love to hear from you!

We're excited to announce that we have released one of the most requested feature for GO Feature Flag.
It will revolutionize how you organize and manage your feature flags: Flag Sets! 🎉

As your applications grow and teams expand, managing feature flags can become increasingly complex. Different teams need their own flags, environments require separate configurations, and multi-tenant applications demand isolated flag management. That's exactly what Flag Sets are designed to solve.

🤔 What Are Flag Sets?​

Flag Sets are a powerful organizational feature in GO Feature Flag that allows you to group related feature flags into separate, isolated collections. Each flag set operates independently with its own:

• Configuration: Retrievers, exporters, and notifiers
• API Keys: Secure access control with dedicated authentication
• Flag Management: Complete isolation from other flag sets
• Data Tracking: Separate evaluation data and analytics

Think of flag sets as "virtual feature flag environments" within your single GO Feature Flag relay proxy instance.
They provide the organizational benefits of multiple instances while maintaining the simplicity of a single deployment.

✨ What are the benefits of flag sets?​

🏢 Team Isolation​

In modern software development, different teams often need to manage their own feature flags independently. With flag sets, you can:

• Team A: Manage application A feature flags: new-navigation, dark-mode, responsive-design.
• Team B: Manage application A feature flags: new-payment-api, caching-strategy, rate-limiting, dark-mode.
• ...

Each team gets their own isolated environment without interfering with others.

• You can have the same feature flag name with a different configuration.
• Team A cannot access to Team B feature flags.
• Each flag set can have a dedicated exporter.
• Each flag set can notify flag changes in a different place.

🏘️ Multi-Tenant Applications​

For applications serving multiple customers or organizations, flag sets provide perfect isolation:

• Each customer gets their own flag set.
• No risk of flag name collisions between customers.
• Isolated configurations and data tracking.
• Secure access control per customer.
• Routing to the flag set is based on API Keys.

⚙️ How Flag Sets Work​

Configuration Structure​

Flag sets are configured in your relay proxy configuration file, instead of defining your configuration on top level of the file we have introduce a new field called flagset.

In each flag set you can configure his behavior like in this example:

server:
  mode: http
  port: 1031
flagsets:
  - name: team-a
    apiKeys:
      - 'team-a-api-key-1'
      - 'team-a-api-key-2'
    retrievers:
      - kind: file
        path: /flags/team-a-flags.yaml
    exporters:
      - kind: s3
        bucket: team-a-evaluations
    notifiers:
      - kind: slack
        webhookUrl: 'https://hooks.slack.com/services/team-a-webhook'

  - name: team-b
    apiKeys:
      - 'team-b-api-key'
    retrievers:
      - kind: github
        repository: my-org/team-b-flags
        path: flags.yaml
    exporters:
      - kind: kafka
        topic: team-b-evaluations
    notifiers:
      - kind: discord
        webhookUrl: 'https://discord.com/api/webhooks/team-b-webhook'

  - name: team-c
    apiKeys:
      - 'team-c-api-key'
    retrievers:
      - kind: s3
        bucket: team-b-feature-flags
        item: flags.yaml
    exporters:
      - kind: file
        outputDir: /logs/team-c-evaluations
    pollingInterval: 1000

As you can see, you are able to configure every flag sets differently.

API Key-Based Routing​

The magic of flag sets lies in their API key-based routing system:

1. Extract API Key: The relay proxy extracts the API key from the X-API-Key header.
2. Find Flag Set: It looks up which flag set is associated with that API key.
3. Route Request: The evaluation request is routed to that specific flag set.
4. Return Result: The evaluation result comes from that flag set's flags.

This means you can have identical flag names across different flag sets without any conflicts ✨.

OpenFeature Provider Integration​

Using flag sets in your applications is straightforward. You simply initialize your providers with the correct API key.
All the providers have a way to pass the API Key to use, based on this one the relay proxy will route the request to the correct flag set.

Key Benefits of using flag sets​

🔒 Complete Isolation​

• No inheritance between flag sets
• Identical flag names can exist across different sets
• Independent configurations and data tracking

🔑 Secure Access Control​

• API key-based authentication for each flag set
• Multiple API keys per flag set for flexibility
• No cross-contamination between teams or customers
• Runtime API key updates: Update, add, or rotate API keys without restarting the relay proxy

🎯 Flexible Configuration​

• Each flag set can have its own retrievers, exporters, and notifiers
• Independent polling intervals and file formats
• Custom notification channels per team

📊 Separate Analytics​

• Evaluation data is tracked separately per flag set
• Independent export configurations
• Team-specific monitoring and alerting

Migration Guide​

If you're currently using a single GO Feature Flag configuration, migrating to flag sets is straightforward:

Option 1: Gradual Migration​

1. Ensure that all your providers are using API Keys to connect to GO Feature Flag.
2. Create a flag set and move your actual configuration inside it.
3. Associate your API Keys to the flag set.
4. Create extra flag sets and move flags over them.
5. Change the API Key used in your provider to point to the right flag set.

Option 2: Full Migration​

1. Create flag sets for each team or purpose.
2. Move all flags to appropriate flag sets.
3. Update all applications with new API keys.
4. Remove the old single configuration.

Get Started Today​

Flag Sets are available now in GO Feature Flag! Whether you're managing multiple teams, serving multiple customers, or just want better organization, flag sets provide the flexibility and isolation you need.

Resources​

• 📚 Flag Sets Documentation
• 🔧 Configuration Guide
• 💬 Community Discussions
• 🐛 Report Issues

We can't wait to see how you use Flag Sets to organize and scale your feature flag management! And please share your feedbacks ! 🚀

Talk: "Decouple Deployments and Releases with OpenFeature"​

In this presentation, Thomas explores how traditional deployment strategies often directly couple feature releases with code deployments, increasing risks and slowing time-to-market. He demonstrates how OpenFeature, a vendor-agnostic API for feature flagging, enables developers to separate feature releases from code deployments, providing precise control over feature visibility and experimentation.

What You'll Learn​

The talk covers several key concepts:

• Fundamental feature flagging concepts and how they transform development workflows
• OpenFeature integration and how it simplifies feature flag management across different providers
• Real-world use cases demonstrating the practical benefits of deployment/release decoupling
• Best practices for implementing feature flags effectively in development workflows
• Risk reduction strategies for safer and more controlled feature rollouts

Why This Matters​

In today's fast-paced development environment, the ability to deploy code without immediately releasing features to users has become crucial for:

• Reducing deployment risks by allowing features to be tested in production before user exposure
• Faster time-to-market through independent deployment and release cycles
• Enhanced experimentation capabilities with controlled feature rollouts
• Improved incident response with the ability to quickly disable problematic features

About PlatformCon 2025​

PlatformCon is the premier conference for platform engineering, bringing together industry experts to share insights on building and scaling development platforms. Thomas's talk was part of the conference's focus on modern development practices and tooling that enable engineering teams to ship software more effectively.

Learn More About GO Feature Flag​

If you're interested in implementing feature flags in your own projects, check out:

• GO Feature Flag Documentation - Get started with our open-source feature flag solution
• OpenFeature Integration - Learn how to use GO Feature Flag with OpenFeature
• Best Practices Guide - Understand how to implement feature flags effectively

Have questions about feature flagging or want to share your own experiences? Join our community discussions or reach out to Thomas on GitHub or LinkedIn.

What is Exporter Metadata?​

Exporter metadata is an object you can configure when initializing your GO Feature Flag provider for OpenFeature.

It allows you to specify a set of static information that you want to consistently include with all your evaluation events. A good example of information you might include in exporter metadata is the environment in which your application is running, the version of the application or anything that helps you when you analyze your evaluation data.

This data is then forwarded to the exporter and incorporated into your feature events as a new field called metadata.

Why Use Exporter Metadata?​

Including exporter metadata in your evaluation events offers several advantages:

• Enhanced Context: By adding static information to your events, you can provide richer context for analysis. This can include details about the environment (e.g., development, staging, production), the application version, or any other relevant data that sheds light on feature usage patterns.
• Improved Observability: With exporter metadata, you gain a more comprehensive view of feature evaluation across different contexts. This can be particularly useful for debugging purposes or identifying trends in feature adoption for specific environments or application versions.
• Simplified Data Enrichment: Exporter metadata eliminates the need to manually inject context information into every evaluation event. This streamlines your code and ensures consistency in the data you collect.

How to Use Exporter Metadata​

In all providers that support exporter metadata, you can pass a map of key-value pairs to the ExporterMetadata field in the provider's configuration. Value can be a string, a bool, an int or a float64.

This map will be included in all evaluation events sent to the exporter and added to the metadata field by the exporter.

Here's an example of how you can configure exporter metadata in the Kotlin provider:

val options =
    GoFeatureFlagOptions(
        endpoint = "https://mygoffserver.com/",
        exporterMetadata = mapOf("device" to "Pixel 4", "appVersion" to "1.0.0")
    )

val provider = GoFeatureFlagProvider(options)

In this example, we're passing some information that can help to understand the context of the evaluation events such as the device type and the appVersion.

With this configuration, all evaluation events sent to the exporter will include the metadata field with the specified key-value pairs. And it will look like this:

{"kind":"feature","contextKind":"user","userKey":"4f433951-4c8c-42b3-9f18-8c9a5ed8e9eb","creationDate":1737465936,"key":"REDIRECTION","variation":"on","value":true,"default":false,"version":"","source":"PROVIDER_CACHE", "metadata": {"device": "Pixel 4", "appVersion":"1.0.0", "openfeature": true, "provider": "android"}}

Which Providers Support Exporter Metadata?​

To be able to use exporter metadata, you need to use the relay-proxy in version v1.41.1 or above and as minimum the following version of the providers:

• Kotlin: v0.3.0
• Web: v0.2.4
• Swift: v0.3.0
• Java: v0.4.2
• NodeJS: v0.7.5
• PHP: 1.1.0
• Ruby: 0.1.3
• Python: v0.4.1
• .NET: 0.2.1
• GO: v0.2.3

Conclusion​

Exporter metadata provides a powerful mechanism to enrich your evaluation events with static information in the GO Feature Flag provider for OpenFeature. By incorporating this functionality, you can gain deeper insights into feature usage patterns and streamline your data collection process.

This blog post has provided a brief introduction to exporter metadata. We encourage you to experiment with this feature and explore its potential to enhance your feature flag evaluation practices.

In order to follow the guidance of the guava team, we have decided to migrate the internal cache of the Java provider from guava to caffeine.

This may create a breaking change for you if you were using a custom cache configuration with the guava cache in your provider.
Because of this, the cache configuration on GoFeatureFlagProviderOptions that used Guava's CacheBuilder is now handled by Caffeine.

How to migrate​

Configuration cache with Guava used to be like this:

import com.google.common.cache.CacheBuilder;
// ...
CacheBuilder guavaCacheBuilder = CacheBuilder.newBuilder()
  .initialCapacity(100)
  .maximumSize(2000);

FeatureProvider provider = new GoFeatureFlagProvider(
  GoFeatureFlagProviderOptions
  .builder()
  .endpoint("https://my-gofeatureflag-instance.org")
  .cacheBuilder(guavaCacheBuilder)
  .build());

OpenFeatureAPI.getInstance().setProviderAndWait(provider);

// ...

Now with Caffeine it should be like this:

import com.github.benmanes.caffeine.cache.Caffeine;
// ...
Caffeine caffeineCacheConfig = Caffeine.newBuilder()
  .initialCapacity(100)
  .maximumSize(2000);

FeatureProvider provider = new GoFeatureFlagProvider(
  GoFeatureFlagProviderOptions
  .builder()
  .endpoint("https://my-gofeatureflag-instance.org")
  .cacheConfig(caffeineCacheConfig)
  .build());

OpenFeatureAPI.getInstance().setProviderAndWait(provider);

// ...

For a complete list of customizations options available in Caffeine, please refer to the Caffeine documentation for more details.

To better serve our users' diverse needs, we've decided to split the previous Go provider into two distinct providers:

• go-feature-flag: For use with the GO Feature Flag relay proxy.
• go-feature-flag-in-process: For direct integration of GO Feature Flag into your application.

Why the Split?​

The decision to create separate providers was driven by several factors:

• Distinct Use Cases: It's uncommon for users to require both the relay proxy and in-process capabilities simultaneously.
• Dependency Management: The in-process provider introduces additional dependencies, which can complicate integration.
• Maintainability: Managing two distinct functionalities within a single provider proved challenging.

By separating these functionalities, we've streamlined the integration process and enhanced overall maintainability.

We also use this split to rewrite from scratch the provider to increase the quality of the OpenFeature integration.

Choosing the Right Provider​

To select the appropriate provider for your application, consider the following:

• go-feature-flag: Ideal for multi-language environments using the GO Feature Flag relay proxy. This provider offers a lightweight integration with minimal dependencies, ensuring consistency with other language-specific providers.
• go-feature-flag-in-process: Best suited for Go-only applications that prefer a direct integration without the overhead of a separate service.

Breaking Changes​

As you may imagine, this split comes with some breaking changes, but we've done everything possible to limit it as much as possible. Please be aware of the following breaking changes:

• Existing go-feature-flag users: If you were previously using the go-feature-flag provider with the Go module, you'll need to transition to the go-feature-flag-in-process provider.
• Configuration Changes: The HTTPClient interface has been removed from the configuration in favor of using the standard http.Client (This should have no impact on the way to pass the http client in the options).
• Cache Compatibility: If you are using the in-memory cache of the provider, ensure your relay proxy is updated to version 1.32.0 or later, if not the cache will not work as expected and you may have an increase on the number of connection to the relay-proxy.

We understand that these changes may require adjustments to your existing setup. We recommend carefully reviewing the updated documentation for both providers to ensure a smooth transition.

Next Steps​

We encourage you to explore the new providers and leverage the enhanced features they offer. If you encounter any issues or have feedback, please don't hesitate to open an issue.

We're committed to providing you with the best possible feature flagging experience.

Effective management of the feature flag lifecycle is crucial for maximizing the value of feature flags within an organization.

This presentation is covering the following key areas:

• Feature flag lifecycle: Understanding the complete journey of a feature flag.
• Roles and responsibilities: Identifying who owns each phase of the lifecycle.
• Feature flag naming conventions: Best practices for clear and consistent flag identification.
• Preventing flag debt: Strategies for avoiding the accumulation of unused or obsolete flags.
• Involving project managers: The importance of project management collaboration in feature flag initiatives.

By understanding these concepts, you can optimize your feature flagging strategy and drive business success.

Why Mobile Feature Flags Matter?​

Mobile app development is a fast-paced world where agility is key. Traditional release cycles can be lengthy and risky. Feature flags provide a dynamic solution by allowing you to control feature visibility without redeploying your app.

This translates to:

• Faster time-to-market: Experiment with new features and iterate quickly based on user feedback.
• Reduced risk: Gradually roll out features to minimize potential issues and impact.
• Enhanced control: Turn features on or off in real-time based on user segments or other criteria.

How GO Feature Flag Delivers for Mobile​

To bring feature flags to mobile, we've fully embraced the OpenFeature standard.

This means:

• Native support for iOS and Android: A provider for each platform ensures seamless integration with the OpenFeature SDKs in your mobile app's core.
• React Native compatibility: With the usage of GO Feature Flag web provider and the OpenFeature React SDK you can now manage feature flags within your React Native app using familiar JavaScript syntax.

Diving Deeper into the Tech​

When it comes to client side, on the 3 platforms we are using the OpenFeature static paradigm (client side SDK). What does it means? The key distinction between the client- and server-side feature flagging is the difference in how often evaluation context changes.

When on your mobile device, your evaluation context is changing very rarely since the device is linked to a user. Also, in the client, you expect a very low latency to get the value of your flag. Based on this idea, the GO Feature Flag providers will retrieve your set of flags and cache them on the device, so you can evaluate them without any network call.

If you want to read more about the OpenFeature static paradigm, you can read this article from Pete Hodgson in the OpenFeature blog.

For those interested in the technical details, let's explore how this integration works in this sequence diagram:

As you can see, the provider is keeping all the flags in memory to serve them as fast as possible without any network call.

How to integrate GO Feature Flag into your mobile app?​

Ready to supercharge your mobile app development with GO Feature Flag? Here's how to get started:

• Integrate the OpenFeature SDK into your iOS project
• Integrate the OpenFeature SDK into your Android project
• Integrate the OpenFeature SDK into your React Native project

Our comprehensive documentation provides detailed instructions and examples to guide you through the process.

The Future of Feature Flags​

We're excited about the potential of feature flags to transform mobile app development. With GO Feature Flag's expanded support, we're empowering developers to build better, faster, and more reliable apps.

Stay tuned for future updates as we continue to enhance our platform and explore new possibilities.

Do you have already integrate GO Feature Flag in your mobile app? Let us know your experience in our Slack channel or on X.

We're excited to announce that GO Feature Flag is now one of the first flag management systems to support the Open Feature Remote Evaluation Protocol (OFREP) (currently in an experimental stage).

This is a significant step towards the adoption of Open Feature, a community-driven initiative aiming to standardize feature flag management across different platforms.

What is OFREP?​

OFREP is an API specification that allows you to connect your applications to any feature flag management system that supports the protocol using generic providers. This means more flexibility and choice when it comes to managing your features.

For the full technical details, you can head over to the Open Feature Protocol documentation: Open Feature Protocol: https://github.com/open-feature/protocol/blob/main/README.md

Why is this exciting?​

While OFREP is still under development, its potential is significant. By integrating with OFREP, GO Feature Flag positions itself for:

• Platform Independence: Easily connect your applications to different feature flag systems without code changes (once OFREP is widely adopted).
• Flexibility: Choose the feature flag management solution that best suits your needs (future benefit).
• Standardization: Foster collaboration and interoperability within the developer community (future benefit).

Open Feature Providers: A Call to Action!​

While OFREP itself is in its experimental stages, Open Feature Providers are still in the Proof-of-Concept (POC) phase. This is a fantastic opportunity for developers and organizations to contribute to building this ecosystem.

If you're passionate about feature flagging and want to be part of the Open Feature revolution, we encourage you to reach out and get involved!

Let's move forward, together!​

We at GO Feature Flag believe that OFREP has the potential to pave the way for a more unified and efficient approach to feature management. By joining the Open Feature movement, we hope to empower developers and create a stronger feature flagging landscape for everyone.

Stay tuned for further updates as we continue to explore the possibilities of OFREP.

Want to test it?​

If you want to test it, go to our documentation and start using it today!

But what happens when things don't go as planned? What if a new feature causes unforeseen issues or negatively impacts your users?

This is where feature flags come to the rescue, offering a safety net that allows you to roll back features immediately without waiting for a deployment. In this blog post, we'll explore why feature flags are an essential tool for securing your software releases.

The old way of doing rollbacks​

If you are not using feature flags, your release process probably look like this:

1. You code your new feature.
2. Your CI/CD is in charge to put your code in production.
3. Your new feature is available to all your users.

BUT what happen if your releases needs to be rollback?

You will most likely use the same process and go with something like

1. Revert your code and push the code.
2. Your CI/CD is in charge to put your code in production.
3. Your rollback is effective.

Don't get me wrong this works, and you are probably doing it for years, but here are some problems your may occur while doing it:

• You have to identify what was changed and rollback the code to rollback the code associated to your feature.
• If you are unlucky, your main branch has changed since your last deployment, so coming back to the previous state may require to rollback more than your feature, and it can impact other teams.
• Depending on your deployment pipeline it can take minutes to hours to push your rollback in production.

Secure your release using feature flags​

How feature flags can help here?​

The main things we try to achieve here is to unlink deploy and release. Changing your release process with feature flags is important if you want to secure your way to release new feature in your application.

To achieve this we will follow these steps:

1. Create a dedicated feature flag for this feature. This flag should be independent of other flags and only control the state of this new feature.
2. In your application's codebase, implement checks that will monitor the state of the flag. This can usually be done with the usage of a boolean flag. If the flag is set to "false" the code should disable the feature's functionality.
3. When deploying the feature to production, ensure that the flag is initially set to false position for 100% of your users.
4. When you are ready to release the new feature, set the feature to true position for a part of your users.
5. Monitor the feature's performance closely during its initial release.

BUT what happen if your releases needs to be rollback?​

Now that we have a flag for our new feature it makes our life way easier to rollback this new feature, because as you guess we only have to put back the flag to 0% of our users and the feature will not be available anymore.

How to do this with GO Feature Flag?​

1. Create a new flag

my-new-feature:
  variations:
    enabled: true
    disabled: false
  defaultRule:
    percentage:
      enabled: 0
      disabled: 100

As you can see the flag my-new-feature will be off for all your users.

2. Wrap your new feature with the check of the flag

    evalCtx := of.NewEvaluationContext("d45e303a-38c2-11ed-a261-0242ac120002")
    if client.BooleanValue(ctx, "my-new-feature", false, evalCtx){
      // code of my new feature ...
    }

This example use the OpenFeature GO SDK syntax, but you can do it in any language.

3. Deploy your code in production.
4. When you are ready to release, edit your flag configuration file to add traffic.

my-new-feature:
  variations:
    enabled: true
    disabled: false
  defaultRule:
    percentage:
      enabled: 100
      disabled: 0

5. 🚨 If you find a bug and you want to rollback, just edit the flag configuration file again and your feature will be rollback.

my-new-feature:
  variations:
    enabled: true
    disabled: false
  defaultRule:
    percentage:
      enabled: 0
      disabled: 100

6. Your feature will be rollback immediately and the good part is that you don't even have deployed anything.

Conclusion​

In the dynamic world of software engineering, ensuring the security of your releases is paramount.
Feature flags offer a powerful mechanism for immediate rollbacks, reducing the risk associated with introducing new features.

By embracing feature flags, you can respond swiftly to issues, minimize downtime, and make informed decisions based on real-time data.
The result is a more robust and user-friendly software release process that enhances both the development team's confidence and the end-users' experience.

So, don't wait—start incorporating feature flags into your development workflow today and unlock the potential for secure and successful releases.

Welcome to this tutorial on using feature flags in Node js with GO Feature Flag and Open Feature SDKs.

In this video, we'll walk you through the process of implementing feature flags in your Node js applications, allowing you to roll out new features gradually and control their visibility in real-time.

Setup GO Feature Flag​

Before we proceed with the implementation, it's essential to set up GO Feature Flag to efficiently evaluate our flags. To achieve this, we will create a new file called goff-proxy.yaml that will contain the configuration on how to retrieve our feature flags' configuration file.

In this file, we will first configure where to retrieve the flags and also a polling interval (here 5000 milliseconds).
It means that GO Feature Flag will read the file every 5 seconds to check if your configuration has changed.

retriever:
  kind: github  # type of retriever we are using
  repositorySlug: thomaspoignant/demo-goff  # repository we are retrieving
  path: flags.yaml  # location of the file in the repository
pollingInterval: 5000  # Time in milliseconds we wait before trying to check for changes

Create our first flag​

To create our flag we start by using the GO Feature Flag editor, for our test we will create a flag named my-new-feature and it will use a type boolean.

When it is ready you can copy/paste the flag definition and commit it in GitHub.

Start GO Feature Flag​

We will now start GO Feature Flag, for this we gonna use the docker image.

docker run -p 1031:1031 -e RETRIEVER_TOKEN=$GITHUB_TOKEN -v $(pwd):/goff thomaspoignant/go-feature-flag

With this command we launch GO Feature Flag on the port 1031 and with the configuration file we just created, you can also see that we provide a GitHub Token, this is to avoid being rate limited by the Github API.

GO Feature Flag is now started, and we can see that our flag is loaded.

Create Node.JS application using OpenFeature​

Now let's start to create our Node JS application.

import { GoFeatureFlagProvider } from "@openfeature/go-feature-flag-provider"
import { EvaluationContext, OpenFeature } from "@openfeature/js-sdk"

async function main(){
  // We start by creating an instance of the Go Feature Flag Provider
  // We are just setting the endpoint to connect to our instance of GO Feature Flag
  const provider = new GoFeatureFlagProvider({
     endpoint: 'http://localhost:1031'
  })

  // We associate the provider to the SDK
  // It means that now when we call OpenFeature it will rely on GO Feature Flag as a backend.
  OpenFeature.setProvider(provider)
  
  // We need to ask for a client to evaluate the flags.
  const client = OpenFeature.getClient()

  // We create a context for our evaluation.
  const ctx: EvaluationContext = {
     targetingKey: 'aae1cb41-c3cb-4753-a117-031ddc958f82'
  }

  // We evaluate the flag.
  const myNewFeature = await client.getBooleanValue("my-new-feature", false, ctx)

  if (myNewFeature) {
    // the new feature is available
  } else {
    // apply the old feature
  }
}

main()

You are now ready to use GO Feature Flag in your application.

Conclusion​

In this tutorial we've seen how simple it is to use GO Feature Flag in your Node.JS application using the OpenFeature SDK.

I encourage you to read our documentation to see all the amazing possibility that you will have.

And please provide us feedbacks on how we can make your experience even better.

In the ever-evolving world of software development, feature flag solutions have become instrumental in enabling continuous integration and deployment. These solutions allow developers to toggle features on and off without deploying new code, providing flexibility and control over feature releases.

But sometimes you need to give context about your flag, is it linked to an issue? Do you need a precise description? ... To respond to this, GO Feature Flag has recently introduced an exciting new feature: the ability to add metadata to each flag configuration.

With the version v1.11.0 of GO Feature Flag, developers can now add valuable metadata to their flag configurations. This metadata serves as additional information linked directly to each flag, allowing for a more comprehensive understanding of its purpose and context. This metadata can include essential details such as issue tracker links, descriptions, or any other information that developers deem relevant.

Improved Code Efficiency​

The inclusion of metadata in flag configurations brings substantial benefits in terms of code efficiency and reusability. By using the VariationDetails functions, developers can easily retrieve the associated metadata when working with the flag.

This eliminates the need for additional queries or requests to obtain essential information related to a specific flag. Developers can conveniently leverage this information within their code, leading to streamlined development processes and improved overall efficiency.

How to add the metadata?​

We have introduced a new field in the configuration of your flag

example_flag:
  variations:
    A: true
    B: false
  defaultRule:
    variation: B
  metadata:
    description: this is a super simple example feature flag
    issue-link: https://jira.xxx/GOFF-01

Now that you have this field available you can read the metadata in your VariationDetails when the evaluation is done.

GO Feature Flag relay-proxy also enable seamless access to the added metadata.

Open Feature SDK Compatibility​

To further enhance the usability and compatibility of GO Feature Flag, the new metadata feature aligns with the v0.6.0 version of the Open Feature specification. This update ensures that the metadata can be retrieved seamlessly using the Open Feature SDKs.

As soon as the SDKs will compatible with the metadata we will support it in the different GO Feature Flag providers.

Conclusion​

The introduction of metadata support in GO Feature Flag marks a significant milestone in feature flag solutions. Enabling developers to attach relevant information directly to their flag configurations opens up new possibilities for enhanced flag management and streamlined development processes. With the ability to retrieve metadata, developers can access essential information with ease.

The compatibility with the Open Feature SDK further solidifies the integration capabilities and ensures seamless utilization of metadata throughout the development cycle. Embrace the power of metadata and unlock a new level of control and efficiency in your feature flag management with GO Feature Flag's latest update.

GO Feature Flag Relay Proxy is a powerful tool that enables you to evaluate your feature flags without deploying code changes. It allows you to test and roll out new features to your users gradually, and to monitor the performance of your code in real-time.

With the recent release of version v1.7.0, GO Feature Flag Relay Proxy introduces a new feature that enhances the security of your feature flag evaluations. This new feature allows you to control who can access your relay proxy by configuring API Keys.

Limiting Access with API Keys​

With the release of GO Feature Flag Relay Proxy version v1.7.0, you can now limit access to the relay proxy by configuring API Keys. This feature allows you to restrict access to only known clients, adding an additional layer of security to your feature flag evaluations.

To enable this feature, you need to add a list of API Keys to your configuration. Only requests with these API Keys will be accepted. This means that any requests without a valid API Key will be rejected.

In your relay proxy configuration file it will look like this:

# ...
# List of authorized API keys.
# Each request will need to provide one of authorized key inside a X-API-Key header with format` X-API-Key: <api-key>`.
# There will be no authorization when this config is not configured.
apiKeys:
  - 6147795c-4438-44f1-8ab2-18cb3fa9591f # apiKey for client 1
  - 3e3fb534-c8fd-42e9-8f2e-c80276b1685c # apiKey for client 2
  - 6603f9f8-2871-4149-81e8-8a362a8ae266 # apiKey for client 3
  - 0fc30ffe-b9bc-4398-a9f1-6f8b8486e8ce # apiKey for client 4
  - 500d222e-2654-41a4-bd31-e24a629cb78a # apiKey for client 5

# ...

Using Client API Keys with Openfeature Providers​

If you are using Open Feature and our providers, we have updated them to handle the apiKey for you. You can now specify your apiKey directly when you are initializing your provider. This will authenticate every request to the relay proxy with this apiKey.

To use this feature, you need to specify the client API Key in your Open Feature provider initialization. This can be done by adding the apiKey like this:

provider, err := gofeatureflag.NewProvider(gofeatureflag.ProviderOptions{
  //...
  APIKey:   "6147795c-4438-44f1-8ab2-18cb3fa9591f",
})

GoFeatureFlagProviderOptions options = new GoFeatureFlagProviderOptions{
    // ...
    ApiKey = "6147795c-4438-44f1-8ab2-18cb3fa9591f"
  }

GoFeatureFlagProvider authenticatedProvider = new GoFeatureFlagProvider(options);

GoFeatureFlagProviderOptions options =
      GoFeatureFlagProviderOptions.builder()
      .apiKey("6147795c-4438-44f1-8ab2-18cb3fa9591f")
      .endpoint(relayProxyAuthenticatedEndpoint)
      .build();

GoFeatureFlagProvider provider = new GoFeatureFlagProvider(options);

const goFeatureFlagProvider = new GoFeatureFlagProvider({
  // ...
  apiKey: '6147795c-4438-44f1-8ab2-18cb3fa9591f'
});

Conclusion​

The new feature of GO Feature Flag Relay Proxy 1.7.0 allows you to limit access to your relay proxy by configuring API Keys.

This adds an extra layer of security to your feature flag evaluations, ensuring that only known clients can access your relay proxy.

This feature is easy to configure and can be set up in a matter of minutes, giving you peace of mind knowing that your feature flags are secure.

Feature flags are a powerful tool for software development, allowing for more flexible and adaptable development processes.

However, to get the most out of feature flags, it's important to follow some best practices to ensure they are used effectively and efficiently.

🤷 Keep flags simple and scoped​

One of the most important best practices for feature flags is to keep them simple and scoped.

This means avoiding overly complex flags that do too much, and instead using small, targeted flags that can be easily managed and maintained. Keeping flags simple and scoped helps to avoid confusion and reduces the risk of bugs or other issues.

⏰ Avoid using flags as a long-term solution​

Another important best practice is to avoid using feature flags as a long-term solution.

Feature flags should be used as a temporary measure to test new features or functionality, and then removed once the feature is fully tested and released.

Leaving flags in place for too long can lead to code bloat and confusion, making it harder to maintain and update your codebase.

🧪 Test and monitor flags​

Testing and monitoring flags is essential to ensuring they are working as intended.

This means setting up a testing environment where you can test flags in a controlled environment, as well as monitoring the usage of flags in production to ensure they are not causing any issues.

By testing and monitoring flags, you can catch any issues early and avoid potential problems down the line.

🎯 Centralize your feature flags in a single location​

Centralize your feature flags in a single location, such as a feature flag management system (GO Feature Flag is here to help you), to make it easier to manage and track them across different applications and environments.

This can help avoid conflicts and inconsistencies, improve collaboration among teams, and reduce the risk of introducing bugs or unintended consequences.

It also helps to use the same flag for multiple applications and to be able to act on a distributed systems.

📝 Document flags and their purpose​

Documenting flags and their purpose is another best practice that can help to avoid confusion and ensure that everyone on the team is on the same page.

This means providing clear documentation for each flag, including its purpose, when it should be used, and any relevant notes or instructions. This can help to prevent misunderstandings and ensure that flags are used correctly.

🔨Use feature flags in combination with other tools​

Finally, it's important to remember that feature flags are just one tool in your development toolbox.

To get the most out of feature flags, it's important to use them in combination with other tools, such as testing frameworks, monitoring tools, CI/CD, and version control systems.

By using feature flags in combination with other tools, you can create a more comprehensive and effective development process.

Conclusion

Following these best practices can help to ensure that your feature flags are used effectively and efficiently, allowing you to take full advantage of the benefits they offer.

By keeping flags simple and scoped, avoiding long-term use, testing and monitoring flags, documenting flags and their purpose, and using feature flags in combination with other tools, you can create a more flexible and adaptable development process that can help you to stay ahead of the competition.

We've got good news for you GO feature flag now supports multiple configuration flags! Plus, we've added a new feature that allows all files to be loaded in parallel, making it faster and more efficient.

Managing feature flags can be a challenging task, especially as your application grows and becomes more complex. With multiple configuration flags, you can easily manage different feature flag configurations for different apps, user groups, or any other criteria that you need. You can also use the same flags for multiple features, making it easier to maintain and update your code.

In addition to multiple configuration flags, we've also ensured that all files are downloaded in parallel. This means that your feature flag configurations will be downloaded faster and more efficiently, improving the performance of your application.

How to configure multiple flag configuration files​

To configure GO Feature Flag using multiple configuration flags files, simply create multiple files and store them in your favorite place.

Then, use the field retrievers in your configuration to configure all the access to your configuration flags.

# ...
retrievers:
  - kind: http
    url: https://raw.githubusercontent.com/thomaspoignant/go-feature-flag/main/examples/retriever_file/flags.yaml
  - kind: file
    path: /local/flag-file.yaml   # Example of local path
  - kind: http   # you can have multiple time the same type of retriever
    url: https://raw.githubusercontent.com/thomaspoignant/go-feature-flag/main/testdata/flag-config.yaml

# Before we were using the field retriever that allows only one retriever at the time
# 
# retriever:
#   kind: http
#   url: https://raw.githubusercontent.com/thomaspoignant/go-feature-flag/main/examples/retriever_file/flags.yaml

err := ffclient.Init(ffclient.Config{
  // ...
  Retrievers: []retriever.Retriever{
    &fileretriever.Retriever{
      Path: "examples/retriever_multiple_config_files/flags.yaml",
    },
    &fileretriever.Retriever{
      Path: "examples/retriever_multiple_config_files/flags2.yaml",
    },
  },
  //...

  // Before we were using the field retriever that allows only one retriever at the time
  //
  // Retriever: &fileretriever.Retriever{
  //     Path: "examples/retriever_multiple_config_files/flags.yaml",
  // },
})

What happen if 2 files have the same flag?​

We are taking all the configuration files in the order of the retrievers. It means than the latest version of your flag will be the one from the latest file.

Conclusion​

We believe that multiple configuration flags and parallel downloads will make it easier for you to manage your feature flags and provide more flexibility to your development process. We hope you find these features useful, and we look forward to hearing your feedback!

If you have any questions or comments, please don't hesitate to reach out to us. We're always happy to help!

Introducing go-feature-flag-lint​

Managing feature flags can be challenging, especially when it comes to configuring them correctly. With our new command line go-feature-flag-lint, we are providing a tool that helps you avoid making mistakes in your feature flag configuration.

To use the feature flag configuration linting feature, simply run the command line, it will analyze your configuration to ensure that it is free of errors. If there are any issues, go-feature-flag-lint will provide you with a detailed report that identifies the problem to help you to fix it.

To get the maximum benefit from this feature, we recommend integrating it into your CI/CD pipelines to catch any issues before they make it to production.

The benefits of using our feature flag configuration linting feature, along with integrating it into your CI/CD pipelines, include:

• Ensuring that your feature flag configuration is correct, which will reduce the risk of issues and errors in your application.
• Saving time and effort by automating the process of checking your feature flag configuration.

Configure your CI/CD pipelines​

Integrating the feature flag configuration linting into your CI/CD pipeline is simple. First, you will need to install the go-feature-flag-lint CLI tool, which can be used to run the linting process. Next, you can add a new step to your pipeline that runs the go-feature-flag-lint CLI tool to lint your feature flag configuration file.

If there are any issues detected, the CLI tool will exit with a non-zero status code, which will cause your pipeline to fail. By integrating the feature flag configuration linting into your CI/CD pipeline, you can catch any issues with your feature flag configuration before it is deployed to production, reducing the risk of errors and issues.

Here's some examples of how to integrate the feature flag configuration linting into a CI/CD pipeline for popular CI/CD services:

name: "Build"
on:
  push:
    branches:
      - main
  pull_request:
    types: [ opened, synchronize, reopened ]

jobs:
  Lint:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v3

      - name: Download go-feature-flag-lint
        run: curl -L $(curl -s https://api.github.com/repos/thomaspoignant/go-feature-flag/releases/latest | jq -r '.assets[] | select(.name|match("Linux_x86_64.tar.gz$")) | .browser_download_url' | grep 'go-feature-flag-lint') --output release.tar.gz && tar -zxvf release.tar.gz

      - name: Run go-feature-flag-lint
        run: ./go-feature-flag-lint --input-format=yaml --input-file=flag-config.yaml # please put the right file name

version: 2.1
jobs:
  build:
    docker:
     - image: cimg/base:2022.05

    steps:
      - checkout
      - run: curl -L $(curl -s https://api.github.com/repos/thomaspoignant/go-feature-flag/releases/latest | jq -r '.assets[] | select(.name|match("Linux_x86_64.tar.gz$")) | .browser_download_url' | grep 'go-feature-flag-lint') --output release.tar.gz && tar -zxvf release.tar.gz
      - run: ./go-feature-flag-lint --input-format=yaml --input-file=flag-config.yaml # please put the right file name

image: ubuntu
lint-job:
  stage: build

  before_script:
    - apt-get -qq update
    - apt-get install -y jq curl

  script:
    - curl -L $(curl -s https://api.github.com/repos/thomaspoignant/go-feature-flag/releases/latest | jq -r '.assets[] | select(.name|match("Linux_x86_64.tar.gz$")) | .browser_download_url' | grep 'go-feature-flag-lint') --output release.tar.gz && tar -zxvf release.tar.gz
    - ./go-feature-flag-lint --input-format=yaml --input-file=flag-config.yaml # please put the right file name

Conclusion​

We are thrilled to be introducing this new feature, which we believe will make a significant difference in how our users manage their feature flags. With the introduction of feature flag configuration linting, we are providing a tool that will make it easier for you to manage your feature flags and get the most out of GO Feature Flag.

If you have any questions about this feature or would like more information, please don't hesitate to get in touch with our support team. We're always here to help!