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.

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

$TERRAGRUNT_INCLUDE_DIR env variable seems not support glob curly braces #3462

Open
Neonox31 opened this issue Oct 10, 2024 · 3 comments
Open
Labels
bug Something isn't working contributions-requested Requesting contributions from the community preserved Preserved issues never go stale

Comments

@Neonox31
Copy link

Describe the bug

Hello 👋

First, thanks for all you work on this awesome project 👍

I found a strange behavior with $TERRAGRUNT_INCLUDE_DIR environment variable, it does not seem to take into account curly braces in unix style globs, but using --terragrunt-include-dir seems working correctly.

FYI, using wildcards with env variable is working.

Is this behavior normal ?

Steps To Reproduce

TERRAGRUNT_INCLUDE_DIR="gcloud/{project-1,project-2}" terragrunt run-all init

Results with an empty output :

14:56:01.853 INFO   The stack at . will be processed in the following order for command init:

Expected behavior

14:57:58.123 INFO   The stack at . will be processed in the following order for command init:
Group 1
- Module ./gcloud/project-1
- Module ./gcloud/project-2

Versions

  • Terragrunt version: 0.68.0
  • OpenTofu/Terraform version: 1.9.7
  • Environment details (Ubuntu 20.04, Windows 10, etc.): Linux EOS 6.6.52-1-lts
@Neonox31 Neonox31 added the bug Something isn't working label Oct 10, 2024
@denis256
Copy link
Member

Hello,
use , to separate values passed through env variables

TERRAGRUNT_INCLUDE_DIR="gcloud/project-1,gcloud/project-2" terragrunt run-all init

@Neonox31
Copy link
Author

@denis256 Thanks for the workaround, but is it normal for the variable and the argument to function differently?

@yhakbar
Copy link
Collaborator

yhakbar commented Oct 15, 2024

At the very least, the difference should be documented if they aren't (I haven't looked through the docs to confirm this).

Given that the workaround is fairly simple, I'm going to mark this issue as requesting community contributions, and marking it as preserved so that the issue doesn't go stale.

This is where flag splitting occurs, and where folks should start looking if they'd like to contribute a fix for this:

vals := splitter(*envValue, valSep)

@yhakbar yhakbar added contributions-requested Requesting contributions from the community preserved Preserved issues never go stale labels Oct 15, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working contributions-requested Requesting contributions from the community preserved Preserved issues never go stale
Projects
None yet
Development

No branches or pull requests

3 participants