I'm interested in knowing which parts of my rake-based build (running within TeamCity) is slow. Is there an MVC-filter-style way I can wrap rake-tasks so that each one runs within a timer, and I output a breakdown of
time-spent on task including prerequisites (I guess the time between invoke starting and execute finishing)
time-spent on task excluding prerequisites (I guess the time between execute starting and finishing)
so that I can analyse which parts of my build are taking the most time, to target my optimisation efforts?
Does TeamCity have any features baked in that would do this for me? (I know I'll be able to chart the results of my performance-logging with custom-charts; I just wondered whether it could do this out of the box already.)
First, in TeamCity 6.0 there is a tree view of the build log. In this tree view you can see duration times spent for different blocks of your build.
Also, in TeamCity's rake runner, there is "Track invoke/execute stages" option, which can be enabled to get more information in your build log (and there is timing information for each record).
You can also try adding rake parameters like -t or -v in TeamCity rake settings to get more verbose output.
TeamCity also allows you to use custom service messages to provide more information to your log and to your build.
Hope this helps,
KIR
Related
I am downloading data from a remote server using curl in Build Phases > Run Script. Downloading takes 5-15s, not that much, but multiple times a day it consumes considerable time. Is there a better way to skip a script than commenting it out? Ideally, it would be some kind of confirmation at compile time (e.g Do you really need to download X? y/n).
You can’t make the run script interactive in the console as far as I know. But you can use a shell conditional with an AppleScript interactive dialog, because AppleScript itself blocks while dialog is shown. See for example https://cantina.co/adding-interactivity-to-the-xcode-build-process/.
However, introducing uncertainty into a build is dangerous. Plus you’d never be able to automate the build. In my view you’d be better off flipping a custom build setting / environment variable.
I have some Issues regarding Jenkins and running a Powershell Script within. Long Story short: the Script takes 8x longe execution time then running it manually (takes just a few minutes) on the Server(Slave).
Im wondering why?
In the script are functions which which invoke commands like & msbuild.exe or & svn commit. I found out that the script hangs up in those Lines where before metioned commands are executed. The result is, that Jenkins time out because the Script take that long. I could alter the Timeout threshold in the Jenkins Job Configuration but i dont think this is the solution for the problem
There are no error ouputs or any information why it takes that long and i do not have any further Idea for the reason. Maybe one of you could tell me, how Jenkins invokes internaly those commands.
This is what Jenkins does (Windows batch plugin):
powershell -File %WORKSPACE%\ScriptHead\DeployOrRelease.ps1
I've created my own Powershell CI Service before I found that Jenkins supports it's own such plugin. But in my implementation and in my current jobs configs we follow sample segregation principle rule: more is better better. I found that my CI Service works better when is separated in different steps (also in case of error it's a lot easy for a root cause analyse). The Single responsibility principle is also helpful here. So as in Jenkins we have pre- & post-, build and email steps as separate script. About
msbuild.exe
As far as I remember in my case there were issues related with the operations in FileSystem paths. So when script was divided/separated in different functions we had better performance (additional checks of params).
Use "divide and conquer" technique. You have two choices: modify your script so that will display what is doing and how much it takes for every step. Second option is to make smaller scripts to perform actions like:
get the code source,
compile/build the application,
run the test,
create a package,
send the package,
archive the logs
send notification.
The most problematic is usually the first step: To get the source code from GIT or SVN or Mercurial or whatever you have as version control system. Make sure this step is not embeded into your script.
During the job run, Jenkins capture the output and use AJAX to display the result in your browser. In the script make sure you flush standard output for every step or several steps. Some languages cache standard output so you can see the results only at the end.
Also you can create log files that can be helpful to archive and verify activity status for older runs. From my experience using Jenkins with more then 10 steps requires you to create a specialized application that can run multiple steps like "robot framework".
I am working with a VS2010 solution we have inherited. It has approx 300 projects. Medium term I will try to break this down into multiple solutions, but I can't do that immediately.
One immediate problem is that if I do 2 consecutive builds, the second still does a lot of work, which says to me that something is wrong with the "make" configuration. What is the best way of analysing the build config to determine incorrect dependencies or other problems?
Is there a tool for doing this or shall I try and make my own? Thanks.
(The solution was migrated through VS2005 and VS2008 before getting to VS2010 which probably didn't help the build config)
The 'lot of work' from the second build could be just actions in the PreBuild steps, which are always executed. Make sure you get at least 'normal' instead of 'minimal' build output (Tools->Options->Projects and Solutions->Build and Run). Just looking at the second output should give you the information you need. As far as I know there's no tool to compare to build log files, but it shouldn't be too hard to write it yourself.
I have a Jenkins job consisting of a matrix style configuration. I want to run a script that determines whether that combination should be run (similar to the combination filter, but dynamic). Thus setting the job to 'No Run' (grey) or running the rest of the scripts over it and producing a result.
Is there a way (or a plugin) to do this? In the event there isn't is there a way to set a job to 'No Run' once it has started running?
Cheers,
Stu
Edit: Discussion at:
http://groups.google.com/group/jenkinsci-users/browse_thread/thread/d99e865b17575e92/6c83ee0f894980fb?lnk=gst&q=dynamic#6c83ee0f894980fb
Suggests two plugins, but perhaps a pre script looking at the previous build is just as easy.
I've done the same things.
I can't do that in matrix filter feature because it's not dynamic.
So what I've done is to add to my build script 2 groovy (pre and post) which determinate if the build should be done or not.
The first script look for a old build execution log file to determine if the current build should be done or not and save the state in a file named disabled at the root of the workspace.
The build process only continue if disabled file is not present.
The second groovy script is to store that a particular build is done and store it for further execution and remove the file.
With this method, I can do a round-robin build of 50 configuration, 6 per day.
The only problem I add is that all build are launched so all are green, and we can't quickly see which build have been really done.
Regards,
Ludovic SMADJA
JALIOS - R&D
http://www.jalios.com
I've been using nosetests for the last few months to run my Python unit tests.
It definitely does the job but it is not great for giving a visual view of what tests are working or breaking.
I've used several other GUI based unit test frameworks that provide a visual snap shot of the state of your unit tests as well as providing drill down features to get to detailed error messages.
Nosetests dumps most of its information to the console leaving it the developer to sift through the detail.
Any recommendations?
You can use rednose plugin to color up your console. The visual feedback is much better with it.
I've used Trac + Bitten for continuous integration, it was fairly complex setup and required substantial amount of time to RTFM, set up and then maintain everything but I could get nice visual reports with failed tests and error messages and graphs for failed tests, pylint problems and code coverage over time.
Bitten is a continuous integration plugin for Trac. It has the master-slave architecture. Bitten master is integrated with and runs together with Trac. Bitten slave can be run on any system that communicate with master. It would regularly poll master for build tasks. If there is a pending task (somebody has commited something recently), master will send "build recipe" similar to ant's build.xml to slave, slave would follow the recipe and send back results. Recipe can contain instructions like "check out code from that repository", "execute this shell script", "run nosetests in this directory".
The build reports and statistics then show up in Trac.
I know this question was asked 3 years ago, but I'm currently developing a GUI to make nosetests a little easier to work with on a project I'm involved in.
Our project uses PyQt which made it really simple to start with this GUI as it provides all you need to create interfaces. I've not been working with Python for long but its fairly easy to get to grips with so if you know what you're doing it'll be perfect providing you have the time.
You can convert .UI files created in the PyQt Designer to python scripts with:
pyuic4 -x interface.ui -o interface.py
And you can get a few good tutorials to get a feel for PyQt here. Hope that helps someone :)
I like to open a second terminal, next to my editor, in which I just run a loop which re-runs nosetests (or any test command, e.g. plain old unittests) every time any file changes. Then you can keep focus in your editor window, while seeing test output update every time you hit 'save' in your editor.
I'm not sure what the OP means by 'drill down', but personally all I need from the test output is the failure traceback, which of course is displayed whenever a test fails.
This is especially effective when your code and tests are well-written, so that the vast majority of your tests only take milliseconds to run. I might run these fast unit tests in a loop as described above while I edit or debug, and then run any longer-running tests manually at the end, just before I commit.
You can re run tests manually using Bash 'watch' (but this just runs them every X seconds. Which is fine, but it isn't quite snappy enough to keep me happy.)
Alternatively I wrote a quick python package 'rerun', which polls for filesystem changes and then reruns the command you give it. Polling for changes isn't ideal, but it was easy to write, is completely cross-platform, is fairly snappy if you tell it to poll every 0.25 seconds, doesn't cause me any noticeable lag or system load even with large projects (e.g. Python source tree), and works even in complicated cases (see below.)
https://pypi.python.org/pypi/rerun/
A third alternative is to use a more general-purpose 'wait on filesystem changes' program like 'watchdog', but this seemed heavyweight for my needs, and solutions like this which listen for filesystem events sometimes don't work as I expected (e.g. if Vim saves a file by saving a tmp somewhere else and then moving it into place, the events that happen sometimes aren't the ones you expect.) Hence 'rerun'.