Giter VIP home page Giter VIP logo

terraform-provider-project's Introduction

Terraform Provider for Artifactory Project

Actions Status Go Report Card

Quick Start

Create a new Terraform file with project resource (and artifactory resource as well). Also see sample.tf:

HCL Example
# Required for Terraform 0.13 and up (https://www.terraform.io/upgrade-guides/0-13.html)
terraform {
  required_providers {
    artifactory = {
      source  = "registry.terraform.io/jfrog/artifactory"
      version = "2.6.24"
    }
    project = {
      source  = "registry.terraform.io/jfrog/project"
      version = "0.9.1"
    }
  }
}

provider "artifactory" {
  // supply ARTIFACTORY_USERNAME, ARTIFACTORY_PASSWORD and ARTIFACTORY_URL as env vars
}

provider "project" {
  // supply PROJECT_URL and PROJECT_ACCESS_TOKEN as env vars
}

variable "qa_roles" {
  type    = list(string)
  default = ["READ_REPOSITORY", "READ_RELEASE_BUNDLE", "READ_BUILD", "READ_SOURCES_PIPELINE", "READ_INTEGRATIONS_PIPELINE", "READ_POOLS_PIPELINE", "TRIGGER_PIPELINE"]
}

variable "devop_roles" {
  type    = list(string)
  default = ["READ_REPOSITORY", "ANNOTATE_REPOSITORY", "DEPLOY_CACHE_REPOSITORY", "DELETE_OVERWRITE_REPOSITORY", "TRIGGER_PIPELINE", "READ_INTEGRATIONS_PIPELINE", "READ_POOLS_PIPELINE", "MANAGE_INTEGRATIONS_PIPELINE", "MANAGE_SOURCES_PIPELINE", "MANAGE_POOLS_PIPELINE", "READ_BUILD", "ANNOTATE_BUILD", "DEPLOY_BUILD", "DELETE_BUILD", ]
}

resource "artifactory_user" "user1" {
  name     = "user1"
  email    = "[email protected]"
  groups   = ["readers"]
  password = "Passw0rd!"
}

resource "artifactory_user" "user2" {
  name     = "user2"
  email    = "[email protected]"
  groups   = ["readers"]
  password = "Passw0rd!"
}

resource "artifactory_group" "qa-group" {
  name             = "qa"
  description      = "QA group"
  admin_privileges = false
}

resource "artifactory_group" "release-group" {
  name             = "release"
  description      = "release group"
  admin_privileges = false
}

resource "artifactory_local_docker_v2_repository" "docker-local" {
  key             = "docker-local"
  description     = "hello docker-local"
  tag_retention   = 3
  max_unique_tags = 5
}

resource "artifactory_remote_npm_repository" "npm-remote" {
  key                                  = "npm-remote"
  url                                  = "https://registry.npmjs.org"
  mismatching_mime_types_override_list = "application/json,application/xml"
}

resource "project" "myproject" {
  key          = "myproj"
  display_name = "My Project"
  description  = "My Project"
  admin_privileges {
    manage_members   = true
    manage_resources = true
    index_resources  = true
  }
  max_storage_in_gibibytes   = 10
  block_deployments_on_limit = false
  email_notification         = true

  member {
    name  = "user1"
    roles = ["Developer", "Project Admin"]
  }

  member {
    name  = "user2"
    roles = ["Developer"]
  }

  group {
    name  = "qa"
    roles = ["qa"]
  }

  group {
    name  = "release"
    roles = ["Release Manager"]
  }

  role {
    name         = "qa"
    description  = "QA role"
    type         = "CUSTOM"
    environments = ["DEV"]
    actions      = var.qa_roles
  }

  role {
    name         = "devop"
    description  = "DevOp role"
    type         = "CUSTOM"
    environments = ["DEV", "PROD"]
    actions      = var.devop_roles
  }

  repos = ["docker-local", "npm-remote"]

  depends_on = [
    artifactory_user.user1,
    artifactory_user.user2,
    artifactory_group.qa-group,
    artifactory_group.release-group,
    artifactory_local_docker_v2_repository.docker-local,
    artifactory_remote_npm_repository.npm-remote,
  ]
}

Initialize Terrform:

$ terraform init

Plan (or Apply):

$ terraform plan

Detailed documentation of the resource and attributes are on Terraform Registry.

License requirements:

