I have two build projects. lets call them project A and project A.pack. When I force build project A it asks me for Boolean parameter if I want to build project A.pack.
But I can't make in publishers block of project A a correct way to force build the project A.pack. I use conditional task but it doesn't work. In log file ccnet writes only that it fails on conditional task. What a usual way to do this in ccnet?
Update:
Sorry for my English. It's not my first language.
What I wanted to do is this:
In project A I added Boolean parameter:
<booleanParameter>
<name>ExampleParam</name>
<true name="Yes">1</true>
<false name="No">0</false>
<display>Example Param</display>
<default>No</default>
<required>false</required>
</booleanParameter>
And added conditional forcebuild in publishers like this:
<publishers>
<!-- some other tasks .. -->
<conditional>
<conditions>
<compareCondition>
<value1>${ExampleParam}</value1>
<value2>1</value2>
<evaluation>equal</evaluation>
</compareCondition>
</conditions>
<tasks>
<forcebuild>
<project>A.pack</project>
<serverUri>tcp://localhost:21235/CruiseManager.rem</serverUri>
</forcebuild>
</tasks>
</conditional>
</publishers>
When I press "force" it asks me for "Example Param", I check "Yes" and when it finishes building dashboard says that build was succesful but ForceBuildPublisher task failed.
There is no information in server log about why force build task failed.
It's CruiseControl.NET-1.6.7
Update 20150808:
I convinced my colleagues to update CCnet. In version 1.8.5 it's possible to do a conditional build like I wrote.
If the boolean parameter is true then write to a file that A.pack watches. A.pack builds if the file gets dirty. See Filesystem Source Control Block for use by A.pack in listening to the file made dirty by A.
Related
Yesterday I was able to run a plain Java class in Android Studio without any problems. I did this by creating an Application configuration:
... for running the main() method of some class I defined in the default app module, e.g.:
package com.example.myappname;
public class Api {
public static void main(String[] arguments) {
System.out.println("API test");
}
}
If I then pressed run:
... the output (which I can't show you now, because it doesn't work anymore) of main() would appear nicely in the Run Tool Window:
As far as I was aware, no gradle task or build process was invoked by running this type of configuration. But now, all of a sudden, it appears as though gradle is being executed before running, because it complains that task [:app:Api.main()] failed with message:
A problem occurred configuring project ':app'.
> Could not create task ':app:Api.main()'.
> SourceSet with name 'main' not found.
... as seen here:
I tried recreating the configuration and for the first run it worked as before again, but on rerunning the same gradle build error appears again.
Do you have any idea why this is happening and how I can solve this? Am I correct in thinking gradle should be omitted with these kinds of Application configurations?
When it worked, the output in the Run Tool Window would appear almost instantaneously and no elaborate build process appeared in the Build Tool Window, leading me to believe no gradle build process was being executed.
I got it to work again:
... but don't ask me how exactly. It appears to be very buggy.
After deleting all sorts of cache directories and files and searching all kinds of directories for the location of the configuration files I was able to find that the configurations are stored in .idea/workspace.xml of the project.
And one thing I appeared to notice is that the following "hidden" option is needed as a minimum (which I believe was not there, when it didn't work):
<method v="2">
<option name="Make" enabled="true" />
</method>
Here's a full example configuration:
<configuration name="API" type="Application" factoryName="Application" nameIsGenerated="true">
<option name="MAIN_CLASS_NAME" value="com.example.myappname.Api" />
<module name="MyAppName.app.main" />
<method v="2">
<option name="Make" enabled="true" />
</method>
</configuration>
But sometimes it works and sometimes it doesn't. It appears to be the most reliable if I signify the classpath (-cp option in the Android Studio dialog) to be MyAppName.app instead of MyAppName.app.main.
Ironically, it started to work again when the configuration dialog claimed it couldn't find the class I wanted to run and a red X appeared in the top right corner of the configuration icon:
So, it's all a bit of a mystery to me, as to why it sometimes works and other times it does not.
PS: I was wrong about gradle not building in this type of configuration; it does.
And after a few more tests, it appears one simply shouldn't select the ".main" part when choosing a module for the classpath argument, as that appears to be some specific gradle configuration/task I don't understand well enough.
In spite of Android Studio claiming it can't find the class then (and the red X appearing), it works.
I've been trying to get an automatic versioning system going for builds (mainly due to external crash analytics picking up each build as the same until I change the version manually). The format is simple, I take the CFBundleShortVersionString from the Info.plist, and append the current date and time (in yyyyMMddmmss format) as subversion.
The task I've put together for this:
<Project>
<Target Name="BeforeBuild">
<XmlPeek XmlInputPath="$(ProjectDir)Info.plist" Query="//dict/key[. = 'CFBundleShortVersionString']/following-sibling::string[1]">
<Output TaskParameter="Result" ItemName="VersionNumber" />
</XmlPeek>
<PropertyGroup>
<BuildNumber>$([System.DateTime]::Now.ToString(yyyyMMddmmss))</BuildNumber>
</PropertyGroup>
<XmlPoke XmlInputPath="$(ProjectDir)Info.plist" Query="//dict/key[. = 'CFBundleVersion']/following-sibling::string[1]" Value="$(VersionNumber).$(BuildNumber)" />
</Target>
</Project>
However it fails with the following error:
Target BeforeBuild:
[...]/[...].csproj(1069,5): error MSB3733: Input file "[...]/Info.plist" cannot be opened. For security reasons DTD is prohibited in this XML document. To enable DTD processing set the DtdProcessing property on XmlReaderSettings to Parse and pass the settings into XmlReader.Create method.
Done building target "BeforeBuild" in project "[...].csproj" -- FAILED.
What am I doing wrong? There's not much info about this error, at least not much that I could find and would help fixing it.
Okay.. I've been searching this specific question, and did find some examples, but not exactly the answer I wanted. Any thoughts, inputs would be greatly appreciated!
Situation I have is..
I have a daily build process via CCNet. They all have a buildCondition="ifModificationExists" parameter when building. This allows the CCNet to build if and only if there are modifications (checking the source "Update").
Problem is, I added a version Commit process at the very last part of each builds. Meaning, if I were to build 1.0.0.3, I'd Commit the changed AssemblyInfo.cs files (that contains the updated version number), and allows me to check the logs when each of the versions were built.
This completely screwed up the entire automated daily build process.. You see, because it commits the version every build whether or not it has any other Updates, the CCNet considers there's ALWAYS a modification before building each morning. Fact is, the only modification there has been was the version update from last build.
I cant think of a way to get around this, by keeping the version update + daily automate build when modifications exists.
Any help? :)
edit 1. here's the Triggers part for each of my build:
<!--TRIGGERS -->
<triggers>
<scheduleTrigger time="04:00" buildCondition="IfModificationExists" name="Scheduled">
</scheduleTrigger>
</triggers>
edit 2. and here's the part where I commit the files (AssemblyInfo.cs) using powershell
<powershell>
<script>commit.ps1</script>
<executable>C:\WINDOWS\system32\WindowsPowerShell\v1.0\powershell.exe</executable>
<scriptsDirectory>D:\SRC\BuildTools</scriptsDirectory>
<buildArgs>D:\SRC\ProjectName\branches\3.0.3\</buildArgs>
<description>BuildCommit Dir D:\SRC\ProjectName\branches\3.0.3\src</description>
</powershell>
Thank you in advance,
I think you should be able to use filtered source control to do what you need:
http://cruisecontrolnet.org/projects/ccnet/wiki/Filtered
I searched a lot but i didn't find a solution for my problem.
I use CruiseControl.NET (1.4.4). My project (in ccnet.config) load a repository from a cvs server to a local repository, and launch some executables (msbuild, NUnit...).
I use a trigger (Interval or Schedule Trigger), that launch regularly my project. But if my project has not been modified, it always launch all next tasks. And I would like to avoid it. So i want to launch my project only if a commit has been detected.
Is there any solution for it please?
Thanks
Olivier
Your trigger needs to specify IfModificationExists:
<intervalTrigger
name = "dave"
seconds = "30"
buildCondition = "IfModificationExists" />
Although buildCondition="IfModificationExists" is the default anyway, so as long as its not set to ForceBuild you should be fine.
EDIT:
The URL Trigger might be of some use to you. You can set your svn server to modify a page on commmit and the CC.Net checks the page to see if it has changed, thus not getting all the files.
I start my project as below, which ensures that the tasks get executed only if there are modifications.
Hope this helps,
Anders, Denmark
Edited: My code excerpt didn't make it to the page - I've tried to replace less-than, bigger-than with brackets.
[project name="SpilMerePool" queue="Q2" queuePriority="1"]
[sourcecontrol type="svn"]
[trunkUrl]https://ajf-ser1.ajf.local:8443/svn/SpilMerePool/trunk[/trunkUrl]
[workingDirectory]c:\from_vc\SpilMerePool[/workingDirectory]
[executable]C:\Program Files\VisualSVN Server\bin\svn.exe[/executable]
[username]username[/username]
[password]password[/password]
[/sourcecontrol]
Just use IntervalTrigger, like this:
<triggers>
<intervalTrigger />
</triggers>
You can also add an modificationDelaySeconds, to wait for a number of seconds before starting the build after the last commit.
<modificationDelaySeconds>30</modificationDelaySeconds>
Thank you Anders Juul abd Andy for your quick answers.
By using the intervalTrigger with "IfModificationExists" build condition, the project must be loaded each time (it's logical ^^). But my project size is about 450Mo. So it's a little long.
So my last question is : can we execute all builds and next tasks when a commit command has been detected? (without loading all files, in CruiseControl).
I use TortoiseCVS (version 1.10.10). Maybe we can force CruiseControl project to be lauched after a commit?
This question already has answers here:
Closed 10 years ago.
Possible Duplicate:
Pre-build task - deleting the working copy in CruiseControl.NET
I would like to delete my working directory during the cruisecontrol build process...I'm sure this is easy, but I have been unable to find an example of it...
If you know how to create a directory, that would be useful as well.
Thanks.
One of two ways.
If you're already using an MSBuild file or something similar, add the action to the MSBuild file.
Instead of directly executing some command, create a batch file that executes that command and then deletes the directory, and have CCnet call that batch file instead.
My guess is that you want to delete the working directory before CruiseControl.NET gets the latest code from source control. If this is the case, then the only way to accomplish this is to write a custom source control provider for CruiseControl.NET that first deletes the working directory and then gets the latest code. Have a look at CruiseControl.NET's source code for examples of how to write a source control provider.
If you want to delete the working directory after the latest code is retrieved from source control, then you can use CruiseControl.NET's executable task by running "cmd /c del directoryname".
In the ASP.NET work, for me, the easiest way I do it (which allows me to hit either MSBUild or NAnt depending upon the project) was to roll my own exe that takes an argument which I pass in with a bat file fired by CC.NET. It's not the safest thing in the world, but if you have total control over your automated build machine; it's not too shabby. Quick and reusable.
Drop in the exe somewhere that does the recursive delete:
static void Main(string[] args)
{
for (int n = 0; n < args.Length; n++)
{
if (Directory.Exists(args[n].ToString()))
{
Directory.Delete(args[n].ToString(), true);
}
}
}
Drop it in somewhere multiple files can pass arguments to it and just write a custom .bat file for each project. So my task block looks like this:
<tasks>
<msbuild>
<executable>C:\WINDOWS\Microsoft.NET\Framework\v3.5\MSBuild.exe</executable>
<workingDirectory>Z:\WorkingDirectory</workingDirectory>
<projectFile>YourSolution.sln</projectFile>
<logger>C:\Program Files\CruiseControl.NET\server\ThoughtWorks.CruiseControl.MsBuild.dll</logger>
</msbuild>
<exec>
<executable>Z:\SomePathToBuildScripts\YourCustomBat.bat</executable>
</exec>
</tasks>
Then the final step is setting up that .bat file to perform the delete/rebuild functions after use. In the bat file just make sure you rebuild ("MD") the directories you deleted if youexpect to publish a site back to them. On our dev boxes I found this to be the best way to prevent the beloved Frankenbuild.
The way I've done this in the past is to not have CC.Net checkout source itself. Instead, there are two <msbuild> elements for the project, the first one calling a build target that runs svn-clean.pl (compiled to .exe), and then updates the source using svn.exe. The second <msbuild> element starts the main build process.
You can easily replace svn-clean with a delete command. For my projects, deleting chaff from a checkout has always been faster than checking out a fresh working copy.
The two msbuild elements are necessary because the main project build file is often updated. This is important because updates to your build file(s) will only be reloaded if you start a new msbuild process.
This setup breaks down when I (very rarely) move or change the dependencies of that clean-and-update build target to the extent that the msbuild process would need to reload for valid instructions to run the clean-and-update target. When this happens, I stop CC.Net before committing, go into the CC.Net server, and do an 'svn update' by hand.
Sidelight: It could well be that CC.Net has a natural clean-before-build operation by now. I've since moved to TeamCity, which is configurable to do this every build or only when the developer chooses (e.g., when you know you've made a change that would not update cleanly--svn moves of directories with build products comes to mind).