New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
pod spec lint doesn't pull from git if the source is already cached #393
Comments
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. |
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 |
I would like to understand where the problem was, because it could be an issues for Can you report what was the |
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. |
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:
|
Was it pointing to commit or a hash?
The hash is just the MD5 of the url, as the cache is a full clone of the remote repo.
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). |
s.source was pointing to a tag:
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. |
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.
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. |
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. |
I had a same problem, |
Thanks @segiddins, that's it! :) |
Thanks...! |
Thanks @segiddins, works for me! |
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:
failed with the following errors:
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.
The text was updated successfully, but these errors were encountered: