Cocoapods: pod spec lint doesn't pull from git if the source is already cached

[100grams]

I recently changed the directory structure of my Pod. That is, I moved things around and pushed them to GitHub, I also updated re-attached the tag accordingly.

I then updated the podspec of that Pod to reflect the changes. However, the following:

  `pod spec lint XXXX.podspec' 

failed with the following errors:

  - ERROR | The sources did not match any file
  - ERROR | The resources did not match any file
  - ERROR | The preserve_paths did not match any file

I found out that lint doesn't really pull the source files from git because it finds a cached copy of the repo under ~/Library/caches/CocoaPods/Git/[HASH], however this cache was clearly no longer relevant as it held the old directory structure of the pod.

Trying to work around this, I changed the version of the podspec, hoping that lint would pick up the change and generate a new hash, thus pulling the source again into the cache. It didn't.

This is very confusing and I wonder if it is the desired behavior. If it is, it should be clearly documented under lint command notes, and an option should be given to _force_ pulling the source from git.

If there is another way to go about this, please let me know.

[fabiopelosin]

Actually lint checks if it can find the reference (hash or tag) in the cache, if it doesn't it will pull from the remote. If it still can't find a reference it will exist with an error message. This behavior seems to be working correctly so I think that you updated the version in the podspec but not the tag, commit in the source. Just pointing the source to the hash of the head should fix the issue.

If you don't specify a hash or a tag the caches should always be updated. If this is not the case, it is a bug.

[100grams]

I don't think it's a bug either.

I raised this issue because I personally found it extremely confusing that lint didn't reflect changes I've made on the remote. The fact that lint actually maintains a cache (not to mention which rules are used to mark the cache as "dirty") is not documented and when you run pod spec lint you expect it to do the whole thing from scratch, as if you are installing the pod for the first time. If this is not the default behavior, and the cache is used instead of pulling from the remote, then at least an option to the lint command should be available to _force_ pull or _clean_ the cache before rebuilding. e.g. -f or --clean.

[fabiopelosin]

I would like to understand where the problem was, because it could be an issues for pod install.

Can you report what was the s.source of the podspec (appropriately redacted) before and after?

[fabiopelosin]

To be clear, the cache is implemented to give the same results that you would get without it. If it doesn't, there is a bug.

[100grams]

The s.source in the podspec was not changed before and after.

What changed was the content of the source, i.e. changes were done on the remote, and the tag was re-attached to reflect those changes.

I haven't looked at how the hash for the source is generated in git.rb, but I assume it's a combination of the source url and the tag/branch/commit SHA1. In either case, lint would never know about these types of changes in the remote repo if the tag doesn't change.

This type of change is not a typical use case for a mature pod (i.e. one that is publicly published). Normally you'd assign a new tag or commit SHA1 to s.source after making changes in the remote. However, this is a rather common use case when developing a new pod and testing different configurations. In such cases you usually don't want to use the cache, i.e. the following will be handly:

pod spec lint --clean XXXX.podspec  //clean (local cache) before running validation. This forces lint to pull the pod's source from the remote

[fabiopelosin]

The s.source in the podspec was not changed before and after.

Was it pointing to commit or a hash?

I haven't looked at how the hash for the source is generated in git.rb, but I assume it's a combination of the source url and the tag/branch/commit SHA1. In either case, lint would never know about these types of changes in the remote repo if the tag doesn't change.

The hash is just the MD5 of the url, as the cache is a full clone of the remote repo.

Normally you'd assign a new tag or commit SHA1 to s.source after making changes in the remote.

That is why you should remove the tag/commit information from the source (while you haven't assigned the new one) otherwise even without the cache it will checkout the reference that you specified (i.e. the old version).

[100grams]

s.source was pointing to a tag:

s.source       = { :git => "[email protected]:XXXX.git",  :tag => '1.0.0' } 

I want to keep the tag info so that I can later add tags for newer releases.

This issue occurs when you _keep_ the same tag in s.source, however you re-attach it to a new commit. In this case the cache is not refreshed.

[fabiopelosin]

This is not an issue with the cache, even without it CocoaPods would checkout that tag because that is what you are instructing it to do. This is how CocoaPods links the correct revision of a repo with the specific version of a Pod.

This issue occurs when you keep the same tag in s.source, however you re-attach it to a new commit. In this case the cache is not refreshed.

There is no concept of attaching a podspec with a commit for CocoaPods other than specifying it in the source.

---

What I meant is before linting you can modify the podspec (without committing it) and remove the tag information. Otherwise you can just duplicate the podspec outside the repo, modify that one, and lint that one.

I acknowledge that the workflow of managing a pod is an area that needs improvements, simply we are not there yet.

[Juddster]

This just happened to me as well. I deleted the cached data (under External and Spec/External) and that allowed the pod spec lint to pass.
My scenario was similar to 100grams'. I kept fixing one issue after another (this was my first pod) and so I deleted and retagged newer commits with the same tag (0.1.0). It finally passed pod lib lint but then failed the pod spec lint with issues that I have fixed already. It was clearly a stale cache issue.
This is worth re-evaluating (unless of course it was addressed in v1.0. My pod is v0.39.0).

[tadija]

I had a same problem, pod spec lint failed, I fixed the error in code, made a push and tag again, but it kept failing until I manually removed cached files from ~/Library/Caches/CocoaPods/Pods.
It would be nice to have something as a --force argument which would then override the local cache.

[segiddins]

https://guides.cocoapods.org/terminal/commands.html#pod_cache_clean

[tadija]

Thanks @segiddins, that's it! :)

[Juddster]

Thanks...!

[AlbertoMDieguez]

Thanks @segiddins, works for me!