I am new to Maven build. Can some one let me know if there is any way we can trigger a job which will run a batch file after successful completion of build in Maven?
Since you didn't provide details on how you are invoking maven, I'm going to just assume some things.
Continuous Integration: If you are using some kind of continuous integration like Jenkins/Hudson, or Travis CI, you should be able to add your batch file as a post-build step that gets executed on success of the build. Alternatively, you could have a separate job that runs your batch script that gets kicked off by the maven build's job.
IDE Configuration:
If you are trying to do it with Intellij or some IDE, you will likely need to make a batch configuration that runs your maven build and then your desired post-build batch file.
Command line/mvn directly:
If you are running this by yourself on the command line using normal mvn install commands, you are either going to want to circle back to having a batch file that kicks off maven for you and then runs your next script, or look into a plugin similar to this question (Note that there are some concerns with this approach, so be careful).
If none of these scenarios describe your situation, you are going to want to provide more information to your question before you get any solid feedback.
Thanks!
Related
I am using Selenium for automation with Eclipse and TestNG.
Whenever required I execute script from testng.xml.
Why do I need a Build tool loke Maven or Ant because Compiling and execution work taken care by Eclipse.
Only possible reason that I can think of are:
1. Scheduling using Windows 'Task Schedular'
2. Ant allows creating a batch file for execution, so execution gets simplified.
2. Craeting ReportNG reports that are triggered through ANT
Is there any other good reason?
Also why do I need Jenkins?
Jenkins can be really helpful when you want Continuous Integration
builds to be Tested frequently.
In the environment where continuous development and Continuous
Integration goes hand in hand we can use Jenkins to test the build
regularly.
With Selenium Automation we can build/develop the automation script
for the developed builds. Once the Automation is developed we can
create a bat file and use Jenkins to run the bat file.
With Jenkins we can also set the time duration when to execute the
test builds like every day at 12:00 pm IST. Also we can get easily
notified if any test build execution fails because Jenkins also
provide features to send email notification on failure.
Also in some odd cases where we need to test the AUT on Linux/Unix
environment we can easily deploy the Automation on the such Test
system and use ANT to run the Selenium Automation from command
prompt.
I'm writing a plugin for maven and I want find out, if it runs on hudson. Then I want to know which user triggered the build.
Is there an API (#component) that provides access to this?
Usually during a run in Hudson some environment variables exists like JOB_ID etc. which you can use to detect if running in Hudson.
I am a Jenkins newbie and need a little hand holding because we only maintain parts of our app in SVN. I have basic Jenkins install setup.
This is what I do to get a local DEV environment setup and need that translated to Jenkins in order to make a build:
DO SVN checkout (and get the 2 folders that are under SVN)
Delete the folders
Copy over the full app from FTP location
Do SVN restore
download sql file
Import into MySQL
How would I get the above mentioned steps in Jenkins? I know there are some post build steps that I can use. Just not sure how to put it all together. Any help will be much appreciated.
Tell Jenkins about the SVN repository and it will check it out automatically when a new build is started. That should take care of 1. 2-5 would be build steps (i.e. execute shell commands). Basically, you can set up Jenkins to do exactly what you do on the command line, except that the first step is taken care of automatically if you tell Jenkins about the repository.
Rather than trying to do these sort of things in Jenkins, you'll likely save yourself some trouble if you make use of something like Ant or NAnt to handle the complexities for your build.
I've found that doing my builds this way gives me added flexibility (ie, if it can be done via the command-line, I can use it in my build, rather than needing a Jenkins plugin to support it), and makes maintenance easier as well (since my NAnt scripts become part of the project and are checked into the VCS system, I can go back if I make a change that doesn't work out.
Jenkins has some build-history plugins, but over time I've found it easier to keep the majority of my 'build' logic and complexity outside of the CI environment and just call into it instead.
The group that I work in has standardized on Jenkins for Continuous Integration builds. Code check-in triggers a standard build, Cobertura analysis and publish to an Artifactory SNAPSHOT repo. I've just finished adding a new target to the master build file that'll kick off a Sonar run but I don't want that running on every check-in.
Is there a way to schedule a nightly build of a specific build target in Jenkins? Jenkins obviously facilitates scheduled builds but it'll run the project's regular build every time. I'd like to be able to schedule the Sonar build target to run nightly.
I could, of course, create a separate Jenkins project just to run the Sonar target on a schedule but I'm trying to avoid that if I can. Our Jenkins server already has several hundred builds on it; doubling that for the sake of scheduling nightly builds isn't very desirable. I looked for a Jenkins plug-in that might facilitate this but I couldn't find anything. Any suggestions?
Here's one way to do it, if you are ok with triggering the build using cron or some other scheduling tool:
Make the build parameterized, and use a parameter in your build file to decide if the Sonar build target should run or not.
Trigger the build remotely by HTTP POST:ing the parameter values as a form to http://[jenkins-host]/jobs/[jobname]/buildWithParameters. Depending on your Jenkins version and configuration, you might need to add an Authentication Token and include this in your url.
Authenticate your POST using a username and password.
wget --auth-no-challenge --http-user=USERNAME --http-password=PASSWORD "https://[jenkins-host]/job/[jobname]/buildWithParameters?token=<token defined in job configuration>&<param>=<value>&<param2>=<value2>"
I am also looking for a solution for this. My current solution in my mind is to create 2 triggers in the regular build, one is the nightly build, another one is Polling SCM
In the sonar plugin configuration, it has the options to skip the builds triggered by the SCM change. Therefore, only the nightly build will start a sonar analysis.
I didn't get a chance to test it now, but I suppose this will work.
Updated on 12/19/2011
The above solution doesn't work if the sonar analysis is invoked as a standalone build step. To make the sonar analysis run conditionally, you could use the following 2 plugins:
Conditional BuildStep Plugin - this allows the sonar analysis to be run conditionally
Jenkins Environment Injector Plug-in - this allows you to inject the variables to indicate how the build is triggered.
I am trying to create 1 package with multiple build configurations. The first will checkout the code, build it (Solution File configuration), and run nunit tests. If that succeeds, another will then build in release mode. If that succeeds, a final script witll package up the output, and mark it as an artifact.
The problem I'm having is that I don't know how to tell TeamCity not to create new directories for each step, and as a result, the steps are failing. Is there a setting for this? It seems like the dependencies tab would be an appropriate place to look, but I don't seem to understand the instructions, and my tinkering so far has been fruitless.
I basically skipped most of the TeamCity workflow, and instead used a scripting language to handle all of this. (I used Rake and Albacore, which I highly recommend for .net projects)
I'd caution you not to use powershell w/ TeamCity. You have to wrap everything in .bat file, which is fairly excruciating.
So the result, is that I have 1 checkout, and everything builds from this point. It's drastically cut down the amount of time required for the builds, though perhaps that wouldn't be the case if I had a lot of agents available.