State management

[ZIJ]

Currently the S3 bucket for state and the dynamoDb table for state locks (unrelated to PR locks) is expected to be there and managed by the user.

Raised by @SalvoRusso8

"Maybe for the future, to provide a terraform file or a cloudformation for the initial configuration could be a nice feature"

"So where do I specify which bucket to use? I think this first configuration part is not discussed enough in the docs"

---

It might be helpful to have some kind of a helper (e.g. CLI) to CRUD those states. Or maybe have them as configurable in digger.yml and have a separate "mgmt" action. We might also introduce some kind of an entity to represent "extended state" with locks etc, similar to Spacelift Stacks - which would basically be the stateful part of Projects, also managed in user's aws account by Digger. Opinionated consideration: oing that part from the main action seems to be confusing concerns that aren't supposed to be mixed together. So there's got to be a separate workflow, be it CLI or config or a different action or whatnot.

[ZIJ]

More from @SalvoRusso8:

Thinking about using different accounts for state and terraform run result, it could be useful to consider the mgmt part (state, locks) and the infrastructure part (target account, resources to deploy with terraform) as two separate points. For example, configuring the parameters like state S3 bucket and locks table in the github action, instead of specifying them in the terraform code, can make it very easy to copy and paste the workflow in different projects, changing only the credentials of the target account.

For Azure, I think you already did this, since the storage account connection string must be specified as secret in the action

[ZIJ]

Related to #428

[ZIJ]

User A. L:

Previously Spacelift was managing the state for me so I had to add the S3 bucket for it. Maybe this is something that digger could handle, a bit like how it creates the DynamoDB table for the locks