Failed: `noCommonShaWithPrimaryRepo` error for Pull Request created from fork repo.

[canhth]

Description

Our CICD jobs have an issue with installing XCRemoteCache for the Pull Request created by fork repo.

Notes:

• $git_remote: ex: https://github.com/spotify/XCRemoteCache.git
• $git_revision commit sha: 0e395ec8a0ad9c4da56bc46444dee6fe2d97d363

Before support XCRemoteCache:

• Our set up in CI, every job will have a specific directory:

  git init
  git remote add origin $git_remote
  git fetch --depth 1 origin $git_revision
  git checkout $git_revision

Support XCRemoteCahe:

Without fork repo's PR, it works normally when I use this:

    git init
    git remote add origin $git_remote
    if [[ ${use_remote_cache} = true ]]; then
      git fetch origin
    else
      git fetch --depth 1 origin $git_revision  
    fi
    git checkout $git_revision

• Because git fetch origin doesn't fetch the git_revision from fork repo. So it would fail.

And this is what I changed to support fork repo (add git fetch origin after checkout the git-revision)

    git init
    git remote add origin $git_remote
    git fetch --depth 1 origin $git_revision  
    git checkout $git_revision
    if [[ ${use_remote_cache} = true ]]; then
      git fetch origin
    fi

---> It makes the fork repo works again, but will cause this problem below:

error: Prepare failed with error: Finding a common commit failed. Please try to call `git fetch origin`. [Error: statusError("status 128: fatal: Not a valid object name origin/master", 128)]
[XCRC] XCRemoteCache failed with an error: undefined method `[]' for false:FalseClass.

Expected/desired behavior

No error when run pod_install with fork repo.

How to reproduce this issue with example repo:

Repo A and master branch is the one generating the cache artifacts.

1. Fork repo A, we have repo B.
2. Create new branch and add new commit to repo B.
3. Push the branch to repo B.
4. At your repo A, run:

   git fetch --depth 1 origin <new commit from step 2>
   git checkout <new commit from step 2>

5. Run pod install at repo A
6. The error: Finding a common commit failed appears.

• primary_repo: repo A
• primary_branch: master

Relevant integration setup

• CocoaPods cocoapods-xcremotecache plugin

[polac24]

Hi! I am afraid I am not following. What is actually a problem? Am I right that you have more than 1 issue (if so, can you create separate issues and close this one)?

Some comments:

• case1 - that seems to be a problem with a sheer git clone/checkout so XCRemoteCache should not affect that? Just guessing, maybe you need to add quotes git checkout "$git_revision"?
• case 2/Reproducible locally: I would double check what is your primary_repo and primary_branch (either in .rcinfo or Podfile). If you use forks, you need to set primary_repo to the repo for which generates artifacts as a producer.

[canhth]

Hi @polac24 , I've updated the description, I'm sorry for the bad explanation, there is only a problem with fork repo.

You can follow the How to reproduce this issue with example repo: path with a supported XCRemoteCache repo.

I think after I called git fetch origin, XCRemotecache setup should work probably, but in my case, git fetch origin after checkout the git_revision is not working.

[polac24]

OK, this is not XCRemoteCache issue, you need to call git fetch --unshallow

[canhth]

Thank you very much @polac24, But honestly, I'm not sure how it can work in this case? Use git fetch origin --unshallow works but not fully understand how this can make XCRemoteCache work again?

Just want to confirm that if my primary_branch is fixed to master for example, can we only fetch the primary branch git fetch origin master --unshallow? Would be nice if in XCRemoteCache can support fetch & find the common commit itself. Does not need additional setup on CI job.

(current version is only find the common commit)

Because we might use one CI for multiple projects, and not really convincible if adding the git fetch xxx --unshallow.

[polac24]

Hi! As your screenshot shows, we execute git merge-base to find the most common sha with a primary branch (for a given origin). If you fetch or clone your repo with shallow mode, there is no git history available. You could validate locally with git log.

If you need a support for explicitly provided shas that could have generated artifacts, feel free to contribute to XCRemoteCache. Initial idea: That could be an extra (optional) array in .rcinfo That would provide historical shas, instead of calling GitClientImpl.

On Sat, 4 Jun 2022 at 02:14, Canh Tran @.***> wrote:

Thank you very much @polac24 https://github.com/polac24, But honestly, I'm not sure how it can work in this case? Use git fetch origin --unshallow works but not fully understand how this can make XCRemoteCache work again?

Just want to confirm that if my primary_branch is fixed to master for example, can we only fetch the primary branch git fetch origin master --unshallow? Would be nice if in XCRemoteCache can support fetch & find the common commit itself. Does not need additional setup on CI job.

[image: Screen Shot 2022-06-04 at 07 12 41] https://user-images.githubusercontent.com/7752679/171968663-26a2b8c5-ded3-48ae-8cf3-16dc8c00090c.png (current version is only find the common commit)

Because we might use one CI for multiple projects, and not really convincible if adding the git fetch xxx --unshallow.

— Reply to this email directly, view it on GitHub https://github.com/spotify/XCRemoteCache/issues/145#issuecomment-1146472675, or unsubscribe https://github.com/notifications/unsubscribe-auth/ACJO52KIM34BZROTVJRQWI3VNKNXBANCNFSM5XX3LVEA . You are receiving this because you were mentioned.Message ID: @.***>

[canhth]

Thank you @polac24 for explaining the issue. Btw, I do have one more question related to: support XCRemoteCache for CI job.

• We use --depth 1 to save clone the repo time. But when using git fetch origin, it will take a lot of time to complete the request (>700k objects and the size >1GB).
• As I think this is a temporary workaround:

  git init
  git remote add origin <git_remote>
  git fetch origin --depth 100 <git_revision>
  git fetch origin --depth 100 master          # master branch is the branch generating cache.

  This should work, but it need to call fetch origin ... two times which is I don't think it's a best practice.

--> Wondering if there is a better approach that Spotify or other team use to support CI job?

[polac24]

Hi! Cannot suggest anything other than caching a git repo on a machine somehow. Many CI automation platforms (like Jenkins) support git repo caching and that could speed up the git fetch origin command.

[canhth]

Thank you @polac24. I'll close this issue then.