Accessing hidden teamcity artifacts - powershell

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.

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

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.

Related

Need help on publishing xml report with the plugin parasoft findings in TeamCity

I added a build step for my project in teamcity which consists on using the plugin Parasoft Findings to publish an XML report of all the code violations. the problem is that teamcity is failing to parse XML report. It says there is an unexpected report format and to see log (which I couldn't find).
I already checked the report location pattern which is right. I don't use SOAtest but C++ test so I only put "Parasof analyzers 10.x" for the report type
I'm sorry but you did not provide any additional details regarding your question and it's hard to help you.
Please, provide:
error message
your configuration of build step and version of TeamCity and C++test
command line used to start C++test ( if you are using variables,
replace variables with real values used in your run)
By log I think, you should check your build step log, and provide us the right content.
You can find such logs on two different ways:
You can download it by clicking "Download full build log" on build
log page (Recommended).
Try to find the raw output from the build agent by looking in the
agents logs directory, for example in
c:\TeamCity_dir_agent\logs\teamcity-build.log
Following article from JetBrains' TeamCity manual might good point to start
Edit:
Parasoft updated the plugin which fixed the issue:
https://plugins.jetbrains.com/plugin/9949-parasoft-findings
I have the same issue. Error messages in build log:
Unexpected report format: <path-to>\report.xml. See log for details.
Failed to parse XML report
Failed to parse XML report
Step test results (Parasoft Findings) failed
teamcity-agent.log and teamcity-build.log are having no entries within this build step because there is no piece of code which would write that into during this error case.
Edit/Workaround:
In the report the node <ExecutedTestsDetails> must be below the node <Exec>. The node still has the right indendation but it is at the same level as <Exec>. The xsl of TeamCity Plugin works perfectly if you fix the report xml manually.
To make it work you can add the Build Feature "File Content Replacer" like that:
Regex: (?s)(<ExecutedTestsDetails.*?<\/ExecutedTestsDetails>).*?(<Exec.*?>)
Replace with: $2 $1

PowerShell script builds the wrong path in TFS2017

I am adding a PowerShell script to run in my build to get the Version Number for the build. When I use the builder(Box with ...) to get the file, it takes me to my TFS Project and I work my way down to the file. When the build definition runs it fails at that step, because it cant find my script.
What it has done is prepended the local Servers work directory to the front of the Path it had me choose.
I feel this is a Bug or how am I suppose to get the most current copy of a script in TFS when the Build Definition runs.
Tried with a simple powershell script on my side, but couldn't reproduce your issue, the script is working.
Only add one step in build, and map to $/teamproject in Repositity, then select the script:
To narrow down the issue, you could create a new pipeline with only one task-Powershell, check what will happen.
If you still get error, please share detail logs with system.debug=true enable.
Also take a look at this tutorial about how to use powershell fetch/change build number, which may helps-- Use a PowerShell script to customize your build pipeline
Update
According to your error info, you are lacking of the definition.
Please make sure you have specified the value in options--build number format
$(BuildDefinitionName)_$(Year:yyyy).$(Month).$(DayOfMonth)$(Rev:.r)
Then it should run without any problem:

TFS 2015 Build step Nuget Publisher "Ambiguous option 's'"

OK, so we're stuck on on-site TFS2015 at the moment. My Nuget Publisher build step is failing with:
##[error]Ambiguous option 's'. Possible values: Source SymbolSource SymbolApiKey.
It appears inside the build step they have put -s instead of -source, and in later versions they've added more commands starting with s. So what are my options?
Write my own in Powershell (Can do, but TFS Build is very clunky for this)
Find wherever this is defined in TFS (hopefully a template .ps file) and fix it there (Anyone know where this is kept?)
Upgrade to a later version of TFS (a fairly large, but perhaps inevitable undertaking)
Somehow override the -s command another way?
????????
Invoke NuGet.exe however you'd like via the Command Line task
If you did #3 (upgrade TFS), you'd find that the PowerShell build task can run an in-line PowerShell script, making it significantly less clunky.
You may be able to extract and modify the task with the tfx command line utility, but I can almost guarantee this will have nasty ramifications when you do eventually upgrade.
I'm adding my answer for details about step 5 maybe it will help team that are still using TFS 2015.
Nuget Publisher seems to use old version, which means "-s" option will not work.
To bypass this situation you can setup your build as follow:
1- Add Nuget Packager Step and specify the the Package Folder value:
2- Add a new step which would copy your artifacts(Note that contents that should be copied must end with nupkg):
3- And Finaly you can just run a command line that will perform the publish operation. In my case we are pushing the whole repository using init command(PackageRepository is the path to our internal feed that we set in we've set in Variables section):

Microsoft.Quantum.Canon.nuspec missing

I am playing around with Microsoft's Q# library, and I've gone through the install, however the build is failing and I am having a tough time figuring out the problem. My first suspicion is Microsoft.Quantum.Canon
EXEC : error QS1001: Assembly E:\Projects\Quantum\Microsoft.Quantum.Canon\bin\Debug\Microsoft.Quantum.Canon.dll not found
I also have noticed Microsoft.Quantum.Canon.nuspec is missing. I've tried to do a Nuget.exe restore on the solutions but that did not work.
Has anyone worked through this?
It's been reported on GitHub already, although it appears to be intentional. See the comments in the .gitignore file:
# These files are generated by bootstrap from a .v.template (version template).
# Any changes must be done to the corresponding the .v.template file directly
Microsoft.Quantum.Canon/Microsoft.Quantum.Canon.nuspec
I can't find any info on this .v.template file, probably it's part of internal Microsoft build tooling. You can copy the template file and fill in the missing parameters if you wish, but the file not existing doesn't make the build fail , does it?

Build error with PostSharp 2.1.6 (NuGet)

I am evaluating PostSharp for a new project but cannot seem to get past the following error when I first build the project after changes:
Cannot copy file "C:\SourcePath\Output\Debug\MyApp.vshost.exe to
obj\Debug\Before-PostSharp\MyApp.vshost.exe: the file is locked by
process(es):MYAPP.VSHOST (8064)
The error only occurs in the first build attempt. If I immediately re-build, the error does not occur. I can only guess this is because the project isn't actually being rebuilt the second time.
I've read a few posts in the SharpCrafters forum that indicate this problem existed prior to v2.1 but was reportedly fixed. I am using v2.1.6.14 from NuGet (in VS 2010) and getting this error for every project I reference PostSharp. It is certainly not reasonable to require 2 builds every time, so I'm looking for a possible solution. I'm really pleased with what I've seen thus far but will have to go another direction if that can't be resolved.
UPDATE
Per Gael's request, I generated the diagnostic build log and sent it to him and it looks like he was able to resolve the problem in the latest release (2.1.6.14).
I believe part (or all) of the issue may be due to the fact that the build output for all of my projects is set to a common location (i.e. not the /bin/debug folder under each project). This is because we are using a MEF DirectoryCatalog which will discover Imports and Exports contained in the assemblies located in the output path. The PostSharp.targets file has the vshost.exe file excluded from the copy operation but only when it shares the name of the output assembly. In my case, the vshost.exe file has a different name and was, therefore, not being excluded.
The issue has been re-fixed in PostSharp 2.1.6.15.