Support ant-patterns filter types for watch resources

[andrei-radulescu]

I tried to use ant-pattern filters in the watch resource configuration but seams that the implementation is yet not done.

Tried to circumvent by using in the watch resource something like:

 watch_resource {
    type       = "all-builds"
    bin_mgr_id = "default"
    filter {
      type  = "ant-patterns"
      value = "{ \"IncludePatterns\": [\"*my_build*/**\"]}"
    }
}

but without success. (I saw that value is defined as string)

[danielmkn]

@andrei-radulescu, thank you for the ticket! Xray Watch API v2 doesn't support ant-patterns filter type for builds. It's only supported by the Watch for the Projects. To filter builds you need to use regex filter: filter { type = "regex" value = ".*" }

[chb0github]

We have no extra juice on the inside - If you want to see this feature you will need to get it supported by the platform first. File a ticket here

[andrei-radulescu]

@chb0github @danielmkn

Hey guys. Thanks for replying. I think Jfrog has again some discrepancy in it's documentation. So right now i'm at the state of probing the xray tf provider. What we alternatively use: are scripts in tf, integrated with scottwinkler/shell provider. Here i'm employing successfully the following script (so I tend to disagree on the no api support):

#!/usr/bin/env bash

# This script does an authenticated API call against an X-Ray API with and creates a watch

set -o errexit
set -o nounset
set -o pipefail

main() {
    cat <<EOF > watch.json
    {
        "general_data": {
            "name": "$NAME",
            "description": "This is a new watch applying $POLICY on all builds including $PATTERN in their name.",
            "active": true
        },
        "project_resources": {
            "resources": [
                {
                    "type": "all-builds",
                    "bin_mgr_id": "default",
                    "filters": [
                        {
                            "type": "ant-patterns",
                            "value": {
                                "IncludePatterns": [
                                    "$PATTERN"
                                ]
                            }
                        }
                    ]
                }
            ]
        },
        "assigned_policies": [
            {
                "name": "$POLICY",
                "type": "security"
            }
        ],
    "watch_recipients": ["$WATCHRECIPIENT"]
    }
EOF

    curl -u"$USER":"$PASSWORD" -X POST "$ARTIFACTORY"/api/v2/watches -H 'Content-Type: application/json' -T "watch.json"
    cat watch.json #to store in the tf state
    rm -f watch.json
}

main "$@"

you can give it a spin 👍 it's v2. Example of $PATTERN: *adhinfra_nonroot*/**

also if we look at the ui when creating a watch -> you see under pattern - a include/exclude and no simple field for a regex (the above script adds the pattern under the include part if you look afterwards in the UI). I mean there is no problem having a normal regex. The include, exclude option is actually the wanted feature. (I saw in your code under the schema a TODO to add this options flag).

I tried also the option with the regex (also took a look at the API doc), but can't see anything in the UI after successfully applying the tf - like the regex went to nirvana (maybe i'm doing something wrong):

resource "xray_watch" "artifactory_xray_watch_base_image_test" {
  name        = "base-image-watch-test
  description = "Watch base image builds"
  active      = true

  watch_resource {
    type       = "all-builds"
    bin_mgr_id = "default"
    # filter {
    #   type  = "ant-patterns"
    #   value = "{ \"IncludePatterns\": [\"*adhinfra_nonroot*/**\"]}"
    # }
    filter {
      type  = "regex"
      value = "*adhinfra_nonroot*"
    }
  } 

Thanks in advance.

[danielmkn]

Thanks, @andrei-radulescu, I need to look deeper into it.

[danielmkn]

@andrei-radulescu, unfortunately, the all-builds type is not described in Xray API documentation. I've created an internal ticket for fixing the documentation and we will work on the implementation of this feature in the Provider. Thanks for pointing this out!