Golang stacktrace when running the provider, the plugin has crashed

[DzeCin]

Describe the bug Xray provider 1.14.0 throws an error when using "filter" block in "watch_resource" block for the "xray_watch" resource.

This error is raised:

Requirements for and issue

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

  resource "xray_watch" "backend_watch" {
  name        = "backend-watch"
  description = "Watch for the backendrepo"
  active      = true
  watch_resource {
  type      = "repository"
  name      = "push"
  repo_type = "local"
  filter {
    type  = "regex"
    value = "$backend.*"
  }
  }
  
  assigned_policy {
  name = xray_security_policy.high_critical_cvss.name
  type = "security"
  }
  
  assigned_policy {
  name = xray_license_policy.opensource_licenses.name
  type = "license"
  }
  
  assigned_policy {
  name = xray_operational_risk_policy.high_ops_risk.name
  type = "operational_risk"
  }
  }

• Artifactory version : 7.47.12
• XRay version : 3.62.4
• Terraform version : 1.3.4

Expected behavior I expect no errors from this.

Additional context No additional context

[danielmkn]

Hi @DzeCin! I can't reproduce the issue on Terraform 1.2.9, 1.3.9, and 1.5.3, there is no 1.3.4 on https://developer.hashicorp.com/terraform/downloads to try that version as well. This is my snippet:

resource "xray_security_policy" "security" {
  name        = "policy1"
  description = "Security policy description"
  type        = "security"
  rule {
    name     = "rule-name-severity"
    priority = 1
    criteria {
      min_severity = "High"
    }
    actions {
      webhooks = []
      mails    = ["test@email.com"]
      block_download {
        unscanned = true
        active    = true
      }
      block_release_bundle_distribution  = true
      fail_build                         = true
      notify_watch_recipients            = true
      notify_deployer                    = true
      create_ticket_enabled              = false
      build_failure_grace_period_in_days = 5
    }
  }
}

resource "xray_security_policy" "security1" {
  name        = "policy2"
  description = "Security policy description"
  type        = "security"
  rule {
    name     = "rule-name-severity"
    priority = 1
    criteria {
      min_severity = "High"
    }
    actions {
      webhooks = []
      mails    = ["test@email.com"]
      block_download {
        unscanned = true
        active    = true
      }
      block_release_bundle_distribution  = true
      fail_build                         = true
      notify_watch_recipients            = true
      notify_deployer                    = true
      create_ticket_enabled              = false
      build_failure_grace_period_in_days = 5
    }
  }
}

resource "xray_watch" "backend_watch" {
  name          = "backend_watch"
  description   = "Description"
  active        = true

  watch_resource {
    type      = "repository"
    name      = "daniel-npm-test"
    repo_type = "local"
    filter {
      type  = "regex"
      value = "$backend.*"
    }
  }
  assigned_policy {
    name    = xray_security_policy.security.name
    type    = "security"
  }

  assigned_policy {
    name    = xray_security_policy.security1.name
    type    = "security"
  }
}

This is the API body for the watch (GET call), generated by this HCL:

{
    "general_data": {
        "id": "73b545f7b12bd12b90222ecb",
        "name": "backend_watch",
        "description": "Description",
        "active": true
    },
    "project_resources": {
        "resources": [{
            "type": "repository",
            "name": "daniel-npm-test",
            "bin_mgr_id": "default",
            "filters": [{
                "type": "regex",
                "value": "$backend.*"
            }],
            "repo_type": "local"
        }]
    },
    "assigned_policies": [{
        "name": "policy2",
        "type": "security"
    }, {
        "name": "policy1",
        "type": "security"
    }]
}

The error from the stack trace refers to line 380, where we set "watch_resource" set: d.Set("watch_resource"... In the HCL example, I see nothing wrong with that attribute, so there should be nothing wrong. Please, double-check the HCL or try again with my snippet.

[DzeCin]

Hi @danielmkn , I updated the terraform version to 1.5.3 and tried with you snippet and I still got the same error. In fact, the error appeared when I added the "filter" block. It works well without it.

[danielmkn]

Weird, what version of Golang do you have?

[DzeCin]

I run the plan in a pipeline, I am using the official terraform:1.5.3 image

[DzeCin]

I tried to run the plan from my laptop with debug enabled and I get those errors :

Not sure where the "path-regex" comes from, I checked in the tfstate just in case and it is not there

The go version is go1.19.5 linux/amd64

[DzeCin]

Ok I found the problem: if you first define the filters manually in the artifactory UI, the terraform plan will crash. IMO it is still a bug

[danielmkn]

Thanks for checking. Looks like an API might return that value since the watch already exists. We will verify that.

[danielmkn]

@DzeCin I'm able to reproduce it. It's an import issue when the watch was created in the UI. Looks like Xray bug to me, because you can create a watch with regex and path-regex filter types in the API, but if the watch was created in the UI, the filter type returned in the GET call will be path-regex. API documentation only states regex as a filter type, so we had no idea about path-regex existence before. UI at the same time, looks identical for both filter types. I'll think about the workaround.

[danielmkn]

The fix is here. It was a missing filter type, which might be added in the newer Xray version after the resource was added to TF Provider initially. Basically, regex and path-regex are different filters in the UI as well. It's not very clear though. You can see it in the screenshot:

Name corresponds to regex and Path to path-regex. I've added a new filter type, now import will work in your case, as well as creation of a new watch with path-filter.

[danielmkn]

@DzeCin, it's fixed in v1.14.2, thanks for reporting!