Cannot redeploy artifact after upgrading to plugin 3.10.6: "Mandatory properties do not match"

[stevemuskiewicz]

Describe the bug After upgrading to plugin version 3.10.6, one of our Jenkins freestyle jobs that uses the plugin to redeploy an artifact has stopped working, giving a 404 response. (Nothing else has changed aside from the plugin version itself)

Further investigation shows it is receiving the following JSON response:

Trying X.X.X.X:443..
< HTTP/1.1 404 Not Found 
< Date: Tue, 06 Apr 2021 18:34:04 GMT 
< Server: Artifactory/6.18.1 
< X-Artifactory-Id: <XXXXX> 
< Content-Type: application/json;charset=ISO-8859-1 
< Access-Control-Allow-Origin: * 
< Connection: close 
< Transfer-Encoding: chunked 
< { "errors" : [ { "status" : 404, "message" : "File 'api-docs-local:myprod/0.1.2/swagger.json' was found, but mandatory properties do not match." } ] 

I'm not sure what properties it seems to be enforcing as mandatory. Looking at https://www.jfrog.com/confluence/display/JFROG/Using+Properties+in+Deployment+and+Resolution#UsingPropertiesinDeploymentandResolution-Non-mandatoryProperties, it looks to me like "mandatory" parameters would have a += in the URL, but I don't see any of those.

Is it possible the plugin is now incorrectly treating non-mandatory properties as mandatory?

To Reproduce Configure a Jenkins freestyle job that deploys an artifact that already exists. Our setup uses the following upload spec to deploy the artifact

{
 "files": [
   {
     "pattern": "docs/swagger.json",
     "target": "api-docs-local/myprod/${VERSION}/"
   }
  ]
 }

Expected behavior Artfiact should be (re)deployed

Versions

• Jenkins Artifactory plugin version: 3.10.6
• Jenkins operating system: Linux
• Artifactory Version: 6.18.1

Additional context I filed a related bug in the Jenkins Jira instance (not sure if anyone looks at those) https://issues.jenkins.io/browse/JENKINS-65296

[eyalbe4]

@stevemuskiewicz, It looks like the configured URL of your Artifactory instance is inaccessible or incorrect. Can you please check the Artifactory URL configured in Manage | Configure System? Try pinging the following API endpoint using cUrl and see if it responds: (Configured Artifactory URL)/api/system/version Please let me know what you see.

[eyalbe4]

@stevemuskiewicz, Notice that in most cases (but not always) the Artifactory URL ends with /artifactory

[stevemuskiewicz]

@eyalbe4 as mentioned in the bug report nothing has changed except for the Artifactory jenkins plugin version. This has been working perfectly for us for several years.

Artifactory is responding normally to /api/system/version:

* Mark bundle as not supporting multiuse
< HTTP/1.1 200 OK
< Date: Fri, 14 May 2021 14:07:44 GMT
< Server: Artifactory/6.18.1
< X-Artifactory-Id: XXXXXX
< Content-Type: application/vnd.org.jfrog.artifactory.system.Version+json
< Connection: close
< Transfer-Encoding: chunked
< 
{
  "version" : "6.18.1",
  "revision" : "61801900",
  "addons" : [ "build", "docker", "vagrant", "replication", "plugins", "gems", "composer", "npm", "bower", "git-lfs", "nuget", "debian", "opkg", "rpm", "cocoapods", "conan", "vcs", "pypi", "release-bundle", "replicator", "keys", "chef", "cran", "go", "helm", "rest", "conda", "license", "puppet", "ldap", "sso", "layouts", "properties", "search", "securityresourceaddon", "filtered-resources", "p2", "watch", "webstart", "support", "xray" ],
  "license" : "XXXXXXXXX"

Our artifactory is behind a reverse proxy, so there is no /artifactory portion of the URL

[eyalbe4]

I understand what you're saying @stevemuskiewicz. From the information you shared here though, the usage seems pretty basic - a plain upload spec used to upload a single file. If the URL is correct, the only thing I can think of right now is something that is related to the http or reverse proxy in front of Artifactory. You can also open a ticket to JFrog Support. They may be able to assist finding the root cause of the issue. If there's additional info which you come access during the investigation, it'll be great if you can share it here, since it may help others.

[mafgh]

We just ran into the same problem.

@stevemuskiewicz do you happen to have AllowEncodedSlashes Off in your apache config?

My untested theory is:

3.10.5 -> 3.10.6 has updated build-info-* 2.23.0 -> 2.24.1 dependencies. This includes https://github.com/jfrog/build-info/pull/460 which fixes https://github.com/jfrog/jenkins-artifactory-plugin/issues/371 in https://github.com/jfrog/build-info/pull/460/commits/53e503f6669da62bea891c39ce1f9e97623a59cf, basically:

-            return URLEncoder.encode(s, "UTF-8").replace("%2F", "/");
+            return URLEncoder.encode(s, "UTF-8");

Before that change, no encoded slashes would reach apache, thus AllowEncodedSlashes Off would not matter.

[stevemuskiewicz]

@mafgh Actually we are using nginx so not sure what the equivalent config would look like. But I think your theory of what is happening is makes sense.

[mafgh]

After changing AllowEncodedSlashes to On, I was able to deploy with v3.12.3.