Facing error while updating provider to 9.3.1

[MA140589]

Describe the bug As a solution to https://github.com/jfrog/terraform-provider-artifactory/issues/818, we are upgrading provider version to 9.3.1, but while appling we are facing issue as below :

logs_591.zip logs_591.zip

Error: 
404 DELETE https://expediauswest2.jfrog.io/access/api/v1/projects/_/attach/repositories/carrental-debian-internal-local
{
  "errors" : [ {
    "code" : "NOT_FOUND",
    "message" : "Could not find resource `carrental-debian-internal-local`; type `repo` in Projects configuration"
  } ]
}

  with module.artylab_repository["carrental-debian-internal-local"].artifactory_remote_debian_repository.this[0],
  on .terraform/modules/artylab_repository/debian.tf line 1, in resource "artifactory_remote_debian_repository" "this":
   1: resource "artifactory_remote_debian_repository" "this" {

Also attaching whole log file of Terraform Apply.

We are using artifactory version : 7.56.5

We are using Terraform version : 1.3.6

We were using Terraform provider version : 8.2.3

We are upgrading Terraform provider version to 9.3.1

Requirements for and issue

• [x] A description of the bug
• [x] A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue). If this is not supplied, this issue will likely be closed without any effort expended.
• [x] Your version of artifactory (you can curl it at $host/artifactory/api/system/version
• [x] Your version of terraform
• [x] Your version of terraform provider

Expected behavior Terraform Apply should run successfully.

[alexhung]

@MA140589 The message suggests that repository carrental-debian-internal-local is no longer assigned to a project in your resource/module, and the provider is attempting to remove it from that project. But it fails because the repository on Artifactory has already been unassigned from that project.

[MA140589]

@alexhung but we have not removed it manually ? Also while creation of repo's in our terraforms we have not passed project_key in remote or smart remote repo's. How can we fix this problem ? This is now a blocker for us to move forward and apply new changes.

When we upgraded the provider, it has automatically changed project key like below :

module.artylab_repository["carrental-debian-internal-local"].artifactory_remote_debian_repository.this[0]` has changed ~ resource "artifactory_remote_debian_repository" "this" { id = "carrental-debian-internal-local" ~ project_key = "" -> "default"

(40 unchanged attributes hidden)

   # (1 unchanged block hidden)

}

module.remote_repository["confluent-maven"].artifactory_remote_maven_repository.this[0]: Refreshing state... [id=confluent-maven]

module.artylab_repository["carrental-debian-internal-local"].artifactory_remote_debian_repository.this[0] will be updated in-place

~ resource "artifactory_remote_debian_repository" "this" { id = "carrental-debian-internal-local"

• project_key = "default" -> null

  (40 unchanged attributes hidden)

  (1 unchanged block hidden)

  }

[alexhung]

@MA140589 I notice that you are currently running Artifactory 7.56.5. As mentioned in the changelog for V9.0.0 release this major version update is to revert the Artifactory API behavior where projectKey contains default for repository that is not assigned to any project. The fix in Artifactory is released for v7.68.7 (self-hosted) and v7.67.0 (cloud). This means your instance does not yet have this fix.

There are a number of workaround if you wish to stay with v9:

• Set project_key = "default". Whilst this will resolve the problem, when you upgrade your instance to post v7.68.7/v7.67.0, you will need to remove this attribute again.
• Use meta attribute lifecycle.ignore_changes

  lifecycle {
  ignore_changes = [
  project_key,
  ]
  }

• Go back to v8.x provider until your instance is upgraded.

[MA140589]

We added project_key = "default" for time being we not get upgraded to v7.67.0 (cloud) version. Thanks for the help.