Closed ryangribble closed 6 years ago
@ryangribble Can you switch to SourceLink.Create.CommandLine
instead of SourceLink.Create.GitHub
. That will avoid any problems with dotnet-sourcelink-git
, which I'm guessing that you are getting.
OK that seems to have sourcelink'ed correctly, but getting a runtime errror on the "test sourcelink" build step, because our TravisCI image only has the 2.0.x runtime on it, and this task is wanting runtime 1.0.4.
Where is the "runtime" for a DotNetCliToolReference
specified, when the tool reference comes from a netstandard
targeted library? Is this because "your" package requires 1.0.4, or because "my" project is still targetting netstandard1.1
? Ultimately Im trying to have our SDK tooling updated to 2.0.x but still keep our library targeted at netstandard1.1
although Im not sure if that's going to be possible
Could this same situation also have been the issue being experienced with the SourceLink.Create.GitHub
option previously?
... just discovered that VS2017 doesnt update DotNetCliToolReference
entries itself... so still had 2.1.0 of those, prior to you supporting a netcoreapp2.0
runtime as well. With that change in place, things are working using the CommandLine
rather than GitHub
sourcelink. Although it would still be nice to know why the GitHub
one doesn't work on linux/OSX for us...
Succesful run: https://travis-ci.org/octokit/octokit.net/jobs/354289022
Argh! Spoke too soon š¬
Succeeded on Linux, but sourcelink test failed on OSX https://travis-ci.org/octokit/octokit.net/jobs/354289023
OK so that OSX failure was weird... retried it and it then passed š¤ Tried another time and it failed again. I might raise a separate issue to look into that sourcelink test issue, because in terms of this issue I think I have all the answers I need.
So now that SourceLink.Create.CommandLine
was working I figured I'd go back and try SourceLink.Create.GitHub
and lo and behold it is now working too š
To sum up:-
My issue was using an earlier version of SourceLink that didnt offer a netcoreapp2.0
target. Furthermore when updating to the newer version I didn't realise that the 2 DotNetCliToolReferene
entries are not updated by VisualStudio and have to be done manually in the csproj file.
Finally, the fact it was a "couldnt find runtime" error the whole time, was only revealed when I got up to my "Test Sourcelink" step (by getting past the build stage by using COmmandLine
rather than GitHub
option), and could see that error output. The SourceLInk.Create.GitHub
method internally runs a dotnet sourcelink-git orgin
tool command and was evidently getting this runtime error too, but the logs just say the step failed and didn't provide the actual reason (was looking for runtime 1.x)
Thanks for the pointers and I'm happy to have both resolved the problem and have a better understanding of what was going on! š
Howdy @ctaggart,
I am fighting with a real doozy over at https://github.com/octokit/octokit.net/pull/1738 at the moment š¤
Background
Until now, our core libraries have been targeting
netstandard1.1
and our test projects werenetcoreapp1.0
, with the .NET Core SDK 1.0.4 being used to do the builds on AppVeyor and TravisCI (Linux and OSX).Due to some changes on that PR I had to update our test projects to
netcoreapp2.0
and change our builds over to .NET Core SDK 2.0.3 (core libraries are still targetingnetstandard1.1
).Problem
The AppVeyor windows builds are working fine, however both linux and OSX builds on Travis are failing with a SourceLink issue:
Logs
Here is a TravisCI linux build with "detailed" verbosity on the
dotnet build
step https://travis-ci.org/octokit/octokit.net/jobs/353796760 And here is one with "normal" verbosity which still shows the sourcelink error https://travis-ci.org/octokit/octokit.net/jobs/353817606Things Ive tried
Ensuring the
origin
remote does existI thought perhaps travis was doing something weird with the way it clones the git repo and there might not be an
origin
remote, however I added a debuggit -v remote show origin
command to the .travis.yml and the output in the build log shows theorigin
remote is as expected.Disabling SourceLink
Passing
/p:SourceLinkCreate=false
to the build step, which allowed the build to complete successfully (see log). Although it technically doesn't matter if we SourceLink on Travis (since it's the AppVeyor builds we publish to NuGet) I'd still like to get to the bottom of this!Updating to latest version of SourceLink packages
We were previously using 2.1.0 and have now updated to 2.8.0. It was a long shot but figured I may as well try... no dice though š
Any insights you have would be much appreciated! š
Thanks!