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.
This new version includes Solaris support, the lack of which previously
caused us to disable readline-using features ("terraform console") on
Solaris builds.
Previously we allowed access to the credentials store only indirectly
through the Disco object, and that's fine for callers that only need to
_read_ credentials, but more specialized callers like "terraform login"
and "terraform logout" need more information in order to be transparent
to the user about what they are going to do and where the credentials
are going to be stored.
Martin Atkins