nupkg downloaded from NuGet feed into the working folder of second TC instance
Answered
We have 2 TC instances (local TC and second TC), in a local instance we have only a Build step, and that is generating a .nupkg.
From this local TC NuGet feed we want to take that packet and use it into second TC server, and from here to publish and deploy to Octopus.
We are encountering some difficulties in using the .nupkg generated, and use that into the second Team City server, because the nuget pack is not downloaded into the working folder of the second TC server, it's only in the NuGet feed.
We get this error on the second TC server: <Failed to find files to create packages matching: [ *.nupkg] under C:\BuildAgent\work\36db94a2ba9df36a.>
Basically we need that .nupkg downloaded from NuGet feed into the working folder of second TC instance, in order to be able to deploy it in Octopus.
We tried with NuGet restore, but seems like not a good solution for us, because we don't have a .sln at this point, only after the pack is being used we create the .sln.
Do we have other options?
Thanks in advance!
Please sign in to leave a comment.
It should be possible to publish the nupkg as an artifact of the build, then download said artifact from the second server directly, maybe using a command line step. More information on how to download it here:
https://confluence.jetbrains.com/display/TCD10/REST+API#RESTAPI-build_artifacts
This is a good idea Denis, and checking the article you shared, we are now trying to download the artifact, but somehow not using the build_locator from the GET command, because that is not too convenient. We need to download this but more or less based on maybe the artifact name, because it will be an recurrent action. Saw that build locator is using build ID or build number. Thanks
Hi Dorin,
please check here for further possibilities: https://confluence.jetbrains.com/display/TCD10/Patterns+For+Accessing+Build+Artifacts, although the REST API is still the recommended way to go. A build locator doesn't strictly have to be an ID, it can be any combination that eventually identifies a build (for example, build Type, dates, etc).
Downloading from artifact name isn't realistic in a number of scenarios as it's expected that basically every build ran on a given build configuration will produce artifacts with the same name over and over (unless the artifact includes the build number), and previous results are kept unless explicitly configured not to, so accessing via filename still would require some sort of build location.
Hope this helps
The artifact name does contain also the build number, so for eg. for build no. #0.0.24, the artifact obtained name is: Azure.0.0.24.nupkg, so this is why I wanted to download it based on the name, and maybe to use a wildcard: Azure.*.nupkg. I am checking also the second article that you send, this is very interesting also, could apply somehow to what we need