We're not ready to ship this in a release yet because there's still some
remaining work to do on the Terraform Cloud side, but we want to get the
implementation work behind this into the master branch so it's easier to
maintain it in the mean time, rather than letting this long-lived branch
live even longer.
We'll continue to iterate on UX polish and other details in subsequent
commits, and eventually enable this.
This was a vestige from earlier prototyping when we were considering
supporting adding credentials to existing .tfrc native syntax files.
However, that proved impractical because the CLI config format is still
HCL 1.0 and that can't reliably perform programmatic surgical updates,
so we'll remove this option for now. We might add it back in later if it
becomes more practical to support it.
These run against a stub OAuth server implementation, verifying that we
are able to run an end-to-end login transaction for both the authorization
code and the password grant types.
This includes adding support for authorization code grants to our stub
OAuth server implementation; it previously supported only the password
grant type.
For unit testing in particular we can't launch a real browser for testing,
so this indirection is primarily to allow us to substitute a mock when
testing a command that can launch a browser.
This includes a simple mock implementation that expects to interact with
a running web server directly.
Because we're going to pass the credentials we obtain on to some
credentials store (either a credentials helper or a local file on disk)
we ought to disclose that first and give the user a chance to cancel out
and set up a different credentials storage mechanism first if desired.
This also includes the very beginnings of support for the owner password
grant type when running against app.terraform.io. This will be used only
temporarily at initial release to allow a faster initial release without
blocking on implementation of a full OAuth flow in Terraform Cloud.
The canonical location of the "template" provider is now in the hashicorp
namespace rather than the terraform-providers namespace, so the output
has changed to reflect that.
This gets us slightly faster test runtimes and also insulates us better
from downtime of individual upstreams, in favor of being dependent only
on one specific upstream (the Go module proxy itself, currently run by
Google).
Properly exclude files under "./vendor/" path, and find "files" only.
The original method "might" found "directories" with the same naming,
or, might exclude occasionally exclude the go files with "vendor" string
in any part of its path.
For a long time now we've been advising against the use of provisioners,
but our documentation for them is pretty prominent on the website in
comparision to the better alternatives, and so it's little surprise that
many users end up making significant use of them.
Although in the longer term a change to our information architecture would
probably address this even better, this is an attempt to be explicit about
the downsides of using provisioners and to prominently describe the
alternatives that are available for common use-cases, along with some
reasons why we consider them to be better.
I took the unusual step here of directly linking to specific provider
documentation pages about the alternatives, even though we normally try
to keep the core documentation provider-agnostic, because otherwise that
information tends to be rather buried in the provider documentation and
thus the reader would be reasonable to use provisioners just because we're
not giving specific enough alternative recommendations.
Martin Atkins