Run cli locally

[motatoes]

When testing out digger for the first time, or when setting up digger with a new AWS account there are alot of initial plans and applies that need to be performed in the first instance. Since this user is applying a large portion of untested terraform there is several applies and state setup that needs to be configured. Furthermore, if the user makes an error during state setup the state is now lost since it terminates after the initial run. In this instance having a PR-workflow to test the initial infrastructure setup is extremely inconvinient. It will be great if the user can trigger terraform runs

• User should be able to download the digger cli and invoke it within the context of the repository.
• User should be able to run plans and applies locally using terraform installed on their machine
• Digger cli will check for digger.yml project locks just as it is done in the PR workflows
• Digger cli will load appropriate environment parameter from github before invoking the terraform cli to mimick the remote workflow experience locally (?)

bumped request from @daanbosch

As a user I want to be able to invoke the cli locally within the context of a digger-configured repository and I should be able to run plan and apply commands

Considerations:

• What access controls will this user be given?
• How will access be given to the cli? User provides access or remote job execution (some users don't want to depend on remote workers and would like the ability to execute terraform commands locally)

[frank-bee]

Some ideas related

• what about providing github codespaces setup?
• important point here is the cloud access ( e.g terraform). From the github pipeline this is our case done via OICD - how would it be done from commandline?

[motatoes]

Hey @frank-bee those are some great points indeed.

1. Will need to look into codespaces as it seems like an interesting way to allow users to run terraform commands on a cloud environment
2. it seems that with local invocation has some limitations and in alot of cases we will need to trigger a remote job and stream the output back to the users -- taking into account all the necessary access controls. With that said I think that digger needs to be able to support some versions of local for ease of running, as well as a remote invocation for other scenarios.
3. I could be wrong about (p#2) and I hope I am because in an ideal scenario digger should abstract away all the environment configuration parts and you should be able to invoke terraform commands seamlessly, subject to the right access and OPA controls