I would like to make ANT process wait for another build or task to finish.
The situation is: I execute a few ANT builds simultaneously. In these builds there are tasks to test the apps. Unfortunately, only one flexunit task can be run at the same time, because it uses net socket to communicate with the AIR app.
The build process should wait for the end of the tasks from other build processes before starting its task.
How to achieve that?
Thank you for any hints,
Rafal
Use the <waitfor> task with your choice of synchronization.
I always use an "IGotTheResourceSoYouCantHaveIt" file that gets created after <waitfor> and deleted when I'm done with it.
Details:
delete the file in some higher-level "clean" so that if a build aborts it gets deleted eventually.
there's a small race condition between the <waitfor> and creating the file. In my use, it's not worth worrying about.
Related
We have several automated build scripts, some of which are run automatically every 2 hours, and some of which are only ever run manually.
If a build script is started manually while another is already running, it can cause...problems. Such as merging untested branches into the production branch.
I'd like to prevent this happening again, and the simplest solution in my mind is to have each build script start by checking that another is not currently running.
Is there a way in ant to directly check if another ant instance/script is currently running?
If not, what's the simplest way to add such a check? My first thought is a file created at the beginning and deleted at the end of a build. I'd prefer a way that handles user-cancelled builds nicely, but it's not necessary. It needs to work if a build succeeded and if a build failed (but was not killed by the user).
If these are separate Ant processes, then I think the only solution is to define a lockfile of some sort that each Ant process needs to acquire before it can continue.
Perhaps the tempfile task could be used for this?
Actually, a sort-of semaphore based on a directory might be better because the tempfile really is a unique tempfile. The first thing your script does is use mkdir to create a shared resource directory name, but it only does this if the directory does not exist.
Upon exit it invokes delete on this shared resource name.
The idea is that the content and name of the directory is meaningless -- it only serves as an "IPC" cooperative locking mechanism.
This isn't particularly elegant, but I think your only other option is to set up a build server that handles scheduled and continuous builds based on various triggers. One that many people use is Jenkins (or has it been renamed?)
[Update]
Perhaps Do I have a way to check the existence of a directory in Ant (not a file)? would do the trick?
To be honest, this approach may work in the short term, but it just moves the problem around. Instead of resetting unit test results you'll be removing lockfiles by hand to get builds working again. My advice is to set up a CI build system, but I recognize this is a fair amount of work (and introduces a whole different set of future problems.)
I have two Jenkins jobs, COMPILE and TEST, COMPILE triggers TEST, COMPILE is quick, TEST is slow. COMPILE re-creates data which is used by TEST, so if COMPILE runs while TEST is running, TEST might fail due to the necessary data being temporarily unavailable or incomplete.
Sometimes, COMPILE gets triggered a lot (via CMS, busy development). The standard way would be to synchronize COMPILE and TEST via a lock, so that both never run at the same time but instead wait for the other to finish before starting. This waiting does not really suit me as it delays the COMPILE jobs too much.
An alternative might be to turn TEST to concurrent running, but in my case TEST requires too many resources to be able to run concurrently.
So my approach now is to configure COMPILE so that it first aborts a running TEST job (in case one is running) and then starts its work (eventually triggering TEST again in the end). Several quickly performed COMPILE builds will then each start a TEST build which will all be aborted (gray bubble). Only the last TEST build will be completed and show a decent red or green (or yellow) bubble. But that will be enough in my case (and I accept the drawback that this way I cannot detect exactly which commit broke the build).
Now the question is: How can I make COMPILE abort a TEST build? (Preferably in an elegant way.)
I only found a way to generally abort a job from the outside using Jenkins's REST interface, but that doesn't seem to be very elegant. Is there a more elegant way, maybe using a Jenkins-internal feature I don't know or maybe by using a suitable plugin?
I would suggest consolidating the two jobs into a single job. That would allow for multiple simultaneous executions and will still fail if the compile fails.
You can set the number of Executors for the node to "1" . By this we can make sure only one jobs run at a time in the node , even if it is executed in parallel it will wait for the 1st job to complete and then start the second
I am setting up my local build using Ant and have decided to use RabbitMQ. I would like to have any Ant task that I can use to configure my local installation for setting things up (stop, start, create queues etc..) and tearing them down as part of my test suite.
Has anyone come across anything like this?
I described a scenario in this question there the op was looking for a way to declare queues and bindings without the overhead of doing it at runtime.
In my solution I use a console utility to perform the queue declarations and have this called from a build step in my build server when running builds and tests.
During the normal course of coding and integration testing from the IDE, I simply make sure that I have used the utility fairly recently to make sure the queues have been established as per the current XML definitions. My test setups ensure that the queues themselves are empty before running.
Hope this helps.
Steve
Ant is a build tool. While running your automated tests is generally part of a build process, the setup of your queues are part of your specification's context and should be included in your tests. If you truly have a need to configure your exchanges and queues once before all test runs, many frameworks provide a facility to do this.
Is it possible "and how if you know", to schedule the execution of an ant task?
For example, i want my build.xml to be executed every 5 hours or every day at a certain time?
I have been looking around but no solution found
Thank you
For very simple requirements, I'd echo the use of cron.
If the reason for running ANT is to periodically perform a master build of your project's code, then you're effectively following a practice called "Continuous Integration". In that case I'd highly recommend running a continuous integration server, such as Jenkins.
Jenkins is a very useful piece of software, easy to install and can become your automation framework for more than just building your code.
Just use cron and call ant.sh from it.
If you are working on a windows environment, you can use the "task scheduler" and set the interval. If you are working in unix/linux, you may use cron for scheduling your job.
I have an Ant task which runs if the lock file is not existing.
But if the build fails, then the lock file is not deleted at the end of the task and subsequently the task is not invoked from my scheduled jobs.
Is there anyway to handle such that even if build fails, I should be able to call my cleanUp task to delete the lock files?
Look at this: Testing and exception handling with Ant
There is macrodef with trycatch
This sounds to me like something that should be cleaned up at the beginning of any build.
Do you have an init task or some task on which all other tasks depend? I would just put the deletion of that file in there so that it always gets deleted even if a previous build failed.
However, it's a confusing requirement. It doesn't sound very idiomatic. Ordinarily, task execution is controlled through dependency and conditional properties. See the relevant section of the targets section of the manual for more details about if and unless. Creating a file is an expensive way to get the functionality already present in ant's core.