dotnet restore nuget source warnings in TeamCity .Net runners

Answered

When using the TeamCity built-in .Net runners we are getting a strange error about publishing the GitHub Packages.

- The runner can be the .Net Restore, or one of the other .Net runners that implicitly calls "restore" like "publish"

- If we run the command manually on the server we do not get the warnings.

- When we run the .Net runner with restore we get hundreds of warnings as follows:

"C:\Program Files\dotnet\sdk\3.1.402\NuGet.targets(128,5): error : Please use the --api-key and --source options when publishing to GitHub Packages"

We are receiving this error and cannot see why.

We previously had a GitHub nuget source added on the machine, but we have now removed this and cleared caches (AFAIK). Requesting the source list from nuget on the command line shows that the GitHub source is not present.

We believe it is a TeamCity issue because when we run the same commands as the same user on the same machine we do not receive these warnings.

The step(s) causing this issue are "dotnet restore" and "dotnet publish" steps that should not even care about publishing to GitHub packages and so shouldn't show this warning.

We have a "dotnet nuget push" step further down that we use that is working as expected.

We also have been using /warnaserror on our "publish" step which causes the build to error and fail, but removing this flag is also not ideal.

This problem seems to have appeared in the last couple of days. I cannot determine when I last updated TeamCity so I am not sure if it coincides with this issue.

 

Any ideas?

4 comments
Comment actions Permalink

By way of a test we have removed the TeamCity dotnet build step and run "dotnet publish" using a command line runner (copy-pasting the parameters)

This works as expected.

0
Comment actions Permalink

What version of TeamCity are you using? Would you be able to share a screenshot of your .NET runner settings with the 'restore' and/or 'publish' command so that I can try to replicate your issue?

0
Comment actions Permalink

Hi Eric,

We are using TeamCity Enterprise 2020.1.5 (build 78938)

We weren't using the step directly but had it included in a metarunner.

The XML of the metarunner was something like this I believe (I no longer have the exact XML)

 

<runner name="Publish" type="dotnet">
<parameters>
<param name="args" value="/warnaserror /p:TreatWarningsAsErrors=true /p:Version=%GitVersion.SemVer% /p:FileVersion=%GitVersion.AssemblySemFileVer% /p:AssemblyVersion=%GitVersion.AssemblySemVer% /p:PackageVersion=%GitVersion.NuGetVersion% /p:InformationalVersion=%GitVersion.InformationalVersion% /p:repoUrl=%env.RepositoryUrl% /p:repoBranch=%env.RepositoryBranch% /p:repoCommit=%env.SourceRevisionId%" />
<param name="command" value="publish" />
<param name="configuration" value="%configuration%" />
<param name="dotNetCoverage.dotCover.home.path" value="%teamcity.tool.JetBrains.dotCover.CommandLineTools.DEFAULT%" />
<param name="framework" value="%framework%" />
<param name="outputDir" value="publish/%configuration%/%framework%/%runtime%/%project%" />
<param name="paths" value="%project%" />
<param name="runtime" value="%runtime%" />
<param name="teamcity.build.workingDir" value="src" />
<param name="teamcity.step.mode" value="default" />
</parameters>
</runner>

 

Our parameters were:

%project%: name of the project folder

%configuration%: Release

%framework%: netcoreapp3.1

%runtime%: win-x64 or linux-x64

All the other parameters passed in "args" are most likely not relevant to the issue as they were always different versions etc.

 

I think the main step to reproduction is the fact that we had another step outside this one that would try and add and remove a nuget source.

Namely, we would run `dotnet nuget remove source --name "GitHub"` and then `dotnet nuget add source https://<our github packages url> --name "GitHub" --username <username> --password <password> --store-password-in-clear-text` while we were pushing our packages up to our nuget feed.

We now know that this was incorrect as it would confuse concurrent builds with the source being added and removed out of sync. There were better commands available to allow pushing to the custom source.

However the problem would arise that all of our restore steps when using TeamCity Net runners would try to use this nuget source whether it was added or not. It felt as if it was cached somewhere.

We tried manually removing the source (using the `dotnet nuget remove source` command above), and then running our builds but our restores would continue to fail. Listing the nuget sources would correctly show 2: the main nuget source and our own TC source.

The only difference that I can see between using the TeamCity Net runners and using the raw `dotnet` command line as we do now is the fact that TeamCity adds in an RSP file with a bunch of additional commands and parameters when it runs. I suspect that in there it may have still been picking up the old nuget source, and trying to use it for every `dotnet` command including `restore` despite the nuget source not being added or applicable.

 

If you require any more information please let me know. I apologise if this is a little convoluted for a reproduction.

0
Comment actions Permalink

Hello Mike,

I have just checked with the development team that TeamCity calls should not explicitly save any NuGet sources on per-user configuration file except for the TeamCity internal feed if it is in use. Just to double-check, could you please let me know if 

dotnet nuget list source

executed under agent identity on the agent machine returns the GitHub NuGet source? The source being present on the TeamCity user-specific configuration is the only reasonable explanation we have so far. 

0

Please sign in to leave a comment.