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.
Related
In CC project config file I have many MSBuild tasks. Each task is used to build one solution.
Problem is that this requires maintenance if this CC config file each time when new project is added to / deleted from repository.
My idea is to pass to the CC dynamic list of solutions that should be build and execute build one by one as it is done now with "static / old fashion" maintenance of config file.
Does anyone prepare already such configuration?
Presuming you have something akin to the following:
On disk:
./solution1.sln
./solution2.sln
./solutionN.sln
And a single ccnet project:
Msbuild task -> solution1.sln
Msbuild task -> solution1.sln
Msbuild task -> solutionN.sln
What you are asking for is ccnet to react to what is outside of its environment. This isn't possible, however it would be possible to get another tool to do so.
Possible options:
1. Custom Msbuild project
Create a specific msbuild project which finds and invokes msbuild on all solution files it finds. Call msbuild on this project alone. It should be possible to do this with vanilla msbuild, see https://msdn.microsoft.com/en-us/library/z7f65y0d.aspx
2. Batch files
Find all files, and for each file execute msbuild. Ensure the output is logged to an XML file (msbuild switch - I believe) and merge in the result in the publishers section.
See How to do something to each file in a directory with a batch script
3. Single solution
Create a single solution, which contains all the projects from all solutions (1 to N) and call msbuild on this once.
This solution file would be need to be updated each time a new project comes along however.
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.
I maintain a classic asp web application, and I'd like to try to automate some of the merging to and from branches using CruiseControl (CruiseControl.net specifically). But I don't have any use for a build tool. Basically I would want a commit on /trunk to automagically get merged to a bunch of feature branches that would exist as CC projects.
Is this possible/recommended or is there an easier way to do this?
Some parts of the repository do contain VB6 or .NET code, so I would like to be able to automate builds to those parts in the future, but for the time being I would just basically be using it to automate keeping my static website clean.
It is not the normal responsibility of CruiseControl to affect source control, short of tagging commits. You could have another, say release, branch that CruiseControl monitors. The merging can then be done manually to this branch as required - resolving any merge conflicts at point of merge. CruiseControl would then just 'build' these merge commits.
CruiseControl is a basically a tool for executing commands in a given order based on a trigger. In your case a SourceControlTrigger.
You can setup CruiseControl to execute msbuild, or not, as required.
As you are trying to deploy/package a classic asp site, I guess you only need to copy/zip the source files and deploy them to your web server. This can be achieved as so:
Use nant to copy, and zip, your source files, execute it via an nant task
use curl, executed via an exec task to send the zip file via http(s)
If required you can preceded this with an msbuild task to build your .net projects.
How do I have SSDT run my publish script when I build my solution file?
If you:
1) Right click on your solution
2) Click Configration Properties
3) Click Configuration
I can see the database project and where it is checked to deploy on build, it does not let me specify what publish script to use.
As far as I know this isn't possible out of the box.
Why? They are two very different things.
Building (if you were to think of it as code) compiles and checks, producing artefacts. For .NET code those artefacts are DLL's/.exe etc. For .sqlproj it's the .dacpac etc that turn up in /sql/[Build Configuration Name].
Publishing is akin to Deploying if you were talking .NET code. Building won't include Publishing as an action.
Ironically, a Publish action also Builds the solution, so my suggestion would instead be to consider one of the following:
Publish the project (right click Publish, or double click your chosen .publish.xml file) whenever you want to build.
Use the Post-Build command line in the project Properties to call sqlpackage.exe to deploy your newly compiled .dacpac with your specified .publish.xml profile - but note that this will also impact your use of the Publish action from within Visual Studio as a Publish builds and then publishes (so you'd end up publishing twice).
Depending on your comfort levels/if you are a command-line fan, then use the command line (bash file? Powershell?) to call msbuild followed by sqlpackage.exe. Whenever you want to build, run your command in cmd.exe.
Similar to #3, add a menu item to the Tools menu that would do exactly the same thing (msbuild followed by sqlpackage deployment) but from within Visual Studio itself.
Look at a Continuous Integration model (TFS/TeamCity/Bamboo/Jenkins and about 3000-others), which could build and deploy for you automatically with every change - either on another server, or running locally (I put this in without knowing your scenario, so may be very much unsuitable to solve your problem).
I have a large web project and I would like to publish only the files that were modified by the last checkin. What would be the best way to do this?
I found an article that detailed the process using robocopy. I thought perhaps there was a task in ccnet that did this, but I couldn't find one.
http://msmvps.com/blogs/omar/archive/2008/10/06/asp-net-website-continuous-integration-deployment-using-cruisecontrol-net-subversion-msbuild-and-robocopy.aspx
It depends on what you are doing. Do you use a build script? Your best bet is to let your build script do your publishing, you will have much more control over it.
There is a Modification Writer Task that will create an XML file of the detected modifications in that build. You could then have your build script read that and publish just those files.
There is also a Modification Reader and the doc implies that you can use the read in modifications and publish based on that list:
The ModificationReaderTask can now easily read the modification
file(s) made by project one, into it's
own integration,
making it possible that these can be used by the existing
tasks/publishers of ccnet for project
2
However, it doesn't make it to obvious how you would do this. Perhaps the BuildPublisher will use the Modification Reader info. This might get you started.