1

So, the key element here is hidden artefacts, also known as those that appear under .teamcity/ part of the build artifacts.

Some context: We currently run dotCover over our NUnit Test step to report on our test coverage. This places a compilation of the results in a file named CoverageResults.xml under .teamcity/.NETCoverage/. This is the file I would like to accces so we can mine if for some data and send it to a gecko board.

Now, so far, we can successfully get at artifacts not in this part of the directory (such as the result of the build when we output it, etc) using the advised methodology. The problem only occurs when accessing this hidden directory.

The other odd things is the response: a 302 Temporarily Moved.

For reference, my link looks like: (in powershell btw)

"http://{0}:{1}@{2}/guestAuth/repository/download/{3}/.lastFinished/.teamcity/.NETCoverage/CoverageReport.xml" -f $serverURl, $gUName, $gPassword, $buildType

Does anyone have any advice on accessing hidden artifacts? Where else this data could be drawn from (we've found nothing on system variables for this)?

Note: We are already aware that these artifacts are not produced till the build step completes. We are doing this after the fact against a completed build, not during the Build Job itself.

Kira Namida
  • 279
  • 3
  • 16
  • You could always access it from the TeamCity drive, if you have network access. If you want the most recent, it should be reasonably easy to find, even with TeamCity's crazy numbering scheme. – Rob May 29 '15 at 14:49
  • Unfortunately, I do not have direct access to the box. I could change gears and look at doing this on the box directly but for a list of reason I shalln't bore you here with, it's not Plan A. That being said, I may look into that seeing as the way we would currently like to do it (from an external source) is not particularly forthcoming. – Kira Namida Jun 01 '15 at 10:37

2 Answers2

0

If you add this in the Artifact Paths field it will attach the report as a build artifact once the build has completed

%system.teamcity.build.tempDir%\**\CoverageReport.xml

Hope this helps

Matt
  • 3,684
  • 1
  • 17
  • 19
  • Okay, this has put is onto what we hope is the right track but we've come up against a bit of a speed dump. Using both `%system.teamcity.build.tempDir%\**\CoverageReport.xml` and `%system.teamcity.build.tempDir%\**\CoverageReport.xml => CoverageReport` (as well as some variations thereof) persist in placing the file in: `CoverageReport\coveragezip\CoverageReport.xml` where the guid appears to a reference to the agent generated per build job. We can find no reference to this guid in the build params to use in looking it up again. Any experience with this? – Kira Namida Jun 08 '15 at 14:54
  • Are you trying to reuse the artifact in another step? If so you could rename it in the artifact dependencies (or unzip it). Rename *.zip => a.zip. Unzip *.zip!CoverageReport.xml => CoverageReport.xml. (Something like that - untested) – Matt Jun 08 '15 at 16:10
0

Leaving the solution we came up with in case it can be help to anyone else:

In the end, we never got the nitty-gritty of the why but in short, using the in URL authentication with Powershell's Invoke-WebRequest does not work. It appears this is culled from the request created or some such but we went in another direction so I cannot comment much more on this.

What we did do was instead, use cURL. This does not do whatever Powershell does so we simply broke this down into two steps on the Team City Build. A command line step to use cURL to download the file and place it in a temporary directory and the a Powershell step afterwards to get the file and do what we wanted to do.

Kira Namida
  • 279
  • 3
  • 16