jfrog / terraform-provider-artifactory Goto Github PK

View Code? Open in Web Editor NEW

273.0 11.0 101.0 41.71 MB

Terraform provider to manage JFrog Artifactory

Home Page: https://jfrog.com/artifactory

License: Apache License 2.0

Go 97.67% Makefile 0.22% Shell 0.44% Dockerfile 0.02% HCL 1.64%

jfrog artifactory terraform terraform-provider infrastructure-as-code configuration-as-code golang

terraform-provider-artifactory's Introduction

Terraform Provider Artifactory

Releases

Current provider major release: 10.x

See CHANGELOG.md for full details

Versions

Version 6.x is compatible with the Artifactory versions 7.49.x and below.

Version 7.x and 8.x is only compatible with Artifactory between 7.50.x and 7.67.x due to changes in the projects functionality.

Version 10.x is the latest major version and is compatible with latest Artifactory versions (>=7.68.7 (self-hosted) and >=7.67.0 (cloud)).

Terraform CLI version support

Current version support Terraform Protocol v6 which mean Terraform CLI version 1.0 and later.

Quick Start

Create a new Terraform file with artifactory resources. Also see sample.tf:

HCL Example

# Required for Terraform 1.0 and up (https://www.terraform.io/upgrade-guides)
terraform {
  required_providers {
    artifactory = {
      source  = "jfrog/artifactory"
      version = "10.0.2"
    }
  }
}

provider "artifactory" {
  // supply JFROG_ACCESS_TOKEN, and JFROG_URL as env vars
}

resource "artifactory_local_pypi_repository" "pypi-local" {
  key         = "pypi-local"
  description = "Repo created by Terraform Provider Artifactory"
}

resource "artifactory_artifact_webhook" "artifact-webhook" {
  key         = "artifact-webhook"
  event_types = ["deployed", "deleted", "moved", "copied"]
  criteria {
    any_local        = true
    any_remote       = false
    repo_keys        = [artifactory_local_pypi_repository.pypi-local.key]
    include_patterns = ["foo/**"]
    exclude_patterns = ["bar/**"]
  }
  url    = "http://tempurl.org/webhook"
  secret = "some-secret"
  proxy  = "proxy-key"

  custom_http_headers = {
    header-1 = "value-1"
    header-2 = "value-2"
  }

  depends_on = [artifactory_local_pypi_repository.pypi-local]
}

Initialize Terrform:

$ terraform init

Plan (or Apply):

$ terraform plan

Documentation

To use this provider in your Terraform module, follow the documentation on Terraform Registry.

License requirements

This provider requires access to Artifactory 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 requires 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"
}

Versioning

In general, this project follows Terraform Versioning Specification as closely as we can for tagging releases of the package.

Developers Wiki

You can find building, testing and debugging information in the Developers Wiki on GitHub.

Contributors

See the contribution guide.

License

Apache 2.0 licensed, see LICENSE file.

terraform-provider-artifactory's People

Contributors

Stargazers

Watchers

Forkers

medains colesgroup absaoss asvoboda ma-sdnshakya donovanmuller namrata-rajpoot jasonwbarnett rossedman gitter-badger mikeycmccarthy neilbeukes ryndaniels kimsondrup computeracer thor kuleuven tenstad briansu2004 iainsteers kevinbuckley netjordan kvonbredow randyhoover cappyzawa feliu cawilson danielris amolgire ax-taustgen sailorgallifrey michaelchristopherson spuder wc-s pleyo danielmkn useurmind amarendarjogula pbvdms antonmos mrgiles russellrollins jamestoyer davidschile-automox jonattta skyzyx ax-kbarry osapozhnikov guent4 batokenms ruheenaansari34 sqlhorizons daftping alexeiser nikitakoselev neilvana gain620 pasangl720 freshvolk martinm82 ribbybibby olamzykenth bmanuel anupamphoghat-contino apr-1985 isimahei jphelton mugioka marek-mikolajczyk ateoto bardielle sharonsbo butch12 alexhung eletenkov subbu2429 kumarcc1 bb-ricardo gwnlng arvindkumar422 ssyeds ljluestc pascal-hofmann christopherfriedrich chb0github tjstansell raghed22 chris-peterson gurudatha14 undefinedhuman tijko ramvisa atz nax-tech dortam888

terraform-provider-artifactory's Issues

Permission targets only get partially applied

Describe the bug

When creating a permission target through Terraform the affected permissions only get partially applied with respect to X-Ray infos. I created a simple scenario with a Docker repository and a test user which only has read and annotate permissions on the respective repository. Meanwhile I pushed a hello-world image to this repository with another user. After logging in, the repository and its content are visible to the test user but the X-Ray tab is not.

Once I login as an administrator and simply save the created permission again without changing anything, the X-Ray tab is accessible to the test user.
I'm talking about the X-Ray tab under Artifactory -> Artifacts -> xray-permissions-test-repo -> hello-world -> manifest.json.

Requirements for and issue

resource "random_password" "password_tu" {
  length           = 30
  special          = true
  override_special = "_%@"
}

resource "artifactory_user" "test" {
  name     = "permission-test-user"
  email    = "[email protected]"
  password = random_password.password_tu.result
}

resource "artifactory_permission_target" "technical_user" {
  name = "permission-test"

  repo {
    repositories = [artifactory_local_repository.test_repo.key]
    actions {
      users {
        name        = artifactory_user.test.name
        permissions = ["read", "annotate"]
      }
    }
  }
}

resource "artifactory_local_repository" "test_repo" {
  key             = "xray-permissions-test-repo"
  package_type    = "docker"
  repo_layout_ref = "simple-default"
  xray_index      = "true"
}

JFrog cloud platform
Terraform v0.14.5

Expected behavior
Permissions working like set.

Additional infos
The system logs don't show any more infos which could lead to the source of the issue.

Env variable defaults ignored when unset in provider

The option to use env variables as a way to provide authentication does not work when user does not set anything in the provider.

How to reproduce:

Set ARTIFACTORY_PASSWORD and ARTIFACTORY_USERNAME in env
Add provider in main.tf and only provide url argument
Run apply
See Error: either [username, password] or [api_key] or [access_token] must be set to use provider

Expected result: provider should see env variables and set according in schema, if no variables and no arguments given, show above error.

Cannot manage group level boolean attributes

Describe the bug
As of now the only attribute that is supported at group resources is admin_privileges, in last some releases Jfrog has added a number of other attributes to the group , this includes
Manage resources
Manage policies
Manage watches
and Manage Reports
With these options not available it is very difficult the mange groups (some settings being manual)
Requirements for and issue

