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

Make ExternalStudioHost be its own resource #2

Open
tessellator opened this issue Jun 25, 2024 · 5 comments
Open

Make ExternalStudioHost be its own resource #2

tessellator opened this issue Jun 25, 2024 · 5 comments

Comments

@tessellator
Copy link
Owner

The following is from @petero-dk in #1.

Why would I want this:
The same sanity project is used in a couple of different deployment pipelines (think staging / prod / dev) and for the Sanity project only one would be able to have the resource of the project (which i don't want) so I have linked the Sanity project as a data object in terraform.

However for my production pipeline, I would like to set the external host name as that is dependent on other resources in that pipeline.

Currently that is not possible because it is available only on the project resource.

@tessellator
Copy link
Owner Author

My initial concern with extracting ExternalStudioHost into its own resource is that there can only be one external studio host per project. Creating multiple instances would interfere with each other.

However, this is exactly how the aws_sqs_queue_redrive_allow_policy works ref. If you create two instances one overwrites the other, and if you delete one, it removes the policy from the queue altogether.

I think it is reasonably to think that people with the use case described in the original write-up will be aware if there are more than one ExternalStudioHost resource is created (or at least, they will figure out out really quickly).

@tessellator
Copy link
Owner Author

I was also concerned that the change here would not be backwards compatible, and it was not clear to me how many people would be affected.

However, in doing some initial research, I have found a bug in the underlying go-sanity library that has prevented anyone from actually using the ExternalStudioHost option to-date.

While the proposed change will technically break backwards compatibility, it won't in practice.

@tessellator
Copy link
Owner Author

Here is a short example of what I think the API should look like.

resource "sanity_project" "my_blog" {
  name        = "My blog"
  color       = "#0000ff"
  studio_host = "my-cool-blog"
}

resource "sanity_project_external_studio_host" "my_blog" {
  project = sanity_project.my_blog.id
  host    = "https://studio.example.com"
}

project is already used in other resources, and host is similar with studio_host in the project resource.

Does this make sense to you, @petero-dk?

@petero-dk
Copy link

I think that looks excellent, just to make sure that would work with a data project object also?

@tessellator
Copy link
Owner Author

Yes, good call out, thanks.

I will use this to start going through your PR later this evening.

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