I'm setting up Jenkins for the first time and running into an issue where Jenkins does not appear to even attempt to execute the Ant task I've specified.
I've defined my JDK and Ant installations under Manage Jenkins.
I've setup my Job to Invoke Ant using the Targets 'war-all'
Whether I force a build or wait for it to naturally execute after the next commit, there is nothing in the Build Console Output about attempting to execute the ant task.
Here is a sample Console Output:
Any ideas as to why it might not be executing would be appreciated. Also tips on how I can find more logging from Jenkins which might provide clues as to why it is not executing would be helpful. I'm not sure what Logger I might specify or even then where the logging information is written on the file system.
The problem was that I was selecting "Build multi-configuration project" as the type of my job. When I select "Build a free-style software project" as my job type the Ant task will execute after the SVN update.
Looks like your svn doesn't see any changes and therefor is not re-building the module.
Try deleting the workspace and re-trigger the build, or change the check-out strategy to 'Always check out a fresh copy'.
I faced the same problem when upgraded to 1.417 from 1.413.
The combobox "Ant version" disappeared from "Invoke ant" build step. It should be here.
I just downgraded to 1.413 and continue to work.
So, the answer is - you should specify "Ant version" in project settings. But you cannot do it in 1.417.
It seems like Jenkins doesn't like when you create a job before configuring JDK. If that happens, job will never work properly. So, for me the solution was:
Delete job.
Configure JDK
Re-create job.
Probably the same problem may arise when job's JDK is deleted.
In my case,ant default target was not being picked up from build.xml so I had to explicitly mention the target in jenkins option.
I resolved this by changing the jdk to default and then again switched to what was set earlier.This is a workaround but not sure how this resolved.
Related
IntelliJ IDEA 2021.1 and 2021.2 leaves the Gradle Daemon running when I exit the program. I would like to know if there is a way to momentarily stop or restart the Gradle Daemon from within IntelliJ without exiting. Gradle has a lock on files that doesn't go away when simply closing IntelliJ. The only way to get it to release the lock is to run gradle --stop from the version of Gradle that is currently running. The approaches I've found so far are far less than ideal. I'll share them in case they help anyone else, but I'm hoping there's a better way.
If I manually browse to my User Home.gradle\wrapper\dists\gradle-x.y.z-all<hash>\gradle-x.y.z\bin for the version of Gradle that I know IntelliJ is using, then I can manually run that gradle command with --stop flag and it will stop the daemon. So, yeah I guess I could create a batch script for this, but the fact that it is stored in such a buried directory involving some sort of hash code, I don't really want to have to change this script for different systems.
In InteliJ IDEA, If I click the "elephant" looking button at the top of the gradle menu called "Execute Gradle Task" it brings up a command line that starts with "gradle", but it only accepts established task names, it doesn't accept "gradle --stop". It gives the error Unknown command-line option '--stop'.
As a less than ideal work around, I have copied the gradle-x.y.z folder from near the end of that path to c:\Gradle\ and I have added that version's bin folder to the PATH environment variable. So, at least, I can open up a command prompt and run gradle --stop for now. This becomes problematic when I want my default / command line accessible gradle version to be different from the project I am working on. Yeah I could create a bunch of custom batch scripts that point to all different versions. That doesn't sound like fun. I have a hard time believing that I can't do something within IntelliJ to get the currently running gradle daemon to shutdown.
IDE does not kill Gradle daemon, because this demon can be reused by another build, including when doing a build from the command line.
There is an action Show Gradle Daemons (you can call it from Help | Find Action action):
It will show you the list of Gradle daemons with the ability to stop them:
For now I have a batch file with commands for update projects using svn and calling maven 'clean install'. How to create some job in Jenkins for similar actions?
Should I write it to ant file (sorry if it's stupid idea, I've just heard about it but I don't know what is it exactly and what can I do with this) or there is other way?
Thanks
Like arghtype suggested, you need to be using Jenkin's own Source Code Management by configuring SVN as SCM source and supplying credentials as part of Maven build job.
If you have to use your own local working copy, you are organizing it wrong, you will lose on all the benefits of having Jenkins manage SVN changes, and in the end, this organization will give you more unsolvable problems in the future. Think about the advice people are giving here and come with up a reason why you need to have a local workspace outside of Jenkins management on a Jenkins build machine. My only guess is: your Jenkins and Development machine are the same. That again is not how it should be organized. Jenkins is a CI-server, not a personal build "automator".
Regardless, if you still want to do what you say.
What you think you want
Create a new Freestyle job
Under Build Steps, click Add build step
Select Execute Windows batch command
Write your batch execute command in there. Your working directory will be Jenkins's $WORKSPACE, so change your path accordingly to where you want to run it.
But with the above configuration, you might have as well put the batch file under windows scheduler... You are not really using Jenkins with the above.
What you should do instead
Create a new maven2/3 build job
Under Source Code Management, select Subversion
Under Repository URL enter the remote SVN repo (i.e. http://your.svnsever.com/path/to/project)
Under Build, enter your Root POM location (this will be relative to the location of your SVN checkout, so if your POM is under http://your.svnserver.com/path/to/project/maven/pom.xml, then enter maven/pom.xml.
Under Goals and options, enter clean install
Click Save
The Source Code Management section will take care of setting up a local workspace and checkout the repository into that workspace. By default, every time a new build is triggered, it will run svn update on that workspace for you.
The Maven Build step will take care of running your Maven, however note that it is configured to use default ~/.m2/repository location. If your local maven repo needs to be different, change this under Jenkins Global Configuration
Create a new job.
In Source Management choose Subversion, specify your repo and credentials.
Add a new build step - maven build, specify your maven goals ('clean install').
Jenkins is a CI(contiounus integration) server. It can be used to generate scheduled builds of ant or maven based projects. It can also start building projects by some triggering event such as a commit to SCM (git, svn, mercurial,...)connected to it. You really have to read its documentation to get a better understanding. It has nice tutorials.
I currently have a SoapUI project which I intend to have executed periodically (every 5 minutes) in Jenkins. I've completed the following thus far:
Created the relevant directory in the Workspace i.e workspace\SOA\SOAProject\src\test\soapui\SoapUIProject.xml
I've configured a pom.xml which sits in the SOAProject folder alongside the src folder
I've created a Jenkins job (I've chosen a Maven project, although it should not be an issue if I had chosen a freestyle job)
My question is, how do I set the endpoint?
I've done the following...
Build
**Root POM** pom.xml
Goals and options
testrunner.bat -e0.00.0.006:8040
Edit:
I've installed the EnvInject plugin. I'm not sure how to create the /properties file and what to put in their in order to set the execution environment?
I don't know the answer, but my suggestion is to get it running via command-line first. Once you figure out how to launch it without Jenkins, having Jenkins issue the same command because easy.
If you choose a Maven project, there is a useful plugin to set the endpoint and different propeties for the testSuites...
https://github.com/redfish4ktc/maven-soapui-extension-plugin
I have a shell script that runs lcov (test coverage) on an iOS project that I have Hudson. Hudson's copy of this project is derived from a Git repository. The way that I have set up now is that whenever the repo is updated or if someone manually builds the project in Hudson, Hudson would automatically run the app, and then run my shell script after the build is done. lcov can only be run after the app is not only built, but automatically run with some functional test tools. So, I cannot run the shell script as part of the build process, through XCode. It must be run after the app finishes building and running.
However, I would like to use this project in multiple Hudson jobs. Unfortunately, in each Hudson job, the iOS project is named differently. I would like to refer to the build path with some sort of environmental variable, but I don't know how to. Does anyone have any tips as to how to find that?
If I understand you correctly this is really a Hudson question. You can set "global variables" in your Hudson config and then invoke shell scripts, batch files, ant builds etc. You can also set them dynamically on each invocation of your Hudson job. Not sure exactly how to help you in your specific environment without more info.
I have just set up Hudson on my server. For some reason, my build will not call javac to compile my builds...? I have set the path to the JDK in the Manage Hudson area, and it seems to recognise it (doesn't give me a warning). Is there something else I'm supposed to do?
Here's a sample console output of one of my jobs (note how javac isn't called at all):
Started by user admin
Checking out
svn+ssh://myhost.com/Project1
A /src/Program.java
A build.xml
U
At revision 119
no change for
svn+ssh://myhost.com/Project1 since
the previous build
Finished: SUCCESS
You need to set the ant-target for your build.
Since this is a netbeans project you should have ant target like: compile, default etc?
One or more of these build target must be set in your job on hudson under the configuration menu. I think the field is called "Targets"
Some information on configuring ant in hudson: http://testinfected.blogspot.com/2009/01/hudson-default-anth.html