I haven’t found anything like this from my Googling, but the logic seems fairly simple: Write a script that analyzes the latest commit (or the last few), fetch the resources that were changed, and then run plan/apply targeting those exact resources.
The idea came to mind the other day after I made a change that I was trying to apply. Someone had manually changed a resource (and I didn’t want to revert without their consent), so I had to manually target every resource I actually wanted to change (given there’s no support to exclude a specific resource).
Would it be harder to make than it sounds? And/or are there any issues/edge-cases it would cause that I’m not seeing?
Personally I wouldn’t recommend going down this route. Anything in Terraform code must be solely managed by Terraform with no changes elsewhere. I know that there are sometimes emergencies where that isn’t possible, but a code change should be made ASAP, and there should be the understanding that until such a change is applied that emergency change could get reverted at any point - it doesn’t really work if you start second guessing why Terraform is seeing changes.
Also it isn’t trivial to know what you should add to a -target (and it won’t just change things you target either). You would need to decode a git diff into something that can identify what the lines that have changed actually affected. You would need to work out the block that has been modified, as well as something about the change.
For example, you presumably want to ignore changes that make no actual difference (for example reordering things within a resource or adjusting spacing and comments). You also need to understand and calculate what changes to variables or locals would have (so you can’t just target a module/resource that has had changes within it). If a change is made within a module you’d need to somehow calculate all the places that module is called from.
So you would actually need a full HCL parser as well as a lot of code that mimics some of the logic that Terraform has.
And as I say it wouldn’t actually limit what might get changed. If you target something but there are dependant resources which are needing to change you would expand the list of changes outside of what you might thing from looking at the git diff.
Finally one of the important uses for Terraform is drift correction. As the Terraform code is the source of truth I expect reality to always match what the code says (assuming that Terraform is being run frequently enough). Your hypothetical script would remove that, as a change outside of Terraform (maybe something manual or due to a platform change - such as when cloud providers update managed services) would no longer be detected/corrected if there isn’t any code change in the correct area.
Overall I don’t really see what advantage all this complexity would achieve. It feels like quite a bit of effort, with a lot of scope for bugs, for an action (using -target) which isn’t recommended to be used (it should be used sparingly rather than a standard option).
Thanks for the response! I figured I was missing something, but I appreciate the detail into all the issues I would run into 