I have a Gradle multiproject hosted in Mercurial repo. I would like to setup my Jenkins in such a way, that if I commit changes into only 1 subproject, then only that subproject will be built and published to my Nexus repo.
Can somebody give me a hint? Or is it at all possible?
We sort of have this working.
We create a project in Jenkins for each gradle subproject. And in the Jenkins configuration we build only the subproject by doing something like:
gradle clean :<subproject>:build
We still have the problem that the job is fired for all checkins to the entire project. I would to configure Jenkins to build only when there's checkin to the subproject, but don't know how to specify this.
Leaving our final solution for the future here.
We created a separate Jenkins job for each subproject. Jenkins' Mercurial plugin allows to specify "modules":
Reduce unnecessary builds by specifying a comma or space delimited list of "modules" within the repository. A module is a directory name within the repository that this project lives in. If this field is set, changes outside the specified modules will not trigger a build (even though the whole repository is checked out anyway due to the Mercurial limitation.)
This way our jobs are triggered only when change occurred in the monitoring sub-project.
I guess you need to create a project in jenkins for each subproject.
Other option would be to find if there is a way to intercept the repo sync and see what subproject has changed and do the build dynamically.
Related
Each time i generate my build through jenkins, my existing jar file in the target folder is overwritten by maven. For example: i have a existing version of 1.0 in jenkins target folder, now if i create a new build with version 1.1, the previous version in my target folder gets overwritten.
I don't want that to happen, i want to archive all the versions (because we might provide some of the old features to certain set of customers). i am just trying to understand is there way to do this in jenkins pipeline. I don't prefer plugins, it would be nice to do it declarative way using jenkins file.
First of all, it's not the best solution to store your artifacts just in target folder without any copying to other place. Usually all needed build artifacts are stored in Nexus or Artifactory repositories (of course, you can copy them to some local directory also). You can do that in pipeline Jenkinsfile as well, but you still require to install needed plugin. For example, for publishing artifacts to Nexus repo, you can use Nexus Platform Plugin, see this answer for details.
About overwriting your target folder, I'm not sure if it's cleaned by Jenkins by default. To clean workspace, you need to specify Discard old builds option in job configuration first.
Seems to be that you just execute mvn clean ... command, that's why target folder is cleaned, so I would recommend to check that first.
Current Setup: Ant deployments to salesforce using Jenkins for CI. Pulls from BitBucket repository with paramaterized build.xml stored in the repo. The build properties are set individually for each job in Jenkins.
The Problem: Build properties could be modified if someone changes the build.xml to not reference the variables set in Jenkins. Developers have the ability to change the testlevel, which we would like to prevent. Also, if we ever need to modify the build.xml, we don't want to have to cascade the changes across all of our branches.
Is there a way to remove the build.xml file entirely from the repo and store everything in Jenkins?
I think you are looking for the Config File Provider plugin:
https://wiki.jenkins.io/display/JENKINS/Config+File+Provider+Plugin
I have only played with it a little, but I think it will do exactly what you want. You will just have to copy the file in to the workspace before you run your build.
I have setup a CI Workflow in Jenkins to build project from bitbucket server.
I followed this Excluded Regions in Jenkins with Git
I made configuration such that ,when ever any changes are pushed into the repository, Jenkins will trigger a build.
I felt Repository is having too many checkins and each project is having separate workflows in Jenkins. So I used the "Polling ignores commits in certain places" option
But it seems not working.
I think this may be a bug as well.
Please see screenshot attached.
Scenario
I have 3 projects named Project1,Project2 and Project3
I want to look only changes in Project1 and then build.
For that i gave "Project1/.*" in the Included Regions. But even when changes are done to Project2 / Project 3, Jenkins triggers a build.
Doubt:
The Repository structure is as below
Project : TestForJenkins
Repository : JenkinsRepo
Project1,Project2,Project3,Packages,.gitignore
Since Project1 is at toplevel in repository, please let me know if i am giving wrong lookup path by providing "Project1/.*" in included region section.
I need to promote debian packages build in jenkins to the repo (aptly.. maybe artifactory). However, the available plugins seem to be broken for multiple branch projects. Has anybody found a solution to get around this?
You can use Artifactory Jenkins plugin for that. Define the deb files you want to upload (metadata will be generated by Artifactory for you).
Please note that you need to attach some properties to the uploaded files. From Jenkins you don't need to craft the URL, instead add the properties in the "Deployment properties" textfield.
I am just starting with Jenkins 1.487 and wanted to integrate Jenkins in my Ant project. But while configuring it, I can't find any way to make Jenkins re-use an already checked out codebase, instead of downloading a fresh copy relative to its workspace root. Is there a way to do that ?
I tried to specify a custom workspace manually (where my codebase was already checked out), and clicked on 'Build now'. The result was that it wiped out my current checked out code saying
"Checking out a fresh workspace because there's no workspace at /home/daud/Work
Cleaning local Directory ."
Not even a warning..
If you really want to build from an existing checkout somewhere on the file system, then do not use "Source Code Management" section of Jenkins. Leave it as "none"
Go straight to the "Build" section
Click "Add Build Step"
Select Invoke Ant"
Click Advanced
And under "Build File", provide a full path to the ant build file on your file system. You would have to include the drive letter (if on Windows) or a leading / (if on Linux) to break from the Workspace (by default, this path is relative to Workspace). Or use a lot of ../../../.. if needed.
But like others have said, this is not the way a CI system is supposed to be used
The idea behind Jenkins and CI is that it works on a fresh copy of the codebase. Every build done by Jenkins should not depend on any external preconditions and it should be reproducible.
You might want to try using the Clone Workspace SCM Plugin for Jenkins. It will allow you to zip up the workspace from one job and use it to create the workspace for another one. I've used this for downstream jobs that need to act on the work from a previous job.
This is also helpful if you're using something like Git for source control and want to avoid a second Git clone (or SVN checkout). Furthermore, you can limit the content of zip file that is used to recreate the workspace, for example to avoid carrying unnecesary files (e.g. the .git or .svn directories) downstream.