I have CC.NET configured with 2 projects like this
BuildApp
RunSmokeTests
RunSmokeTests uses project trigger to start whenever BuildApp project finishes with Success.
When smoke tests fail I want to be able to send e-mails containing version number of our app (${CCNetLabel} from BuildApp project).
I can't find a way to do it. I thought this should be built in in CC.NET. I want to make sure that there is no such functionality in CC.NET before I come up with my own solution.
You can use a remoteProjectLabeller to label the SmokeTests project with the same label as the BuildApp project.
Otherwise you could use a ForceBuildPublisher in the publishers section of the BuildApp project, where you can pass custom parameters.
If I were to suggest an option, I'd go for the latter as there is a underlying issue with the remoteProjectTrigger which can mean that your RunSmokeTests project can fire when BuildApp fails. It is also less efficient than the ForceBuildPublisher
For example
<forcebuild>
<project>RunSmokeTests</project>
<serverUri>tcp://buildserver:21234/CruiseManager.rem</serverUri>
<integrationStatus>Success</integrationStatus>
<!-- <enforcerName>BuildApp has finished </enforcerName> -->
<parameters>
<namedValue name="$BuildAppLabel" value="$Label" />
</parameters>
</forcebuild>
There is a bug where but the enforcerName won't be passed, so don't rely on that property.
In the RunSmokeTests project you should be able to read out the $BuildAppLabel for the email.
Related
We have multiple repos and whenever the developer runs the sonarQube scanner through Jenkins job, it is creating one project with build number along with the date, is there anyway I can re-use the same project name ..?
developers are running sonarQube reports through Jenkins jobs.
sonar.projectKey=portal1-sonar:1stiteration-${BUILD_NUMBER}
sonar.projectName=SonarQube nodeJS portal1 Build : ${BUILD_NUMBER}_${BUILD_TIMESTAMP}
anyway, I can change and use same project name, whenever developer runs sonarQube.
every project is defined in SonarQube with it's own key. That means if the key is the same, it is the same Project, and you will have a "history" of analyses and can compare parameters.
Although the idea of buildnumbers seems to be interesting, i recommend to use Branch names instead. There are currently two ways of doing this, for the first one, you need to have a SonarQube installation with a paid price. Than you are entitled to use the branch plugin. Which is actually the more superior way, because your project will show branches. The sonarQube docs are quiet helpful regarding this.
The old/Deprecated way will create a new project per branch, which you can than compare. the property you need to set is sonar.branch and this will be automatically added to your project key. So if the project key is Project and the sonar.branch is set to develop your new project will have the key Project:develop. This parameter is deprecated, and i am not sure, how long it will stay in the system.
I'm using cruisecontrol.net to do CI, but the test type is configured in an xml file is not what I want. The xml file looks like:
<config>
<Test type="A"/>
</config>
Is there any way to change it from A to B?
I would switch mentality a bit.
Think of CC.NET as a "super fancy msbuild.exe executor".
Write most of your logic in msbuild files. Then you can easily find XmlPeek and XmlPoke (XmlUpdate) "extension tasks" that are tried and true.
This has some advantages. If you ever switch from CC.NET to something else (TFS for example), having most of your logic in an msbuild (.proj) file will make that transition very easy.
The more "proprietary" tasks you write that is CC.NET specific, the deeper you get in.
I go with this:
Have CC.NET download your .proj file.
Have CC.NET excecute msbuild.exe yourfile.proj.
Have CC.NET "merge" all resulting xml.
Have CC.NET run its "publishers" (email being the most popular)
Your .proj file will have the majority of logic.
It will pull down the rest of your code.
It will build the code.
It will zip up files or create installers or whatever.
This will serve you better than trying to get CC.NET to do everything.
I don't think there is CC.NET xml-update task.
Msbuild Community Tasks has ~lots of extra tasks to get done what you want to get done.
Yes there is with parameters. See this page:
http://cruisecontrolnet.org/projects/ccnet/wiki/Parameters
When someone forces a build a dialog pops up allowing them to choose between test type A and test type B.
I have a build definition set up that successfully builds on each check-in and deploys to the cloud (Azure). However, I'd like to know how to modify it if I wanted it to build, but not actually deploy to Azure. Just build after the check-in, make sure nothing breaks, and that's it. I've tried searching around and modifying MSBuild arguments, but to no avail. This should be easy. What am I missing?
These are the MSBuild arguments I have plugged in. The last two (DeployOnBuild and CreatePackageOnPublish) don't seem to matter at all...not sure /t:Publish is making any difference either
/t:Publish
/p:TargetProfile=Cloud
/p:DeployOnBuild=false
/p:CreatePackageOnPublish=false
Thanks!
The key is to use the correct build process template:
Right click the build definition -> Edit Build definition
Process tab
Up at the top there is a section for the Build Process Template
Show Details
Select "DefaultTemplate" from the dropdown
The options available in the process tab will be different than the AzureContinuousDeployment template I was using. I didn't need any MSBuild arguments (though you might depending on how you named your service configs).
I had never noticed the template before. Most people probably just assumed I was already using the default one!
I'm wondering about this because i'd like to find a way to create a post-build event that is different whether I'm trying to compile and run in the emulator or wheter I'm compiling and publishing to the cloud.
I don't know if there is an easier way, but I thought that If I could find where the current setting (cloud or local) is saved I could branch my post-build event based on that
thx
It is in a variable TargetProfile so you should be able to do something similar to this (which is for after publish, but you get the idea):
<Target Name="AfterPublish">
<ItemGroup Condition="'$(TargetProfile)' == 'Cloud'">
<-- Do you thing here -->
</ItemGroup>
</Target>
In CruiseControl.NET, I have two projects set up, one for building and one for deploying build packages.
Our build is largely based around MSBuild, and as it runs the dashboard constantly updates with the latest output from the build. This means that even though a full build may take 15 minutes, you can see exactly where it is, and that it's making progress.
The deploy is run using another tool (VisualBuild, though I'm see the same basic behaviour with other tools like PowerShell). This is another long-running task, but in this case the dashboard is not updated with its output as it progresses. Since a deploy may take a long time, it's hard to tell whether things are progressing or if things have stalled. The output is getting logged to the CruiseControl.NET log, and will display on the dashboard once things are done, but not while the deploy is in progress.
Is there a way to get output from other arbitrary long-running tasks updated on the dashboard in something resembling real time? What makes MSBuild special in this regard?
CruiseControl.Net, since version 1.4, includes support for build listener files: it's a mechanism which allows tracking the execution of long-running tasks by reading from a log file. While this mechanism is generic, and can be used with any tool, CruiseControl.Net by itself ships only with build listeners for MSBuild and NAnt (which means that for those two tools progress is reported automatically, without the need for extra configuration).
For an external tool, such as VisualBuild, called by <exec> task, you would have to plug in your own logger that creates a simple progress file:
<data>
<Item Time="2007-10-14 08:43:12" Data="Starting Build timetester" />
<Item Time="2007-10-14 08:43:16" Data="Starting Target build" />
<Item Time="2007-10-14 08:43:16" Data="Sleeping for 5000 milliseconds." />
</data>
in the location pointed to by the CCNetListenerFile environment variable.