Reference delta not found error when pulling a repo

[wazery]

I have the following error while syncing this GitHub public action

pulling OctopusDeploy/install-octopus-cli-action to /tmp/actions/OctopusDeploy_install-octopus-cli-action ...                                                    
reference delta not found

I am using the latest version of the actions-sync binary.

[ajaykn]

Interesting, its happening for this repo OctopusDeploy/install-octopus-cli-action but when tried with actions/checkout or some other repos, its working fine: https://github.com/actions/checkout

Error coming from this lib we are using:
https://github.com/go-git/go-git/blob/bf3471db54b0255ab5b159005069f37528a151b7/plumbing/format/packfile/parser.go#L18

We will have to debug more and get back.

[bmoqimi]

Did you by any chance have time to follow up on this @ajaykn ?

[ajaykn]

@bmoqimi Sorry, my team was quite stuck with other feature work, we will have a look this week and see what we can improve. Thanks for reminder.

[ajaykn]

@bmoqimi Logged an issue in go-git go-git/go-git#495

And we will keep an eye once a fix is rolled out, we will bump to a new version of this sync tool.

[ajaykn]

@wazery @bmoqimi, Hope you are doing well.

Quick workaround on this issue:
Since reference delta not found is happening at the time of cloning the repo locally due to bug from go-git package,
we can clone manually and use the actions sync tool to push the code to your instance

• Under cache dir we use when running the sync tool, in this case: --cache-dir "tmp/cache"
• Create folder OctopusDeploy
• Navigate to folder cd OctopusDeploy
• Clone manually git clone https://github.com/OctopusDeploy/install-octopus-cli-action.git

Cloning into 'install-octopus-cli-action'...
remote: Enumerating objects: 8209, done.
remote: Counting objects: 100% (1511/1511), done.
remote: Compressing objects: 100% (897/897), done.
remote: Total 8209 (delta 847), reused 968 (delta 518), pack-reused 6698
Receiving objects: 100% (8209/8209), 10.12 MiB | 5.56 MiB/s, done.
Resolving deltas: 100% (2173/2173), done.

• Now run the sync tool, so that it skips cloning and we can bypass this reference delta not found error
  bin/actions-sync sync --cache-dir "tmp/cache" --destination-token "token" --destination-url "https://ghes-url.com/" --repo-name OctopusDeploy/install-octopus-cli-action

fetching * refs for OctopusDeploy/install-octopus-cli-action ...
syncing `OctopusDeploy/install-octopus-cli-action`
Created repo `OctopusDeploy/install-octopus-cli-action`
successfully synced `OctopusDeploy/install-octopus-cli-action`

[adnansakel]

@wazery @bmoqimi, Hope you are doing well.

Quick workaround on this issue: Since reference delta not found is happening at the time of cloning the repo locally due to bug from go-git package, we can clone manually and use the actions sync tool to push the code to your instance

• Under cache dir we use when running the sync tool, in this case: --cache-dir "tmp/cache"
• Create folder OctopusDeploy
• Navigate to folder cd OctopusDeploy
• Clone manually git clone https://github.com/OctopusDeploy/install-octopus-cli-action.git

Cloning into 'install-octopus-cli-action'...
remote: Enumerating objects: 8209, done.
remote: Counting objects: 100% (1511/1511), done.
remote: Compressing objects: 100% (897/897), done.
remote: Total 8209 (delta 847), reused 968 (delta 518), pack-reused 6698
Receiving objects: 100% (8209/8209), 10.12 MiB | 5.56 MiB/s, done.
Resolving deltas: 100% (2173/2173), done.

• Now run the sync tool, so that it skips cloning and we can bypass this reference delta not found error
  bin/actions-sync sync --cache-dir "tmp/cache" --destination-token "token" --destination-url "https://ghes-url.com/" --repo-name OctopusDeploy/install-octopus-cli-action

fetching * refs for OctopusDeploy/install-octopus-cli-action ...
syncing `OctopusDeploy/install-octopus-cli-action`
Created repo `OctopusDeploy/install-octopus-cli-action`
successfully synced `OctopusDeploy/install-octopus-cli-action`

