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

feature request: allow importing opslevel_service_repository by service id and repository id #531

Open
jpo-tu opened this issue Nov 6, 2024 · 5 comments

Comments

@jpo-tu
Copy link

jpo-tu commented Nov 6, 2024

Today, importing opslevel_service_repository requires importing via the ServiceRepository id, which is a uid representing the "marriage" of a service and a repository:

terraform import opslevel_service_repository.example Z2lkOi8vb3BzbGV2ZWwvU2VydmljZS82MDI0

(Note: it's unclear if that actually is the supported usage as importing this resource does not actually work for any combination of uid(s), but that's a separate issue).

The uid required is only discoverable via inspection of the graphql API response for a service, via the .repos.Edges[].ServiceRepositories[].Id property.

This is a feature request to support importing opslevel_service_repository via a combination of the service id and repository id. For example for a fictional service with id Z2lkOi8abc and repository with id Z2lkOi8123

terraform import opslevel_service_repository.example Z2lkOi8abc:Z2lkOi8123

This is simply a more intuitive way of importing said resource.

@rocktavious
Copy link
Collaborator

Hey @jpo-tu - I know this is a follow up from your other requests and while i'd love to support this there is a limitation that would break this assumption that you can use the repo ID to import a "service repository". Currently in-app you are allowed to connect the same repository to a service multiple times as long as the "base path" is different. This is why the import functionality needs the actual "service repository" ID and not just the service ID and repository ID. Because under the hood its actually a Join Table that we call "service repository"

Now that being said we could try to implement this and try to detect that a service has the same repository connected twice and then throw up an error saying its an ambiguous situation so that in the 90% of cases where its a 1:1 mapping it works but we safe guard that edgecase.

Do you know if your account has any repos with the same repository attached twice with different base paths?

@jpo-tu
Copy link
Author

jpo-tu commented Nov 6, 2024

Do you know if your account has any repos with the same repository attached twice with different base paths?

I don't know. I would guess we hardly have any with multiple repos differentiated by base path.

you are allowed to connect the same repository to a service multiple times as long as the "base path" is different

Ah good point! What if the base_path was part of the import id as a third component?

@rocktavious
Copy link
Collaborator

What if the base_path was part of the import id as a third component?

That would make it foolproof but then its gets back to being more complicated to use

Long term the right thing is to fix our CLI opslevel export terraform so you can just use that to dump it all out and pick and choose want you need / want to terraform.

This is already on the roadmap to being in Dec. I'm not sure i'll beable to fit in taking on this import fix before that lands.

@rocktavious
Copy link
Collaborator

Hey @jpo-tu - So upon further investigation it looks like the code for import got broken in the 1.X upgrade where we changed the underlying terraform provider framework from their v1 to v3.

Since we are going to go in and fix this bug we are also going to pull in adding support for the service alias and service repository default alias as options for import. So after the next release the following will be possible:

import {
  id = "my-cool-service-alias:github.com:Example-Org/cool-service"
  to = opslevel_service_repository.my-cool-service
}

@jpo-tu
Copy link
Author

jpo-tu commented Nov 7, 2024

support for the service alias and service repository default alias

Ahh that would be great if you could! Regardless, if importing at the very least is fixed that would be wonderful.

Thanks for looking into this.

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