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

Support creating azuredevops_git_repository with import using signed in account #1076

Open
Pidgegeddon opened this issue Jun 17, 2024 · 3 comments

Comments

@Pidgegeddon
Copy link

Community Note

  • Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
  • Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
  • If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Our team would like to be able to create new repos based on a private template repo we have. We currently need to supply a service connection with PAT to import this repo without creating a fork. Instead of using this service connection, we would like this resource to try creating the repo using the signed-in user/principal that the provider uses for other operations.

New or Affected Resource(s)

  • azuredevops_git_repository

Potential Terraform Configuration

Simply omitting the argument initialization.service_connection_id in the resource azuredevops_git_repository should try creating the repo with initialization type import using the logged-in user

data "azuredevops_project" "example" {
  name = "Example Project"
}

data "azuredevops_git_repository" "example_source_repo" {
  project_id = data.azuredevops_project.example.id
  name       = "Source Repository" #private repo
}

resource "azuredevops_git_repository" "example" {
  project_id = data.azuredevops_project.example.id
  name       = "copied git repo"
  initialization {
    init_type   = "Import"
    source_type = "Git"
    source_url  = data.azuredevops_git_repository.example_source_repo.remote_url
  }
}

References

Importing repos like this was added in #402, but since then this provider has added the support for login with a Service Connection in #747

@Pidgegeddon Pidgegeddon changed the title Support creating azuredevops_git_repository using signed in account Support creating azuredevops_git_repository with import using signed in account Jun 17, 2024
@xuzhang3
Copy link
Collaborator

@Pidgegeddon Service account/SPN login user cannot be used to import repositories. In fact, the credentials used to import repository are delegated to the service connection

@joshshand
Copy link

@Pidgegeddon Service account/SPN login user cannot be used to import repositories. In fact, the credentials used to import repository are delegated to the service connection

Hey @Pidgegeddon - are you saying that it is only possible to do a private repo Import using a service connection in the current version of this provider or that it's a technical limitation of ADO?

I have just managed to get it working using a service connection defined in TF with the same PAT configured that I use to run the project. Seems a bit strange you couldn't, by default, just pass the running provider credentials to the initialization 🤔 which is what this request is asking for...

@Pidgegeddon
Copy link
Author

Hi!

are you saying that it is only possible to do a private repo Import using a service connection

It does seem like it. I also believe this is an ADO limitation from the fact that when you manually do it from ADO, you need to reference a PAT or username/password.

We ended up solving it by referencing another service connection that have a PAT configured. The service connection running the pipeline with terraform apply is using workload federation and could not be used.
We want to avoid using PAT as they need to be renewed at some point

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

No branches or pull requests

3 participants