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

Standardise logic for failing/warning when an error occurs during terraform version detection #451

Open
MatthewJohn opened this issue Jun 4, 2024 · 4 comments
Labels
enhancement Refactor existing code for better performance and quality

Comments

@MatthewJohn
Copy link
Collaborator

MatthewJohn commented Jun 4, 2024

Is your feature request related to a problem? Please describe.

There are two use-cases when running tfswitch:

  • As a local user, I wish to run tfswitch. If tfswitch runs into a problem (i.e. it cannot parse my Terraform or it thinks there's an issue with a terragrunt config file), I would like it to show a warning and continue as normal (perhaps I specified the version as an arg, or have the version defined elsewhere).
  • As a CI/CD execution server, if I am expected to parse Terraform and obtain a version, if the terraform cannot be parsed, I do not wish to begin an endless loop of waiting for user input (because there won't ever be any)

Describe the solution you'd like

As suggested in the thread on/after #429 (comment), we could/should detect for a valid TTY and act accordingly. If there is no TTY, then we should fail when these errors occur, otherwise, we should continue to ask the user for input.

@MatthewJohn MatthewJohn added the enhancement Refactor existing code for better performance and quality label Jun 4, 2024
@yermulnik
Copy link
Collaborator

Out of curiosity: what that screencast (git switch branch + open main.go in vi) is meant for? 🤔

@MatthewJohn
Copy link
Collaborator Author

Out of curiosity: what that screencast (git switch branch + open main.go in vi) is meant for? 🤔

Ah, I saw it in the new issue template and wondered what it was - and then forgot to remove it!

@warrensbox
Copy link
Owner

Can this wait after release 1.2.0?

@yermulnik
Copy link
Collaborator

Can this wait after release 1.2.0?

It probably can. Though this "bug" may impact someone's CI/CD pipeline by halting it to wait for an input w/o a meaningful reason.
I'd personally target this to be release as soon as possible. Though! Though we may (and need) to establish release cadence if we may (and can) provide a more-or-less stable release cadence I guess.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement Refactor existing code for better performance and quality
Projects
None yet
Development

No branches or pull requests

3 participants