-
Notifications
You must be signed in to change notification settings - Fork 9.6k
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.
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
allow -target
to accept globs
#2182
Comments
👍 would love to be able to use as opposed to writing CLIs to wrap Terraform |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
There are other requests I've seen for "exclude" logic, so it may be useful to have this use regex instead of glob to take care of both requests. |
Where is the issue for "exclude" logic? that it'll resolve me many problems 👍, maybe like target: |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Wow this is a very old request for a very useful feature. |
This comment has been minimized.
This comment has been minimized.
Would it be correct to relate with Issue #2253 The feature request is for a different option parameter, but the nature of the feature to have an "exclude" pattern instead of just "apply" could be interesting. Considering they are both trying to achieve somewhat similar results. By supporting also the exclude and this pattern feature, it would make it that much more flexible and powerful. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
2 similar comments
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Please do not post "+1" comments here, since it creates noise for others watching the issue and ultimately doesn't influence our prioritization because we can't actually report on these. Instead, react to the original issue comment with 👍, which we can and do report on. |
Not only the option target, the "Data" ressource block as well should be able to target a ressource name="prefix-*". Ressources often needs to have dynamic name to be able to spawn in parallel to have zero downtime with lifecycle "create_before_destroy", it makes them pretty hard to target sometimes. |
Any schedule on this feature? It helps on managing multiple modules. E.g. modify resources under specific module instead of all resources among modules |
we are managing 700+ domains (plus records) with terraform in cloudflare. our resource naming is perfect for prefix wildcarding (if that's easier to implement than full-on globbing):
some zones have hundreds of records so it would be incredibly tedious to list them all as targets. but all the records are prefixed with the zone name. so definitely 👍 on this feature. |
This comment has been minimized.
This comment has been minimized.
Please do not post "+1" comments here, since it creates noise for others watching the issue and ultimately doesn't influence our prioritization because we can't actually report on these. Instead, react to the original issue comment with +1, which we can and do report on. |
Hi, this request is almost four years old and seems to be rather important. Any progress on that? Thanks and best regards, Josef |
There were at least two implemented/mentioned by @phzietsman and me a few comments above. But I guess there is more out there in the wild... |
Not sure as of what version but you can |
That only gets you so far though. Imagine you have a complex setup containing modules for k8s clusters on AWS with lambdas, ELBs, databases, DNS records, etc. and just wanna update your ELBs. Then you need scope it to something like |
I hear, at work we use CI (jenkins) to help alleviate some of the tedious bits associated. A |
Yeah, exactly that was also my approach and it's pretty much what my little wrapper project does (see above). |
@schneidexe Instead of parsing the human-readable console output of terraform plan, you could render the plan to a file and then use |
Here's my low-tech workaround. Add this function to your terraform-targets () {
sed 's/\x1b\[[0-9;]*m//g' | grep -o '# [^( ]* ' | sed " s/^# /-target '/; s/ $/'/; "
} You can use it it in a variety of ways: terraform plan | terraform-targets
terraform plan | terraform-targets | grep 'some pattern'
terraform plan | terraform-targets | grep 'some pattern' | xargs -r terraform apply (The |
Thanks @alahijani . I've added an additional grep to the line because we have bash scripts with comments, and those comments are incorrectly shown as terraform-targets () {
sed 's/\x1b\[[0-9;]*m//g' | grep -o '# [^( ]* ' | grep '\.' | sed " s/^# /-target '/; s/ $/'/; "
} |
When I try your last command for the "yes" prompt, something else gets passed and I get action cancelled. Am I doing something wrong? |
I run |
I have another workaround for this, but I think this will apply only for resource that already in state for i in $(terraform state list | grep "some-pattern");
do
terraform apply -target=$i -auto-approve;
done note: be careful with |
@suryastef keep in mind that will run a separate plan/apply for each resource matching which could take a while esp. if you have e.g. a big remote state file in s3. Also in some cases the state might chnage and resources in the list would be removed as dependecies to others... so it would be beneficial to chain the -target .... -target for each $i and run the command only once. |
@schneidexe thank you for your concern, I didn't think that way before
|
The problem is the lock acquisition and release time for each call, and if they were route53 targets every call could take 3 minutes. (grumble about route53 (not terraform) taking so long to do ANYTHING...). so if I wanted to destroy 120 route53 entries
|
This comment was marked as duplicate.
This comment was marked as duplicate.
Based on the solution provided by @suryastef at #2182 (comment), I think this makes more sense as it only makes use of one terraform call. (terraform allows us to define multiple targets at the same apply call) targets=$(for x in `terraform state list | grep -e "azurerm_key_vault*.*"`; do echo "-target=$x "; done);
echo $targets | xargs terraform apply -var-file=... # add here your own options; |
Unfort. that does not cover for targets that were not yet deployed and hence do not yet exist in the state... |
@schneidexe figured that out after commenting it in here. 😬 |
This comment was marked as off-topic.
This comment was marked as off-topic.
8 years and a half later... I hardly believe such a widespread need remains unconsidered! :| Adding to the list of alternatives: https://github.com/future-architect/tftarget |
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as off-topic.
This comment was marked as abuse.
This comment was marked as abuse.
I know this issue hadn't been resolved for long time, but maybe this will help someone. This is another low-level option for my case, How I used it with terraform/terragrunt:
updated function for multiple pattern in 15/4/2024 |
This comment was marked as off-topic.
This comment was marked as off-topic.
That's what I came up with, and it's helping me a lot. I'm using regex on resource names from the tf source and state files. Just added an exclude option to skip some of the previously selected targets for finer control. Single python script, easy to integrate in a pipeline. |
Thank you @Positronico ! Looks like it can't handle the following context :
|
Suppose one declares several concurrent environments in a single tf config.
To limit cli actions to a single environment at a time, it would be convenient if a way existed, via
-target
to glob-match modules, module_paths, resource_types and resource_names:terraform apply -target=aws*.staging*
# target aws* resource_typesor similarly, for all modules:
terraform apply -target=*.*.staging*
# target all modules and resource_typesor similarly, for all module_paths:
terraform apply -target=**.staging*
# star star = target all modules and submodulesThe text was updated successfully, but these errors were encountered: