-
Notifications
You must be signed in to change notification settings - Fork 1.4k
Move the 'GitRepositoryProvider' to compare urls using their canonical representation, correctly accepting results where repositories only differ by '.git' #7741
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
…l representation, correctly accepting results where repositories only differ by '.git'.
Im gonna pre-flight what I think @MaxDesiatov will say: "Could you add some tests for this?" |
Yeah, we definitely need tests for this before merging. |
The motivation for local dependencies makes sense to me, but I don't think it's correct to ignore schemes and path extensions here, the whole purpose of the validation was to make sure that we have the "correct" repo. If we're now not doing that anymore, it might make more sense to remove the entire validation logic. |
TBH I'd be fine with this - the repository cache seems like the correct layer to validate this. Otherwise we're just going to run into issues where the cache says the repositories match, but this validation disagrees). EDIT: Though thinking about it more, this does check that the directory is at least a valid git repository + that the underlying origin maps (in our canonicalization sense). Which is better than not doing that at all. |
return CanonicalPackageURL(remoteURL) == CanonicalPackageURL(url.absoluteString) | ||
case .path(let absolutePath): | ||
// Compare the canonical representation, which will drop any suffix | ||
return CanonicalPackageLocation(remoteURL) == CanonicalPackageLocation(absolutePath.pathString) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I doubt this matters in practice, but the caching logic always uses URL and it's probably better to do that here as well. That wouldn't fix the case mentioned in the description, but to fix that you could update computeCanonicalLocation
to return a file
scheme if one wasn't given (which seems somewhat reasonable given we're already inferring ssh
if the user is git
). Does that seem fine to you @neonichu?
@swift-ci test |
…ider. Clarified the API surface and reduced the change to only ignore path extensions for local (path-based) dependencies.
…eintroduced the 'RepositorySpecifier' and moved to using 'CanonicalPackageURL', where paths now have a scheme of 'file'.
public var url: String { | ||
public var url: CanonicalPackageURL { | ||
switch self.location { | ||
case .path(let path): return path.pathString | ||
case .url(let url): return url.absoluteString | ||
case .path(let path): return CanonicalPackageURL(path.pathString) | ||
case .url(let url): return CanonicalPackageURL(url.absoluteString) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why this change 🤔?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I removed this, it wasn't necessary.
@@ -89,74 +89,6 @@ private class MockRepository: Repository { | |||
} | |||
} | |||
|
|||
private class MockRepositories: RepositoryProvider { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was unused.
@swift-ci please test |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
IMO the change seems noteworthy enough to be included in CHANGELOG.md
?
I was preparing my own PRs for this issue, but this one is much further along. Great work @francescomikulis! One question I had was: Would it make sense to canonicalize the origin URL before populating the cache? As it stands now, whether the cached repo uses |
…ension." This reverts commit 8e2691e.
@swift-ci test |
@swift-ci test windows |
I agree that we should try and ensure that the underlying cache is populated with expected values, matching the new validation logic in the GitRepositoryProvider. |
…sitories that aren't yet checked out, even though the InMemoryFileSystem claims the directories exist.
@swift-ci please test |
@swift-ci please test Windows platform |
…l representation, correctly accepting results where repositories only differ by '.git' (#7741) Resolving local package dependencies often outputs a warning: <path> is not valid git repository for '<repo>', will fetch again. The underlying issue is that updating packages with a local SCM path dependency always fail, as the shell-based repository URL has a file:// scheme, while the absolute path string does not. After this change we only compare the canonical URLs, which will resolve the inconsistency of comparing strings without considering the scheme and / or path extension. Validating the origin of checked-out repositories no longer ensures that the path extension (often .git) matches the repository's specifier, as different git clients inconsistently preserve the path extension of the remote. Moving to the CanonicalPackageURL also ensures that absolute paths are treated as urls with a file:// scheme, matching git's behavior.
…l representation, correctly accepting results where repositories only differ by '.git' (#7741) Resolving local package dependencies often outputs a warning: <path> is not valid git repository for '<repo>', will fetch again. The underlying issue is that updating packages with a local SCM path dependency always fail, as the shell-based repository URL has a file:// scheme, while the absolute path string does not. After this change we only compare the canonical URLs, which will resolve the inconsistency of comparing strings without considering the scheme and / or path extension. Validating the origin of checked-out repositories no longer ensures that the path extension (often .git) matches the repository's specifier, as different git clients inconsistently preserve the path extension of the remote. Moving to the CanonicalPackageURL also ensures that absolute paths are treated as urls with a file:// scheme, matching git's behavior.
Motivation:
Resolving local package dependencies often outputs a warning:
is not valid git repository for '', will fetch again.
Modifications:
The underlying issue is that updating packages with a local SCM path dependency always fail, as the shell-based repository URL has a file:// scheme, while the absolute path string does not.
Result:
After this change we only compare the canonical URLs, which will resolve the inconsistency of comparing strings without considering the scheme and / or path extension.
Validating the origin of checked-out repositories no longer ensures that the path extension (often .git) matches the repository's specifier, as different git clients inconsistently preserve the path extension of the remote. Moving to the CanonicalPackageURL also ensures that absolute paths are treated as urls with a file:// scheme, matching git's behavior.