Github.modified_since_commit shouldn't raise an exception if /GET to api.github.com fails #746
Conversation
Currently, the check to detect if the public Cocoapods spec repo is being used is a simple Regex match on github.com This backfires when we use private instances in github.com to host the spec repo (As is the case at LinkedIn) This patch makes the Regex more specific and only targets the public Cocoapods spec repo instance. The following two regex matches verify that claim: HTTPS remote URL match: https://rubular.com/r/oIsVWngbVcPTGT SSH remote URL match: https://rubular.com/r/HvnyKImgQptFU8
|
I think we likely want to keep the check for compatibility with other public specs repos on GitHub, and maybe have a more robust fallback when that request 4xxs ? |
|
This seems weird to change for the base class of def update(show_output)
return [] if unchanged_github_repo?
prev_commit_hash = git_commit_hash
update_git_repo(show_output)
@versions_by_name.clear
refresh_metadata
if version = metadata.last_compatible_version(Version.new(CORE_VERSION))
tag = "v#{version}"
CoreUI.warn "Using the `#{tag}` tag of the `#{name}` source because " \
"it is the last version compatible with CocoaPods #{CORE_VERSION}."
repo_git(['checkout', tag])
end
diff_until_commit_hash(prev_commit_hash)
endWouldn't that break for all other git based repos that are managed by CocoaPods? Is it possible to provide more info on what "backfires" means here and more details on the issue? |
@segiddins I hadn't considered the possibility of multiple public spec repos. I assumed it was intended only for https://github.com/CocoaPods/Specs |
@dnkoutso Let me explain how I read the flow. When a user runs If it does match i.e. it's presumably a public spec repo (which I assumed to be exclusively the master one), then Github.modified_since_commit is called. That method makes a If this PR were to be merged, the update workflow for only the master public spec repo would invoke the
Sure thing. LinkedIn is sunsetting its private Github Enterprise instance and is moving to GHEC, wherein the new spec repo url is Note that cloning the spec repo isn't a problem because we control the SSH config of the CI user bot and we can add a proxy there. Finally, we really don't need this check given the size of our private spec repo and the current code seems to indicate that this wasn't intended for private spec repos to begin with. Let me know if I'm making sense, totally possible that I'm missing something. |
|
Buzz-Lightyear
changed the title
|
@segiddins Let me know if this fallback works. |
|
Only thing that stands out to me is being a bit less permissive: can we allow 4xxs through, but continue to raise an exception on other errors? |
@segiddins I tried: The issue is that the request times out and |
|
@segiddins Just following up this, do you have any ideas as to how I can guard against a timeout? |
Github.modified_since_commit shouldn't raise an exception if /GET to api.github.com fails. Instead pod repo update should continue.
See #746 (comment) for detailed context.
Current Behavior when /GET fails:
Behavior if this PR is merged:
