Due to some mistakes I made in configuring some builds my Teamcity nuget feed has the wrong artefacts in some of the feeds. How do I purge the feeds so I can restart them from scratch?
Buried in the Using Team City as a NuGet Server section at this link, you'll find the following text:
"If the build artifacts are changed under TeamCity Data Directory manually, you need to instruct TeamCity to reindex NuGet feed. For that, click "reset" link for "buildsMetadata" under Administration > Diagnostic > Caches."
you can use nuget command line:
list
nuget locals all -list
clear
nuget locals all -clear
you can even run it as build step...
Related
We have a TeamCity build server and for a time were had the internal Nuget server enabled. We'd generate Nuget packages, which it'd automatically publish to the nuget feed.
We've since moved to another Nuget server and disabled the TC internal Nuget server; additionally we started building Nuget packages using OctoPack in some configurations which never built them before. The problem is that these Nuget packages seem to automatically be added to the build configuration's Artifacts. This is a waste, since the same packages are being published to the external (to TeamCity) Nuget server.
Is there a setting which automatically will find and include Nuget packages in TeamCity's artifacts, or is it just doing this on its own? I cant even explicitly exclude the packages in the configuration's artifacts setting, they get included regardless.
TeamCity is version 2018.1.2.
New packages in built-in TeamCity NuGet feeds could be added via the followings ways.
So to avoid publishing produced nuget packages as a build artifacts inspect:
Artifact paths settings in your build configuration
NuGet Pack build steps settings: uncheck "Publish created packages to build artifacts" option
NuGet Publish build steps settings: don't specify TeamCity built-in NuGet feed URLs in "Package source" field.
I need to update package repo before building a solution in TFS Build Definition. I want to implement this using CommandLine build task.
Could someone tell me how to write a command to update package repo using a path.
According to your prior question, there are just missing some external packages during your TFS build pipeline.
Usually TFS use Package Management that hosts NuGet, npm, and Maven packages alongside all your other TFS assets: source code, builds, releases, etc, also be able to handle the external packages.
You could directly add external packages to a TFS Package Management feed. When you restore the packages, select the feed. All need packages will be restored entirely. To achieve this, just use Push NuGet packages to specify the packages you want to publish and the target feed location.
More details please refer Get started with NuGet Package Management in TFS
I need to execute a command line utility from a package that is downloaded as part of nuget package restore in the TFS build process.
On my local computer that is stored in c:\users\me.nuget*
I've tried every permutation of that on TFS without success. I've also tried \mydir\packages with no success as well.
The biggest problem is that I have to run the package restore step before being able to see any sort of feedback from the log. That's some slow debugging.
Any ideas? Thanks ahead.
With the latest nuget/msbuild the packages folder is held under the active user's profile directory, so an appropriate Powershell command is
Get-ChildItem $(UserProfile)\.nuget\packages
This currently evaluates on the VSTS 2017 Hosted build agent to C:\Users\VssAdministrator\.nuget\packages but by using the variable you are insulated from any changes made.
Just an addition to #Paul Hatcher's answer:
I also faced the same problem in Azure DevOps build pipeline where a specific package and nuget packages directory could not be found.
It is a Xamarin.Forms app based on a .net standard library where no packages folder exists. I later noticed in build logs that the packages are restored to nuget folder under user's profile. However this particular case is not documented on https://learn.microsoft.com/en-us/azure/devops/pipelines/build/variables?view=vsts#agent-variables.
That means #Paul Hatcher's answer is also valid if you try to reference nuget package folder directly from your build pipeline. This ($(UserProfile).nuget\packages) should actually be a (standard) predefined build variable.
The Nuget package cache folder is in C:\Users\buildguest.nuget\packages, but it will be cleaned after build if you are using Hosted build server.
The simple way to verify:
Add NuGet restore or .Net Core Restore build step to restore packages
Add PowerShell build step to list files in C:\Users\buildguest.nuget\packages
Code:
Get-ChildItem -Path C:\Users\buildguest\.nuget\packages
Queue build and check the PowerShell step log (the packages’ will be listed in the log)
Remove/disable NuGet restore or .Net Core Restore build step > Save build definition
Queue build
The build will be failed, because the path does not exist.
So, the packages need to be restored before build solution/project if aren’t existing. You can add packages to source control and map to build agent to deal with the issue of too long time takes to restore packages.
I've got a build running in VSTS which is restoring NuGet packages from both nuget.org and a custom feed in VSTS. The custom feed is in the solutions NuGet.config as a <packageSource>, along with the user name and password in <packageSourceCredentials>
The build, including the restore, is working Ok, but there is a warning ...
2016-10-12T16:18:57.6589001Z ##[warning]To connect to NuGet feeds
hosted in your Team Services account/TFS project collection with
NuGet 3.1 or below, edit your build definition to specify a path
to a NuGet.config containing the package sources you wish to use.
How can I remove this?
Based on my test, that warning remains even through using higher version of nugget (e.g. 3.3) or do not restore package from VSTS feed. (Hosted build agent has the same result).
You can’t remove it unless you custom a build task to restore package through command line.
I submit a issue here.
Update:
The issue has been updated.
I see the issue in the code coming from our transition from depending
on assets coming with the agent to being deployed with the task. You
can get around this for now until we get an official change out by
either (1) choosing to use the Nuget 3.5 version radio button in the
task config or (2) supplying a path to your nuget.config.
So, you can use Nuget 3.5 version or specify nuget.config file.
Trying to use PowerShell's Publish-Module to upload a PowerShell Module to TeamCity's NuGet server.
I can use PowerShell with Find-Module to find modules that were added to TeamCity from previous build artefacts, but would also like to upload "manually".
On other NuGet Servers I am used to see the /Packages/ folder. Does that not exist on TeamCity?
Thanks.
TeamCity NuGet feed is readonly. The only way to publish a package is running a build and publish it as an artifact.