Hey everyone. I noticed some discussions about introducing the registries from Tuist, but my situation involves using AWS CodeArtifact.
Unfortunately, it’s quite tricky to authenticate the runner in CI, and right now it’s getting stuck because system prompts are appearing.
The only solution I know of is to either unlock or delete the keychain or provide the packageAuthorizationProvider with a .netrc file for xcodebuild. Is this an option that has already been discussed?
Hey @ichikmarev
If I understood it correctly, SwiftPM, which Xcode uses to resolve packages, relies on a registries.json file (global or local) to obtain the list of registries along with their authentication configuration. Since the authentication features of the protocol are quite basic, you’ll have to add a step before compiling that logs you in, either using the aws CLI or swift’s to create the configuration file, and then xcodebuild should pick it automatically.
Unless I’m missing something, I think the need and solution happen at a level lower than Tuist, but I might be wrong.
@pepicrft Yes, this works that way, but when you have a private package, you need to authenticate it when resolving the packages.
In the Xcode UI (during the resolution), it will appear like this:
However, on CI, it will block the package resolution during tuist generate, as it will use xcodebuild -resolvePackageDependencies under the hood.
I am linking this issue, as it might be related: Fails to save credentials to keychain when using login command with token option · Issue #7236 · swiftlang/swift-package-manager · GitHub
The xcodebuild is trying to retrieve it from the keychain. However, in the linked thread, there is a discussion indicating that it doesn’t work. Some additional and unclear steps should be added to clean the keychain on CI, among other things
However new Xcode versions supports -packageAuthorizationProvider netrc which will help a lot to solve the issue
This is the piece that I was missing. We can add a new option here, additionalPackageResolutionArguments: [String] and mark clonedSourcePackagesDirPath and resolveDependenciesWithSystemScm as deprecated. That way you can pass any options that you wish, and you don’t depend on us adding/removing new APIs. How does it sound?
That sounds good. I will wait for it. It seems like a sensible and scalable approach!
Tried to resolve here feat(cli): Add additionalPackageResolutionArguments for xcodebuild by ichikmarev · Pull Request #8099 · tuist/tuist · GitHub
Just curious, why have you decided not to go down this path? This is what we recommend when using a Tuist Registry (or any other registry): Continuous integration · Registry · Features · Guides · Tuist – it doesn’t involve deleting a keychain, but creating a new, unlocked keychain and setting that as a new default. A lot of CI providers do this out of the box in macOS environments btw.
You could certainly pass additionalPackageResolutionArguments, but I’d argue that locally you still want to use a keychain instead of netrc as it’s generally more secure (and the default behavior).
I’m still aligned with the proposed API changes, though.
I am doing it right now, using a rather unconventional solution from the discussion I provided above. For some reason, the workaround is to unlock the keychain, delete it, and create it again. This is the only method that helps to disable the prompt completely
