beta JSON podspec is fetched with wrong 'source'

[mirkoluchi]

When I publish a beta podspec in JSON format, the pod repo-art update command fetches it with the source attribute wrongly pointing to the previous release.

Let me explain the steps to reproduce:

• publish a pod with version 3.0.0 using a Ruby podspec (Framework-bin.podspec) like this:

Pod::Spec.new do |spec|
  
  spec.name                = 'Framework-bin'
  spec.version             = '3.0.0'
  spec.license             = 'MIT'
  spec.homepage        = 'https://www.mysite.com'
  spec.authors             = { 'Foo' => '[email protected]' }
  spec.summary             = 'Framework'
  spec.platform            = :ios, '8.0'
  spec.ios.vendored_frameworks = 'Framework.framework'
  spec.source = { :http => "https://myartifactoryserver.com/artifactory/api/pods/mylocalrepo/pod/pkg/Framework-bin/3.0.0", :type => 'tgz'}

end

• publish a pod with version 3.1.0-beta using a JSON podspec (Framework-bin.podspec.json) like this:

{
  "name" : "Framework-bin",
  "version" : "3.1.0-beta",
  "summary" : "Framework",
  "homepage" : "https://www.mysite.com",
  "source": {
		"http": "https://myartifactoryserver.com/artifactory/api/pods/mylocalrepo/pod/pkg/Framework-bin/3.1.0-beta",
		"type": "tgz"
	},
  "license" : "MIT",
  "ios" : {
    "vendored_frameworks" : "Framework.framework"
  },
  "authors" : {
    "Foo" : "[email protected]"
  },
  "platforms" : {
    "ios" : "8.0"
  }
}

• update the local podspecs repo

pod repo-art update mylocalrepo

• check the podspecs in the ~/.cocoapods/Repos/mylocalrepo/Specs folder. The podspec for version 3.1.0-beta will have a source that points to 3.0.0!

{
  "name" : "Framework-bin",
  "version" : "3.1.0-beta",
  "summary" : "Framework",
  "homepage" : "https://www.mysite.com",
  "source": {
		"http": "https://myartifactoryserver.com/artifactory/api/pods/mylocalrepo/pod/pkg/Framework-bin/3.0.0",
		"type": "tgz"
	},
  "license" : "MIT",
  "ios" : {
    "vendored_frameworks" : "Framework.framework"
  },
  "authors" : {
    "Foo" : "[email protected]"
  },
  "platforms" : {
    "ios" : "8.0"
  }
}

Notice that browsing the repo using the Artifactory repository browser, the tar.gz published have the correct source in the JSON podspec. Therefore my guess is that the issue is in the REST API that downloads the full specs repo from Artifactory.

[choli]

did you ever solve this? I have the same problem right now, and I would really like to release podspec.json files

[rwalbergpd]

I had this issue, and it would actually retrieve an entirely different CocoaPod instead of the one specified. I spent over three hours with JFrog support and they were never able to resolve it.

Artifactory indeed rewrites podspecs to change the source to the Artifactory instance, and in some cases it chooses the wrong artifact version, or even the wrong artifact.

[atreat]

Artifactory indeed rewrites podspecs to change the source to the Artifactory instance, and in some cases it chooses the wrong artifact version, or even the wrong artifact.

Just ran into this as well. This is undocumented and entirely unnecessary. It appears when the repo index is fetched from /api/pods/<repo-name>/index/fetchIndex the download includes podspecs that are modified.

[jonasborsch]

Hello,

this - reported 6 years ago - behaviour cost me multiple hours. As stated, this is not documented in any way.

In my case we have a big pod containing multiple vendored frameworks. The file structured looks like this:

A.podspec
frameworks/B.xcframework
frameworks/C.xcframework

Instead of this I now want to publish the frameworks separately:

B.podspec.json
frameworks/B.xcframework

C.podspec.json
frameworks/C.xcframework

But the fetchIndex endpoint always returns C.podspec.json with a source pointing to A even tho the name and version of the pod is different. When switching from C.podspec.json to the ruby format C.podspec it works as expected.

The artifactory documentation states that JSON format is supported therefore I would expect this to get fixed (especially for a paid software)

Current workaround: Don't use JSON format.