Creating a repository with init_type as Uninitialized fails on subsequent apply

[roryprimrose]

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

Terraform (and Azure DevOps Provider) Version

Terraform v1.0.11
on windows_amd64
+ provider registry.terraform.io/hashicorp/local v2.1.0
+ provider registry.terraform.io/microsoft/azuredevops v0.1.8

Affected Resource(s)

• azuredevops_git_repository

Terraform Configuration Files

resource "azuredevops_project" "project" {
  name               = "Sample Project"
  visibility         = "private"
  version_control    = "Git"
  work_item_template = "Agile"
}

resource "azuredevops_git_repository" "repo" {
  project_id = azuredevops_project.project.id
  name       = "Blank.Repo.Testing"
  default_branch = "refs/heads/main"
  initialization {
    init_type = "Uninitialized"
  }
  lifecycle {
    ignore_changes = [
      # Ignore changes to initialization to support importing existing repositories
      # Given that a repo now exists, either imported into terraform state or created by terraform,
      # we don't care for the configuration of initialization against the existing resource
      initialization,
      size
    ]
  }
}

Debug Output

Output from first apply

  # module.azdo_repository["7fe4e3d3-0f73-4be1-93e4-d46607457597"].azuredevops_git_repository.repository will be created
  + resource "azuredevops_git_repository" "repository" {
      + default_branch = "refs/heads/main"
      + id             = (known after apply)
      + is_fork        = (known after apply)
      + name           = "Blank.Repo.Testing"
      + project_id     = "70c59e49-2d7a-4ea5-ad11-10843c24df7b"
      + remote_url     = (known after apply)
      + size           = (known after apply)
      + ssh_url        = (known after apply)
      + url            = (known after apply)
      + web_url        = (known after apply)

      + initialization {
          + init_type = "Uninitialized"
        }
    }

module.azdo_repository["7fe4e3d3-0f73-4be1-93e4-d46607457597"].azuredevops_git_repository.repository: Creating...
module.azdo_repository["7fe4e3d3-0f73-4be1-93e4-d46607457597"].azuredevops_git_repository.repository: Creation complete after 0s [id=b2d67e6c-6a31-4a35-a7d2-b1786af00ef0]

Output from second apply

  # module.azdo_repository["7fe4e3d3-0f73-4be1-93e4-d46607457597"].azuredevops_git_repository.repository will be updated in-place
  ~ resource "azuredevops_git_repository" "repository" {
      + default_branch = "refs/heads/main"
        id             = "b2d67e6c-6a31-4a35-a7d2-b1786af00ef0"
        name           = "Blank.Repo.Testing"
        # (7 unchanged attributes hidden)

        # (1 unchanged block hidden)
    }

    terraform apply "state.tfplan"
module.azdo_repository["7fe4e3d3-0f73-4be1-93e4-d46607457597"].azuredevops_git_repository.repository: Modifying... [id=b2d67e6c-6a31-4a35-a7d2-b1786af00ef0]
╷
│ Error: Error updating repository in Azure DevOps: TF401020: The Git ref with name refs/heads/main does not exist in the repository with name or identifier B2D67E6C-6A31-4A35-A7D2-B1786AF00EF0.
│
│   with module.azdo_repository["7fe4e3d3-0f73-4be1-93e4-d46607457597"].azuredevops_git_repository.repository,
│   on azdo.repository\main.tf line 2, in resource "azuredevops_git_repository" "repository":
│    2: resource "azuredevops_git_repository" "repository" {
│
╵

Panic Output

Expected Behavior

Apply the second time should not fail.

Actual Behavior

The first apply does not seem to set the default branch because the repo is going to be uninitialized. The second apply sees that the default branch is different and tries to set it. This then fails on the AzDO REST API because the default branch doesn't exist.

Is it possible to have the provider not try to set the default_branch if the repo is still uninitialized?

Steps to Reproduce

1. terraform init
2. terraform validate
3. terraform plan -var-file dev.tfvars -out state.tfplan
4. terraform apply "state.tfplan"
5. terraform plan -var-file dev.tfvars -out state.tfplan
6. terraform apply "state.tfplan"

Important Factoids

N/A

References

• #0000

[roryprimrose]

Because we use the AzDO provider to keep the org in sync with configuration, we run apply regularly. With this issue in play, we can't use uninitialized repository resources and must use Clean instead.

[roryprimrose]

There is also another issue with this. If you do the first apply with an uninitialized repo, followed by creating a build branch policy that uses the default_branch then you get the following error.

╷
│ Error: Provider produced inconsistent final plan
│ 
│ When expanding the plan for
│ module.azdo_pipeline["0a91cc14-57d6-411a-894f-488af6999045"].azuredevops_build_definition.pipeline
│ to include new values learned so far during apply, provider
│ "registry.terraform.io/microsoft/azuredevops" produced an invalid new value
│ for .repository[0].branch_name: was cty.StringVal("refs/heads/main"), but
│ now cty.StringVal("").
│ 
│ This is a bug in the provider, which should be reported in the provider's
│ own issue tracker.
╵
##[error]PowerShell exited with code '1'.

The workaround here was to not specify the default branch as it was optional on the build policy anyway. That then leads into the issue above when apply comes in against the repository the second time.

[xuzhang3]

@roryprimrose When setting the init_ype=Uninitialized, the repo won't be initialized which means this repos does not have any branches, when you apply the second apply command, the default branch setting operation will call the branch API but it cannot find any branches because this repo was not initialized. ADO should enhance the condition checks for repo intial, some configuration is not suitable for all init_type