Will new provider version have breaking changes?

[carlitos081]

I see that the a specific provider version works only with a specific range of Artifactory versions...
I'm in the middle of creating and migrating all our Artifactory configuration(a lot of it having around 38 licences) and I'd like to know if that will create any headache when we will update Artifactory which happens in the frequency of twice a year. Any experiences from users is much appreciate, thanks

[alexhung]

@carlitos081 The Artifactory versions referenced in the CHANGLOG.md is to show the version the provider has been tested against and known to work. This doesn't mean the provider doesn't work with earlier version of Artifactory.

There are some specific cases that only specific version of providers work with specific Artifactory versions but those are very rare and we try to document this in CHANGELOG.md as well as the resource's documentation.

If you can provider more details on your migration (e.g. the version of Artifactory you are upgrading to, the resources you use, etc.), I should be able to tell you if there are any potential conflict.

[carlitos081]

Hi @alexhung, I try to explain my experience on which I wrote this github question...
I was just testing the jfrog terraform provider with version 10.0.0 and my Artifactory is on 7.55.6
When I create a repo with the following code:

resource "artifactory_local_gems_repository" "terraform-local-dev-gems-repo" {
  provider = artifactory.test_instance
  for_each = {
    for index, repo in var.local-gems-repository : repo.team_name => repo
    if repo.dev
  }
  key         = "gems-${each.value.team_name}-dev"
  description = each.value.description
  xray_index  = each.value.xray-index
}

It create the repo without issue, except when I try to run terraform apply again I get update in place as it try to change the project_key and I get a 404:

 tg apply
data.google_service_account_access_token.default: Reading...
data.google_service_account_access_token.default: Read complete after 0s [id=projects/-/serviceAccounts/sa-tier2-ambt-art-cicd-prod@wd-ambt-art-cicd-prod.iam.gserviceaccount.com]
artifactory_local_gems_repository.terraform-local-dev-gems-repo["opseng"]: Refreshing state... [id=gems-opseng-dev]

Terraform used the selected providers to generate the following execution
plan. Resource actions are indicated with the following symbols:
  ~ update in-place

Terraform will perform the following actions:

  # artifactory_local_gems_repository.terraform-local-dev-gems-repo["opseng"] will be updated in-place
  ~ resource "artifactory_local_gems_repository" "terraform-local-dev-gems-repo" {
        id                       = "gems-opseng-dev"
      - project_key              = "default" -> null
        # (13 unchanged attributes hidden)
    }

Plan: 0 to add, 1 to change, 0 to destroy.

Do you want to perform these actions?
  Terraform will perform the actions described above.
  Only 'yes' will be accepted to approve.

  Enter a value: yes

artifactory_local_gems_repository.terraform-local-dev-gems-repo["opseng"]: Modifying... [id=gems-opseng-dev]
╷
│ Error: 
│ 404 DELETE https://artifactory-aws.com/access/api/v1/projects/_/attach/repositories/gems-opseng-dev
│ {
│   "errors" : [ {
│     "code" : "NOT_FOUND",
│     "message" : "Could not find resource `gems-opseng-dev`; type `repo` in Projects configuration"
│   } ]
│ }
│ 
│   with artifactory_local_gems_repository.terraform-local-dev-gems-repo["opseng"],
│   on main.tf line 1, in resource "artifactory_local_gems_repository" "terraform-local-dev-gems-repo":
│    1: resource "artifactory_local_gems_repository" "terraform-local-dev-gems-repo" {
│ 
╵
Releasing state lock. This may take a few moments...

Then I came on this github project and saw that the version 10.0.0 is not compatible with my Artifactory version so I downgrade my terraform provider to the one suggested(8.9.1) for my artifactory version and it worked with no issue.

So based on that experience I'm quite afraid to import all thousands of resources, spending very long time to do it, and then when we update Artifactory we will see attempt to update and delete resources that are unchanged. This is what scary me at the moment, can you reassure me in some way that we will get all the jfrog support when issue with terraform provider rises?
Also have you heard of anyone else in the same situation, where they invested on the terraform migration and then regretted it? Thanks

[alexhung]

@carlitos081 In my original response I mentioned:

There are some specific cases that only specific version of providers work with specific Artifactory versions

and this project_key issue is one of these.

This was a bug introduced to Artifactory 7.50.x at the beginning of last year that took a while to fix and released. For a while we maintained both v6 (for pre 7.50.x) and v7 (for post 7.50.x) to ensure our customers could take advantage of fixes and new features.

The fix to this bug was released in September (7.68.7 for self-hosted and 7.67.0 for cloud) and provider v9 was released to work with the new Artifactory versions.

In general the provider releases tracks the latest Artifactory version, this is how the provider can support new features, etc. For cases that there is breaking changes, we increment the major version to signify such backward incompatibility.

To your question:

can you reassure me in some way that we will get all the jfrog support when issue with terraform provider rises?

Yes and 'it depends' 😄 . We stride to support any issue our customers reported but we don't have large team maintaining the TF provider repos so we have to prioritize what we can and cannot support.

[carlitos081]

Hi @alexhung, Thanks all make sense, and see also someone answering questions is encouraging, I hope also to collaborate if needed, thank you