Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Read-only workspace ID from the API add to Workspace resource #19

Closed
petems opened this issue Sep 14, 2018 · 3 comments
Closed

Read-only workspace ID from the API add to Workspace resource #19

petems opened this issue Sep 14, 2018 · 3 comments

Comments

@petems
Copy link
Contributor

petems commented Sep 14, 2018

Right now, the ID given for a workspace from Terraform is org-name|workspace-name

However, if you want to use the API to do something, like trigger a run or such, you have to use the workspace ID as defined by the TFE API, which is an alphanumeric like ws-oMQsEub2cEKmPBAs:

{
  "data": {
    "id": "ws-mD5bmJ8ry3uTzuHi", #this bit
    "type": "workspaces",
    "attributes": {
      "name": "workspace-1",
      "environment": "default",
      "auto-apply": false,
      "locked": false,
      "created-at": "2018-03-08T22:30:00.404Z",
      "working-directory": null,
      "terraform-version": "0.11.3",
      "permissions": {
        "can-update": true,
        "can-destroy": true,
        "can-queue-destroy": true,
        "can-queue-run": true,
        "can-update-variable": true,
        "can-lock": true,
        "can-read-settings": true
      },
      "actions": {
        "is-destroyable": true
      }
    },

It would be good to have this as a read-only varible for resources, so it can be output on creation so it can be used outside of Terraform

@svanharmelen
Copy link
Contributor

The TFE API is a bit nasty with regards to the workspace API calls. If you want to retrieve or update the workspace, you need the organization and workspace name. But indeed some other API's that reference a workspace, do this by the external workspace ID.

Can you share the use case for this (why having this in the TF state is needed)? Of course we can add the external ID, but I'm a bit worried that people are going to be even more confused when they see that ID next to the value that is called id in the TF state 😏

@petems
Copy link
Contributor Author

petems commented Sep 14, 2018

Yeah id would be confusing... we can call it something else if needed. Like workspace_id or external_id or something 😅

My usecase is the ability to trigger runs in TFE. I'm creating 500 workspaces with TFE, and want to trigger a plan in all of them. the only way to trigger plans is using the ws id.

output "ids_of_all_workspaces" {
  value = ["${tfe_workspace.5mb_workspace.*.id}"]
}

but got the other ID... 😞

There's no easy way of outputting all the ID's from Terraform for consumption with another tool (like Postman/Curl/Ruby script)

One solution could be to have a run/plan/trigger resource in the TFE provider, but I feel like run/plan triggering falls outside of the scope of the provider, since it's not a "State". It might even be a usecase for a provisioner almost?

@svanharmelen
Copy link
Contributor

Fixed by PR #21

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants