jeskew
Repos
39
Followers
136

Events

closed issue
Add the ability to enable/disable preview features through Bicep config

It would be helpful to give users the ability to preview new functionality through a switch in the bicepconfig.json.

Created at 14 hours ago

Add support for sourcing feature flags from bicepconfig.json (#8559)

  • Add support for sourcing feature flags from bicepconfig.json

Also emit a deprecation notice when a feature flag is sourced from an environment variable.

  • Leave only bicepconfig.json as a feature flag source

  • Use fixed property names in Config.ExperimentalFeaturesEnabled

  • Cleanup diff

  • Fix failing tests

  • Update bicepconfig.json schema

Created at 14 hours ago
delete branch
jeskew delete branch jeskew/source-feature-flags-from-config
Created at 14 hours ago
pull request closed
Add support for sourcing feature flags from bicepconfig.json

Resolves #7955

~~This PR updates Bicep's feature flag façade to support multiple sources and adds two more: configuration via bicepconfig.json files and CLI arguments. The existing feature flag environment variables are still supported, but they may be overridden with a CLI argument, and if a feature is not explicitly enabled or disabled via CLI args or environment variables, the appropriate bicepconfig.json file for the template/module being compiled will be queried.~~

This PR updates IFeatureProvider to read from bicepconfig.json instead of the currently supported environment variables.

As a consequence of reading bicepconfig.json for feature flags, we can no longer associated an IFeatureProvider with a Compilation instance but must instead bind feature providers to the Compilation's constituent SemanticModel instances, as each bicep file may have different features enabled or disabled depending on its location on disk. The same is true of IApiVersionProvider, which takes an IFeatureProvider as a constructor argument.

Microsoft Reviewers: Open in CodeFlow
Created at 14 hours ago
opened issue
Consolidate CLI warnings about experimental features
    As a follow-up item, I think we should converge on a single message that covers enablement of all experimental features.

Originally posted by @anthony-c-martin in https://github.com/Azure/bicep/pull/8559#discussion_r987323686

Created at 15 hours ago
opened issue
Remove `RegistryEnabled` feature flag
    Should we remove this? (feel free to create a follow-up issue)

Originally posted by @anthony-c-martin in https://github.com/Azure/bicep/pull/8559#discussion_r987186092

Created at 15 hours ago

Update bicepconfig.json schema

Created at 15 hours ago

Fix failing tests

Created at 21 hours ago

Prevent broken VS integration tests from failing the build (#8567)

Merge branch 'main' into jeskew/source-feature-flags-from-config

Cleanup diff

Created at 21 hours ago

Remove mutable instance state from LinterAnalyzer and use as it as a singleton (#8565)

Merge branch 'main' into jeskew/source-feature-flags-from-config

Created at 22 hours ago

Fix broken package locks (#8564)

  • Fix broken package locks

  • Add GHA step to ignore VS flaky tests

Improve module path completions (#8560)

  • Fix for suggestions under issue 7820

  • Use file system abstraction for InMemoryFileResolver

  • Fix Windows-specific path issues

Bump type package versions (#8562)

  • Bump type package versions

  • Update test baseline

Merge branch 'main' into jeskew/source-feature-flags-from-config

Use fixed property names in Config.ExperimentalFeaturesEnabled

Created at 22 hours ago
closed issue
Make `LinterAnalyzer` a stateless singleton

Originally posted by @anthony-c-martin in https://github.com/Azure/bicep/pull/8301#discussion_r969084819

Created at 22 hours ago

Remove mutable instance state from LinterAnalyzer and use as it as a singleton (#8565)

Created at 22 hours ago
delete branch
jeskew delete branch jeskew/stateless-linteranalyzer
Created at 22 hours ago
pull request closed
Remove mutable instance state from LinterAnalyzer and use as it as a singleton

Resolves #8385

Since configuration is now a property of a Bicep file's semantic model, linter rules can track relevant configuration as variables local to LinterRuleBase::AnalyzeInternal instead of as instance state on the rule class. This allows for safe concurrent usage of a single LinterAnalyzer instance, so this PR also updates the CLI and LangServer packages to use a LinterAnalyzer singleton rather than instantiating new instances at various points in the compilation process.

Microsoft Reviewers: Open in CodeFlow
Created at 22 hours ago

Fix broken package locks (#8564)

  • Fix broken package locks

  • Add GHA step to ignore VS flaky tests

Improve module path completions (#8560)

  • Fix for suggestions under issue 7820

  • Use file system abstraction for InMemoryFileResolver

  • Fix Windows-specific path issues

Bump type package versions (#8562)

  • Bump type package versions

  • Update test baseline

Merge branch 'main' into jeskew/stateless-linteranalyzer

Created at 23 hours ago

Add support for sourcing feature flags from bicepconfig.json

Also emit a deprecation notice when a feature flag is sourced from an environment variable.

Leave only bicepconfig.json as a feature flag source

Created at 23 hours ago