The `remote` backend config contains an attribute that is defined as a `*schema.Set`, but currently only `string` values are accepted as the `config` attribute is defined as a `schema.TypeMap`.
Additionally the `b.Validate()` method wasn’t called to prevent a possible panic in case of unexpected configurations being passed to `b.Configure()`.
This commit is a bit of a hack to be able to support this in the 0.11 series. The 0.12 series will have proper support, so when merging 0.12 this should be reverted again.
This commit fixes a bug that (in the case of the `local` backend) would only check if the selected workspace had a state when deciding to preform a migration.
When the selected workspace didn’t have a state (but other existing workspace(s) did), the migration would not be preformed and the other workspaces would be ignored.
While this initial implementation is a very simple wrapper function, implementing this in the helper/resource package provides some downstream benefits:
* Provides a standard interface for plugin developers to enable parallel acceptance testing
* Existing plugins can simply convert resource.Test to resource.ParallelTest references (as appropriate) to enable the functionality, rather than worrying about additional line(s) to each acceptance test function or TestCase
* Potential enhancements to ParallelTest (e.g. adding an environment variable to skip enabling the behavior) are consistently propagated
Here our prior existing single template becomes the "Bug report" template,
and we introduce a second "Feature request" template that is more
appropriate for gathering context about a feature request.
By adding this method you now only have to pass a `*disco.Disco` object around in order to do discovery and use any configured credentials for the discovered hosts.
Of course you can also still pass around both a `*disco.Disco` and a `auth.CredentialsSource` object if there is a need or a reason for that!
These flags are presented as POSIX/GNU-style long-form flags
(double-dash), whereas the rest of our CLI flags as seen in sub-commands
are presented as single-dash options.
While both work in both cases (on part of the flag package allowing
double dashes as well), we converge around the single-dash form, so the
basic help text here should be consistent.
It's been a while since we made any significant updates to this page.
The main theme of this revamp is to ensure that we highlight how to
provide "ambient credentials" for each of the module sources using the
standard mechanisms for each source type.
While there, I also attempted a general cleanup to highlight the main
cases and make this less like a detailed description of all of
go-getter's esoteric features, and did some general copy-editing to write
it in our usual documentation "voice".
Sander van Harmelen