Teamcity artifacts directory

Hi,

We have a TeamCity project which builds a solution made up of approximately 80 projects.

After the solution has been built, nuget packages are created for each of the applications to be deployed over Octopus Deploy.

Creating the NuGet packages alone takes around 20 minutes. It does this by creating the nuget packages in a directory within the TeamCity project and then publishing them to the TeamCity feed.

It would be really helpful if we could simply create the nuget packages directly to the teamcity artifacts directory to speed up build times.

If a variable was made available; e.g. %teamcity.nuget.artifacts.directory% that we could use to pack to.

We do have a multiple agent environment.

Is there currently a better way to achieve a performance improvement?

Kind regards,

Rik

0
1 comment

Hi Rik,

 

I don't think this is currently possible "as is", but there might be some ways, although please be mindful of the problems mentioned at the end. First, some issues to begin with:

-TeamCity's artifacts are not produced on the server, but on the build agents, which are often in a separate machine. This point is critical, as it means you still need to send them through the network anyways.

-TeamCity's artifact storage might even be on a separate machine to that of the server if using external storage. It might be on a cloud storage.

-Many of TeamCity's features with artifacts depend on the artifact publishing step to gather the metadata form the package. This might not impact you if you publish to the feed manually using the nuget publish instead of automatic collection of artifacts.

 

With this in mind, you could set up a local agent to the server, then have your nuget-generating builds run there (through agent requirements) and manually copy them to the storage folder. If you haven't modified it, it should be in the data_directory/system/artifacts/<project_id>/<build_config_id>/<build_id>/. You can gather all the data in the build and copy them.

 

Be mindful that this approach will severely impact TeamCity's performance, as the same machine would be running the server and build processes. TeamCity does need some resources to work and process everything, and build processes are usually pretty resource intensive, so it might lead to performance issues.

0

Please sign in to leave a comment.