Once your build is finished, how do you get the data out of it?
In TeamCity, you can do that easily with the help of artifacts. In this tutorial, we’ll take a closer look at how to work with artifacts in TeamCity.
Any file that your build produces is a potential artifact, like a packaged application in a .jar or .zip file. After the build has finished running on the build agent, TeamCity will take those files and upload them to the TeamCity server UI, where you can access and review them.
Learn more about build artifacts in our documentation.
To get the data produced by your build, head over to Edit Configuration.
Under the General Settings tab, you’ll find an input field called Artifact Paths.
In TeamCity, the artifact path refers to the location where build artifacts are stored after a successful build process. Artifacts are the output files, binaries, or other important results generated during the build. The artifact path specifies the directory or folder structure within the TeamCity server where these artifacts are published and can be accessed.
In this example, we know that our build creates an artifact subdirectory, and we want to make every file from that subdirectory available. Specify the artifact path in the field and then click Save.
TeamCity has a built-in artifact storage. You can also connect an external artifact storage to work with TeamCity. Currently, TeamCity supports Amazon S3, Azure Artifact Storage, and Google Cloud Artifact Storage.
Now, once we run the build, we can see some changes. Previously, the artifact icon was grayed out, which means no user-identified artifacts were in this build.
The light blue icon indicates that TeamCity has successfully discovered and stored artifacts for this build. When we click on the blue icon, we can see that there are two files stored as artifacts – an application log and a Selenium recording.
You can also click on each file separately and review it.
The data on the build agents is transferred to the TeamCity server or, more specifically, to a specific storage. The storage could be in the cloud, locally, or anywhere you specify.
Not only is this data available on the TeamCity server, but it’s also available and ready to be passed through a build chain or several build configurations. For example, if a deploy job needs a .jar file from a previous build job, this file can be passed over with the help of artifacts.
In TeamCity, you can copy artifacts from one build to another using the “Artifact Dependency” feature. To do that, you need to configure artifact paths in the source build, configure artifact dependency in the target build, run the builds, and verify artifact copy. By setting up artifact dependencies, you create a linkage between builds in TeamCity, allowing for the seamless transfer of artifacts from one build to another.
Ready to start configuring artifacts? Check out our documentation, and feel free to reach out in case you have any questions.
This tutorial shows you how to use TeamCity to run command-line scripts that are the foundation of build pipelines.
TeamCity bundles a number of features that will supercharge your builds. In this tutorial, we’ll explore how to use specific runners and why you’ll want to use them.
This video covers configuring a build to produce and upload artifacts, running the build, and then downloading the artifacts via the TeamCity interface.
Learn what an artifact repository is in the TeamCity CI/CD Guide.