Add stack_activator resource to terraform provider

[dobarx]

Description of the change

Created a new resource for enabling/disabling Spacelift stacks. Example:

resource "spacelift_stack" "app" {
  branch     = "master"
  name       = "Application stack"
  repository = "app"
}

resource "spacelift_stack_activator" "test" {
  enabled  = true
  stack_id = spacelift_stack.app.id
}

Type of change

• [ ] Bug fix (non-breaking change that fixes an issue)
• [x] New feature (non-breaking change that adds functionality)
• [ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
• [ ] Documentation (non-breaking change that adds documentation)

Related issues

Checklists

Development

• [x] Lint rules pass locally
• [x] The code changed/added as part of this pull request has been covered with tests
• [x] All tests related to the changed code pass in development
• [x] Examples for new resources and data sources have been added
• [x] Default values have been documented in the description (e.g., "Dummy: (Boolean) Blah blah. Defaults to false.)
• [x] If the action fails that checks the documentation: Run go generate to make sure the docs are up to date

Code review

• [x] This pull request has a descriptive title and information useful to a reviewer. There may be a screenshot or screencast attached
• [x] Pull Request is no longer marked as "draft"
• [x] Reviewers have been assigned
• [ ] Changes have been reviewed by at least one other engineer

[Clickup-user]

Task linked: CU-334hhwd Add stack_activator resource to terraform provider

[dobarx]

@adamconnelly

So what if we flipped it slightly:

1. Try to invoke the enable/disable mutation. I'm assuming it'll fail if the stack doesn't exist / you don't have access to it (but you'd need to double check that).
2. Call resourceStackActivatorRead to query for the stack, and set the state based on the IsDisabled field.

Just a thought - feel free to ignore me if that doesn't make sense for some reason.

But how do we know which mutation to invoke? We have two separate mutations stackDisable(id) & stackEnable(id). I do not know which to call unless I query stack first and compare. It would only be possible if we had something like setStackEnabled(id, value).

[adamconnelly]

@adamconnelly

So what if we flipped it slightly:

1. Try to invoke the enable/disable mutation. I'm assuming it'll fail if the stack doesn't exist / you don't have access to it (but you'd need to double check that).
2. Call resourceStackActivatorRead to query for the stack, and set the state based on the IsDisabled field.

Just a thought - feel free to ignore me if that doesn't make sense for some reason.

But how do we know which mutation to invoke? We have two separate mutations stackDisable(id) & stackEnable(id). I do not know which to call unless I query stack first and compare. It would only be possible if we had something like setStackEnabled(id, value).

I guess I figured you'd know which one to call based on the value of the enabled Terraform property. But maybe that doesn't handle the situation where the stack is enabled but the Terraform state thinks it's disabled or something like that?

[dobarx]

@adamconnelly

So what if we flipped it slightly:

1. Try to invoke the enable/disable mutation. I'm assuming it'll fail if the stack doesn't exist / you don't have access to it (but you'd need to double check that).
2. Call resourceStackActivatorRead to query for the stack, and set the state based on the IsDisabled field.

Just a thought - feel free to ignore me if that doesn't make sense for some reason.

But how do we know which mutation to invoke? We have two separate mutations stackDisable(id) & stackEnable(id). I do not know which to call unless I query stack first and compare. It would only be possible if we had something like setStackEnabled(id, value).

I guess I figured you'd know which one to call based on the value of the enabled Terraform property. But maybe that doesn't handle the situation where the stack is enabled but the Terraform state thinks it's disabled or something like that?

I could use this d.GetChange("enabled") to get old and new values of TF state. But I figured if stack is enabled/disabled by other process then this could lead to the issue when applying changes fail. So retrieving current state before applying these changes seems a bit safer.

[adamconnelly]

@dobarx ok - no worries. Makes sense.