This provider requires access to the APIs, which are only available in the licensed pro and enterprise editions. You can determine which license you have by accessing the following URL ${host}/artifactory/api/system/licenses/

You can either access it via api, or web browser - it does require admin level credentials, but it's one of the few APIs that will work without a license (side node: you can also install your license here with a POST)

curl -sL ${host}/artifactory/api/system/licenses/ | jq .
{
  "type" : "Enterprise Plus Trial",
  "validThrough" : "Jan 29, 2022",
  "licensedTo" : "JFrog Ltd"
}

The following 3 license types (jq .type) do NOT support APIs:

  • Community Edition for C/C++
  • JCR Edition
  • OSS

Limitations of functionality

Currently this provider does not support the followings:

  • Xray support for the project

Versioning

In general, this project follows semver as closely as we can for tagging releases of the package. We've adopted the following versioning policy:

  • We increment the major version with any incompatible change to functionality, including changes to the exported Go API surface or behavior of the API.
  • We increment the minor version with any backwards-compatible changes to functionality.
  • We increment the patch version with any backwards-compatible bug fixes.

Contributors

See the contribution guide.

License

Copyright (c) 2022 JFrog.

Apache 2.0 licensed, see LICENSE file.

terraform-provider-project's People

Contributors

alexanderrmcneill avatar alexhung avatar antonmos avatar apr-1985 avatar ax-taustgen avatar bendrucker avatar bodgit avatar chb0github avatar danielku15 avatar danielmkn avatar dasmanas avatar dependabot[bot] avatar dillon-giacoppo avatar jamestoyer avatar jasonwbarnett avatar jfroche avatar jfrogsolutioncicd avatar josh-barker-coles avatar kaitimmer avatar kierranm avatar ma-sdnshakya avatar michaelchristopherson avatar rossedman avatar ryndaniels avatar trevorah avatar ttsangatlassian avatar turhsus avatar volkc-basf avatar wc-s avatar zymzxq avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

terraform-provider-project's Issues

Deleting project fails sometimes

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"
  } ]
}
  1. 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

Fetching artifacts to file fails in newer versions of the provider

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.

Error: expected "access_token" to not be an empty string when project provider is removed

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

Unable to install provider in OpenTofu

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!

Provider attempts to remove already deleted repo from project

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
    }
  }
}

Support sharing repositories between projects

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

Allow for Projects resource to not manage associated repositories

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

provider failed with terraform 1.5.3

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.

Project Key param does not support 2 characters as mentioned in the docs and the UI

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

Fails to create project with Could not find resource `charts.bitnami.com`; type `repo` in Projects configuration

Delete(projectsUrl + "/_/attach/repositories/{repoKey}")

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:
image

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

var createProject = func(ctx context.Context, data *schema.ResourceData, m interface{}) diag.Diagnostics {

calls update repos

_, err = updateRepos(ctx, data.Id(), repos, m)

calls readRepos

projectRepoKeys, err := readRepos(ctx, projectKey, m)

and fetches the projects:

_, err := m.(*resty.Client).R().

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

deleteErr := deleteRepos(ctx, projectKey, repoKeysToBeDeleted, m)

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:

image

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

Environment mapping for repositories in project

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
  ]
}

Not able to manage users in project with project admin role permissions using terraform.

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.

Allow project members to be missing (due to API limitations on checking user availability)

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.

Importing project environment shows diff

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.

Inconsistency of terraform code for jfrog artifactory provider for federated repos.

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
  }
}

Project key must be 3 - 6 lowercase alphanumeric characters

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.

Projects support

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?

Edge Nodes Failing License Check

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

Changing project key not supported

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.

Possible logic negation bug on block_deployments_on_limit

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.

Creation of the jfrog virtual repository in terraform code

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

Terraform import error for JFrog Project

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.

Terraform destroy has issues when using for_each for the project resource

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`"
│   } ]
│ }
│ 

Support for Mac M1 (darwin_arm64)

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

[FEATURE] Add User/Group to project independent after the project is created

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.

Cyclic dependency when creating terraform code that creates a project and some related repositories.

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.

Define HCL

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
  }
}

Project key length

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:
image

Terraform plan error:
image

Was check_license removed from published provider?

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.

Add support for Xray resources in projects

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]
}

Enhance Terraform Support for Simultaneously Managing Shared and Assigned Repositories in Artifactory

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.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.