Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Support the sensitive attribute on outputs (#55) #56

Merged
merged 1 commit into from
Oct 27, 2020
Merged

Support the sensitive attribute on outputs (#55) #56

merged 1 commit into from
Oct 27, 2020

Conversation

andy-caruso
Copy link
Contributor

If sensitive is not specified or is false it will not be present in the Output object as per omitempty behavior.

@andy-caruso
Support the sensitive attribute on outputs (hashicorp#55)
5bf370f 
If sensitive is not specified or is false it will not be present
in the Output object as per omitempty behavior.
@andy-caruso andy-caruso requested a review from a team as a code owner October 22, 2020 21:52
@hashicorp-cla
Copy link

hashicorp-cla commented Oct 22, 2020 •
edited
Loading

CLA assistant check
All committers have signed the CLA.

@mildwonkey
Copy link
Contributor

Hi @andy-caruso ,
Can you explain a bit about your use case here? terraform-config-inspect is a general tool used to inspect configuration, not display it to other users, and I don't think suppressing output is something terraform-config-inspect should be expected to handle. I'd go as far as to say it's counter-indicated; the whole point is to be able to inspect the given configuration, and that may include sensitive values.

@andy-caruso
Copy link
Contributor Author

I don't think I explained it well, this change doesn't suppress the output, it populates the Sensitive field in the Output object when inspecting a terraform module.

type Output struct {
	Name        string `json:"name"`
	Description string    `json:"description,omitempty"`
	Sensitive   bool      `json:"sensitive,omitempty"`  <--- Newly added
	Pos         SourcePos `json:"pos"`
}

I added an example of some use-cases to Feature Request #55

@mildwonkey
Copy link
Contributor

Hi, thanks @andy-caruso !

Your explanation was just fine, but I definitely misinterpreted what I was seeing and indeed thought you were suppressing the value (trust me when I say we yell about terraform's overloaded terminology on a daily basis). This makes sense and I am very sorry I did not look closely enough at first.

justincampbell
justincampbell reviewed Oct 27, 2020
View reviewed changes
Copy link

@justincampbell justincampbell left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me from the Registry perspective! Will defer to @hashicorp/terraform-core for approval.

@mildwonkey
Copy link
Contributor

Thanks @justincampbell that's all I needed!

@mildwonkey mildwonkey merged commit b049036 into hashicorp:master Oct 27, 2020
@mrwacky42 mrwacky42 mentioned this pull request Feb 15, 2022
Merged
mrwacky42 added a commit to HeadspaceMeditation/terraform-config-inspect that referenced this pull request Feb 15, 2022
@mrwacky42 @bflad
@mildwonkey @radeksimko @mdeggies @jstewmon @alisdair @andy-caruso @jbardin @apparentlymart @kylecarbs
OPS-8302 Merge upstream to support TF 1.x syntax (#11)
7dbd629 
* deps: Migrate from github.com/hashicorp/hcl2 to github.com/hashicorp/hcl/v2 (hashicorp#34)

Reference: https://github.com/hashicorp/hcl2#experimental-hcl2

* contributing: terraform-config-inspect is feature complete (hashicorp#35)

* terraform.required_providers provider source (hashicorp#37)

* tfconfig: add parser for new (optional) required_providers syntax

This is a breaking change: module.ProviderRequirements is now a map[string]ProviderRequirement
instead of map[string][]string, and the json output has changed
accordingly.

The following syntaxes are now supported:

terraform {
required_providers {
    // new syntax
    "cloud" = {
      source = "hashicorp/cloud"
      version = "1.0.0"
    }
    // original syntax is also supported
    "cloud" = "1.0.0"
  }
}

* Fix Markdown rendering

* Cleanup Readme formatting

* Standardize directory for test data

Use standard name for fixtures dir per Go conventions
https://golang.org/cmd/go/#hdr-Test_packages

* Migrate to Circle

* fix: disambiguate variable defaults with "empty" values from undefined (hashicorp#24)

- Variable struct and json representation now have an explicit
  `required` field to disambiguate between a variable with a default
  value which may either be `null` or the variable type's zero value

* Merge source across required_providers blocks

If multiple terraform.required_providers blocks are in the config, we
already merge the version constraints for each provider. We should also
merge the source attribute, and warn if there are duplicates.

Consider the following configuration:

terraform {
  required_providers {
    foo = {
      version = "1.0.0"
    }
  }
}

terraform {
  required_providers {
    foo = {
      source = "abc/foo"
    }
  }
}

Before this commit, this would result in a provider requirement for
"foo" with version constraint "1.0.0", but no "source". This commit
merges the source attribute from the second block into this requirement.

* Multiple provider source attributes is an error

Previously we were diagnosing multiple provider different provider
source attribute values as a warning, but this is really a configuration
error. This commit updates the diagnostic to be an error, and adds a
forced failure in the legacy parser when a `required_providers` block is
encountered to ensure that the error propagates.

* Allow parsing module from any filesystem (hashicorp#49)

* Allow parsing from any filesystem

* avoid caching parsed files

* Expose lower-level hcl.File load function (hashicorp#53)

* Support the sensitive attribute on outputs (hashicorp#55) (hashicorp#56)

Add a "sensitive" attribute to outputs. If sensitive is not specified or is false it will not be present
in the Output object as per omitempty behavior.

* tfconfig: decode provider aliases (hashicorp#54)

* allow parsing of required_providers containing ref

The syntax for configuration_aliases contains bare references to match
their use in other parts of the configuration. These however cannot be
decoded directly without an EvalContext, as they represent variables.

Refactor decodeRequiredProvidersBlock to use the lower level ExprMap
function.

* Expose configuration_aliases from required_providers (hashicorp#60)

* README: The latest releases of this library support the Terraform v0.15 language

* README: This library is compatible with the Terraform 1.0 language

* README: Updated note about compatibility

We now have 1.0 compatibility promises, so we can be more specific in what this library can do.

* Parse the sensitive key for input variables

* Remove Sensitive property for legacy modules

* Update CircleCI config to fix build failures

* Give up on 1.11.13, replace with 1.17.3

* update circle config and docker mirror

* Fixup after merge

Co-authored-by: Brian Flad <bflad417@gmail.com>
Co-authored-by: Kristin Laemmert <mildwonkey@users.noreply.github.com>
Co-authored-by: Radek Simko <radek.simko@gmail.com>
Co-authored-by: Michele <mdeggies@gmail.com>
Co-authored-by: Jonathan Stewmon <jstewmon@gmail.com>
Co-authored-by: Alisdair McDiarmid <alisdair@users.noreply.github.com>
Co-authored-by: Andy Caruso <63117216+andy-caruso@users.noreply.github.com>
Co-authored-by: James Bardin <j.bardin@gmail.com>
Co-authored-by: Martin Atkins <mart@degeneration.co.uk>
Co-authored-by: Kyle Carberry <kyle@carberry.com>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@justincampbell justincampbell justincampbell left review comments

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@andy-caruso @hashicorp-cla @mildwonkey @justincampbell