-
Notifications
You must be signed in to change notification settings - Fork 341
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
Revert "Revert "Update to February Servicing"" #14487
Conversation
This reverts commit 1cb6418.
@tmat There is an interesting regression here. For some reason, after the update to the latest SDK, the LocateRepository task is no longer able to determine the ScmRepositoryUrl of the inner cloned repo in SB. It would have been this change that altered things: dotnet/sourcelink@f6b97c9...94eaac3 Any ideas what happened here? |
More info (note the Arcade Repo: 8.0.101 (working)
Arcade Repo: 8.0.102 (not working)
VMR: 8.0.102 (working)
|
The VMR in 8.0.* copies rather than clones, IIRC |
@tmat - Can you investigate what might be the issue here? See #14487 (comment) |
Also seeing this in main now. @tmat Looks to be out right now. I'm inclined to put in a workaround so that we can get unblocked. Will look into it. |
I didn't get a chance to fix this, but the issue appears to be that the inner clone doesn't end up with a remote that matches the outer clone's URI. It appears that the sourcelink targets look for origin and then upstream. I think it probably has the correct behavior? Perhaps before, if there was no remote URI for inner clone, it kept looking up the directory structure. Two possible solutions include:
I think the first option one is better. |
Reverts #14486