You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Use the main action that hides away the hosts environment behind the Action, forcing the steps to be owned by the action when it comes to anything related to terragrunt, but more often than not, people build around a step.
I seen this done before and end up being an anti-pattern, or requiring hacky things of passing things like SSH keys and Github Tokens to the container rather than leveraging the hosts, at least as I could expect. Or adding things like tg_dir that mimics working-directory flag, among many other configurations that dont need to be pass in and are configured at the job level. Also (maybe) speed since the action is always dealing with checking downloads and whatnot instead of just one time during the setup-* action.
Additional context
Most setup-* action exists that only inject the binaries to avoid the problems listed before.
Hey @denis256 I would love to migrate from autero1/action-terragrunt (just to use the official things) Is there any opportunity to get the setup-terragrunt action?
Hi,
I’d recommend exploring mise as an alternative for installing the required tools. It’s a versatile solution that simplifies the setup process and ensures that the necessary dependencies are installed efficiently, mise is already included in the action image.
With mise, you can define your required tools and their versions in a mise.yml file, ensuring consistency and ease of configuration across your projects.
Would be too much to ask to include gruntwork-io/terragrunt-action/setuo-terragrunt as part of the repo? I can do the work.
Since you are already familiar with the tooling, which is almost the same, just remove the extra indirection.
Please understand that dealing with compliance is more complicated than necessary. Because of the paid packages we used, Gruntwork already passed the check, so your owning the situation makes it more straightforward to continue introducing more Gruntwork tooling.
Describe the solution you'd like
I would like to have an Action that setup the tools in the given context, without doing magical things like
tg_command
Describe alternatives you've considered
Use the main action that hides away the hosts environment behind the Action, forcing the steps to be owned by the action when it comes to anything related to terragrunt, but more often than not, people build around a step.
I seen this done before and end up being an anti-pattern, or requiring hacky things of passing things like SSH keys and Github Tokens to the container rather than leveraging the hosts, at least as I could expect. Or adding things like
tg_dir
that mimicsworking-directory
flag, among many other configurations that dont need to be pass in and are configured at thejob
level. Also (maybe) speed since the action is always dealing with checking downloads and whatnot instead of just one time during thesetup-*
action.Additional context
Most
setup-*
action exists that only inject the binaries to avoid the problems listed before.Among many other things it will ask to keep adding and opening the action to add more complexity to it :2cents:
The text was updated successfully, but these errors were encountered: