I can setup teamcity trigger to run tests whenever there in VCS checkin/ change.
Then I setup command line build steps to access files on system .
e.g. `custom script'
cd ~/Desktop
ls
But is there way to trigger test run if there is change in file e.g. test.txt
I want to setup trigger as 'if file changes run tests'.
Or it has to be git checkin?
You would add a new "VCS Trigger" under your project configuration and you would add a new "Trigger rules" specifying the file/directory that should trigger the build. For example: +:root=ContecIT:ContecRepairSystem/** (here I am saying monitor the VCS root "ContecIT", and watch for any files changes under the "ContecRepairSystem" directory.
I'm not aware of any "FileSystemWatcher" feature in TC for triggering builds, unfortunately. Sounds like a good idea for a new TC plugin.
I've checked (here) if perhaps there's such a plugin already. Seems not. The "Url Build Trigger" comes closest. You could try to fork and adjust it to suit your needs.
I think your use case is quite rare. Usually a TC farm comprises many TC agents, each running on a different machine. Thus, they can't monitor the same filesystem (e.g. the Desktop directory), except perhaps some shared folders...
VCS trigger configuration would monitor for any git checkin and triggers the build process
Related
I have a source code using which I want to test some processes through Jenkins.For that I've installed Jenkins and plugins as well. But I do not have internet access to my machine so I have my source code in a local folder instead of Git.
Please help me to configure Jenkins without git.
Thanks a ton in advance.
in the build steps, you can do something like
cd C:\users\user\Documents\Projects\
// build here
if you're in a different directory, you need to do:
cd D:\Projects
D:
// build here
But deleting the workspace option won't work now. since your artifacts will be stored in the current directory and the workspace is a different directory. you can add an additional step, in this case, to clean up things or you can change the workspace from the advanced option in the general tab.
I want to trigger a Jenkins job for a maven(v3.5.3) project from my local work space folder location instead of configuring SVN Repository URL in the Source code management section. Is there a way to achieve this?. I need to test with code modifications in the project and not wanting to commit the changes, that is the purpose.
I am using Jenkins (v2.161) and it is installed in another machine.
Thanks in Advance.
Although it might look like a sort of tinkering, the source code can be pulled to the Jenknins' host from your local machine, provided that they are properly configured to communicate via ssh.
In the project build configuration on Jenkins' host:
Do not use "Source Code Management" (choose "None").
Check "Delete workspace before build starts", to avoid conflicts with previous changes.
As the very first build step, add "Execute shell" and write a few commands that pull the data, for example:
scp myusername#myhost:/path/to/myworkspace/myproject/src .
scp myusername#myhost:/path/to/myworkspace/myproject/pom.xml .
# etc for all the files/dirs you need to build the project
Then continue with the build steps that were already used for building the project from SCM.
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.
What I have done :
I have Jenkins set up on my Ubuntu in :
/var/lib/jenkins/
I have a job, that runs every 45 minutes that does a hg pull and hg update --clean default
from my bitbucket repository.So this is running fine.I have a folder
/var/lib/jenkins/jobs/Code Deployement
which contains the latest updated code from my repository.
Problem :
However, I want to access my updated code from
/var/www/html/[project-name]
Query :
Is there anyway i can make jenkins job update this folder instead of the /var/lib/jenkins/Code Deployment folder ? I certainly dont want to make /var/www/html/[project-name] as my jenkins home folder.
How can I achieve what I described above.Will I have to copy the folder from the jobs folder to my desired location after every time the job runs ? Please help me out with the solution,I'am a beginner with automated deployment using Jenkins.
Thank you.
Under "Advanced" you can explicitly choose a working directory for the projects without changing the Jenkins home directory. Check the "Use custom workspace" box and set the directory that Jenkins will pull the code to and build in.
In our setup we wait for the build process to complete in the working directory and add a build step for Jenkins to copy (most) of the files out to the directory that serves up the website. We had issues with file locking preventing the build process if someone (e.g. the testers) were using the site.
One simple way to do it is to create a symlink under /var/www/html/ that points to your code directory, e.g.:
sudo ln -s /var/lib/jenkins/jobs/"Code Deployement" /var/www/html/[project-name]
How can I make Jenkins do the following?
Checkout trunk/ from SVN, then build configurations Debug and Release using CMake, without having duplicate jobs for the configurations.
Took me a while to figure this out. Here's how I managed to do it.
Create a free-style job "Checkout". This job is going to do all the stuff that doesn't depend on the configuration type (Debug/Release).
Under "Source Code Management" select Subversion
Fill in the Repository URL. Probably a good idea to make it point to /trunk.
Set Local module dir to "." (no quotes)
As Check-out Strategy "Emulate clean" is nice
Build trigger Poll SCM, set Schedule to "5 * * * *" to check every 5 minutes.
Now under Advanced Project Options check 'Use custom workspace' and set the dir to e.g. "c:/src". We don't want Jenkins to use its internal workspace, because we want other jobs to be able to access the source.
Under Build add the following Windows batch command, which is used to clean the build dir. For some reason, CMake doesn't provide a way to do this.
cd c:\
rmdir /S /Q build
mkdir build
cd build
cmake --version
rem optionally: svn info c:\src
cmake -G "Visual Studio 10" c:\src
Create another job "Build", this time make it a "multi-configuration" job. This job is going to run for each configuration (Debug/Release).
First, set the Build Triggers to build after job "Checkout"
Now under Configuration Matrix add an axis "configuration" with values "Debug Release" (whitespace = separator). Unfortunately, the CMake builder plugin for Jenkins doesn't work with multi-configuration jobs. We can't even use cmake --build, because it always builds the Debug configuration. To build, we have to use another batch script:
cd c:\build
call "%ProgramFiles(x86)%\Microsoft Visual Studio 10.0\VC\vcvarsall.bat"
msbuild ALL_BUILD.vcxproj /verbosity:minimal /maxcpucount:1 /property:Configuration=%configuration%
If you want to build the entire solution, specify the .sln file instead of ALL_BUILD.vcxproj. If you only want to build a specific project, use
msbuild <solution>.sln /target:<project>
Use Jenkins Matrix job. Define one of the axes as build_mode with values Debug and Release. You then run CMake that will create both configurations for the compilation tool you'll be using (XCode, gcc, VisualStudio, etc.). You can then use build_mode as if it were an environment variable and pass it to build steps that do actual compilation.
When using the Visual Studio generator you can pass the configuration to build to the cmake --build-command:
cmake --build . --config Release
cmake --build . --config Debug
See also the CMake docs.
After using Jenkins for a while now, I found that you should use as few jobs as possible if you want to reuse the source directory.
The default setup in Jenkins is that each build uses a different directory as its workspace. Which implies that you do a complete SVN checkout every build. Which takes forever.
If you want to use the same source directory for every build, you have to worry about synchronization: Only one build at a time. As far as I know, Jenkins has no built-in means of synchronization. The only way is to only use one executor. Even then you can't control the way the executor chooses its next job.
Let's say job "SVN update" triggers job "Build". Someone starts "SVN update #33", which is supposed to trigger "Build #33". If, however, Jenkins' "Poll SCM" feature schedules "SVN update" #34 in the meantime, I haven't found a way to tell it that "Build #33" must run before "SVN update #34". So you might end up with "SVN update #34" running before "Build #33", and everything fails. Unless you manually disable the polling job. And remind yourself to re-enable it afterwards, of course.
Anyways. After using Jenkins for two years, I change my answer to: Never use multiple jobs that share resources (like the source dir), and bake all the logic into shell scripts (for loop over configurations).