Allows to store anything on null_resource

[mildred]

trafficstars

The null_resource can be great to store any value. This commit add the bility to store arbitrary values without recreating the resources (in the values section) and to store inputs that are stored within the tfstate, accessible as outputs and updated only when the resource is (re-)created.

This can solve use case in issue #5

[JnMik]

I like that very much.

Very often we have to rely on null_resource local-exec to run bash commands because Terraform is not flexible enough. And 50% of the time, we would like to return a value from that bash script and use it as a dependency on a next resource in the stack.

The hacky way top achieve this right now is to run the bash and output it to a file (with echo >> ), then use a data local_file with the filename associated to the null_resource triggers (to assure the data.local_file is run after the bash). That's kinda messy and it took me multiple trial errors before finding this solution.

I believe a lot of people who needed to do that bumped their head trying to use file() function or else at first (Well I was xD).

Just getting a value out of a bash script shouldn't be that hacky, I think it's basics.

I am not sure of your implementation, as I have no desire to become a code maintainer for this, but +1 for the idea.

Cheers !

[jw-maynard]

@apparentlymart Can we get this merged? I'm in a situation where I need to create a CRD in k8s but currently the k8s provider does not support CRDs. To work around this I'm using a null_resource with creation and destroy time provisioners that call kubectl to apply a manifest to k8s. I'm passing in the appropriate info needed to auth to the k8s cluster as ENV VARs and have a wrapper script that runs but when I run I get the following warning:

Warning: External references from destroy provisioners are deprecated

So my solution was to pass all the needed info to the null_resource as a trigger. However one of the items needed is a token that changes with every run of terraform. This causes the null_resource to be re-created every time. If there were a way to store data on the null_resource that did not trigger a change that would solve this issue. I think there would be other use cases that this would assist in and it should be a pretty simple change.

[jw-maynard]

@appilon Would you be the correct person to review and merge this?

[hashicorp-cla]

All committers have signed the CLA.

[bflad]

Hi @mildred 👋 Thank you for raising this and apologies for the delayed review.

Terraform 1.4.0 has been released today with the new terraform_data resource. Its implementation supports the input/output reflection for in-place updates and it should not impose any type restrictions on its input, output, or triggers_replace attributes. If there are any feature requests or bug reports with the terraform_data resource, please create an issue in the Terraform core issue tracker.

Given that this functionality is now baked into Terraform itself, I'm going to close this. Thanks again.

[github-actions[bot]]

I'm going to lock this pull request because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active contributions. If you have found a problem that seems related to this change, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.