jfrog / terraform-provider-project Goto Github PK

Describe the bug
I fetch in my Terraform pipeline a couple of artifacts from a JFrog Artifactory Repository and put them on a S3 bucket.

terraform {
  required_providers {
    artifactory = {
      source  = "jfrog/artifactory"
    }
  }
}

data "artifactory_file" "lambda_function_example_package" {
  repository  = "example-generic-local"
  path        = "aws/lambda/function/example/example-0.0.1.zip"
  output_path = "${path.module}/lambdafunctionexample-0.0.1-${random_id.random.hex}.zip"
}
resource "random_id" "random" {
  keepers = {
    uuid = uuid()
  }
  byte_length = 8
}

This works perfectly fine in version = "6.7.3". However in more recent versions of the Terraform provider (I do not know exactly which version this error is introduced), I get the following errors

module.lambda-demo.module.lambda.module.example.data.artifactory_file.lambda_layer_example: Reading... [id=https://artifactory.example.org/artifactory/example-generic-local/aws/lambda/layer/example/example-layer-0.0.1.zip]
module.lambda-demo.module.lambda.module.example.data.artifactory_file.lambda_function_example_package: Reading... [id=https://artifactory.example.org/artifactory/example-generic-local/aws/lambda/function/example/example-function-0.0.1.zip]
╷
│ Error: open example/artifactory-integration/example-layer-0.0.1-b34i4239377f9de726.zip: no such file or directory
│ 
│   with module.artifactory_integration.data.artifactory_file.testdeploy,
│   on example/artifactory-integration/main.tf line 33, in data "artifactory_file" "testdeploy":
│   33: data "artifactory_file" "testdeploy" {
│ 

Expected behavior
I expect the same behaviour as in version 6.7.3 - file is correctly fetched

module.lambda-demo.module.lambda.module.example.data.artifactory_file.lambda_function_example_package: Read complete after 0s [id=https://artifactory.example.org/artifactory/example-generic-local/aws/lambda/layer/example/example-layer-0.0.1.zip]
module.lambda-demo.module.lambda.module.example.data.artifactory_file.lambda_layer_example: Read complete after 0s [id=https://artifactory.example.org/artifactory/example-generic-local/aws/lambda/function/example/example-function-0.0.1.zip]

Additional context
Add any other context about the problem here.

Describe the bug
When trying to add a project with two letters ("da" in this case) the provider gives an error that the key must be 3 - 6 lowercase letters. The documentation states it can be 2 - 20 lowercase letters and the UI states it can be 2 - 32 lowercase letters.

Provider Error:

│ Error: invalid value for key (key must be 3 - 6 lowercase alphanumeric characters)
│
│ with module.artifactory_projects["da.yml"].project.project,
│ on modules/artifactoryProject/main.tf line 2, in resource "project" "project":
│ 2: key = var.delivery
│
╵

Documentation:
key (String) The Project Key is added as a prefix to resources created within a Project. This field is mandatory and supports only 2 - 20 lowercase alphanumeric and hyphen characters. Must begin with a letter. For example: us1a-test.

UI:
The Project Key is added as a prefix to resources created within a Project
This field is mandatory and supports only
2 - 32 lowercase alphanumeric characters.
Must begin with a letter.
For example: us1a.

Expected behavior
The Provider should let me create or import a project with 2 lowercase letters

Describe the bug
terraform validate says that project keys must be 3-6 characters only. This seems to be fine for Artifactory 7.21.12 (on-premise) but on Artifactory Cloud (7.34.4) one can use 3-10 characters.

Requirements for and issue

• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version: "version" : "7.34.4", "revision" : "73404900"
• Your version of terraform: 1.1.0

Expected behavior
While creating projects against Artifactory Cloud 7.34.4 we get the info that only 3-6 characters are allowed whereas on 7.34.4 3-10 are allowed.

Additional context
Add any other context about the problem here.

This is an open request for input on the HCL for supporting projects

current suggestion:

resource "jfrog_projects" "myproject" {

  repositories = ["myrepo", "other-repo"]
  users = ["user1","user2"]
  group {
    name = "somegroup"
    roles = ["admin","reader"]
  }
  group {
    name = "somegroup1"
    roles = ["admin","reader"]
  }
  member {
    name = "christian"
    roles = ["admin"]
  }
  member {
    name = "karol"
    roles = ["admin"]
  }
  build_repository = "mybuild"
  quota  {
    max_storage = "10gb"
    notification_threshold = "50g"
    block_deployments_on_limit = true
  }
  project_admin {
    user_names = ["christian"]
    roles = ["some_admin_role"]
    manage_resources = true
    index_resources = true
    manage_members = true
  }
}

• A description of the bug
  When setting roles: [] in a project_group resource, rather than the group having no project roles, it gets assigned the default value of ["viewer"]. I have noticed this issue before when defining users to a project in Terraform. What is peculiar is that the plan will clearly mark the "viewer" role to be removed from the plan, but after applying the permission still exists. Manually removing the viewer role resolves the issues as it is never recreated on apply once it is gone.

• 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.

resource "project_group" "pipeline-reader-groups" {
  for_each = var.team_to_users_map

  project_key = var.sdg
  name        = "${each.key}-pipeline-reader"
  roles       = []
  depends_on  = [resource.artifactory_group.pipeline-reader-groups]
}

The plan correctly points out the roles to be removed

# xxx["dct-gbs-mera"] will be updated in-place
  ~ resource "project_group" "pipeline-reader-groups" {
        id          = "dct:dct-gbs-mera-pipeline-reader"
        name        = "dct-gbs-mera-pipeline-reader"
      ~ roles       = [
          - "Viewer",
        ]
        # (1 unchanged attribute hidden)
    }

  # xxx["dct-runteam"] will be updated in-place
  ~ resource "project_group" "pipeline-reader-groups" {
        id          = "dct:dct-runteam-pipeline-reader"
        name        = "dct-runteam-pipeline-reader"
      ~ roles       = [
          - "Viewer",
        ]
        # (1 unchanged attribute hidden)
    }

It also claims in the apply that the updates were applied.

Versions of tf + providers:
terraform_1.7.5_linux_amd64.zip
jfrog/project v1.5.2
jfrog/platform v1.7.4
jfrog/artifactory v10.8.0

Expected behavior
roles: [] should apply what the plan states, and remove the default 'viewer' role.

Describe the bug
Based on the Artifactory REST API it is not possible to change the key of an already existing project. When doing this in Terraform we get an error saying:

{
│   "errors" : [ {
│     "code" : "BAD_REQUEST",
│     "message" : "project key mismatch requested project key doesn't match the body project key"
│   } ]
│ }

Requirements for and issue

• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version: 7.34.4 Artifactory Cloud
• Your version of terraform: 1.0.11

Expected behavior
Either it should be not allowed to rename a key of a project or it should be implemented by re-creating the project.

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.

It is currently only possible to share a central repository with new projects via the UI. This is slow and prone to error when there are 100+ projects within the organisation.

Describe the solution you'd like

resource "artifactory_remote_alpine_repository" "my-remote-alpine" {
  key = "my-remote-alpine"
  url = "http://dl-cdn.alpinelinux.org/alpine"
}

resource "project" "myproject" {
  key          = "myproj"
  display_name = "My Project"
  description  = "My Project"
}

resource "artifactory_share_repository" "my-remote-alpine" {
  repo_name          = artifactory_remote_alpine_repository.my-remote-alpine.name
  target_project_key =  project.myproject.key
}

Describe alternatives you've considered

Additional context

Share Repository with Target Project API

I as a Platform engineer would like to provision Project Roles using terraform.

similar to as implemented here #78

When create environment resource, everything goes well. When importing an existing project environment, some weird behavior happens:

Prerequirement to replicate:

• have a manually created environment named "platform-dta"

Then follows the process:
add the following to your terraform

resource "project_environment" "platform-dta" {
  name        = "platform-dta"
  project_key = "team01"
}

Run import command:
terraform import project_environment.platform-dta team01:platform-dta

Run terraform plan:

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:

 

  # project_environment.platform-dta will be updated in-place
  ~ resource "project_environment" "platform-dta" {
        id          = "adat-common-prd"
      ~ name        = "common-prd" -> "platform-dta"
        # (1 unchanged attribute hidden)
    }

common-prd is an environment that already exists, and it is not intented to be managed by terraform now (it will be in the future).

what my colleague observed is that the import is using the "last" available environment.

Describe the bug
A clear and concise description of what the bug is.

terraform import fail with error: "The configuration for provider["registry.terraform.io/jfrog/project"] depends on values that cannot be determined until apply."

Requirements for and issue

• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)
• [ X] Your version of artifactory (you can curl it at $host/artifactory/api/system/version: Artifactory 7.63.5
• [ X] Your version of terraform: 1.4.6
• JFrog project provider version: 1.1.16.

Expected behavior
A clear and concise description of what you expected to happen.

terraform import the project successfully.

Additional context
Add any other context about the problem here.

We are using below version of providers.

terraform {
  required_providers {
    artifactory = {
      source  = "jfrog/artifactory"
      version = "9.7.0"
    }
    project = {
      source  = "jfrog/project"
      version = "1.3.3"
    }
    xray = {
      source  = "jfrog/xray"
      version = "2.0.1"
    }
    random = {
      source = "hashicorp/random"
      version = "3.5.1"
    }
  }
}

We are running terraform code against 2 artifcatory server ha1 and ha2. We have federated repos in each side and they are in sync.

Whenever we apply the terraform code to provision projects, local, remote, virtual and federated repos.

Projects were not getting assigned to federated repos, so we have used local-exec artifactory api call to set project for repositories.

But ever we reapply the terraform code on same. Projects were getting removed for all the repos.

Please help us resolving this inconsistency of terraform code artifactory.

Here is the code for one of our federated repo.

resource "artifactory_federated_maven_repository" "maven-bu-prod-fed_ha1" {
  depends_on = [artifactory_federated_maven_repository.maven-bu-np-fed_ha1]
  count                = var.maven_enable ? 1 : 0
  key = "${var.business_unit}-maven-prod"
  project_key = project.BU_project_HA2.key
  xray_index                      = true
  #cleanup_on_delete = true

  member {
    enabled = true
    url     = "${var.artifactory-ha1_url}artifactory/${var.business_unit}-maven-prod"
  }

  member {
    enabled = true
    url     = "${var.artifactory-ha2_url}artifactory/${var.business_unit}-maven-prod"
  }
  checksum_policy_type            = "client-checksums"
  handle_releases                 = true
  handle_snapshots                = false
  suppress_pom_consistency_checks = false
  project_environments = ["PROD"]
  provider = artifactory.ha1

  provisioner "local-exec" {
    command = <<-EOT
      exec curl --location --request PUT '${var.artifactory-ha2_url}access/api/v1/projects/_/attach/repositories/${project.BU_project_HA2.key}-maven-prod/${project.BU_project_HA2.key}?force=true/false' --header 'Authorization: Bearer ${var.artifactory-ha2_token}'
    EOT
  }
 
  provisioner "local-exec" {
    command = <<-EOT
      exec curl -u 'admin:${var.ha2_password}' -X POST ${var.artifactory-ha2_url}artifactory/api/repositories/${project.BU_project_HA2.key}-maven-prod -H 'Content-Type: application/json' -d '{"environments":["PROD"]}'
    EOT
  }

}

resource "null_resource" "destroy_prod_maven" {

  triggers = {
    artifactory-ha2_url = var.artifactory-ha2_url
    projectKey          = project.BU_project_HA2.key
    ha2_password        = var.ha2_password
  }
  provisioner "local-exec" {
    when     = destroy
    command = <<-EOT
      exec curl -u 'admin:${self.triggers.ha2_password}' -X DELETE ${self.triggers.artifactory-ha2_url}artifactory/api/repositories/${self.triggers.projectKey}-maven-prod
    EOT
  }
}

Is your feature request related to a problem? Please describe.
Right now, when we create users, we create the users before the project and then assign the users we have created to the project. One of my users is looking to automate this at a much higher scale and I cannot offer him that because terraform right now only allows member association during project creation.

Describe the solution you'd like
I'm eagerly looking for a project_user_association, very similar to how sonarqube does: https://github.com/jdamata/terraform-provider-sonarqube/blob/master/sonarqube/resource_sonarqube_qualitygate_usergroup_association.go

Describe alternatives you've considered
I have no other option besides providing dozens of system account references back to the project admin and he has to add one by one.

Describe the bug
When managing Projects via this provider, whatever value is set for block_deployments_on_limit, the OPPOSITE of this value is being set on the actual project.

In the API the underlying value is called soft_limit. As there is no documentation around the value of this field we can't be 100% sure what JFrog meant this field to mean, but what is true is that if you make an API call for a Project with Block Deployment Beyond Limit set to TRUE, soft_limit will be FALSE in the resulting API GET. The inverse is also true - if you make an API call for a Project with Block Deployment Beyond Limit set to FALSE, soft_limit will be TRUE in the resulting API GET. Either this is intentional or there is a UI bug, I can't be sure which.

The Terraform provider code does this (https://github.com/jfrog/terraform-provider-project/blob/master/pkg/project/resource_project.go#L235):

SoftLimit:              d.GetBool("block_deployments_on_limit", false),

It is setting the value of SoftLimit to be the value of block_deployments_on_limit.

If JFrog intended soft_limit to be the opposite of block_deployments_on_limit then this logic needs to be negated I believe.

Requirements for and issue

• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version
• Your version of terraform

Terraform v1.3.4
Artifactory version 7.47.10
Provider version 1.1.8

Expected behavior
The value set in the Terraform code for block_deployments_on_limit should appear the same in the UI as it the data passed to the provider.

Additional context
Speaking with a colleague we could not be sure what soft limit was intended for. It would be really handy if the same wording was used throughout.

Is your feature request related to a problem? Please describe.
There are two ways of associating repositories and projects - either associating the project key when creating the repository, or assigning a list of repositories when creating the project. I see this as being very similar to the link between groups and users - you basically need to decide on which side you'd like to map the other object.

If you look at the description for user_names under artifactory_group:

users_names - (Optional) List of users assigned to the group. If missing or empty, tf will not manage group membership

This does not seem to work the same way between projects and repositories. If I create a repository and include a project_key, if that repository then isn't in the list passed to projects (even if that attribute is missing) then the relationship is revoked.

Describe the solution you'd like
I'd like the repos attribute on https://registry.terraform.io/providers/jfrog/project/latest/docs/resources/project to work the same way as user_names for artifactory_group, i.e. I can decide to not manage the relationship from the projects side should I so wish.

Describe alternatives you've considered
I've got a hacky workaround where I use lifecycle ignore_changes specifically on the repos attribute when creating my project resources. It seems to work well enough.

Additional context
N/A

Our use case for Xray requires granting access to resources without the global "manage" permissions that would grant access to all Xray resources. To do this, we need to use the limited access granted with Projects to allow Xray resources to be created with the same limited access.

We would like to be able to do this all within Terraform, which means that the project provider needs to be extended to allow a list of Xray resources that are created within a project.

For example:

resource "project" "myproject" {
  # most configuration omitted
  repos = ["docker-local", "rpm-local"]

  # Add watches that are configured in other Terraform code
  watches = ["docker-watch", xray_watch.rpm_watch.name]
}

Describe the bug

When destroying multiple projects by using for_each, there are two issues that can happen:

1. The destroy finishes successfully but some of the projects are not actually deleted from Artifactory. They are deleted from the TF state.
2. The destroy fails with an error message like:

 │ Error: 
│ 404 DELETE https://xxx/access/api/v1/projects/foo-6028e52
│ {
│   "errors" : [ {
│     "code" : "NOT_FOUND",
│     "message" : "Could not find project `bar-6028e52`"
│   } ]
│ }

Note the different project names in the URL vs the error message.

Requirements for and issue

• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)

locals {
  projects = [
    {
      name = "Tfproj1"
      key   = "tfproj1"
    },
    {
      name = "Tfproj2"
      key   = "tfproj2"
    },
    {
      name = "Tfproj3"
      key   = "tfproj3"
    },
    {
      name = "Tfproj4"
      key   = "tfproj4"
    },
    {
      name = "Tfproj5"
      key   = "tfproj5"
    }
  ]
}

provider "project" {
  access_token = var.artifactory_token
  url          = ""
}

terraform {
  required_providers {
    project = {
      source  = "registry.terraform.io/jfrog/project"
      version = "~> 1.1"
    }
  }
}

variable "artifactory_token" {
  type = string
}

resource "project" "project" {
  for_each = { for project in local.projects: project.key => project }

  key          = "${each.value.key}"
  display_name = "${each.value.name}"

  admin_privileges {
    manage_members   = false
    manage_resources = true
    index_resources  = true
  }
}

Run

terraform apply -var artifactory_token=<token>

terraform destroy -var artifactory_token=<token>

• Your version of artifactory (you can curl it at $host/artifactory/api/system/version

7.59.9

• Your version of terraform

v1.5.6

Expected behavior

The projects should be destroy successfully.

Additional context

Logs from the terraform destroy:

project.project["tfproj5"]: Destroying... [id=tfproj5]
project.project["tfproj3"]: Destroying... [id=tfproj3]
project.project["tfproj4"]: Destroying... [id=tfproj4]
project.project["tfproj2"]: Destroying... [id=tfproj2]
project.project["tfproj1"]: Destroying... [id=tfproj1]
project.project["tfproj5"]: Destruction complete after 1s
project.project["tfproj2"]: Destruction complete after 2s
project.project["tfproj1"]: Destruction complete after 2s
project.project["tfproj3"]: Destruction complete after 2s
╷
│ Error: 
│ 404 DELETE https://artifactory-staging.build.ingka.ikea.com/access/api/v1/projects/tfproj4
│ {
│   "errors" : [ {
│     "code" : "NOT_FOUND",
│     "message" : "Could not find project `tfproj2`"
│   } ]
│ }
│ 

Hi Team,

I am trying to manage users in artifactory project and i have project admin role permissions but not able to apply changes using terraform.

Here is the script :

resource "project" "mypro" {
    block_deployments_on_limit = false      
    description                = "My Project"
    display_name               = "dev-test"
    email_notification         = true        
    key                        = "dev001"
    max_storage_in_gibibytes   = 1
    lifecycle {
      ignore_changes = [
          repos
      ]
    }
    admin_privileges {
        index_resources  = true
        manage_members   = true
        manage_resources = true
    }
    member {
        name  = "prakash"
        roles = [
            "Project Admin",
        ]
    }
    member {
        name  = "user1"
        roles = [
            "Viewer",
        ]
    }
    member {
        name  = "user2"
        roles = [
            "Viewer",
        ]
    }
}

Here is the error i am getting while performing terraform apply

"project.mypro: Creating...
╷
│ Error:
│ 403 POST https://prakashrd.jfrog.io/access/api/v1/projects
│ {
│   "errors" : [ {
│     "code" : "FORBIDDEN",
│     "message" : "Logged in 'prakash' is not an admin."
│   } ]
│ }
│
│   with project.mypro,
│   on main.tf line 39, in resource "project" "mypro":
│   39: resource "project" "mypro" {
│
╵"

Please help me is there any solution to skip this error and I can't get admin role for entire org if required.

Thanks in advance.

Describe the bug
Provider does not refresh current state before running destroy and attempts to remove already deleted repo.

Selected output:

# module.project["projectA"].project.this will be destroyed
  # (because module.project["projectA"] is not in configuration)
  - resource "project" "this" {
      - block_deployments_on_limit = false -> null
      - display_name               = "projectA" -> null
      - email_notification         = true -> null
      - id                         = "projectA" -> null
      - key                        = "projectA" -> null
      - max_storage_in_gibibytes   = -1 -> null
      - repos                      = [
          - "projectA-docker",
        ] -> null

      - admin_privileges {
          - index_resources  = true -> null
          - manage_members   = true -> null
          - manage_resources = true -> null
        }

      - group {
          - name  = "projectA-contributors" -> null
          - roles = [
              - "Contributor",
            ] -> null
        }
    }

...

│ Error: failed to delete repos for project: failed to delete repo projectA-docker:
│ 404 DELETE https://blahblah.jfrog.io/access/api/v1/projects/_/attach/repositories/projectA-docker
│ {
│   "errors" : [ {
│     "code" : "NOT_FOUND",
│     "message" : "Could not find resource `projectA-docker`; type `repo` in Projects configuration"
│   } ]
│ }

State file:

 {
      "module": "module.project[\"projectA\"]",
      "mode": "managed",
      "type": "project",
      "name": "this",
      "provider": "provider[\"registry.terraform.io/jfrog/project\"]",
      "instances": [
        {
          "schema_version": 1,
          "attributes": {
            "admin_privileges": [
              {
                "index_resources": true,
                "manage_members": true,
                "manage_resources": true
              }
            ],
            "block_deployments_on_limit": false,
            "description": "",
            "display_name": "projectA",
            "email_notification": true,
            "group": [
              {
                "name": "projectA-contributors",
                "roles": [
                  "Contributor"
                ]
              }
            ],
            "id": "projectA",
            "key": "projectA",
            "max_storage_in_gibibytes": -1,
            "member": [],
            "repos": [
              "projectA-docker"
            ],
            "role": []
          },
          "sensitive_attributes": [],
          "private": "blah==",
          "dependencies": [
            "module.project.artifactory_group.contributors"
          ]
        }
      ]
    },

Requirements for and issue

• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version
• Your version of terraform

Expected behavior
The provider should recognize the response from the API and consider something already removed a success.

OR

The provider should recognize that the repo no longer exists and not attempt to remove it.

Additional context

Artifactory version: 7.39.10
Terraform v1.2.6
on linux_amd64

• provider registry.terraform.io/jfrog/artifactory v6.15.1
• provider registry.terraform.io/jfrog/project v1.1.7

Project definition in node module:

resource "project" "this" {
  key          = substr(var.display_name, 0, 10)
  display_name = var.display_name
  description  = var.description
  admin_privileges {
    manage_members   = true
    manage_resources = true
    index_resources  = true
  }
  max_storage_in_gibibytes   = var.storage_quota
  block_deployments_on_limit = false
  email_notification         = true

  dynamic "group" {
    for_each = var.groups_contributor
    content {
      name  = group.key
      roles = ["Contributor"]
    }
  }

  group {
    name  = artifactory_group.contributors.name
    roles = ["Contributor"]
  }

  # Repos are created in the repository module. Ignore changes in the project modudle.
  lifecycle {
    ignore_changes = [
      repos
    ]
  }
}

Repository definition in platform module:

resource "artifactory_federated_docker_repository" "this" {
  key                  = "${local.project_key}-docker"
  max_unique_tags      = 300
  project_environments = var.project_environments
  project_key          = local.project_key
  tag_retention        = 100
  xray_index           = true

  dynamic "member" {
    for_each = toset(var.platform_nodes)
    content {
      url     = "https://${member.value}/artifactory/${local.project_key}-docker"
      enabled = true
    }
  }
}

Describe the bug
When assigning a large number (200+) existing repos to project(s) using the repos attribute, some assignments fail with 400 error. The error message suggests Artifactory isn't able to service all the concurrent API calls.

Expected behavior
All the repos be assigned to the respective projects

Additional context

See jfrog/terraform-provider-artifactory#329 (comment)

Describe the bug

Artifactory Cloud version: 7.78.1
Terraform version: 1.3.6
Project provider version: 1.5.2

Upon removing the project provider, terraform plan fails with the following error:

Error: Invalid provider configuration

Provider "registry.terraform.io/jfrog/project" requires explicit
configuration. Add a provider block to the root module and configure the
provider's required arguments as described in the provider documentation.

Error: expected "access_token" to not be an empty string, got 

  with provider["registry.terraform.io/jfrog/project"],
  on <empty> line 0:
  (source code not available)

Requirements for and issue

• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version
• Your version of terraform

Expected behavior
The project provider can be removed without any errors.

This is similar to the issue for the artifactory provider: jfrog/terraform-provider-artifactory#425

The new projects feature was released recently and we are very interested in using it. However going over the docs here it seems that there is not support yet.

Is your feature request related to a problem? Please describe.
terraform doesn't have resource to create virtual repositories.

Describe the solution you'd like
terrfrom resource component to create virtual resources

Describe alternatives you've considered
jfrog API instead of terraform

Additional context
none

I can map repository with environment (DEV or PROD) in Artifactory Project UI. How could I do this in the terraform provider?
Maybe you have any plans to implementation this feature.
In project resource I seen only one point to map repositories repos = local.all_repos_list

My code example:

## Projects
resource "project" "terraform-project" {
  key          = var.art_project_key
  display_name = "${upper(var.art_base)} Project"
  description  = "Business unit: ${upper(var.business_unit)}, Responsobility person: ${var.responsibility_person}"
  admin_privileges {
    manage_members   = false
    manage_resources = false
    index_resources  = true
  }
  max_storage_in_gibibytes   = var.art_repos_size
  block_deployments_on_limit = false
  email_notification         = true

  repos = local.all_repos_list

  dynamic "group" {
    for_each = var.art_env
    content {
      name  = "sec_artifactory_${var.art_base}_${group.value}_rw"
      roles = group.value == "prod" ? ["Release Manager", "Viewer"] : ["Contributor"]
    }
  }

  dynamic "group" {
    for_each = var.art_env
    content {
      name  = "sec_artifactory_${var.art_base}_${group.value}_read"
      roles = ["Viewer"]
    }
  }

  depends_on = [
    artifactory_local_generic_repository.terraform-local-generic-repo,
    artifactory_local_nuget_repository.terraform-local-nuget-repo,
    artifactory_local_docker_v2_repository.terraform-local-docker-repo,
    artifactory_local_npm_repository.terraform-local-npm-repo,
    artifactory_local_pypi_repository.terraform-local-pypi-repo,
    artifactory_local_maven_repository.terraform-local-maven-repo,
    artifactory_local_conan_repository.terraform-local-conan-repo,
    artifactory_local_debian_repository.terraform-local-debian-repo,
    artifactory_local_gitlfs_repository.terraform-local-gitlfs-repo,
    artifactory_local_go_repository.terraform-local-go-repo,
    artifactory_local_helm_repository.terraform-local-helm-repo,
    artifactory_group.adsync_user_group,
    artifactory_group.adsync_user_group_read
  ]
}

Describe the bug
Managing a project via terraform 1.4.6 works fine.
same code with terraform 1.5.3 produce the following error:

C:\terraform_1.5.3\Modules>..\terraform apply
module.Artifactory.artifactory_user.build-user: Refreshing state... [id=mydemo-build-system]
module.Artifactory.artifactory_user.admin-user: Refreshing state... [id=e175409]

Terraform used the selected providers to generate the following execution plan. Resource actions are indicated with the following symbols:
  + create

Terraform will perform the following actions:

  # module.Artifactory.project.terraform-project will be created
  + resource "project" "terraform-project" {
      + block_deployments_on_limit = true
      + description                = "mydemo project admin: Terraform Project"
      + display_name               = "mydemo Project"
      + email_notification         = true
      + id                         = (known after apply)
      + key                        = "mydemo"
      + max_storage_in_gibibytes   = 10

      + admin_privileges {
          + index_resources  = true
          + manage_members   = true
          + manage_resources = true
        }

      + member {
          + name  = "e175409"
          + roles = [
              + "Project Admin",
            ]
        }
      + member {
          + name  = "mydemo-build-system"
          + roles = [
              + "Contributor",
            ]
        }
    }

Plan: 1 to add, 0 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

module.Artifactory.project.terraform-project: Creating...
╷
│ Error:
│ 400 POST https://artifactory-dev.amat.com/access/api/v1/projects
│ {
│   "errors" : [ {
│     "code" : "BAD_REQUEST",
│     "message" : "Project Quota cannot be lower than `1073741824` bytes. Input: -2147483648"
│   } ]
│ }
│
│   with module.Artifactory.project.terraform-project,
│   on ..\Artifactory_Project\main.tf line 51, in resource "project" "terraform-project":
│   51: resource "project" "terraform-project" {

Requirements for and issue

• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version 7.59.9
• Your version of terraform 1.5.3

Expected behavior
should work as terraform 1.4.6.
changes to max_storage_in_gibibytes produce the same error again

Additional context
Add any other context about the problem here.

Is your feature request related to a problem? Please describe.
It seems like I can't manage "shared" repositories together with “assigned” repositories and this is what I need to do. My TF state gets messed up.

Describe the solution you'd like
I would like to create remote repos for all public repos we use and share with all the projects (I need sharing here).
Then, we plan to have ~10 projects and for each project we need many local repos assigned to a project and virtual also assigned to a project which contains local and the "shared remotes" (here I need assignments). All via Terraform.

# I'm using "repos" as per the documentation
resource "project" "project" {
  key          = var.tla
  display_name = var.name
  .....
  # Not adding assignments yet on purpose
  repos = []

# 
resource "artifactory_remote_maven_repository" "mvn" {
  url = var.url
  key = var.name
  .....
  #ignoring bause I'm managing assignments via "project"
  #I coundn't find anything separate for "sharing" feature
  lifecycle {
    ignore_changes = [
      project_key
    ]
  }
}

Since I couldn't find an option to "share" via terraform, I went to the UI and shared it. Of course it starts to get messy. Even though I didn't use "assign to project" in the UI, I used "share", I'm seeing this change.

Terraform will perform the following actions:

  # module.onsite_project.project.project will be updated in-place
  ~ resource "project" "project" {
      ~ repos                      = [
          - "shared-docker-remote",
            # (1 unchanged element hidden)
        ]
    }

and then I get a message:

Error: failed to update repos for project:
│ 404 DELETE https://jfrog.bestsecrettec.com/access/api/v1/projects/_/attach/repositories/shared-docker-remote
│ {
│ "errors" : [ {
│ "code" : "NOT_FOUND",
│ "message" : "Could not find resource shared-docker-remote; type repo in Projects configuration"
│ } ]
│ }

In the end, I think it would be a good idea to allow people to "share" repos on the repo level as part of the "artifactory_virtual_maven_repository" resource and leave the "repos = []" on the project level only for project assignments.

Describe alternatives you've considered
I was thinking to use the "project_key" in the repo to do the assignments (which is not suggested by the docs) and use lifecycle to ignore the "repos" on the project level. Then I have to share the repos manually via UI.

Describe the bug
The project resource allows project key with length 3-6 and in the UI the length is between 2-32

Requirements for and issue

• Example code

resource "project" "backend" {
  key                        = "backend"
  display_name               = "Backend"
  max_storage_in_gibibytes   = -1
  block_deployments_on_limit = false
  email_notification         = true

  admin_privileges {
    index_resources  = true
    manage_members   = true
    manage_resources = true
  }

  dynamic "member" {
    for_each = local.users_contributor
    content {
      name = member.value
      roles = [
        "Contributor",
        "Viewer"
      ]
    }
  }

  dynamic "member" {
    for_each = local.users_viewer
    content {
      name = member.value
      roles = [
        "Viewer"
      ]
    }
  }

  repos = [
    artifactory_local_npm_repository.npm.key,
    artifactory_remote_npm_repository.npm.key,
    artifactory_virtual_npm_repository.npm.key,
  ]
}

• Artifactory SaaS: 7.76.0
• Terraform: 1.6.6

Expected behavior
The requirements for the project key in the terraform resource is the same that in the JFrog UI

Additional context
UI information:

Terraform plan error:

Describe the bug
Edge nodes are failing the license check. check_license = false is being required to work around issue.

Requirements for and issue

• A description of the bug
• 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.
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version
• Your version of terraform
• Your version of terraform provider

Expected behavior
Edge nodes should not need to have the license check bypassed as they are included in the necessary license levels.

Additional context

curl -H "Authorization: Bearer $TOKEN"  https://xxxx.jfrog.io/artifactory/api/system/license
{
  "type" : "Edge",
  "validThrough" : "N/R",
  "licensedTo" : "Artifactory Online Dedicated"
}

Terraform v1.2.5

provider registry.terraform.io/jfrog/artifactory v6.11.2
provider registry.terraform.io/jfrog/project v1.1.3

Describe the bug
When trying to install the jfrog/project provider we get the error

Initializing modules...
- customers in modules/customer
Initializing provider plugins...
- Reusing previous version of jfrog/project from the dependency lock file
- Reusing previous version of jfrog/artifactory from the dependency lock file
- Installing jfrog/project v1.4.0...
- Installing jfrog/artifactory v10.3.0...
- Installed jfrog/artifactory v10.3.0 (signed, key ID 6B219DCCD7639232)
Providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://opentofu.org/docs/cli/plugins/signing/
╷
│ Error: Failed to install provider
│ 
│ Error while installing jfrog/project v1.4.0: authentication signature from
│ unknown issuer
╵

We tested this is 1.4.0 as well as 1.5.1.

We are using opentofu 1.6.2

Example code

provider "artifactory" {
}

provider "project" {
}


terraform {
  required_providers {
    artifactory = {
      source  = "jfrog/artifactory"
      version = "10.3.0"
    }
    project = {
      source  = "jfrog/project"
      version = "1.4.0"
    }
  }

  required_version = ">=1.0"
}

Expected behavior
Being able to install the provider.

I hope this is the right place for this issue! Thank you for your help!

I as a Platform engineer would like to provision Project Environments using terraform

Is your feature request related to a problem? Please describe.
The general access to our artifactory is controled via SSO while we'd like to manage our project and memberships through terraform. Unfortunately project admins have no access to the user list (only main admins) which is quite contradictive to the UI behavior where you can search for users (API call: GET /ui/api/v1/access/entities/users?filter=&limit=50&direction=asc)

We have a code managed list of our developers as we also manage our GitHub Enterprise Organization via terraform and would like to grant the same users access to Artifactory. Now it can happen that users haven't logged in yet and there is no account yet in artifactory.

Describe the solution you'd like

It would be great if we can specify for each member block whether it is OK that a user is missing.

If this flag is set, an error for a missing/unknown user would be ignored.

Additionally, if the user later logs in and we re-run the apply, the user should be assigned successfully. So likely some information has to be written into the state or be considered in the refresh step that it is detected that a user is missing.

Describe alternatives you've considered
We could flag users separately whether to be created in artifactory but this solution doesn't scale well.

Additional context
Unfortunately this request is more a workaround than a proper solution to user management. But the limitations are rather on the backend (artifactory / projects) due to missing APIs to check for user existence. If there would be an API whether users exist (input: list of usernames, output: whether they exist) we could dynamically generate the right user list before triggering terraform.

Until then I see it as more realistic that this provider might ignore the API errors on assignment.

Describe the bug
Using both providers, terraform-provider-project and terraform-provider-artifactory, I create the project, with all the information needed with the attribute "repos" empty. Then, the repositories are created with reference to that project. Repositories are created inside the project.

After a second update, "repos" field will update from having some repositories to having none, as repos are empty. To solve this I need to add the list of repositories created... but I only can add them afterward as there is a dependency between the project and the repositories and the other way around.

Expected behavior
If repos field is not set, it should not be forced to be empty, or in some way, I need to be able to retrieve the repositories associated with the project to add them to that list.

Is your feature request related to a problem? Please describe.
We use jfrog terraform provider. We want to setup projects but now its impossible

Describe the solution you'd like
We need to add resource for create Project with provide additional data: Storage Quota, Groups, Repository linking, etc

Any plans to add this functionality?

Describe the bug
When I test 0.9.1-pre now I'm getting this error:

│ 
│   on providers.tf line 10, in provider "project":
│   10:   check_license = false
│ 
│ An argument named "check_license" is not expected here.

I see that arg is still in the source code, but is missing from the terraform registry documentation. Here are my terraform.tf and providers.tf files:

terraform {
  required_version = ">= 0.15.3"
  required_providers {
    artifactory = {
      source  = "registry.terraform.io/jfrog/artifactory"
      version = "2.6.15"
    }
    project = {
      source  = "registry.terraform.io/jfrog/project"
      version = "0.9.1-pre"
    }
    aws = {
      source  = "registry.terraform.io/hashicorp/aws"
      version = "3.70.0"
    }
    pipeline = {
      source  = "jfrog/pipelines"
      version = "0.0.1"
    }
 }

provider "artifactory" {
  url          = var.artifactory_url
  access_token = var.artifactory_access_token
  check_license = false
}

provider "project" {
  url           = var.artifactory_url
  access_token  = var.artifactory_access_token
  check_license = false
}

provider "pipeline" {
  url           = var.artifactory_url
  access_token  = var.artifactory_access_token
  check_license = false
}

provider "aws" {
  region = "us-west-2"
}

Requirements for and issue

• [x ] A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)
• [ x] Your version of artifactory (you can curl it at $host/artifactory/api/system/version: 7.29.8
• [x ] Your version of terraform: v0.15.3

Expected behavior
A clear and concise description of what you expected to happen.
The provider should accept the check_license argument

Additional context
Add any other context about the problem here.

If we try to create a project and the artifactory already have repositories shared with all projects, it fails to create project with the following error message:

╷
│ Error: failed to delete repos for project: failed to delete repo charts.bitnami.com: 
│ 404 DELETE <OMITTED_JFROG_URL>/access/api/v1/projects/_/attach/repositories/<REPO_KEY>
│ {
│   "errors" : [ {
│     "code" : "NOT_FOUND",
│     "message" : "Could not find resource `<REPO_KEY>`; type `repo` in Projects configuration"
│   } ]
│ }
│

provider version 1.1.7
jfrog version, enterprise plus latest available.

test case:
create remote repo, share with all projects:

if we create the project via UI, the remote gets created successfully.

if we create the project using this provider, it fails with the above error message.

what I expect: projects to be created.

from my humble understanding of golang, I traced to the following:

first create project

calls update repos

calls readRepos

and fetches the projects:

it returns the available shared repos as "to be deleted" and tries to delete

then it fails here

I could not find a proper GET to see if repo is sharedWithAllProjects, but I found this rest call via UI

https://<JFROG_INSTANCE>/ui/api/v1/ui/admin/repositories/remote/info?projectKey=unassigned

that returns a json list with the following:

so there is a way to check. Can we check if the repo is already shared in the updateRepos or readRepos method??

Describe the bug
A clear and concise description of what the bug is.

Requirements for and issue

• A fully functioning terraform snippet that can be copy&pasted (no outside files or ENV vars unless that's part of the issue)
• Your version of artifactory (you can curl it at $host/artifactory/api/system/version
  JFrog Platform SaaS
• Your version of terraform
  v1.5.7

How to reproducte

1. Create terraform config with 1 project that links to 3 virtual, 3 remote and 3 local repos using the repos key.
2. Apply config. Project is successfully created and has all 9 repos listed
3. Perform terraform destroy
4. In arround 30% of executions there is the error:

400 DELETE https://xxxxxx.jfrog.io/access/api/v1/projects/project_name
{
  "errors" : [ {
    "code" : "BAD_REQUEST",
    "message" : "project containing resources can't be removed"
  } ]
}

5. Checking in the UI you can see that the unassignment of the repos did not work. One repo still shows the project that should have been deleted.

Workaround
Execute destroy again and it will work.

Additional context

This provider is currently only available for amd64 processors on Mac (Darwin). Support for new Mac M1 processors will require the code to be compiled for darwin_arm64.

Current behaviour

$  terraform init

Initializing the backend...

Initializing provider plugins...
- Finding jfrog/project versions matching "1.0.1"...
╷
│ Error: Incompatible provider version
│
│ Provider registry.terraform.io/jfrog/project v1.0.1 does not have a package available for your current platform, darwin_arm64.
│
│ Provider releases are separate from Terraform CLI releases, so not all providers are available for all platforms. Other versions of this provider may have different platforms supported.
╵