2023-05-02 10:33:06 -05:00
|
|
|
// Copyright (c) HashiCorp, Inc.
|
|
|
|
// SPDX-License-Identifier: MPL-2.0
|
|
|
|
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
package experiments
|
|
|
|
|
|
|
|
import (
|
|
|
|
"testing"
|
|
|
|
)
|
|
|
|
|
|
|
|
// OverrideForTesting temporarily overrides the global tables
|
|
|
|
// of experiments in order to allow for a predictable set when unit testing
|
|
|
|
// the experiments infrastructure code.
|
|
|
|
//
|
|
|
|
// The correct way to use this function is to defer a call to its result so
|
|
|
|
// that the original tables can be restored at the conclusion of the calling
|
|
|
|
// test:
|
|
|
|
//
|
2022-08-17 13:46:02 -05:00
|
|
|
// defer experiments.OverrideForTesting(t, current, concluded)()
|
experiments: a mechanism for opt-in experimental language features
Traditionally we've preferred to release new language features in major
releases only, because we can then use the beta cycle to gather feedback
on the feature and learn about any usability challenges or other
situations we didn't consider during our design in time to make those
changes before inclusion in a stable release.
This "experiments" feature is intended to decouple the feedback cycle for
new features from the major release rhythm, and thus allow us to release
new features in minor releases by first releasing them as experimental for
a minor release or two, adjust for any feedback gathered during that
period, and then finally remove the experiment gate and enable the feature
for everyone.
The intended model here is that anything behind an experiment gate is
subject to breaking changes even in patch releases, and so any module
using these experimental features will be broken by a future Terraform
upgrade.
The behavior implemented here is:
- Recognize a new "experiments" setting in the "terraform" block which
allows module authors to explicitly opt in to experimental features.
terraform {
experiments = [resource_for_each]
}
- Generate a warning whenever loading a module that has experiments
enabled, to avoid accidentally depending on experimental features and
thus risking unexpected breakage on next Terraform upgrade.
- We check the enabled experiments against the configuration at module
load time, which means that experiments are scoped to a particular
module. Enabling an experiment in one module does not automatically
enable it in any other module.
This experiments mechanism is itself an experiment, and so I'd like to
use the resource for_each feature to trial it. Because any configuration
using experiments is subject to breaking changes, we are free to adjust
this experiments feature in future releases as we see fit, but once
for_each is shipped without an experiment gate we'll be blocked from
making significant changes to it until the next major release at least.
2019-07-10 14:37:11 -05:00
|
|
|
//
|
|
|
|
// This function modifies global variables that are normally fixed throughout
|
|
|
|
// our execution, so this function must not be called from non-test code and
|
|
|
|
// any test using it cannot safely run concurrently with other tests.
|
|
|
|
func OverrideForTesting(t *testing.T, current Set, concluded map[Experiment]string) func() {
|
|
|
|
// We're not currently using the given *testing.T in here, but we're
|
|
|
|
// requiring it anyway in case we might need it in future, and because
|
|
|
|
// it hopefully reinforces that only test code should be calling this.
|
|
|
|
|
|
|
|
realCurrents := currentExperiments
|
|
|
|
realConcludeds := concludedExperiments
|
|
|
|
currentExperiments = current
|
|
|
|
concludedExperiments = concluded
|
|
|
|
return func() {
|
|
|
|
currentExperiments = realCurrents
|
|
|
|
concludedExperiments = realConcludeds
|
|
|
|
}
|
|
|
|
}
|