I'am trying to override a pre-built age old ant script. For some reasons, I cannot edit the ant file directly.
-----------Psuedo of the gradle tasks--------
ant.importBuild antFileName
defaultTasks = ['greet']
task takeCare << {
println('Switch off security cam')
}
-----------Psuedo of the ant targets---------
<target name="greet">
<echo>Be nice, say hello!</echo>
<antcall target="tackle"/>
</target>
<target name="tackle">
<echo>Brought him down!</echo>
</target>
What I want to achieve is to do a pre-check on gradle before calling ant target tackle. So my output looks like -
Be nice, say hello!
Switch off security cam.
Brought him down!
How do I achieve this?
Did you try this?
tackle.dependsOn takeCare
UPDATE
If you use dependsOn and run
gradle tackle
you will get
:takeCare
Switch off security cam
:tackle
[ant:echo] Brought him down!
But if you use run greet, takeCare will not be executed, because you make an ant call directlly. So greet runs ant target and not gradle task.
You can try to change the tackle target in gradle.
ant.project.getTargets().find{it.value.name == "tackle"}.value
See java docs: Target
Related
I have PHP Project, that is hosted on GitHub.
Now, I'd like to configure Jenkins to run unit tests so that:
Whenever developer push/commits code to specific branch, it triggers corresponding PHPUnit build job.
If commit passes the unit tests, the source code is deployed (assuming I already have the required script to deploy).
The question is how to trigger the deployment script when source code passes the unit test (i.e. PHPUnit tests succeed)?
Please suggest to me the way to do that, which plugin I should try to achieve the result?
Thanks!
This is going to be a long post, as there's a lot involved, but it works a treat:
You will need:
Ant
Git Publisher plugin
Ant and phpunit will need to be on your PATH
Step 1: Configure your project
In your Jenkins, configure your project to 'Poll SCM' under the Git option. Leave the 'Schedule' as blank. Under 'branches to build' set that as the branch you want to build your release package from.
Reference:
Step 2: Run ant for every build
Add a build step to 'Invoke Ant'
If you don't use Ant already, create a build.xml file in your project root, add it to Git and have the following contents:
<?xml version="1.0" encoding="UTF-8"?>
<project default="full-build">
<property name="phpunit" value="phpunit"/>
<target name="full-build"
depends="phpunit-unittests,-check-failure"
description="runs the tests"/>
<target name="phpunit-unittests"
unless="phpunit-unittests.done"
description="Run unit tests with PHPUnit">
<exec executable="cmd" failonerror="true" resultproperty="result.phpunit" taskname="phpunit-unittests">
<arg value="/c"/>
<arg value="${phpunit}"/>
<arg value="--configuration"/>
<arg path="${basedir}/phpunit.xml"/>
<arg value="--testsuite=Unit"/>
</exec>
<property name="phpunit-unittests.done" value="true"/>
</target>
<target name="-check-failure">
<fail message="PHPUnit did not finish successfully">
<condition>
<not>
<equals arg1="${result.phpunit}" arg2="0"/>
</not>
</condition>
</fail>
</target>
</project>
That will run all unit tests whenever the Ant task is invoked, which is now set for every time the project is built.
Then, install the Git Publisher tool. Configure as follows:
This creates a new release tag upon a successful build. You will use this later to publish the release to the final location. Note: There are different variables that Git Publisher provides for use, commit hash, user etc so use what you want. I stick to an incremental tag of v1.1.BUILD as that's a bit more standard.
Lastly, you will need to add a Git hook which will trigger a build upon a commit/push from any location.
Navigate to your repository folder and within that the 'hooks' directory.
Create a new file named 'post-receive' (you will see examples in there; overwrite this one). Place the following content in:
#!/bin/bash
while read oldrev newrev refname
do
branch=$(git rev-parse --symbolic --abbrev-ref $refname)
if [ "master" == "$branch" ]; then
curl http://YOUR_JENKINS_URL:8080/git/notifyCommit?url=YOUR_GIT_REPOSITORY_URL
fi
done
That should do the job nicely. I have left out implementation details of how you actually release your project as everyone does this differently. There are options to FTP files to a location, and all sorts. Personally I go into the folder where the application resides and do a checkout of the newly created tag - a one line command. Whatever suits your environment.
Other stuff I've ommitted but you will find useful - the Ant build task can do literally anything - In mine, I run composer to install dependences, run bower, run grunt, do syntax checking, coding standard checking, fire up selenium and run web tests, and a load of other stuff. It's a perfect combination of tools to automate the whole project deployment.
In one of our build script, we have following simple copy task added ->
<copy todir="${targetdir}"
file="${sourcedir}/modules/glassfish.jaxb.xjc_1.0.0.0_2-1-12.jar"/>
This copy task started hanging when the glassfish jar name got changed (version upgrade which are not in our control) at the source location. I was expecting it to error out causing the build failure in that case. Actually at first I was not able to figure out at what particular step build was hanging. Then when I added "-debug" to the ant command and I realized its successfully completing a step prior to this copy task and still there was no trace of copy command that is hung. When I updated the new jar name, it worked fine and build was successful which proved that the copy task is hanging because of filename got changed. To make it easy to debug next time, I added an echo statement like below just prior to that copy task ->
<echo message="Copying glassfish jar to ${targetdir}.."/>
But I am still confused as to why it didn't give error with build failure? I am using Apache Ant version 1.7.1. Could this be a bug? How else I can avoid this situation in future with just the copy task (without using * in the jar name)? TIA
That worked for me. Well, didn't work for me. I got the error message. I am using Ant 1.8 and Ant 1.9.2. I didn't try it with Ant 1.7, but I doubt it's a bug.
Try to use the -v parameter in Ant:
$ ant -v target
And be prepared for a longwinded output. This will give you information what's going on with Ant, and may explain why it's freezing. There's a few things you could do: Use a fileset to specify the file.
<copy todir="${targetdir}">
<fileset dir="${sourcedir}/modules">
<include name="glassfish*.jar"/> <!-- Will catch any glassfish.jar -->
</fileset>
</copy>
Of course, if the file doesn't exist, you won't get an error or even a warning. However, a <fail/> before will detect the issue:
<fail message="missing file ${sourcedir}/modules/glassfish.jaxb.xjc_1.0.0.0_2-1-12.jar">
<condition>
<not>
<available
file="${sourcedir}/modules/glassfish.jaxb.xjc_1.0.0.0_2-1-12.jar"
type="file"/>
</not>
</condition>
</fail>
To force the build to quit, an alternative way
<available file="${sourcedir}/modules/glassfish.jaxb.xjc_1.0.0.0_2-1-12.jar"
property="glassfish.jaxb.xjc.jar.present"/>
<fail message="you message" unless="glassfish.jaxb.xjc.jar.present"/>
just a few lines less :)
If you want to dig into it, try this:
write a simple build file, which contains only one target with copy, and put it to the same place of your main build file.
<target name="test-copy">
<!-- here use an old (wrong) file name -->
<copy todir="${targetdir}"
file="${sourcedir}/modules/glassfish.jaxb.xjc_1.0.0.0_2-1-12.jar"/>
</target>
run it, check if it fails or hangs.
If this simple build file works, it's very possible that something else in your main build file is causing the bug.
I want to make a Jenkins job to run an ant task to run all tests in my codebase which are tagged #Ignore because using annotations like #Category(IgnoredTest.class) do not work with our test run parallelization. After a lot of searching it looks undoable, but I still have hope. Help?
JUnit 4.10
I'm not sure what the impediment is with your "test run parallelization", but you might be able to do this with a rule if you're willing to use a custom "ignore" annotation instead of the JUnit one. The reason for that is that JUnit handles #Ignored tests at the Runner level, specifically in the BlockJUnit4ClassRunner.runChild() (by default). If you could find a way to use a custom Runner in Ant, you could come up with one to meet your needs pretty easily, but I don't know if that's easily doable in Ant.
As I first mentioned, though, you can easily use a different annotation and a rule to choose which methods to run. I made up a quick example of such a rule on github, along with a test that uses it. My little example uses a system property for switching, but you can also obviously make it switch on anything you can think of that you can get your hands on here.
You can clone and run this example with:
git clone git#github.com:zzantozz/testbed tmp
cd tmp
mvn test -pl stackoverflow/9611070-toggleable-custom-ignore -q
mvn test -pl stackoverflow/9611070-toggleable-custom-ignore -q -D junit.invertIgnores
The one downside of this approach that I can think of is that your tests won't get properly marked as "ignored" because that's also done by the BlockJUnit4ClassRunner.runChild() method, and if you peek at ParentRunner.runLeaf() (which runChild() delegates to), you'll see that the notifier, which is what you need to report ignored tests, isn't passed down far enough to be used by a Rule. Again, it's something you'd need a custom Runner for.
You could create a special ant target that removes the #Ignore annotation and add an #ignore annotation to any active #Test annotated method
the target would be something like this:
<project name="anyname" default="test" basedir=".">
..
..
<target name="enable-ignored-test" depends="copy-code-to-replace-ignored">
<fileset id="fsTestCase" dir="." includes="**/*Test.java">
</fileset>
<replaceregexp flags="gm">
<regexp pattern="^#Ignore"/>
<substitution expression=""/>
<fileset refid="${fsTestCase}"/>
</replaceregexp>
<replaceregexp flags="gm">
<regexp pattern="#Test"/>
<substitution expression="#Ignore #Test"/>
<fileset refid="${fsTestCase}"/>
</replaceregexp>
</target>
<target name="run-ignored-tests" depends="enable-ignored-test,test" />
..
..
</project>
I am trying to run an Ant task from within IBM RSA IDE using Ant build ...
I get the following error message:
BUILD FAILED
build.xml:21: Could
not create task or type of type: getProjectData.
Ant could not find the task or a class this task relies upon.
This is common and has a number of causes; the usual
solutions are to read the manual pages then download and
install needed JAR files, or fix the build file:
- You have misspelt 'getProjectData'.
Fix: check your spelling.
- The task needs an external JAR file to execute
and this is not found at the right place in the classpath.
Fix: check the documentation for dependencies.
Fix: declare the task.
- The task is an Ant optional task and the JAR file and/or libraries
implementing the functionality were not found at the time you
yourself built your installation of Ant from the Ant sources.
Fix: Look in the ANT_HOME/lib for the 'ant-' JAR corresponding to the
task and make sure it contains more than merely a META-INF/MANIFEST.MF.
If all it contains is the manifest, then rebuild Ant with the needed
libraries present in ${ant.home}/lib/optional/ , or alternatively,
download a pre-built release version from apache.org
- The build file was written for a later version of Ant
Fix: upgrade to at least the latest release version of Ant
- The task is not an Ant core or optional task
and needs to be declared using <taskdef>.
- You are attempting to use a task defined using
<presetdef> or <macrodef> but have spelt wrong or not
defined it at the point of use
Remember that for JAR files to be visible to Ant tasks implemented
in ANT_HOME/lib, the files must be in the same directory or on the
classpath
Please neither file bug reports on this problem, nor email the
Ant mailing lists, until all of these causes have been explored,
as this is not an Ant bug.
Here's the Ant buildfile:
<!-- Get property locationName. -->
<target name="config">
<echo message="${ear.project.name}" />
<getProjectData projectName="${ear.project.name}" />
</target>
I am not quite sure what the problem is here because the error message seems not helpful. Any suggestions?
I believe getProjectData is an IBM extension to ant. Like you, I had a similar error, but I was able to get it working after ensuring the Run in the same JRE as the workspace option was enabled (which you can find by right-clicking the build file, run-as, Ant Build..., and selecting the option on the JRE tab).
I discovered the solution on the IBM info center:
The Run in the same JRE as the workspace option enables the classpath
of the workbench to access the additional Ant tasks that perform
operations that are specific to the workbench, such as projectImport,
projectBuild, workspaceBuild, ejbDeploy, or earExport. If your Ant
build script uses any Ant tasks that perform workbench operations,
verify that you selected the Run in the same JRE as the workspace
option; otherwise you might get the following error message in the
Console view:
Problem: failed to create task or type <Ant task> Cause:
The name is undefined.
The build file I used looked like this:
<?xml version="1.0"?>
<project name="Test" default="config" basedir=".">
<target name="config">
<getProjectData Basedir="${basedir}" />
<echo message="getProjectData: projectName=${projectName}
nature=${natureName}
workspace=${workspaceName}
basedir=${basedir}" />
</target>
</project>
And output:
Buildfile: C:\DATA\java\workspace\test-java\build.xml
config:
[getProjectData] Setting projectName=test-java
[getProjectData] Retrieved following Project Data :
[getProjectData] workspaceName=C:\DATA\java\workspace
[getProjectData] natureName=Java
[echo] getProjectData: projectName=test-java
nature=Java
workspace=C:\DATA\java\workspace
basedir=C:\DATA\java\workspace\test-java
BUILD SUCCESSFUL
Total time: 78 milliseconds
i am currently writing an ANT script which will include some intelligence to check for things. I am using SnapshotCM from True Blue Software as my version control and using CruiseControl as a framework for my nightly build.
Basically, I will need to always check for the latest version found in my version control and execute commands. In this case here is an example:
<project name="nightly_build" default="main" basedir="checkout">
<target name="init">
<property file="initial.properties"/>
</target>
<target name="main" depends="init">
<!-- need some code to set variable -->
<!-- need some code to increment variable -->
<!-- need some code here to check for the latest version -->
<exec executable="C:/Program Files/True Blue Software/SnapshotCM/wco.exe">
<arg line='-f -R "C:/Work/7.10.000_Tip/7.10.000_Tip_GUI_TEST/"'/>
</exec>
</target>
</project>
In the code above, I will load the "initial.properties" file.
The algorithm should be as follow:
load the initial properties file
get the build_number
increment build_number by 1 (let this new variable be X)
if X is found, increament X by 1 (if not found jump to 6.)
if X is found, repeat 4 (until X cannot be found)
else use the build number inside the <arg line ='-f -R "C:/..../7.10.100.X..../"'/>
The initial.properties file is as follow:
Major_Version=7
Minor_Version=10
Project_Number=100
Build_Number=036
Product_Version=${Major_Version}.${Minor_Version}.${Project_Number}.${Build_Number}
can anyone guide me on that?
Ant is not a programming language. It's a dependency matrix language.
That means you don't specify execution order in Ant. Ant will calculate the order it needs to run the targets. It also means Ant doesn't have the ability to do loops, or even change the value of a property once it is set.
There are a few packages that build upon Ant. The old standby is the Antcontrib. Antcontrib has the concept of variables which are like mutable properties. It also has various looping structures. However, I'm not sure if the <foreach> or <for> tasks will do what you want...
Searching sequentially for the next build number is something you can do in a shell script. In fact, I highly recommend this.
I use Ant for builds only and keep my CM functions outside of my build.xml file. Instead, I rely on my build system to do everything that's not related to the build itself. This includes checking out the code, saving the artifacts, and compiling unit tests. This way, if I change the way I use my continuous build system or my version control system, I don't have to modify my build.xml files.