Is there any way to generate the good error report from Cruise Control?
I like to get the following things in that report.
The line number of File that break the build
The name of developer who commited that file. (It should not be related to last person who committed because the build might be broken earlier before last person check-in. )
Thanks.
this should be doable with a bit of xsl parsing alone :-)
Needed steps :
Create the xsl file (blame.xsl for instance)
this xsl should look at the <modifications/> node and the <msbuild/> node to get the data.
Define a new xslReportBuildPlugin in your webdashboard.config pointing to the
new xsl file. Something in the likes of :
<xslReportBuildPlugin description="Blame"
actionName="BlameBuildReport" xslFileName="xsl\blame.xsl"/>
do an iisreset to activate it (just to be sure) and clear your browser cache
now you should see a Blame in every build report :-)
Custom report creation information
A custom xsl modification to bring the error info up to the top of the file - this would be helpful in applying the blame
Then if you add in thesteps from Williams' answer you'd have blame information.
You do already have the file/line number. CruiseControl.NET provides the detailed MSBuild report, which is nothing but the usual compiler output.
This would be only possible with an extension that is specific your the Version Control System. You would have to write such an extension by yourself (but I doubt that it's worth the effort...).
HTH.
Related
As seen above, there’s some error with the building of data table… Any help here?
Error message is as follows:
Creating dtData2: Type ‘UiPath.Core.GenericValue, UiPath.System.Activities, Version=20.4.0.0, Culture=neutral, PublicKeyToken=null’ is not allowed here. See https://go.microsoft.com/fwlink/?linkid=2132227 for more information.
2nd upload as per requested:
You might be using a .xaml file from a newer version of Studio. The BuildDataTable seems to be picky about that.
I encountered that mysterious crash on our production system after some third party developers made some code changes. I noticed the version of UIPath generic object in my crash screen was 19.10.x.x, and I know our Production and Test/Dev systems are on v18.x.
I suspected they sent us code developed in a newer version of Studio, or copied and pasted remotely from their Studio to ours and it happened to work (at least the pasting). I got a complaint from the users that the robot didn't work so they'd just do it manually until it could be fixed.
To "fix", edit the .xaml in Studio. Find the Build Data Table in the Activities and created a new code block. Since the Build command is so simple, needing only the output dt field, that might be the easiest option. I reran it in debugging with the new "BuildDataTable" acitivity and it didn't throw the exception. [I probably could've downgraded the genericvalue version number in the .xaml file, but I was already in Studio.]
You can also use "findstr" to search for the BuildDataTable commands from the .xaml file. The findstr or egrep command can show you the version of the genericvalue UIPath is trying to stuff into the empty datatable on creation:
<ui:BuildDataTable DataTable="[DetailDT]" DisplayName="Details Data Table"
xs:element name="Change_x0020_Type_x0020_Index"
...
msdata:DataType="UiPath.Core.GenericValue, UiPath.System.Activities, Version=19.10.1.0,
One of the nicer "features" of UIPath is their use of a sort of open format .xaml file for all the code storage. Using findstr or egrep has really helped find hidden problems spread across our large collection of folders. Their xaml is not as easy as merging code written in autoIt3 or AutoHotKey, as they have graphic screen size elements and block number tags embedded in it, but at least all the graphical code blocks aren't completely locked away in some compressed or OLE format as would be tempting for software that works (only?) on Windows.
Check your UiPath.System.Activities version. I had the same error with a DataTable containing another DataTable as a column. Basic datatypeas as string and int were no problem, but a DataTable threw the error.
I updated UiPath.System.Activities to 20.10.4 (from 19 something) and it worked after that. Also tried with 21.10.4 and that works as well.
I'm looking of a DTSX file that I didn't make, trying to get an overview of how it works. But I've noticed that every time I open up an Execute SQL Task or File System Task it checks out the dtsx from TFS. I haven't changed anything, so why does it always check out the file?
Because the dtsx file is overly burdensome and mixes UI and data/programming elements in the same backing file? winces
Without seeing the specific file, what I had noticed back when I used version control systems that subscribed to the checkout/modify/checkin pattern is that things such as package configuration, expressions, etc may get re-evaluated as you open tasks which I assume the TFS modify daemon in VS detects the file could get dirty and so checks it out to help you.
You'll also notice that if you run the package, sometimes it gets checked out and marked as modified. Which is totally fun as you get to play: what was I doing before I left my desk? Did I actually make a change or was I just looking?
Not helping matters is that the save action from visual studio always triggers two changes: version build (which is a monotonically increasing number) and the corresponding version guid.
Not an answer, but I can commiserate with your experience. The answer likely lies in the engineering minds in Redmond and was never publicly documented.
I am fairly new to TeamCity and have recently been tasked with creating various builds, which I have done with no real issues.
What I am trying to do now though is include an external text file into the build output.
The external text file will be received from a service call made during the build.
These are my intended build steps:
Check out solution.
Restore packages.
Run tests.
Call web service with a configurable parameter and receive text file back.
Include text file in build.
Deploy.
Steps 1,2,3 and 6 are covered.
What are my options here? I must confess I do not really know where to begin.
I've spent some time today googling but it has been tricky getting the correct search term to return information on what I am trying to achieve.
I've seen some confusing articles on a 'meta runner'.
Any pointers to get me started in the right direction would be much appreciated.
Thanks.
Use a TeamCity command line build step - https://confluence.jetbrains.com/display/TCD9/Command+Line
I assume you are using build steps for all the other steps you listed so this is simply another of those.
The command line process would run somewhere under your checkout folder and thus anything it downloads would be made available as an artifact for your build
These days, I have started learning to write enterprise level code and started to follow open source codes. Apart from the readability to have comments in the code, I liked having author name in the code/file which I write.
Do we have any plugin/macro/extension which will automatically add my name and email id in the beginning, to the files which I create in visual studio.
Any plugin or process to generate a template for comments too automatically, automatically cause i can bother less on the template and can bother mmore about the description is much appreciated.
Apart from the readability to have comments in the code, I liked having author name in the code/file which I write.
Why? What useful information does it provide, which can't be better ascertained elsewhere? I've always found it a pain, personally - it gets out of date so quickly when other maintainers are involved, and it just clutters up the code.
Any decent source control system will show you the history of a file including who's behind each commit, and also show an annotated version of the file to show which commit last edited each line. Both of these are far more useful than hand-written, out-of-date annotations which are irrelevant when actually writing code.
I'd strongly advise you to stop even looking for such a feature.
My team has a goal to minimize the amount of time that our build is broken.
We use CruiseControl.NET for continuous integration. What I'd like to find out is how best to approach answering the following question:
"In the last {timespan}, how much time has {project-name} spent in a broken status?"
For example:
"Over the last 1 month, how much time has our project spent in a broken status?"
Are there any advanced features of CruiseControl.NET that would facilitate making this information available in some type of a report or somewhere in the dashboard?
Alternatively, how would you approach parsing the xml artifact files to glean this info?
you can use the statistics publisher,
http://www.cruisecontrolnet.org/projects/ccnet/wiki/Statistics_Publisher
and you can display them via project statistics plugin
I see at least two ways to approach this:
You write an external tool which parses CC.NET's XML log files for a project (stored in buildlogs subdirectory by default), calculates statistics and writes a HTML report. This is probably easier to do, but it won't be directly integrated with CC.NET.
You write a CC.NET plug-in to do this. You'll need to do a bit of investigating in this case. My guess the starting point would be to look at the source code of some existing plug-in.
Here are some links about CCNET plugins:
http://www.cruisecontrolnet.org/projects/ccnet/wiki/DevInfo_MakingPlugins
BrekiLabeller - my own plug-in, useful if you want to see how a plug-in can be implemented.
Having had a very quick look at the CC docs, I imagine if you were writing your own Cruise control dashboard, you could consume the RSS feed of build results, parse in all the date times and success/failure states up to your threshold, then sum up the totals.
As for displaying it in a dashboard, I think Cruise Control has a plugin architecture which might help http://cruisecontrol.sourceforge.net/main/plugins.html
So my eventual solution wasn't ideal, but it was easy to do and it works:
I had CC.NET send build emails to an email address (we'll call it build_emails#build_statistics.com). Then I use a ruby script to get the emails via imap and process them to determine our build failure time.
I didn't go the route of directly parsing the xml because I would have had to parse every xml file in the timeframe to build up a timeline and then go over the timeline to make my calculations. It just seemed too complicated to get a simple statistic like this.
I like cc.net, but in this case TeamCity just does this for you. It has lots of other great statistics too. It's free for less than 20 projects.