Ephemeral action ids are impossible to reference in octopusdeploy_variable action scopes

[BuriedStPatrick]

Describe the bug

Deployment steps get new ids whenever they're changed. This makes it impossible to target them in the octopusdeploy_variable.scope.actions array if they change.

Steps to reproduce

1. Add an octopusdeploy_project and a octopusdeploy_deployment_process resource with 2 deployment steps (doesn't matter which type).
2. Deploy the changes to Octopus
3. Gather the IDs of your deployment steps by navigating to them in the Octopus UI (or via the API)
4. Add an octopusdeploy_variable, reference the octopusdeploy_project with the owner_id and limit the scope to a particular action:

resource "octopusdeploy_variable" "my_connection_string" {
  name = "ConnectionStrings:DefaultConnection"
  value = "..."
  owner_id = octopusdeploy_project.my_project.id
  type = "string"

  scope {
    actions = [
      "42110fb4-6e4f-4bd3-b795-0743aa7ab5be" # The ID of the deployment step you want to target
    ]
  }
}

5. Deploy the changes to Octopus
6. Make a change to your targeted deployment step via Terraform
7. Deploy the changes to Octopus
8. The ID you provided for the scope.actions is no longer valid. You will be pointing to an invalid resource.

Expected behavior

In an ideal world, the ID of the deployment step (action) would simply stay the same. I can gather that, due to how OctopusDeploy probably works at the moment, that would be quite the breaking change. The deployment steps are far too ephemeral to have deterministic terraform deployments. This borders between bug and feature because essentially, the actions array is useless as a write-property which I see as a bug, but the proper solution would be a feature-implementation so we can better track these deployment steps as individual entities in our terraform configurations.

Alternatively, the scope.actions array could target steps by name. Not ideal since multiple steps could have the same name, but it's at least something relatively tangible.

Environment and versions:

• OS: Windows
• Octopus Server Version: 2021.3.12372
• Terraform Version: 1.4.6
• Octopus Terraform Provider Version: 0.12.0

[mjhilton]

I think you're correct in saying that the boundary between bug and feature/behaving-as-designed is quite unclear here, @BuriedStPatrick. You're right that this is fairly deep in the way Octopus works right now, and we're unlikely to change it.

In my opinion, the best way of holding the provider in this situation would be to avoid hardcoding IDs gathered from the UI. I'd prefer to see the ID referenced directly from the Terraform resource that creates it, something like this:

resource "octopusdeploy_project" "project" {
  name = "Ephemeral Action IDs"
  lifecycle_id = "Lifecycles-1"
  project_group_id = "ProjectGroups-1"
}

resource "octopusdeploy_deployment_process" "process" {
  project_id = octopusdeploy_project.project.id
  
  step {
    name = "ExampleScript"
    run_script_action {
      name = "ExampleScript"
      worker_pool_variable = "Hello"
      run_on_server = true
      script_body = "Write-Host 'Hello world'\r\n"
      sort_order = 1
    }
  }
}

resource "octopusdeploy_variable" "var" {
  name = "ScopedVariable"
  type = "String"
  value = "I'm scoped to the 'ExampleScript' step"
  owner_id = octopusdeploy_project.project.id
  scope {
    actions = [
      octopusdeploy_deployment_process.process.step[0].run_script_action[0].id
    ]
  }
}

I know it's been a long time since you reported this, but are you able to fill me in on the reason for gathering those IDs from the UI instead of referencing them directly?