The work around unfortunately does not work when the repository name has to be different on our GHES instance. So the repository name should be passed as,
bin/actions-sync sync --cache-dir "tmp/cache" --destination-token $DESTINATION_TOKEN --destination-url "https://ghes.url/" --repo-name OctopusDeploy/install-octopus-cli-action:actions/OctopusDeploy_install-octopus-cli-action
This tries to pull from the remote instead of skipping the pulling and results in the reference delta not found error

pulling OctopusDeploy/install-octopus-cli-action to tmp/cache/actions/OctopusDeploy_install-octopus-cli-action ...
reference delta not found

[ajaykn]

The work around unfortunately does not work when the repository name has to be different on our GHES instance. So the repository name should be passed as,
bin/actions-sync sync --cache-dir "tmp/cache" --destination-token $DESTINATION_TOKEN --destination-url "https://ghes.url/" --repo-name OctopusDeploy/install-octopus-cli-action:actions/OctopusDeploy_install-octopus-cli-action
This tries to pull from the remote instead of skipping the pulling and results in the reference delta not found error

pulling OctopusDeploy/install-octopus-cli-action to tmp/cache/actions/OctopusDeploy_install-octopus-cli-action ...
reference delta not found

@adnansakel As mentioned in previous comment, the issue is happening when cloning the repo.

The reason it is failing in your case, is because,

• the sync command first checks if the repo exists under tmp/cache folder with the destination name: here it checks for repo under actions/OctopusDeploy_install-octopus-cli-action.
• Since it doesnt exists, it tries to clone locally to the folder.

Please make sure to have the repo cloned manually to tmp/cache/actions/OctopusDeploy_install-octopus-cli-action
And since cloning is done already, please run the command either sync / push.

i tried and able to successfully pushed the repo to destination.

syncing `actions/OctopusDeploy_install-octopus-cli-action`
Created repo `actions/OctopusDeploy_install-octopus-cli-action`
successfully synced `actions/OctopusDeploy_install-octopus-cli-action`

[adnansakel]

The work around unfortunately does not work when the repository name has to be different on our GHES instance. So the repository name should be passed as,
bin/actions-sync sync --cache-dir "tmp/cache" --destination-token $DESTINATION_TOKEN --destination-url "https://ghes.url/" --repo-name OctopusDeploy/install-octopus-cli-action:actions/OctopusDeploy_install-octopus-cli-action
This tries to pull from the remote instead of skipping the pulling and results in the reference delta not found error

pulling OctopusDeploy/install-octopus-cli-action to tmp/cache/actions/OctopusDeploy_install-octopus-cli-action ...
reference delta not found

@adnansakel As mentioned in previous comment, the issue is happening when cloning the repo.

The reason it is failing in your case, is because,

• the sync command first checks if the repo exists under tmp/cache folder with the destination name: here it checks for repo under actions/OctopusDeploy_install-octopus-cli-action.
• Since it doesnt exists, it tries to clone locally to the folder.

Please make sure to have the repo cloned manually to tmp/cache/actions/OctopusDeploy_install-octopus-cli-action And since cloning is done already, please run the command either sync / push.

i tried and able to successfully pushed the repo to destination.

syncing `actions/OctopusDeploy_install-octopus-cli-action`
Created repo `actions/OctopusDeploy_install-octopus-cli-action`
successfully synced `actions/OctopusDeploy_install-octopus-cli-action`

Thank you very much @ajaykn . Yes it works now. I misunderstood the destination directory for the cloned repository. I was cloning in /tmp/cache; but it should be in /tmp/cache/actions , in my case. Also did not realise that the destination directory name should be also same as the custom repository name. Now works after cloning in /tmp/cache/actions/OctopusDeploy_install-octopus-cli-action. Thank you !

[github-actions]

This issue is stale because it has been open for 30 days with no activity.

[github-actions]

This issue was closed because it has been inactive for 14 days since being marked as stale.