jfrog / terraform-provider-project Goto Github PK
View Code? Open in Web Editor NEWTerraform provider to manage JFrog Projects
Home Page: https://jfrog.com/artifactory
License: Apache License 2.0
Terraform provider to manage JFrog Projects
Home Page: https://jfrog.com/artifactory
License: Apache License 2.0
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
curl
it at $host/artifactory/api/system/version
: "version" : "7.34.4", "revision" : "73404900"
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
curl
it at $host/artifactory/api/system/version
: 7.34.4 Artifactory CloudExpected 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.
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.
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
}
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:
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
curl
it at $host/artifactory/api/system/version
: Artifactory 7.63.5Expected 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
curl
it at $host/artifactory/api/system/version
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:
│ 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
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>
curl
it at $host/artifactory/api/system/version
7.59.9
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
curl
it at $host/artifactory/api/system/version
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
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
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
curl
it at $host/artifactory/api/system/version
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
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
curl
it at $host/artifactory/api/system/version
7.59.9Expected 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 resourceshared-docker-remote
; typerepo
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
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,
]
}
Expected behavior
The requirements for the project key in the terraform resource is the same that in the JFrog UI
Describe the bug
Edge nodes are failing the license check. check_license = false
is being required to work around issue.
Requirements for and issue
curl
it at $host/artifactory/api/system/version
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
curl
it at $host/artifactory/api/system/version
: 7.29.8Expected 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
curl
it at $host/artifactory/api/system/version
How to reproducte
project
that links to 3 virtual, 3 remote and 3 local repos using the repos
key.400 DELETE https://xxxxxx.jfrog.io/access/api/v1/projects/project_name
{
"errors" : [ {
"code" : "BAD_REQUEST",
"message" : "project containing resources can't be removed"
} ]
}
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
.
$ 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.
╵
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.