Adding a Swift Package using the SSH URL

Hi,

Overview

  • I have an Xcode project that uses a swift package
  • This is a private repository (both Swift Package and Xcode project)
  • On Xcode accounts > source control I am using SSH
  • The swift package was added to the Xcode project using a SSH URL (git@github.com:....)
  • I added some commits to the swift package
  • I tried to update to the latest swift package and got the following error

Error:

Error while fetching remote repository/.....: An unknown error occurred. reference 'refs/remotes/origin/main' not found (-1)

exhausted attempts to resolve the dependencies graph, with '<package name> remoteSourceControl git@github.com:.....git' unresolved.

Workaround:

  • Use HTTPS URL for Swift Package
  • In Xcode source control account use HTTPS and not SSH

Questions:

  1. Can a swift package be added using a Swift package SSH URL? If so how?
  2. Is it working for you?
  3. Am I missing something?

Environment:

  • macOS: 13.0 Beta (22A5373b)
  • Xcode: 14.1 beta 3 (14B5033e)
1 Like

I thought many would be using SSH for Swift Packages.

Is this something that is working fine for you guys? Or is this not supported at all?

Works fine.

1 Like

Thanks a lot @Jon_Shier for confirming it works fine for you.

Probably something at my end, will wait to test it on macOS 13 final release.

Works fine 2

1 Like

Thanks a lot @martinlau

Are you using SSH with Xcode 14.1 RC, on macOS 13 RC?

workin on Xcode 14.0 / macOS 12.6

1 Like

@martinlau thanks a lot will continue to check at my end

@somu you are not alone: my team has been seeing this issue for some time, at least since spring of 2022. Initially it only seemed to affect new team members, particularly if they got an M1 Mac. But recently all remaining Intel Mac users on our team were upgraded to M1s, and now all team members are having this problem--except for one person, who is using an M1, so the correlation isn't perfect. Although that person has been on an M1 for longer than anyone else.

My team uses Azure DevOps for SCM and CI. We have several apps, each of which depends on several in-house Swift package dependencies in common. Our in-house dependencies are all specified using SSH URLs in the various Package.swift files and Xcode project settings. We also have several more Apple and 3rd-party dependencies which are specified with HTTPS URLs.

Attempts to update package dependencies always fail (either File -> Packages -> Update to Latest Package Versions, or right-clicking a dependency and choosing Update Package), with one or more of the SSH-method dependencies giving the reference 'refs/remotes/origin/main' not found (-1) error, and ultimately the exhausted attempts to resolve the dependencies graph error.

We find that resolving package dependencies usually works, although that sometimes fails in the same way.

Deleting ~/Library/Developer/Xcode/DerivedData and ~/Library/Caches/org.swift.swiftpm does not solve the problem. Our workaround is to change the minimum version of the dependency rule to the version we want to update to. That results in a package resolve operation (not update), which usually succeeds. Sometimes even that fails in the same way, and we have to do a Package Cache Reset--very time-consuming with a dozen or more dependencies.

As I mentioned, we've been seeing this for some time, so I don't remember which Xcode version it started with--at least something in the 13.x range, and it's still occurring with 14.2. macOS versions have also ranged from 12.x to the latest, 13.1.

Switching from SSH to HTTPS URLs does eliminate the issue, but HTTPS auth is inconvenient so we'd prefer not to do that.

1 Like

There has been one improvement during the lifetime of this issue: I believe it was Xcode 14.1 that introduced a change that made package resolution more reliable. Previously that would fail much more frequently. But since 14.1 we now see the warning skipping cache due to an error [...] reference 'refs/remotes/origin/main' not found (-1) for one or more SSH-method dependencies during otherwise successful package resolves. But we never see the cache being skipped during package update operations.

1 Like

Have you tried regenerating your SSH keys for Azure? I found I needed to regenerate them every time I updated my OS, otherwise I would start getting git errors. But that was with all repos, not just packages.

A centralized Swift package registry can't come soon enough.

Thinking about it more, I think I replaced my git URLs from Azure with the tokenized HTTP URLs it will generate for you. To be truly safe there you'd want to use a very limited account to generate the token. Azure security is pretty messed up anyway, they don't even support the latest SSH key standards.

@toddthomas

Thanks a lot for confirming that you have experienced this as well.

Now things seem to work alright for me, not sure what fixed the issue, I did a clean install of my macOS and therefore regenerated the SSH keys on GitHub. And I am on Xcode 14.1.

I am glad it works now, but not sure what fixed the issue

Thank you @Jon_Shier and @somu for the suggestion to try regenerating my SSH keys. I have seen that recommended as a solution in some StackOverflow answers to similar questions from a few years ago, but I think that was specific to GitHub disabling support for legacy encryption schemes. As you mention @Jon_Shier, Azure DevOps doesn't require anything beyond the defaults provided by ssh-keygen.

I did generate a new keypair when I set up the M1 MacBook Pro I'm currently using. Unfortunately it was when I switched to this machine that the problem started for me! :cry:

Tonight I tried using a new keypair with the default base name id_rsa, and without a passphrase. But that didn't fix the problem.

I am no expert (still don't know how it got fixed).

Try a couple of things:

  • Clear DerivedData
  • Clear ~/Library/Caches/org.swift.swiftpm (I am not sure I did this, but check with others)
  • Try to clone your project on a new location
  • I am using Xcode 14.2 (not sure if this matters)

The quickest (still sad) workaround that works 100% of the time for me with the reference 'refs/remotes/origin/main' not found (-1) error is File -> Packages -> Reset Package Caches. Nothing else required.

And FWIW, I get into this bad state when running swift build on the command line and also edit the same project in Xcode.

I know it's sad but with two separate checkouts, one where I swift build and another one that I edit & build in Xcode prevents this from happening for me. Let's hope for a fix soon.

1 Like

For my team and the original poster, it's updating dependencies that is troublesome, not resolving dependencies (although resolving is still not 100% reliable). Resetting the package cache doesn't opportunistically update dependencies (nor do I think it should), so it's a workaround for resolves but not updates. When update operations fail (which is pretty much always for all but one of my team members), we update the minimum version of the dependency's rule to the desired version. That results in a resolve operation that still has the effect of updating the dependency. It's heavy-handed, but works. And if that resolve fails, package cache reset will fix it.

It seems like perhaps the skip-cache-on-error improvement that was made to the resolve operation in Xcode 14.1 wasn't applied to the update operation?

Update on this issue: recently one of my colleagues discovered that the script in this Stack Overflow answer fixes the problem.

I had seen this answer before, but I never tried the script, because the author first suggests deleting derived data and the SPM cache, which does not work for me. But evidently there is a difference in the more precise deletions the script makes, because it has solved the problem for everyone on my team that has tried it.

3 Likes

Still happening as of Xcode 14.3 when you depend on branch or tag using git URL.

This has nothing to do with the ssh keys. It is simply a bug in either Xcode or SPM since adding the package works initially, and it also works after Reset Package Cache is invoked from Xcode.

2 Likes