[7.15.3 ] Your version of artifactory (you can curl it at $host/artifactory/api/system/version
[ .12] Your version of terraform

Expected behavior
Provider should give options to set other boolean properties for groups and ditto for users
Additional context
Add any other context about the problem here.

Strings that change to empty fail to be updated.

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

terraform 0.13.2

Affected Resource(s)

artifactory_remote_repository

Probably all resources that have string fields that it is valid to be the empty string.

Terraform Configuration Files

Using gocenter.io as a remote for the purposes of this example

Initial state

resource "artifactory_remote_repository" "someremote" {
  url             = "https://gocenter.io"
  key             = "gocenter"
  package_type    = "go"
  repo_layout_ref = "go-default"
  proxy           = "someproxy"
}

Second apply

resource "artifactory_remote_repository" "someremote" {
  url             = "https://gocenter.io"
  key             = "gocenter"
  package_type    = "go"
  repo_layout_ref = "go-default"
  proxy           = ""
}

Expected Behavior

Proxy should have been removed with a change of

proxy "someproxy" -> ""

Actual Behavior

Proxy field not passed to the API, as it got reduced to null

proxy "someproxy" => null

This retains the value "someproxy" in the remote.

Steps to Reproduce

This affects any string field in which changing the field to "" in the API would be a valid change.

terraform apply with initial state
terraform apply after changing a string field to ""

Possible fix

At https://github.com/jfrog/terraform-provider-artifactory/blob/master/pkg/artifactory/util.go#L15
d.GetOk(key) should perhaps be d.GetOkExists(key) so that empty strings are not treated as null

Strings that change to empty fail to be updated

Community Note
Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Terraform Version
terraform 0.13.2

Affected Resource(s)
artifactory_remote_repository
Probably all resources that have string fields that it is valid to be the empty string.

Terraform Configuration Files
Using gocenter.io as a remote for the purposes of this example

Initial state

resource "artifactory_remote_repository" "someremote" {
url = "https://gocenter.io"
key = "gocenter"
package_type = "go"
repo_layout_ref = "go-default"
proxy = "someproxy"
}
Second apply

resource "artifactory_remote_repository" "someremote" {
url = "https://gocenter.io"
key = "gocenter"
package_type = "go"
repo_layout_ref = "go-default"
proxy = ""
}
Expected Behavior
Proxy should have been removed with a change of

proxy "someproxy" -> ""

Actual Behavior
Proxy field not passed to the API, as it got reduced to null

proxy "someproxy" => null

This retains the value "someproxy" in the remote.

Steps to Reproduce
This affects any string field in which changing the field to "" in the API would be a valid change.

terraform apply with initial state
terraform apply after changing a string field to ""
Possible fix
At https://github.com/atlassian/terraform-provider-artifactory/blob/master/pkg/artifactory/util.go#L15
d.GetOk(key) should perhaps be d.GetOkExists(key) so that empty strings are not treated as null

System Configuration

Is there a plan for adding system configurations like backups to the terraform module?

I want to be able to setup my fleet of artifactory clusters using terraform.
I was not able to find how can I achieve configs like backups.

I know I can do that through PATCH calls as described in Artifactory YAML Configurations, but using terraform is the standard way in my case.

Request to add support for repo_type in resources while creating a watch

Describe the bug
Recently this jfrog/artifactory provider added support to create XRay policies and watches which is a nice feature and many of us were waiting for this capability to be added in this provider.

I just started exploring policy and watch creation using terraform but what I notice is specifically for the watches that we can't add a remote repository in resources section. By default it treat the repository as local. I think it make sense if we can add one more attribute repo_type something like this:

resource "artifactory_xray_watch" "xray_watch" {
    name = "watch1"
    active = true
  
    resources {
       type = "repository"
       name = "abc-local"
       repo_type = "local"    ---- this is default value
    }

   resources {
       type = "repository"
       name = "abc-remote"
       repo_type = "remote"
  }
  ....
  ....
}

Requirements for and issue

SaaS Artifactory
0.14.5

Expected behavior
As stated above I think we should have a parameter to segregate local and remote artifactory repositories.

Additional context
Add any other context about the problem here.

State-Drift when AccessToken exists in TerraformState but not in Artifactory

Describe the bug
When an Access-Token exists in Terraform-State, but is deleted in Artifactory (e.g. by using the UI), the provider is not able to detect the drift.

I understand from

terraform-provider-artifactory/pkg/artifactory/resource_artifactory_access_token.go

Line 191 in c15a858

func resourceAccessTokenRead(d *schema.ResourceData, m interface{}) error {

that this is intended, but the provider can at least check if an Access-Token with the same name exists. Otherweise a warning or something comparable would be nice.

Requirements for and issue
...

Expected behavior
The Access-Token should be created if not existing in artifactory or a warning should be shown.

Additional context
...

Support docker repo setting for blocking manifest v1 publishing

Per https://www.jfrog.com/confluence/display/JFROG/Repository+Configuration+JSON, I think this is just a single boolean in a local repo setting for

blockPushingSchema1 = true | false

Add legit support for nuget packages

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

While Jfrog Rest API docs for create repo do not seem to list this flag (https://www.jfrog.com/confluence/display/RTF6X/Repository+Configuration+JSON#RepositoryConfigurationJSON-LocalRepository), when I raised a support ticket with Jfrog support, they have confirmed that forceNugetAuthentication should work. I will look to raise a PR for this, but I have not worked with GOlang before (I have done plenty of work in C#).

New or Affected Resource(s)

artifactory_local_repository
artifactory_remote_repository

Potential Terraform Configuration

artifactory_local_repository {
  force_nuget_authentication = true
}

Add Force Nuget Auth option for virtual Repo also

Hi,

As per the #23 Issue Created a while ago,

It would be great to also have this option when creating a nuget virtual repo. In the Above issue it was only added to Remote and Local.

New or Affected Resource(s)

artifactory_virtual_repository

Potential Terraform Configuration

artifactory_virtual_repository {
  force_nuget_authentication = true
}

Support mTLS for HTTP SSO

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Corporate environments often rely on PKI. There's currently no way of using the provider (without rebuilding) in a situation when HTTP SSO is used with in conjunction with mTLS (client side TLS auth). Also, allowing using custom CaCertsPool would be necessary.

New or Affected Resource(s)

None

Potential Terraform Configuration

Three env variables for provider configuration, e.g.:

ARTIFACTORY_KEY
ARTIFACTORY_CERT
ARTIFACTORY_CA

References

None

Implement full support for GO virtual repos

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Description

Implement support for Go Virtual repository type features:

Follow 'go-import' Meta Tags
'go-import' Whitelist

More details on vendor page

New or Affected Resource(s)

artifactory_virtual_repository

Potential Terraform Configuration

resource "artifactory_virtual_repository" "go" {
  key                     = "go"
  package_type            = "go"
  repo_layout_ref         = "go-default"

  repositories = [
    "github-remote",
    "gocenter"
  ]

  enable_go_import         = false
  go_import_whitelist = [
    "**/github.com/**",
    "**/github.com/**/**",
    "**/golang.org/**",
    "**/gopkg.in/**",
    "**/k8s.io/**",
    "**/go.googlesource.com/**"
  ]

}

References

Non-described argument in artifactory_permission_target resource

An argument is added to the artifactory_permission_target resource after import. It is also added when the artifactory_permission_target resource is created from scratch.

Terraform Version
Terraform v0.12.29

provider.artifactory (unversioned)
Affected Resource(s)
artifactory_7.6.3
Terraform Configuration Files
resource "artifactory_permission_target" "test-team" {
name = "test-team"
repo {
includes_pattern = ["**",]
repositories = [
"datalab-docker-local",
]
actions {
groups {
name = "test-team"
permissions = ["manage", "delete", "write", "annotate", "read"]
}
users {
name = "test-deploy"
permissions = ["delete", "write", "annotate", "read"]
}
}
}
}
Expected Behavior
No changes. Infrastructure is up-to-date.
Actual Behavior

artifactory_permission_target.test-team will be updated in-place

~ resource "artifactory_permission_target" "test-team" {
id = "test-team"
+ includes_pattern = "**"
name = "test-team"

  repo {
      excludes_pattern = []
      includes_pattern = [
          "**",
      ]
      repositories     = [
          "datalab-docker-local",
      ]

      actions {
          groups {
              name        = "test-team"
              permissions = [
                  "annotate",
                  "delete",
                  "manage",
                  "read",
                  "write",
              ]
          }

          users {
              name        = "test-deploy"
              permissions = [
                  "annotate",
                  "delete",
                  "read",
                  "write",
              ]
          }
      }
  }

}
Steps to Reproduce
Create permission in artifactory
Create artifactory_permission_target with the same permission, users and groups as in the artifactory
Import artifactory_permission_target into terraform state
terraform apply
I expect to see a message "No changes. Infrastructure is up-to-date."
Instead, the resource is updated with the addition this argument

+ includes_pattern = "**"

artifactory provider url needs to be artifactory.site.io/artifactory in the documentation

provider "artifactory" {
url = "artifactory.site.com/artifactory"
username = "myusername"
password = "mypassword"
}

Support resource retry due to async nature of RT

After moving resource from /main.tf:

terraform {
  required_providers {
    artifactory = {
      source  = "jfrog/artifactory"
      version = "~> 2.2.5"
    }
  }
}

# Configured via ENV
provider "artifactory" {}

resource "artifactory_local_repository" "npm-local" {
  key          = "npm-local"
  package_type = "npm"
}

to a module /modules/core/main.tf

terraform {
  required_providers {
    artifactory = {
      source  = "jfrog/artifactory"
      version = "~> 2.2.5"
    }
  }
}

resource "artifactory_local_repository" "npm-local" {
  key          = "npm-local"
  package_type = "npm"
}

so that the /main.tf looks like

terraform {
  required_providers {
    artifactory = {
      source  = "jfrog/artifactory"
      version = "~> 2.2.5"
    }
  }
}

# Configured via ENV
provider "artifactory" {}

module "core" {
  source = "./modules/core"
  providers = {
    artifactory = artifactory
  }
}

Terraform does not wait for Artifactory to delete a resource / repository:

[Pipeline] sh
16:53:24  + terraform apply -auto-approve
...
16:53:30  artifactory_local_repository.npm-local: Refreshing state... [id=npm-local]
...
16:53:35  artifactory_local_repository.npm-local: Destroying... [id=npm-local]
...
16:53:36  artifactory_local_repository.npm-local: Destruction complete after 1s
...
16:53:38  
16:53:38  Error: PUT https://SOME_SAAS_ARTIFACTORY.jfrog.io/artifactory/api/repositories/npm-local: 400 [{Status:400 Message:error when validating repository name: Case insensitive repository key already exists}]
16:53:38  
16:53:38    on modules/core/main.tf line 10, in resource "artifactory_local_repository" "npm-local":
16:53:38    10: resource "artifactory_local_repository" "npm-local" {

Lifecycle ignore_changes for password is not ignored and breaks the replication password resulting in the 401 Unauthorized

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment

Terraform Version

0.12.24
0.12.29

Affected Resource(s)

artifactory_replication_config

Terraform Configuration Files

resource "artifactory_replication_config" "npm-test" {
  repo_key                 = artifactory_local_repository.npm-test.key
  cron_exp                 = "0 0 6,23 ? * * *"
  enable_event_replication = false

  replications {
    enabled               = true
    socket_timeout_millis = 15000
    sync_deletes          = true
    sync_properties       = true
    sync_statistics       = true
    url                   = "https://art-instance.com/artifactory/npm-test/"
    username              = "username"
  }

  lifecycle {
    ignore_changes = [
      replications.0.password
    ]
  }

}

Debug Output

Gist link

Panic Output

Expected Behavior

If artifactory_replication_config has defined:

  lifecycle {
    ignore_changes = [
      replications.0.password
    ]
  }

Password should be never updated.

Actual Behavior

If you don't use decrypted passwords in the artifactory and you specify to ignore password with:

  lifecycle {
    ignore_changes = [
      replications.0.password
    ]
  }

Then you will modify replication (in this case just enable from disabled state) and apply via terraform:

# artifactory_replication_config.npm-test will be updated in-place
  ~ resource "artifactory_replication_config" "npm-test" {
        cron_exp                 = "0 0 6,23 ? * * *"
        enable_event_replication = false
        id                       = "npm-test"
        repo_key                 = "npm-test"

      ~ replications {
          ~ enabled               = false -> true
            password              = (sensitive value)
            socket_timeout_millis = 15000
            sync_deletes          = true
            sync_properties       = true
            sync_statistics       = true
            url                   = "https://art-instance.com/artifactory/npm-test/"
            username              = "username"
        }
    }

Replication will be set according to the terraform plan but password will be also set with random hashed value. By this replication will stop to work with Connection failed: Target replication URL returned error 401: Unauthorized

Steps to Reproduce

Define artifactory_local_repository + artifactory_replication_config with the ignore_changes for the password.
terraform apply
Check the replication settings in the artifactory and hit the test button - you will receive 401: Unauthorized

Important Factoids

This could be related to the hashicorp/terraform#21433
Lifecycle configuration in this repository is invalid for 0.12.X. Needs to be used ignore_changes = [replications.0.password] instead of ignore_changes = ["password"]

References

[Feat] Xray Watch Support

Hi,

This issue is to discuss the implementation of a watch resource.

I've started implementing the code in jfrog/jfrog-client-go#211 to support a watch resource.
I've also started working on the watch resource locally, and will push this up, but I have a few design questions.

Firstly, the endpoint to create/manage a watch is different.

For example:

Artifactory: https://something.jfrog.io/artifactory
Xray: https://something.jfrog.io/xray

This means the provider will need at least the xray_url parameter, as an optional parameter.

Can we use the existing credential variables - username, password, api_key and access_token, or would we need a separate set of variables?

Do you have any feedback on the below examples of the resource?

Example resource - All Repos

resource "artifactory_watch" "all_repos" {
    name = "all_repos"
    description = "all_repos"
    active = true

    all_repositories {
        package_types = ["NuGet", "Docker"]
        filter_path = ["path/**"]
        filter_names = ["name1", "name2"]
        filter_mime_types = ["application/zip"]

        filter_property {
            key = "field1"
            value = "value 1"
        }
        filter_property {
            key = "field2"
            value = "value 2"
        }

        include_patterns = [
            "path1/**"
        ]
        exclude_patterns = [
            "path1/ignore/**"
        ]
    }

    policy {
      name = "policy-1"
      type = "security"
    }

    policy {
      name = "policy-2"
      type = "security"
    }
}

Example resource - Repos by name

resource "artifactory_watch" "named_repos" {
    name = "named_repos"
    description = "named_repos"
    active = true

    repository {
        name = "repo1"
        package_types = ["NuGet", "Docker"]
        filter_path = ["path/**"]
        filter_names = ["name1", "name2"]
        filter_mime_types = ["application/zip"]

        filter_property {
            key = "field1"
            value = "value 1"
        }
        filter_property {
            key = "field2"
            value = "value 2"
        }

        include_patterns = [
            "path1/**"
        ]
        exclude_patterns = [
            "path1/ignore/**"
        ]
    }

    policy {
      name = "policy-1"
      type = "security"
    }
}

Example resource - All Builds

resource "artifactory_watch" "all_builds" {
    name = "all_builds"
    description = "all_builds"
    active = true

    all_builds {
        bin_mgr_id = "default"
    }

    policy {
      name = "policy-1"
      type = "security"
    }

    policy {
      name = "policy-2"
      type = "security"
    }
}

Example resource - Named build

resource "artifactory_watch" "named_builds" {
    name = "named_builds"
    description = "named_builds"
    active = true

    build {
        name = "build1"
        bin_mgr_id = "default"        
    }

    policy {
      name = "policy-1"
      type = "security"
    }
}

Is there anything else I need to know?

Cheers,

Josh

References:

atlassian/terraform-provider-artifactory#92

artifactory_file read error

The file I am trying to read from does not have a sha256 set. So in my response object I only get the other two checksums:

  "checksums" : {
    "sha1" : "293ddf0e11093b420f312f83ceaf5b476560ecea",
    "md5" : "5e49fbfd88d2204b6a1cbbd70872c07a"
  },

This gives me a runtime error:

data.artifactory_file.my-file: Refreshing state...

Error: rpc error: code = Unavailable desc = transport is closing

panic: runtime error: invalid memory address or nil pointer dereference
2020-10-23T04:12:42.662-0700 [DEBUG] plugin.terraform-provider-artifactory_v2.2.4: [signal SIGSEGV: segmentation violation code=0x1 addr=0x8 pc=0x1c246cd]
2020-10-23T04:12:42.662-0700 [DEBUG] plugin.terraform-provider-artifactory_v2.2.4:
2020-10-23T04:12:42.662-0700 [DEBUG] plugin.terraform-provider-artifactory_v2.2.4: goroutine 31 [running]:
2020-10-23T04:12:42.662-0700 [DEBUG] plugin.terraform-provider-artifactory_v2.2.4: github.com/atlassian/terraform-provider-artifactory/pkg/artifactory.dataSourceFileRead(0xc0002a6770, 0x1cc45c0, 0xc0008e3d00, 0x0, 0x0)
2020-10-23T04:12:42.662-0700 [DEBUG] plugin.terraform-provider-artifactory_v2.2.4: 	github.com/atlassian/terraform-provider-artifactory/pkg/artifactory/datasource_artifactory_file.go:97 +0x26d

recommend either making the sha256 checksum optional, or at least make the error message more clear.

Importing xray policy does not include name of policy

Describe the bug

After importing an xray policy via terraform import the state has the name set to null. This leads to the next update to detect a name change which forces destroying and re-creating.

    {
      "mode": "managed",
      "type": "artifactory_xray_policy",
      "name": "block_high_severity",
      "provider": "provider[\"registry.terraform.io/jfrog/artifactory\"]",
      "instances": [
        {
          "schema_version": 0,
          "attributes": {
            "author": "admin",
            "created": "2021-02-18T13:57:30.743-05:00",
            "description": "BlockHighSeverity",
            "id": "BlockHighSeverity",
            "modified": "2021-03-22T13:58:24.691-04:00",
            "name": null,
            "rules": [
              {
                "actions": [
                  {
                    "block_download": [
                      {
                        "active": true,
                        "unscanned": true
                      }
                    ],
                    "custom_severity": "",
                    "fail_build": false,
                    "mails": [],
                    "webhooks": []
                  }
                ],
                "criteria": [
                  {
                    "allow_unknown": false,
                    "allowed_licenses": [],
                    "banned_licenses": [],
                    "cvss_range": [],
                    "min_severity": "High"
                  }
                ],
                "name": "BlockHighSeverity",
                "priority": 1
              }
            ],
            "type": "security"
          },
          "private": ""
        }
      ]
    }

version of plugin

v2.2.7

version of xray

v3.17.4

version of terraform

v0.13.5

Expected behavior

I would expect the name to be correctly set in state after doing an import

[FEATURE] use lazy connections

The Provider is currently not using lazy connections. This can cause issues when importing and prevents depends_on use-cases.

For example, if lazy connections were implemented, I should be able to build:

module "artifactory" {
  source = "./modules/artifactory"
  # Config here
}

provider "artifactory" {
  url      = "${module.artifactory.endpoint}/artifactory"
  username = module.artifactory.admin_user
  password = module.artifactory.admin_password
}

without receiving this error:

Error: either [username, password] or [api_key] or [access_token] must be set to use provider

  on main.tf line 6, in provider "artifactory":
 6: provider "artifactory" {

An example of this feature can be seen in this postgresql provider & mysql provider.

JFrog is not working with TF 0.13-0.15

I could not run Terraform code, got the next issue:

$ tfswitch
Reading required version from terraform file, constraint: = 0.13
Matched version: 0.13.0
Downloading https://releases.hashicorp.com/terraform/0.13.0/terraform_0.13.0_darwin_amd64.zip to terraform_0.13.0_darwin_amd64.zip
Downloading ...
35631250 bytes downloaded.
Switched terraform to version "0.13.0"

$ terraform init
Initializing modules...

Initializing the backend...

Initializing provider plugins...
- Finding jfrog/artifactory versions matching "2.2.9"...
- Finding latest version of hashicorp/artifactory...
- Installing jfrog/artifactory v2.2.9...
- Installed jfrog/artifactory v2.2.9 (signed by a HashiCorp partner, key ID 6B219DCCD7639232)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/plugins/signing.html

Error: Failed to install provider

Error while installing hashicorp/artifactory: provider registry
registry.terraform.io does not have a provider named
registry.terraform.io/hashicorp/artifactory

TF code:

# Required for Terraform 0.13 and up (https://www.terraform.io/upgrade-guides/0-13.html)
terraform {

  # required_version = "= 0.13"

  required_providers {
    
    artifactory = {
      source = "jfrog/artifactory"
      version = "2.2.9"
    }
  }
}

# Configure the Artifactory provider
provider "artifactory" {
  url      = "https://internal-adb96e117fff1436ea9aedbaf0ca997b-774872943.us-east-1.elb.amazonaws.com"
  
  username = "admin"
  password = "admin"
  # or
  # access_token = null
  # api_key      = null

}

module "jfrog_local_repository" {
  source = "[email protected]:SebastianUA/terraform.git//jfrog/modules/jfrog_repository?ref=dev"

  enable_local_repository       = true
  local_repository_key          = "local-repo-1"
  local_repository_package_type = "npm"
}

module "jfrog_remote_repository" {
  source = "[email protected]:SebastianUA/terraform.git//jfrog/modules/jfrog_repository?ref=dev"

  enable_remote_repository       = true
  remote_repository_key          = "remote-repo-1"
  remote_repository_package_type = "npm"
  remote_repository_url          = "https://registry.npmjs.org/"

  remote_repository_repo_layout_ref = "npm-default"
}

module "jfrog_virtual_repository" {
  source = "[email protected]:SebastianUA/terraform.git//jfrog/modules/jfrog_repository?ref=dev"

  enable_virtual_repository       = true
  virtual_repository_key          = "virtual-repo-1"
  virtual_repository_package_type = "maven"
  virtual_repository_repositories = []
}

v2.2.8 prevents use of conda repositories

terraform-provider-artifactory/pkg/artifactory/resource_artifactory_remote_repository.go

Line 37 in 2517982

ValidateFunc: validation.StringInSlice([]string{

After upgrading to v2.2.8 my terraform plans now fail as I have a conda remote. Seemingly because this is missing from the new validate method.
https://www.jfrog.com/confluence/display/JFROG/Conda+Repositories

My terraform configuration looks like this:

resource "artifactory_remote_repository" "conda_remote" {
  ...
  type    = "conda"
  url       = "https://repo.anaconda.com/pkgs/main/"
  layout = "simple-default"
  ...
}

Accepted 202 error

Hi, I updated to the new version, 2.2.6 and on doing my terraform plan I get this :

Need support to check xray index while creating repository

Describe the bug
Actually this is not a bug. This is just a feature request to check xray index while creating the artifactory repository. We are actively using SaaS Artifactory and XRay and therefore need support to check XRay index checkbox to enable the XRay indexing for the repository.

Requirements for and issue

Need support to enable XRay indexing while creating repository in artifactory
We are using SaaS or Cloud Artifactory with XRay license.
We are using terraform 0.14.5

Expected behavior
The expectation is to get the XRay index checkbox get enabled automatically via terraform code.

Unable to add more than 1 user to permission target

There does not currently appear to be a way to manage multiple users on a permission target.
I'd like to be able to define multiple users on a permission

resource "artifactory_permission_target" "foobar" {
  name = "foobar"
  repo {
    excludes_pattern = []
    includes_pattern = [
      "**"
    ]
    repositories = [
      "bakerstreet",
    ]
    actions {
      users {
        name = "bar
        permissions = [
          "annotate",
          "read",
          "write"
        ]
      }
    }
  }
}

Actions appears to only take 1 'users' or 'groups' object, if you try and use a hash or array of objects, it failes

Attempt 1 (array)

actions [
      users {
        name = "user1"
        permissions = ["read"]
       }, 
      users {
        name = "user2"
        permissions = ["read"]
       }, 
    ]

Attempt 2 (hash)

actions {
      users {
        name = "user1"
        permissions = ["read"]
       }, 
      users {
        name = "user2"
        permissions = ["read"]
       }, 
    }

Attempt 3 (users array)

actions [
      users {
        name = ["user1", "user2"]
        permissions = ["read"]
       }, 
    ]

Is there no way to pass an array to actions so that multiple users can be added to a permission target?

JFrog Cloud Artifactory

It does not seem like JFrog Cloud Artifactory is supported.

Configured the provider :

provider "artifactory" { url = "org_name.jfrog.io/artifactory" username = var.artifactory_username password = var.artifactory_password }

which produces the following error

Error: Get "/org_name.jfrog.io/artifactory/org_name.jfrog.io/artifactory/api/system/ping": unsupported protocol scheme ""

[Question] Moving issues from atlassian to jfrog

Hi, I'm wondering when issues will be migrated from https://github.com/atlassian/terraform-provider-artifactory?

Cheers

Provider assumes a `/artifactory/` subpath in your artifactory url

Describe the bug
The provider assumes you are hosting Artifactory at a /artifactory subpath in your url. In situations where you don't have a subpath, just hosting at https://artifactory.sitename.com/ , this terraform provider doesn't work.

Example:

What it assumes: https://artifactory.sitename.com/artifactory
What doesn't work: https://artifactory.sitename.com

referring to this line: https://github.com/jfrog/terraform-provider-artifactory/blob/master/pkg/artifactory/provider.go#L152

Requirements for and issue

provider "artifactory" {
  url = "${var.artifactory_url}"
  username = "${var.artifactory_username}"
  password = "${var.artifactory_password}"
}

terraform version 0.15.1
artifactory version: 7.4.3

Expected behavior

Provide an override for the subpath over the url

provider "artifactory" {
  url = "${var.artifactory_url}"
  url_sub_path = ""  # the default would be /artifactory
  username = "${var.artifactory_username}"
  password = "${var.artifactory_password}"
}

Additional context
I'd be happy to submit a merge request for this, but wanted to see if this approach was acceptable. Thanks!

Leaking API Token Secret on Auth Failure

Community Note

Please vote on this issue by adding a 👍 reaction to the original issue to help the community and maintainers prioritize this request
Please do not leave "+1" or "me too" comments, they generate extra noise for issue followers and do not help prioritize the request
If you are interested in working on this issue or have submitted a pull request, please leave a comment
Terraform Version
Terraform v0.12.20 - but I suspect this will affect any Terraform version.

$> ./terraform version
Terraform v0.12.20

Your version of Terraform is out of date! The latest version
is 0.13.5. You can update by downloading from https://www.terraform.io/downloads.html
Affected Resource(s)
N/A - this appears to be a provider issue or an issue with the github.com/atlassian/go-artifactory/v2/artifactory client implementation when the provider invokes its configure function and attempts to ping Artifactory
Terraform Configuration Files
# Copy-paste your Terraform configurations here - for large Terraform configs,
# please use a service like Dropbox and share a link to the ZIP file.

terraform {
  required_version = "~> 0.12.20"
}

provider "artifactory" {
  url      = "https://<artifactory URL>/artifactory"
  api_key  = "this-is-a-secret-key"
}

data "artifactory_fileinfo" "test" {
  repository = "terraform"
  path       = "modules/foreman-subnet/foreman-subnet_v1.0.0.tar.gz"
}

Debug Output
Panic Output
Expected Behavior
If the provider encounters an authentication failure, I expect the provider to fail and cause a halt in Terraform execution. However, the API token should not be dumped back to console - the token should remain hidden and the provider only displays an indication of a bad token (possibly masking token details if it absolutely must be dumped?). Something like this:

GET https:///artifactory/api/system/ping: 403 [{Status:403 Message:Bad props auth token}]
on .terraform/modules/docker-terraform-test/providers.tf line 7, in provider "artifactory":
7: provider "artifactory" {
Actual Behavior
The provider fails and dumps the token in plaintext to the console. This is a huge security issue causing us to pull/revoke this provider from our internal registry and redo compromised credentials.

GET https:///artifactory/api/system/ping: 403 [{Status:403 Message:Bad props auth token: apiKey=}]
on .terraform/modules/docker-terraform-test/providers.tf line 7, in provider "artifactory":
7: provider "artifactory" {
Steps to Reproduce
Copy configuration from Terraform Configuration Files - give it a nonsensical token for your instance

$> ls
terraform.tf

$> cat terraform.tf
terraform {
  required_version = "~> 0.12.20"
}

provider "artifactory" {
  url      = "https://<artifactory URL>/artifactory"
  api_key  = "this-is-a-secret-key"
}

data "artifactory_fileinfo" "test" {
  repository = "terraform"
  path       = "modules/foreman-subnet/foreman-subnet_v1.0.0.tar.gz"
}

#initialize Terraform
$> terraform init

Initializing the backend...

Initializing provider plugins...

Terraform has been successfully initialized!

You may now begin working with Terraform. Try running "terraform plan" to see
any changes that are required for your infrastructure. All Terraform commands
should now work.

If you ever set or change modules or backend configuration for Terraform,
rerun this command to reinitialize your working directory. If you forget, other
commands will detect it and remind you to do so if necessary.
attempt to plan the project
$> terraform plan
Refreshing Terraform state in-memory prior to plan...
The refreshed state will be used to calculate this plan, but will not be
persisted to local or remote state storage.                                                                                                                                                                                                                                                       
Error: GET https://<artifactory URL>/artifactory/api/system/ping: 403 [{Status:403 Message:Bad props auth token: apiKey=this-is-a-secret-key}]

  on terraform.tf line 5, in provider "artifactory":
   5: provider "artifactory" {                                                                                                                                                  
Important Factoids
This issue does not occur when using username/password auth. It appears to only occur on API key. It does not matter if this API key is specified via env vars or statically configured.

GET https://<artifactory URL>/artifactory/api/system/ping: 401 [{Status:401 Message:Bad credentials}]
  on .terraform/modules/docker-terraform-test/providers.tf line 88, in provider "artifactory":
  88: provider "artifactory" {
References
#0000

Apply fails despite successful plan

After updating an existing permission, single line update, I end up with this:

15:14:10  + terraform init
15:14:11  Initializing modules...
15:14:11  - core_local in modules/core/local
15:14:11  - core_local.local_repo_generator in modules/core/local_repo_generator
15:14:11  - core_remote in modules/core/remote
15:14:11  - core_remote.dockerhub-name in modules/core/remote_naming_convention
15:14:11  - core_remote.mirrors in modules/core/remote_repo_generator
15:14:11
15:14:11  Initializing the backend...
15:14:11
15:14:11  Initializing provider plugins...
15:14:11  - Finding jfrog/artifactory versions matching "~> 2.2.5"...
15:14:12  - Installing jfrog/artifactory v2.2.5...
15:14:13  - Installed jfrog/artifactory v2.2.5 (signed by a HashiCorp partner, key ID 6B219DCCD7639232)
15:14:13
15:14:13  Partner and community providers are signed by their developers.
15:14:13  If you'd like to know more about provider signing, you can read about it here:
15:14:13  https://www.terraform.io/docs/plugins/signing.html
15:14:13
15:14:13  Terraform has created a lock file .terraform.lock.hcl to record the provider
15:14:13  selections it made above. Include this file in your version control repository
15:14:13  so that Terraform can guarantee to make the same selections by default when
15:14:13  you run "terraform init" in the future.
15:14:13
15:14:13  Terraform has been successfully initialized!
15:14:13
15:14:13  You may now begin working with Terraform. Try running "terraform plan" to see
15:14:13  any changes that are required for your infrastructure. All Terraform commands
15:14:13  should now work.
15:14:13
15:14:13  If you ever set or change modules or backend configuration for Terraform,
15:14:13  rerun this command to reinitialize your working directory. If you forget, other
15:14:13  commands will detect it and remind you to do so if necessary.
## -- redacted -- ##
15:14:14
[Pipeline] sh
15:14:15  + terraform plan
15:14:23  module.core_local.artifactory_group.default-rw-local: Refreshing state... [id=default-rw-local]
15:14:23  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[4]: Refreshing state... [id=jenkins-ci-remote]
15:14:23  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[0]: Refreshing state... [id=helm-remote]
15:14:23  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[8]: Refreshing state... [id=npm-remote]
15:14:23  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[1]: Refreshing state... [id=gocenter-remote]
15:14:23  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[6]: Refreshing state... [id=jfrog-dependencies-remote]
15:14:23  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[10]: Refreshing state... [id=ghcr-remote]
15:14:23  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[9]: Refreshing state... [id=pypi-remote]
15:14:23  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[7]: Refreshing state... [id=netbeans-remote]
15:14:24  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[3]: Refreshing state... [id=jcenter-remote]
15:14:25  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[2]: Refreshing state... [id=imagej-remote]
15:14:25  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[5]: Refreshing state... [id=jenkins-ci-incrementals-remote]
15:14:25  module.core_remote.artifactory_group.default-cache-remote: Refreshing state... [id=default-cache-remote]
15:14:25  module.core_remote.artifactory_remote_repository.dockerhub: Refreshing state... [id=dockerhub-remote]
15:14:25  module.core_remote.artifactory_permission_target.default-permission-cache-remote: Refreshing state... [id=default-permission-cache-remote]
15:14:28  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[3]: Refreshing state... [id=default-maven-dev-local]
15:14:28  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[2]: Refreshing state... [id=default-docker-dev-local]
15:14:28  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[5]: Refreshing state... [id=default-pypi-dev-local]
15:14:28  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[7]: Refreshing state... [id=default-go-dev-local]
15:14:28  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[6]: Refreshing state... [id=default-conan-dev-local]
15:14:28  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[4]: Refreshing state... [id=default-helm-dev-local]
15:14:28  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[0]: Refreshing state... [id=default-npm-dev-local]
15:14:28  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[1]: Refreshing state... [id=default-generic-dev-local]
15:14:29  module.core_local.artifactory_permission_target.default-permission-rw-local: Refreshing state... [id=default-permission-rw-local]
15:14:29
15:14:29  An execution plan has been generated and is shown below.
15:14:29  Resource actions are indicated with the following symbols:
15:14:29    ~ update in-place
15:14:29
15:14:29  Terraform will perform the following actions:
15:14:29
15:14:29    # module.core_remote.artifactory_permission_target.default-permission-cache-remote will be updated in-place
15:14:29    ~ resource "artifactory_permission_target" "default-permission-cache-remote" {
15:14:29          id   = "default-permission-cache-remote"
15:14:29          name = "default-permission-cache-remote"
15:14:29
15:14:29        ~ repo {
15:14:29              # (3 unchanged attributes hidden)
15:14:29
15:14:29            ~ actions {
15:14:29                + groups {
15:14:29                    + name        = "default-cache-remote"
15:14:29                    + permissions = [
15:14:29                        + "annotate",
15:14:29                        + "delete",
15:14:29                        + "read",
15:14:29                        + "write",
15:14:29                      ]
15:14:29                  }
15:14:29                - groups {
15:14:29                    - name        = "default-cache-remote" -> null
15:14:29                    - permissions = [
15:14:29                        - "annotate",
15:14:29                        - "read",
15:14:29                        - "write",
15:14:29                      ] -> null
15:14:29                  }
15:14:29              }
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.artifactory_remote_repository.dockerhub will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "dockerhub" {
15:14:29          id                                    = "dockerhub-remote"
15:14:29        ~ password                              = (sensitive value)
15:14:29          # (45 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[0] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "helm-remote"
15:14:29          # (31 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[1] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "gocenter-remote"
15:14:29          # (33 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[2] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "imagej-remote"
15:14:29          # (31 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[3] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "jcenter-remote"
15:14:29          # (31 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[4] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "jenkins-ci-remote"
15:14:29          # (31 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[5] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "jenkins-ci-incrementals-remote"
15:14:29          # (31 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[6] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "jfrog-dependencies-remote"
15:14:29          # (31 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[7] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "netbeans-remote"
15:14:29          # (31 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[8] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "npm-remote"
15:14:29          # (31 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[9] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "pypi-remote"
15:14:29          # (32 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29    # module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[10] will be updated in-place
15:14:29    ~ resource "artifactory_remote_repository" "local-repo-from-template" {
15:14:29          id                                    = "ghcr-remote"
15:14:29          # (31 unchanged attributes hidden)
15:14:29
15:14:29        - content_synchronisation {
15:14:29            - enabled = false -> null
15:14:29          }
15:14:29      }
15:14:29
15:14:29  Plan: 0 to add, 13 to change, 0 to destroy.
15:14:29
15:14:29  ------------------------------------------------------------------------
15:14:29
15:14:29  Note: You didn't specify an "-out" parameter to save this plan, so Terraform
15:14:29  can't guarantee that exactly these actions will be performed if
15:14:29  "terraform apply" is subsequently run.
15:14:29
## -- redacted -- ##
15:14:30
[Pipeline] sh
15:14:30  + terraform apply -auto-approve
15:14:38  module.core_remote.artifactory_remote_repository.dockerhub: Refreshing state... [id=dockerhub-remote]
15:14:38  module.core_remote.artifactory_group.default-cache-remote: Refreshing state... [id=default-cache-remote]
15:14:38  module.core_remote.artifactory_permission_target.default-permission-cache-remote: Refreshing state... [id=default-permission-cache-remote]
15:14:39  module.core_local.artifactory_group.default-rw-local: Refreshing state... [id=default-rw-local]
15:14:39  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[0]: Refreshing state... [id=helm-remote]
15:14:39  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[3]: Refreshing state... [id=jcenter-remote]
15:14:39  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[6]: Refreshing state... [id=jfrog-dependencies-remote]
15:14:39  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[4]: Refreshing state... [id=jenkins-ci-remote]
15:14:39  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[1]: Refreshing state... [id=gocenter-remote]
15:14:39  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[5]: Refreshing state... [id=jenkins-ci-incrementals-remote]
15:14:39  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[8]: Refreshing state... [id=npm-remote]
15:14:39  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[10]: Refreshing state... [id=ghcr-remote]
15:14:39  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[2]: Refreshing state... [id=imagej-remote]
15:14:41  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[7]: Refreshing state... [id=netbeans-remote]
15:14:41  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[9]: Refreshing state... [id=pypi-remote]
15:14:45  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[1]: Refreshing state... [id=default-generic-dev-local]
15:14:45  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[3]: Refreshing state... [id=default-maven-dev-local]
15:14:45  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[2]: Refreshing state... [id=default-docker-dev-local]
15:14:45  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[7]: Refreshing state... [id=default-go-dev-local]
15:14:45  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[6]: Refreshing state... [id=default-conan-dev-local]
15:14:45  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[0]: Refreshing state... [id=default-npm-dev-local]
15:14:45  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[5]: Refreshing state... [id=default-pypi-dev-local]
15:14:45  module.core_local.module.local_repo_generator.artifactory_local_repository.local-repo-from-template[4]: Refreshing state... [id=default-helm-dev-local]
15:14:46  module.core_local.artifactory_permission_target.default-permission-rw-local: Refreshing state... [id=default-permission-rw-local]
15:14:54  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[9]: Modifying... [id=pypi-remote]
15:14:55  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[10]: Modifying... [id=ghcr-remote]
15:14:55  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[2]: Modifying... [id=imagej-remote]
15:14:55  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[0]: Modifying... [id=helm-remote]
15:14:55  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[8]: Modifying... [id=npm-remote]
15:14:55  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[4]: Modifying... [id=jenkins-ci-remote]
15:14:55  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[5]: Modifying... [id=jenkins-ci-incrementals-remote]
15:14:55  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[3]: Modifying... [id=jcenter-remote]
15:14:55  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[7]: Modifying... [id=netbeans-remote]
15:14:55  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[6]: Modifying... [id=jfrog-dependencies-remote]
15:14:56  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[9]: Modifications complete after 1s [id=pypi-remote]
15:14:56  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[1]: Modifying... [id=gocenter-remote]
15:14:56  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[8]: Modifications complete after 2s [id=npm-remote]
15:14:56  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[10]: Modifications complete after 2s [id=ghcr-remote]
15:14:56  module.core_remote.artifactory_permission_target.default-permission-cache-remote: Modifying... [id=default-permission-cache-remote]
15:14:57  module.core_remote.artifactory_permission_target.default-permission-cache-remote: Modifications complete after 0s [id=default-permission-cache-remote]
15:14:57  module.core_remote.artifactory_remote_repository.dockerhub: Modifying... [id=dockerhub-remote]
15:14:58  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[0]: Modifications complete after 3s [id=helm-remote]
15:14:58  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[6]: Modifications complete after 3s [id=jfrog-dependencies-remote]
15:14:58  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[2]: Modifications complete after 3s [id=imagej-remote]
15:14:59  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[5]: Modifications complete after 4s [id=jenkins-ci-incrementals-remote]
15:14:59  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[7]: Modifications complete after 4s [id=netbeans-remote]
15:14:59  module.core_remote.module.mirrors.artifactory_remote_repository.local-repo-from-template[1]: Modifications complete after 3s [id=gocenter-remote]
15:14:59  module.core_remote.artifactory_remote_repository.dockerhub: Modifications complete after 3s [id=dockerhub-remote]
15:15:05
15:15:05  Error: POST https://X_redacted_X/artifactory/api/repositories/jcenter-remote: 400 [{Status:400 Message:Could not merge and save new descriptor [org.jfrog.common.ExecutionFailed: Last retry failed: Should update revision 3108. Not trying again (exceeded number of attempts (5))]
15:15:05  }]
15:15:05
15:15:05    on modules/core/remote_repo_generator/main.tf line 33, in resource "artifactory_remote_repository" "local-repo-from-template":
15:15:05    33: resource "artifactory_remote_repository" "local-repo-from-template" {
15:15:05
15:15:05
15:15:05
15:15:05  Error: POST https://X_redacted_X/artifactory/api/repositories/jenkins-ci-remote: 400 [{Status:400 Message:Could not merge and save new descriptor [org.jfrog.common.ExecutionFailed: Last retry failed: Should update revision 3108. Not trying again (exceeded number of attempts (5))]
15:15:05  }]
15:15:05
15:15:05    on modules/core/remote_repo_generator/main.tf line 33, in resource "artifactory_remote_repository" "local-repo-from-template":
15:15:05    33: resource "artifactory_remote_repository" "local-repo-from-template" {
15:15:05
15:15:05
[Pipeline] }
15:15:05

New Release

What is the process of cutting a new Release? This is in order to get this PR released : #45

"Only one auth mechanism allowed" error when using Basic auth

Affected Resource(s)
artifactory_file
Expected Behavior
When using the artifactory provider with ARTIFACTORY_USERNAME and ARTIFACTORY_PASSWORD set (Basic auth). The artifactory_file data source should be handled without errors provided the credentials are correct.

Actual Behavior
The tf plan fails with the following message:

InvalidArgument Only one auth mechanism allowed; only the X-Amz-Algorithm query parameter, Signature query string parameter or the Authorization header should be specified Authorization Basic ******************** ******************** ******************** Steps to Reproduce Add the provider provider "artifactory" {} Set valid env vars for ARTIFACTORY_URL (or optionally provide URL in provider block), ARTIFACTORY_USERNAME and ARTIFACTORY_PASSWORD Add some data "artifactory_file" "test" { ... } data source block. (Only tested this with a valid artifactory repository and file. Not sure if this can be reproduced with dummy values too.) Execute tf plan Important Factoids This works if ARTIFACTORY_API_KEY is used instead of ARTIFACTORY_USERNAME and ARTIFACTORY_PASSWORD (likely because it does not use the Authorization header?) The error message seems to be AWS S3 related (We are running the SaaS version of JFrog on AWS) Based on this artifactory issue, this knowledge base article and this CVE in gradle, this has something to do with incorrect client-side handling of redirects, so it might rather be a go-artifactory issue. References https://www.jfrog.com/jira/browse/RTFACT-19728 https://jfrog.com/knowledge-base/why-do-i-get-a-400-bad-request-error-when-working-with-direct-cloud-storage-download/ GHSA-4cwg-f7qc-6r95

permission_target include_pattern duplicated

Terraform 0.13
Provider 2.2.4
Artifactory 6.23.1

If you import an artifactory_permission_target, the resource will have conflicting includes_pattern

resource "artifactory_permission_target" "conan-read" {
    name = "conan-read"
    repo {
        excludes_pattern = []
        repositories = [
            "conan-local",
            "conan-remote",
        ]
        actions {
            groups {
                name = "conan-read"
                permissions = [
                    "read"
                ]
            }
            users {
                name = "anonymous"
                permissions = [
                    "read"
                ]
            }
        }
    }
}

  # artifactory_permission_target.conan-read will be updated in-place
  ~ resource "artifactory_permission_target" "conan-read" {
        id               = "conan-read"
      + includes_pattern = "**"                         <------------- note that it will automatically add includes pattern
        name             = "conan-read"

      ~ repo {
            excludes_pattern = []
          ~ includes_pattern = [
              - "**",
            ]
            repositories     = [
                "conan-local",
                "conan-remote",
            ]

            actions {
                groups {
                    name        = "conan-read"
                    permissions = [
                        "read",
                    ]
                }

                users {
                    name        = "anonymous"
                    permissions = [
                        "read",
                    ]
                }
            }
        }
    }

Workaround 1

If you try and explicitly add the includes_pattern to the resource, it will throw an error

resource "artifactory_permission_target" "conan-read" {
    name = "conan-read"
    includes_pattern = "**" <---------------- Added this line here
    repo {
        excludes_pattern = []
        repositories = [
            "conan-local",
            "conan-remote",
        ]
        actions {
            groups {
                name = "conan-read"
                permissions = [
                    "read"
                ]
            }
            users {
                name = "anonymous"
                permissions = [
                    "read"
                ]
            }
        }
    }
}

Error: "includes_pattern": conflicts with repo

  on permission:conan-read.tf line 1, in resource "artifactory_permission_target" "conan-read":
   1: resource "artifactory_permission_target" "conan-read" {

Workaround 2

resource "artifactory_permission_target" "conan-read" {
    name = "conan-read"
    repo {
        excludes_pattern = []
        includes_pattern = [
            "**"                                     <------- added this line here
        ]
        repositories = [
            "conan-local",
            "conan-remote",
        ]
        actions {
            groups {
                name = "conan-read"
                permissions = [
                    "read"
                ]
            }
            users {
                name = "anonymous"
                permissions = [
                    "read"
                ]
            }
        }
    }
}

terraform apply will still show that it is trying to add the parameter includes_pattern

  # artifactory_permission_target.conan-read will be updated in-place
  ~ resource "artifactory_permission_target" "conan-read" {
        id               = "conan-read"
      + includes_pattern = "**"        <------------ terraform is adding this line here
        name             = "conan-read"

        repo {
            excludes_pattern = []
            includes_pattern = [
                "**",                                 <----- which is a duplicate of this line here
            ]
            repositories     = [
                "conan-local",
                "conan-remote",
            ]

            actions {
                groups {
                    name        = "conan-read"
                    permissions = [
                        "read",
                    ]
                }

                users {
                    name        = "anonymous"
                    permissions = [
                        "read",
                    ]
                }
            }
        }
    }

Local file opened to verify checksum may not exist

terraform-provider-artifactory/pkg/artifactory/datasource_artifactory_file.go

Lines 96 to 97 in 46efef9

 fileExists := FileExists(outputPath) 

 chksMatches, _ := VerifySha256Checksum(outputPath, *fileInfo.Checksums.Sha256)

Maybe I'm doing something wrong here but it seems like if the file doesn't already exist, line 97 will fail. This was done with the following configuration block. I'm just using it to download files from artifactory. I'm willing to make the fix if this is in fact an issue

provider "artifactory" {
  url = "${var.artifactory.url}/artifactory"
  username = "${var.artifactory.username}"
  password = "${var.artifactory.password}"
}

data "artifactory_file" "file" {
   for_each = toset(var.files)

   repository  = "generic-repo"
   path        = "/${each.value}"
   output_path = "${path.root}/.terraform/tmp/${each.value}"
}

Support for priority resolution in local and remote repositories

Per https://www.jfrog.com/confluence/display/JFROG/Repository+Configuration+JSON and the updated REST API following from Artifactory 7.16, I'd like to request (and possibly implement) support for priority resolution for local and remote repositories.

Are there any particular considerations to keep in mind if I want to implement this? Would a pull request for such a change be desired? I'd love to help if possible.

'content_synchronisation' is updated every time

Terraform 0.13.0
Module 2.2.4
Artifactory 6.23

When importing a remote resource from artifactory, it wants to set a value named content_synchronisation, but that does not appear to be a valid resource parameter

resource "artifactory_remote_repository" "conan-remote" {
  key = "conan-remote"
  package_type = "conan"
  url = "https://conan.bintray.com"
  repo_layout_ref = "conan-default"
  notes = "managed by terraform"
}

terraform import artifactory_remote_repository.conan-remote conan-remote

terraform apply

 # artifactory_remote_repository.conan-remote will be updated in-place
  ~ resource "artifactory_remote_repository" "conan-remote" {
        allow_any_host_auth                   = false
        blacked_out                           = false
        block_mismatching_mime_types          = true
        bypass_head_requests                  = false
        enable_cookie_management              = false
        enable_token_authentication           = false
        fetch_jars_eagerly                    = false
        fetch_sources_eagerly                 = false
        force_nuget_authentication            = false
        handle_releases                       = true
        handle_snapshots                      = true
        hard_fail                             = false
        id                                    = "conan-remote"
        includes_pattern                      = "**/*"
        key                                   = "conan-remote"
        max_unique_snapshots                  = 0
        missed_cache_period_seconds           = 1800
      + notes                                 = "managed by terraform"
        offline                               = false
        package_type                          = "conan"
        property_sets                         = []
        remote_repo_checksum_policy_type      = "generate-if-absent"
        repo_layout_ref                       = "conan-default"
        retrieval_cache_period_seconds        = 600
        share_configuration                   = false
        socket_timeout_millis                 = 15000
        store_artifacts_locally               = true
        suppress_pom_consistency_checks       = true
        synchronize_properties                = false
        unused_artifacts_cleanup_period_hours = 0
        url                                   = "https://conan.bintray.com"
        xray_index                            = false

      - content_synchronisation {               <------------ What should this resource be set to? 
          - enabled = false -> null
        }
    }

https://registry.terraform.io/providers/jfrog/artifactory/latest/docs/resources/artifactory_remote_repository#synchronize_properties

Virtual repository key pair assignement does not work

Describe the bug
Changing/assigning key_pair on a virtual repository has no effect. Apply never converges.
The issue has been fixed here: atlassian/go-artifactory#31
As this repository has not much activity for a while. Can jfrog take ownership or fork that repository so that we can use it in this repository ?

terraform 0.15
artifactory 7.17.4

resource "artifactory_virtual_repository" "repo" {
  key          = "repo"
  package_type = "rpm"
  key_pair     = "key1"
}

Add a bold warning that the TF provider does not work with Artifactory OSS

It seems in Artifactory OSS the REST API is unavalable. Consequently, this TF provider is useless and the README.md should contain a bold warning that is does not work with Artifactory OSS.

If you attempt to use this TF provider with jfrog/artifactory-jcr:

Error: PUT http://127.0.0.1:8082/artifactory/api/repositories/dockerhub: 400 [{Status:400 Message:This REST API is available only in Artifactory Pro (see: jfrog.com/artifactory/features). If you are already running Artifactory Pro please make sure your server is activated with a valid license key.
}]

Enable support for docker token authentication

There are settings in the GUI that don't appear to be available through terraform. Specifically Enable Token Authentication and Block pulling of image manifest v2 schema 1

resource "artifactory_remote_repository" "dockerhub-remote" {
  key             = "dockerhub-remote"
  package_type    = "docker"
  repo_layout_ref = "simple-default"
  url             = "https://registry-1.docker.io/"
  notes           = "managed by terraform"
  content_synchronisation {
    enabled = false
  }
}

Create repository API https://www.jfrog.com/confluence/display/JFROG/Artifactory+REST+API#ArtifactoryRESTAPI-CreateRepository

Support for webhooks

It looks like there is REST support for webhooks .

Would it be a good enhancement to add support for managing webhooks to this provider?
Would a pull request for this be welcome?

Please add more data sources

Please add data sources to match existing resources.

For example there is artifactory_local_repository but there is no artifactory_local_repository data source.

Specifically I'd like to be able to create a virtual repository for existing repositories.

The obvious workaround for me is to run a REST API to fetch list of repositories already in Arifactory, store output in a JSON file, subsequently read that JSON file in Terraform, and use the list of repositories in an artifactory_local_repository but that creates unnecessary steps.

Missing "Enable Indexing in Xray" for local repos

I can set this in the GUI but not in the TF provider yet.

Enable full support for docker remote repos

The option "Enable Foreign Layers Caching" (enableForeignLayersCaching) for remote Docker repos is available in the UI, but missing from the Terraform provider.

Because many other type-specific options are also missing, I would suggest you add an option to directly provide a JSON for typeSpecific map that would be passed to the Artifactory API as-is (without validation). This way you will no longer have to maintain and keep type-specific options up-to-date with the Artifactory API.

Terraform fails to init with 'Error: Failed to query available provider packages'

main.tf

terraform {
  required_providers {
    artifactory = {
      source  = "jfrog/artifactory"
      version = "~> 2.2.5"
    }
  }
}

# Configured via ENV
provider "artifactory" {
  url = "${var.artifactory_url}/artifactory"
}

module "core" {
  source = "./modules/core"
}

console

❯ terraform init
2020/12/31 13:33:00 [INFO] Terraform version: 0.14.2
2020/12/31 13:33:00 [INFO] Go runtime version: go1.15.5
2020/12/31 13:33:00 [INFO] CLI args: []string{"/usr/local/bin/terraform", "init"}
2020/12/31 13:33:00 [DEBUG] Attempting to open CLI config file: /Users/kmarek/.terraformrc
2020/12/31 13:33:00 [DEBUG] File doesn't exist, but doesn't need to. Ignoring.
2020/12/31 13:33:00 [DEBUG] ignoring non-existing provider search directory terraform.d/plugins
2020/12/31 13:33:00 [DEBUG] ignoring non-existing provider search directory /Users/kmarek/.terraform.d/plugins
2020/12/31 13:33:00 [DEBUG] ignoring non-existing provider search directory /Users/kmarek/Library/Application Support/io.terraform/plugins
2020/12/31 13:33:00 [DEBUG] ignoring non-existing provider search directory /Library/Application Support/io.terraform/plugins
2020/12/31 13:33:00 [INFO] CLI command args: []string{"init"}
Initializing modules...
2020/12/31 13:33:00 [TRACE] ModuleInstaller: installing child modules for . into .terraform/modules
2020/12/31 13:33:00 [DEBUG] Module installer: begin core
2020/12/31 13:33:00 [TRACE] ModuleInstaller: core is not yet installed
2020/12/31 13:33:00 [TRACE] ModuleInstaller: cleaning directory .terraform/modules/core prior to install of core
2020/12/31 13:33:00 [TRACE] ModuleInstaller: core has local path "./modules/core"
2020/12/31 13:33:00 [TRACE] ModuleInstaller: core uses directory from parent: modules/core
2020/12/31 13:33:00 [DEBUG] Module installer: core installed at modules/core
2020/12/31 13:33:00 [TRACE] modsdir: writing modules manifest to .terraform/modules/modules.json
- core in modules/core

Initializing the backend...
2020/12/31 13:33:00 [TRACE] Meta.Backend: no config given or present on disk, so returning nil config
2020/12/31 13:33:00 [TRACE] Meta.Backend: backend has not previously been initialized in this working directory
2020/12/31 13:33:00 [DEBUG] New state was assigned lineage "04b0986f-c248-bd84-7e76-0a8131e163e5"
2020/12/31 13:33:00 [TRACE] Meta.Backend: using default local state only (no backend configuration, and no existing initialized backend)
2020/12/31 13:33:00 [TRACE] Meta.Backend: instantiated backend of type <nil>
2020/12/31 13:33:00 [DEBUG] checking for provisioner in "."
2020/12/31 13:33:00 [DEBUG] checking for provisioner in "/usr/local/bin"
2020/12/31 13:33:00 [INFO] Failed to read plugin lock file .terraform/plugins/darwin_amd64/lock.json: open .terraform/plugins/darwin_amd64/lock.json: no such file or directory
2020/12/31 13:33:00 [TRACE] Meta.Backend: backend <nil> does not support operations, so wrapping it in a local backend
2020/12/31 13:33:00 [TRACE] backend/local: state manager for workspace "default" will:
 - read initial snapshot from terraform.tfstate
 - write new snapshots to terraform.tfstate
 - create any backup at terraform.tfstate.backup
2020/12/31 13:33:00 [TRACE] statemgr.Filesystem: reading initial snapshot from terraform.tfstate
2020/12/31 13:33:00 [TRACE] statemgr.Filesystem: snapshot file has nil snapshot, but that's okay
2020/12/31 13:33:00 [TRACE] statemgr.Filesystem: read nil snapshot

2020/12/31 13:33:00 [DEBUG] Service discovery for registry.terraform.io at https://registry.terraform.io/.well-known/terraform.json
2020/12/31 13:33:00 [TRACE] HTTP client GET request to https://registry.terraform.io/.well-known/terraform.json
Initializing provider plugins...
- Finding latest version of hashicorp/artifactory...
2020/12/31 13:33:00 [DEBUG] GET https://registry.terraform.io/v1/providers/hashicorp/artifactory/versions
2020/12/31 13:33:00 [TRACE] HTTP client GET request to https://registry.terraform.io/v1/providers/hashicorp/artifactory/versions
- Finding jfrog/artifactory versions matching "~> 2.2.5"...
2020/12/31 13:33:00 [DEBUG] GET https://registry.terraform.io/v1/providers/jfrog/artifactory/versions
2020/12/31 13:33:00 [TRACE] HTTP client GET request to https://registry.terraform.io/v1/providers/jfrog/artifactory/versions
2020/12/31 13:33:01 [DEBUG] GET https://registry.terraform.io/v1/providers/jfrog/artifactory/2.2.5/download/darwin/amd64
2020/12/31 13:33:01 [TRACE] HTTP client GET request to https://registry.terraform.io/v1/providers/jfrog/artifactory/2.2.5/download/darwin/amd64
2020/12/31 13:33:01 [DEBUG] GET https://github.com/jfrog/terraform-provider-artifactory/releases/download/v2.2.5/terraform-provider-artifactory_2.2.5_SHA256SUMS
2020/12/31 13:33:01 [TRACE] HTTP client GET request to https://github.com/jfrog/terraform-provider-artifactory/releases/download/v2.2.5/terraform-provider-artifactory_2.2.5_SHA256SUMS
2020/12/31 13:33:01 [TRACE] HTTP client GET request to https://github-production-release-asset-2e65be.s3.amazonaws.com/288509997/02507c80-3a61-11eb-8c46-658cb328b2de?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20201231%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20201231T123241Z&X-Amz-Expires=300&X-Amz-Signature=3a5e8fca93a6427f74fc07c9ea1b5b6199424b71b1a194bfbb3764ef20bf4a9b&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=288509997&response-content-disposition=attachment%3B%20filename%3Dterraform-provider-artifactory_2.2.5_SHA256SUMS&response-content-type=application%2Foctet-stream
2020/12/31 13:33:01 [DEBUG] GET https://github.com/jfrog/terraform-provider-artifactory/releases/download/v2.2.5/terraform-provider-artifactory_2.2.5_SHA256SUMS.sig
2020/12/31 13:33:01 [TRACE] HTTP client GET request to https://github.com/jfrog/terraform-provider-artifactory/releases/download/v2.2.5/terraform-provider-artifactory_2.2.5_SHA256SUMS.sig
2020/12/31 13:33:01 [TRACE] HTTP client GET request to https://github-production-release-asset-2e65be.s3.amazonaws.com/288509997/01b7e600-3a61-11eb-9ba0-dd84f19c37ae?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20201231%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20201231T123242Z&X-Amz-Expires=300&X-Amz-Signature=2517a0789296f907aaf95f29ed3e07705f6a3f662cb20ef3cfbad3bdb53f1f83&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=288509997&response-content-disposition=attachment%3B%20filename%3Dterraform-provider-artifactory_2.2.5_SHA256SUMS.sig&response-content-type=application%2Foctet-stream
- Installing jfrog/artifactory v2.2.5...
2020/12/31 13:33:02 [TRACE] providercache.Dir.InstallPackage: installing registry.terraform.io/jfrog/artifactory v2.2.5 from https://github.com/jfrog/terraform-provider-artifactory/releases/download/v2.2.5/terraform-provider-artifactory_2.2.5_darwin_amd64.zip
2020/12/31 13:33:02 [TRACE] HTTP client GET request to https://github.com/jfrog/terraform-provider-artifactory/releases/download/v2.2.5/terraform-provider-artifactory_2.2.5_darwin_amd64.zip
2020/12/31 13:33:02 [TRACE] HTTP client GET request to https://github-production-release-asset-2e65be.s3.amazonaws.com/288509997/02507c80-3a61-11eb-8a53-7cd915a5ab34?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAIWNJYAX4CSVEH53A%2F20201231%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20201231T123242Z&X-Amz-Expires=300&X-Amz-Signature=2ba85c7cf448fe7e7ae15e16545e3753703f8bb9dcf884ae8a061bef292fbf46&X-Amz-SignedHeaders=host&actor_id=0&key_id=0&repo_id=288509997&response-content-disposition=attachment%3B%20filename%3Dterraform-provider-artifactory_2.2.5_darwin_amd64.zip&response-content-type=application%2Foctet-stream
2020/12/31 13:33:04 [DEBUG] Provider signed by 6B219DCCD7639232 JFrog Inc. <[email protected]>
2020/12/31 13:33:04 [TRACE] providercache.fillMetaCache: scanning directory .terraform/providers
2020/12/31 13:33:04 [TRACE] getproviders.SearchLocalDirectory: .terraform/providers is a symlink to .terraform/providers
2020/12/31 13:33:04 [TRACE] getproviders.SearchLocalDirectory: found registry.terraform.io/jfrog/artifactory v2.2.5 for darwin_amd64 at .terraform/providers/registry.terraform.io/jfrog/artifactory/2.2.5/darwin_amd64
2020/12/31 13:33:04 [TRACE] providercache.fillMetaCache: including .terraform/providers/registry.terraform.io/jfrog/artifactory/2.2.5/darwin_amd64 as a candidate package for registry.terraform.io/jfrog/artifactory 2.2.5
- Installed jfrog/artifactory v2.2.5 (signed by a HashiCorp partner, key ID 6B219DCCD7639232)

Partner and community providers are signed by their developers.
If you'd like to know more about provider signing, you can read about it here:
https://www.terraform.io/docs/plugins/signing.html

Error: Failed to query available provider packages

Could not retrieve the list of available versions for provider
hashicorp/artifactory: provider registry registry.terraform.io does not have a
provider named registry.terraform.io/hashicorp/artifactory

Documentation example how to upload a license file

Maybe you could add an example to the documentation (https://registry.terraform.io/providers/jfrog/artifactory/latest/docs) how to upload a license file:

With base64 encoded password:

curl --location --request POST 'http://localhost:8082/artifactory/api/system/licenses' \
--header 'Content-Type: application/json' \
--header 'Authorization: Basic YDSAfhdsafdnosavcmQ=' \
--data-raw '{
    "licenseKey": "licese with \n separated lines"
}'

With plain text password:

curl --user admin:pawwsord --location --request POST 'http://localhost:8082/artifactory/api/system/licenses' \
--header 'Content-Type: application/json' \
--data-raw '{
    "licenseKey": "licese with \n separated lines"
}'

Terraform fails to init while using a module.

This is a followup to #26
I created a git repo with code example - https://github.com/KrystianMarek/bug-terraform-artifactory-provider

As described in the readme, when a module is used https://github.com/KrystianMarek/bug-terraform-artifactory-provider/blob/main/main.tf#L13 terraform init fails.

Package Types Validation Missing Options

The list of valid repository types seems to be missing a few options listed on the JFrog API docs:
https://www.jfrog.com/confluence/display/JFROG/Repository+Configuration+JSON

Source Terraform

resource "artifactory_local_repository" "conan-local" {
  key          = "conan-local"
  package_type = "conan"
}

Failure Output

Error: expected package_type to be one of [alpine bower chef cocoapods composer cran debian docker gems generic go gradle helm ivy maven npm conda nuget opkg p2 puppet pypi rpm sbt vcs yum], got conan
--
8 |  
9 | on terraform/repo_conan.tf line 1, in resource "artifactory_local_repository" "conan-local":
10 | 1: resource "artifactory_local_repository" "conan-local" {

Artifactory version: 7.10.5
Terraform version: 0.14.9
Artifactory provider version: 2.2.9

Expected behavior

Create and manage the repository resources, working before the type validation was added.

Ping failing while running a plan

Hi,

I've set up the provider information url and credentials in this way:

terraform {
  required_providers {
    artifactory = {
      source  = "jfrog/artifactory"
      version = "~> 2.2.5"
    }
  }
}

provider "artifactory" {
  url = "https://my-artifactory.com"
  username = "myusername"
  password = "mypassword"
}

However, when I run terraform plan I get this error:

Error: Get "https://my-artifactory.com/api/system/ping": dial tcp: lookup my-artifactory.com on 192.168.86.1:53: no such host

  on provider.tf line 10, in provider "artifactory":
  10: provider "artifactory" {

The IP that shows is the same one that if I do nslookup my-artifactory.com
Can't this be resolved in the same way that the API does it? If I run curl against the api/system/ping it works just fine.
We have ICMP disable in the host but the API and the JFrog CLI work just fine with ping in the same environment.

Do you have any workaround for this issue?

Remote repository - Smart remote repository settings reset after terraform apply

Describe the bug
When configuring remote repository, Smart Remote Repository settings are reseted to default values even if those settings are not supported by Artifactory provider. ("Report Statistics" & "Sync Properties" & "Source Absence Detection" checkboxes are cleared, "List Remote Folder Items" stays checked)

Requirements for and issue

Snippet

resource "artifactory_remote_repository" "repo-remote" {
  provider     = artifactory.myinstance
  key          = "nuget-repo-remote"
  package_type = "nuget"
  description  = "(local file cache)"
  url          = "https://artifactory.company.com/artifactory/api/nuget/nuget-location-a-local/"
  username     = var.art_login_cloud_account
  password     = var.art_login_cloud_password
  offline      = false

  allow_any_host_auth          = false
  blacked_out                  = false
  block_mismatching_mime_types = true
  bypass_head_requests         = true
  content_synchronisation {
    enabled = true
  }
  download_context_path                 = "Download"
  enable_cookie_management              = false
  enable_token_authentication           = false
  feed_context_path                     = null
  fetch_jars_eagerly                    = false
  fetch_sources_eagerly                 = false
  force_nuget_authentication            = false
  handle_releases                       = true
  handle_snapshots                      = true
  hard_fail                             = false
  includes_pattern                      = "**/*"
  max_unique_snapshots                  = 0
  missed_cache_period_seconds           = 900
  notes                                 = "abcd note"
  property_sets                         = ["artifactory"]
  remote_repo_checksum_policy_type      = "generate-if-absent"
  repo_layout_ref                       = "nuget-abcd-layout"
  retrieval_cache_period_seconds        = 1800
  share_configuration                   = false
  socket_timeout_millis                 = 15000
  store_artifacts_locally               = true
  suppress_pom_consistency_checks       = true
  synchronize_properties                = false
  unused_artifacts_cleanup_period_hours = 168
  v3_feed_url                           = "https://api.nuget.org/v3/index.json"
}

Version of artifactory: 7.13.4
Version of terraform: 0.13.6
Version of provider: 2.2.7

Expected behavior
When "Smart Remote Repository" are set up using WebUI, terraform apply command does not affect them when it is not supported by provider. Or better way, include these settings in provider.

	fileExists := FileExists(outputPath)
	chksMatches, _ := VerifySha256Checksum(outputPath, *fileInfo.Checksums.Sha256)

jfrog / terraform-provider-artifactory Goto Github PK

terraform-provider-artifactory's Introduction

Terraform Provider Artifactory

Releases

Versions

Terraform CLI version support

Quick Start

Documentation

License requirements

Versioning

Developers Wiki

Contributors

License

terraform-provider-artifactory's People

Contributors

Stargazers

Watchers

Forkers

terraform-provider-artifactory's Issues

Requirements for and issue

Community Note

Terraform Version

Affected Resource(s)

Terraform Configuration Files

Expected Behavior

Actual Behavior

Steps to Reproduce

Possible fix

Community Note

Description

New or Affected Resource(s)

Potential Terraform Configuration

New or Affected Resource(s)

Potential Terraform Configuration

Community Note

Description

New or Affected Resource(s)

Potential Terraform Configuration

References

Community Note

Description

New or Affected Resource(s)

Potential Terraform Configuration

References

artifactory_permission_target.test-team will be updated in-place

Community Note

Terraform Version

Affected Resource(s)

Terraform Configuration Files

Debug Output

Panic Output

Expected Behavior

Actual Behavior

Steps to Reproduce

Important Factoids

References

References:

Describe the bug

version of plugin

version of xray

version of terraform

Expected behavior

Community Note

Workaround 1

Workaround 2

main.tf

console

Recommend Projects

Recommend Topics

Recommend Org