null_resource the only resource with
triggers attribute is not special in any way, it’s an attribute of type
map(string). The provider is what will indicates the resource needs replacement if there is a planned change to that attribute. You can see similar attributes for example on random_pet, with
keepers, but any attribute change which the provider deems will force replacement works in this manner.
@jbardin Appreciate the answer! I’m trying to understand whether
triggers is a Meta-Argument or not?
I think not as it’s not documented under
…… but why not? Why isn’t
triggers a Meta-Argument? What makes it different from one?
It is something specific to how the null_resource works and makes little sense with other resources. As the null_resource doesn’t actually manage any underlying item without the triggers once it was created nothing would ever change again. The triggers parameter allows the resource to respond to changes, causing the resource to be destroyed & recreated, impacting on any dependencies or attached provisioners.
For other resources none of this is important. They generally manage real systems and have lots of different parameters that might be changed. When the underlying item changes state or the code is adjusted to change things the resource can then detect this and make changes as needed, again triggering provisioners or impacting dependencies in certain situations.
Right, what you said makes sense and this is why I am also confused why
triggers isn’t a Meta-Argument - for majority of the resources,
triggerswould result in a “no-op” and potentially only refresh the resource state but making it a Meta-Argument would bring conformity to Terraform resources
It’s possible I am missing some detail - so this is me more thinking out aloud.
A reason it’s not a meta argument is that it can be implemented as needed by any individual resource, where as options like
depends_on cannot (aside from the fact that we cannot add arbitrary arguments to resources without breaking compatibility). There are many proposals for expanded
lifecycle options, like Feature Request: Destructive dependencies · Issue #16065 · hashicorp/terraform · GitHub, which covers the same idea as “triggers”, but there has not yet been a clear plan devised for expanding and implementing those ideas.