Does TeamCity support the ability to move rather than copy artifacts?

My projects generate a very large amount of data from tests in a short amount of time by parallelizing across many machines. I would like to keep a few copies of the last runs around so that I can investigate problems when they occur (running a new instance could overwrite the files) but am wondering how to do that. My inclination is to store them as artifacts and setup a clean-up process to delete them quickly, though unfortunately it looks like the quickest I can get in practice will be once a day since that's the granularity of the clean-up process scheduler. I could probably live with it though but a bigger problem is how long TeamCity might take to copy the artifacts. Is there an option to have it move the files rather than copy them? It seems silly to generate the files in ~1 hour and then spend the next 3 hours copying them. Another option would be if TeamCity could provide a hook to write my own copy routine so that at least it could be parallelized to speed it up.

2 comments
Comment actions Permalink

Uri,

> Is there an option to have it move the files rather than copy them

Generally artifacts are copied from the agent machine to TeamCity server machine. Move will not help speed up the process here.

Theoretically, you can make your build script place the files right under .BuildServer/system/artifacts where TeamCity stores the files, but that should be done with care and is not recommended.

BTW, is reporting the tests via TeamCity means, so that they appear in build status, build's Tests results, etc. an option for you? That might be problematic indeed, if the number of tests or failed tests output is huge.

0
Comment actions Permalink

Ok - that's pretty to close what I have now then (building and managing my own parallel artifacts directory). I was hoping to prune it.

The tests and their stdout are reported to TeamCity through a JUnit XML file. What's not returned otherwise are all the files written to the disk in the process of running the tests. These are really system and integration tests, which is why the file sizes are so big. The number of tests aren't all that high (up to 1k).

0

Please sign in to leave a comment.