My situation is the following:
I have three branches in a repo: master, dev and staging.
And I have one job for each one of these branches, configured in 'Branches to build' section in Jenkins. origin/master, origin/dev, origin/staging.
Bitbucket triggers the job to build whenever there are changes to the repository via a repository hook .(https://confluence.atlassian.com/display/BITBUCKET/Jenkins+hook+management).
However, when I push to master, all jobs starts to build, and the same with the other two ones.
I want Jenkins "master" job to be built only when I push to master branch. Jenkins "dev" job to dev branch. Jenkins "staging" job to dev staging.
Is there a way to control this behaviour?
Did you set up polling?
https://wiki.jenkins-ci.org/display/JENKINS/Git+Plugin#GitPlugin-Pushnotificationfromrepository
... This will scan all the jobs that's configured to check out the specified URL, the optional branches, and if they are also configured with polling, it'll immediately trigger the polling (and if that finds a change worth a build, a build will be triggered in turn.) We require the polling configuration on the job so that we only trigger jobs that are supposed to be kicked from changes in the source tree.
I just discovered that Bitbucket does not allow to choose a specific hook when pushing to branches. It just calls all the hooks, then it starts all Jenkins' jobs.
My solution was to create a specific file on my machine, on which Jenkins is installed and set a Bitbucket hook to this file. (e.g. http://{jenkins url}:{apache port}/check.php)
Note that this apache port is not the same of Jenkins', but Apache's. In my case, Jenkins was running at 8080 and Apache at 7777. It did this to run php script, but not in Jenkins' directory.
Since Bitbucket hook sends a json file, I was able to verify in check.php which branch has been pushed on.
Reference: POST hook management
After the verification using a simple 'if', I just called the right url to start the right job with exec_curl, like:
$ch = curl_init();
curl_setopt($ch, CURLOPT_URL, http://{jenkins url}:{jenkins port}/job/{job name}/build?token={job token});
curl_setopt($ch, CURLOPT_HEADER, 0);
curl_exec($ch);
curl_close($ch);
And voilà.
To have different Jenkis projects for different branches I did the following:
Install Bitbucket Plugin at your Jenkins
Add a normal Post as Hook to your Bitbucket repository (Settings -> Hooks) and use following url:
https://YOUR.JENKINS.SERVER:PORT/bitbucket-hook
Configure your Jenkins project as follows:
under build trigger enable Build when a change is pushed to BitBucket
under Source Code Management select GIT; enter your credentials and define Branches to build (like **feature/*) <- this is where you define different branches for each project
By this way I have three build projects, one for all features, one for develop and one for release branch.
And best of it, you don't have to ad new hooks for new Jenkins projects.
Yes!! You can trigger the jenkins build whenever there is a commit or merge into a specific branch of the git repo.
STEPS:
Configure the webhook for your jenkins instance in the Webhook section of the github Repository, the Payload URl will look similar to,
http://jenkinsinstance:8080/github-webhook/
In the Jenkins Job configuration just enable,
GitHub hook trigger for GITScm polling
Then in the SCM section add the below configuration available in the image, assuming the branch you want to build being the Hotfix branch. The Below image defines the exact configuration of SCM section.
SCM Configuartion image
Once done, try to commit code changes to the Hotfix branch, which in return should trigger the jenkins job.
Related
I am working on a project which needs me to migrate the storage of artifacts from PVCS to Azure Devops. (Problem statement was provided like that)
Current Setup:
The Jenkins Pipeline takes a master.xls file from a folder created (unique for each build number) in PVCS and based on the data manually entered into master.xls, it interacts with Pega DB and creates an Artifact (Rules.Zip).
To interact with the PEGA DB, the Jenkins job executes few Java programs and executes a few batch and ant scripts. The ant scripts produce the artifacts.
Finally it stores that artifact in the same PVCS folder created initially with an empty master.xls file.
Jenkins is interacting with PVCS usling PCLI commands which will be executed from Java programs run by Jenkins jobs.
Required Setup:
The PVCS needs to be replaced with Azure Devops, i.e. the Jenkins Pipeline should be able to do the following:
Create a folder in Azure Devops with an empty master.xls
After master.xls is updated manually, The pipeline should be interacting with Pega DB as usual and store the artifact thus created into Azure Devops.
I am pretty new to Azure Devops. Kindly help me understand if the said requirement is possible and If so, how can that be achieved. A list of abstract steps would be of great help. I will work on them.
There is Jenkins Download Artifacts task in azure devops pipeline that you can make use of to download the artifacts from Jenkins pipeline to azure devops pipeline.
First you need to create Jenkins service connection in your azure devops project.
Open the Service connections page under the project settings page, and select New service connection and choose Jenkins.
Then you can initialize a empty azure repo. Click the + beside your project name and select New Repository
Then you need to create a build pipeline, selecting your azure repo as the location of your source code. Below example is in classic view(Choose use the classic editor to create a classic view build pipepline).
Then choose start with an empty job to create a empty build pipeline
When your pipeline is initiated you can add Jenkins Download Artifacts task to download the artifacts from Jenkins pipeline.
And you can add command line task to run git command in your pipeline to commit and push the artifacts to your azure repo.
You can also add Publish build artifacts task to publish the artifacts to azure devops pipeline server.
Here is more information about how to integrate Jenkins with azure devops.
I am suspecting you want the file stored in version control... Right? Cause, like #DanielMann suggests, you can attach the file as a Build Artifact or as a package in an Artifact feed. You can use the Azure CLI + DevOps extension to interact with the package feeds:
If you want to store it in version control... What kind of version control has been selected in Azure DevOps, Git or TFVC?
If TFVC, you can use tf.exe from jenkins or this set of tasks for Azure Pipelines to store the artefact in TFVC.
If Git, you can use git.exe in both jenkins and Azure Pipelines to add, commit and push the changes to the Git repository.
I am learning Jenkins. Can someone tell me if my understanding is correct?
To build the app:
I commit my code and push my branch to my remote repository.
Jenkins sees my commit and triggers off a build (possibly using maven install).
Jenkins runs all the tests and if all pass, a war/ear is created. This artefact is pushed to nexus.
To deploy to an environment:
A deploy script in my branch contains steps to deploy the app to, say, Tomcat.
Jenkins goes to Nexus, retrieves the latest artefact (built above), and deploys this app to Tomcat.
Other steps in the deploy file shutdown and restart Tomcat as necessary, possibly testing to make sure the app started and is ready to serve requests.
Am I right in saying that a deploy doesn't need to build the latest artefact, that it uses that last one pushed to Nexus, or is a fresh one built every deploy?
It's all according to how you set up your build on Jenkins and/or git.
Jenkins can be configured to monitor your repository (repo, for short) and to kick off a build when it detects a change.
Jenkins can be configured to run a build. You provide the Maven command-line arguments; Jenkins just orchestrates the commands you give it.
Some of the steps you provide Jenkins will be shell code. This is how you can run custom shell scripts, say to access Nexus. Things don't happen by themselves; if you tell Jenkins to deploy an artifact, say by using Maven, then Jenkins will invoke the deployment command as you told it to.
It is highly irregular for an app deployment to arrogate responsibility to start, restart, or shut down your server (Tomcat). That could be done via Jenkins, sure, but it's at a higher "pay grade" than an app deployment should have. Keep it simple; if your Jenkins build is managing an app for testing and deployment, keep its focus on the app and not on the server.
Jenkins is magical, but it's not a mind reader. It will do none of the things you said unless you tell it to. That said, the process you outlined is a reasonable one, whatever tool you use to enact it. Jenkins certainly can do those things, if you set it up accordingly.
We are using the standard git flow branching model (develop, master, release-, hotfix-, etc).
As part of our workflow, we would like to set up a "one-click" release via jenkins.
I was looking at the jgitflow-maven-plugin. Can I set up this plugin to do a one-click release from jenkins? If so, what are the configuration options?
In particular, can I do something like this?
Jenkins Job
Maven goals: release-start release-finish -Dsomething -Delse
And is there a way tell it to automatically build from the latest -SNAPSHOT version, e.g. if the version is 1.2.3-SNAPSHOT it would build release-1.2.3.
Otherwise, is there a maven plugin that builds releases according the git flow branching model (i.e. build from develop and create a new release branch named release-x.y.z).
Although this answer is one year old I'd like point out that meanwhile the jgitflow (v1.0-m5.1) works with maven batch mode.
So to release an artifact with just one command you can execute:
mvn --batch-mode jgitflow:release-start jgitflow:release-finish
You don't need to set developmentVersion and releaseVersion.
JGitFlow will use the current version minus the -SNAPSHOT part as release version. Then it increments the least significant digit and adds -SNAPSHOT again for the next development version.
Example 1.0.0-SNAPSHOT --> Release: 1.0.0, next Development version: 1.0.1-SNAPSHOT
In order to configure a single click Jenkins release job you need to configure some things regarding Git.
Under Source Code Management > Git > Additional Behaviors select
Wipe out repository & force git clone: just to make sure the workspace is clean
Checkout to specific local branch: your develop branch.
Finally, the release happens locally on your Jenkins server, so you want to push back the changes to your Git remote server.
To accomplish this, the easiest way is to add a Post-build action which executes the following bash command (the branch names may vary, I've used the JGitFlow default values):
git push origin develop master --tags
Note If Jenkins is running on Windows you either have to execute a Batch script containing the same command (sometimes this doesn't work due to SSH issues with Windows) or configure the Git Publisher Post-build action accordingly.
You can simply use the jenkins plugin M2 Release Plugin with the release goals an options
-B -DautoVersionSubmodules=true jgitflow:release-start jgitflow:release-finish
We ended up with starting the release via CLI on the client (because in Jenkins there is a bug starting the release).
git flow release start -DautoVersionSubmodules=true
If you want to use the batch mode you need to specify developmentVersion and releaseVersion.
Created a new job in Jenkins to build the release branch and use the M2 Release Plugin to release it finally:
-B jgitflow:release-finish
If you use some custom profiles, you have to pass them additional via arguments caused by a bug.
-Darguments=-Pprofile
We never found a way to get this to work via a plugin or maven goal in Jenkins.
Our solution ended up with a bash script that did git flow release start <version>, maven release process, git flow release finish <version> and other things (git pull on develop and master at very start, git push and slack notification at very end).
I have a maven project which uses git for version control. I have setup jenkins to perform maven builds for specific revisions of my repo. What i have thought is, I can use puppet to deploy specific builds done by jenkins.
Is there any other workflow which i can try, when using git,maven,puppet and jenkins?
Currently we a have a "per feature" branch flow
I've setup jenkins with several jobs
my_project-ci : one that poll the git server and do continuous integrations on all branch starting with origin/feature/*
then we a have a build pipeline
my_project : launch test, once the something is merged in master, it then archive the workspace and trigger the following job
my_project-staging : this one deploy automatically to the stating servers
my_project-production : this one is triggered manual
the cycle looks like :
local : Clone -> git branch -b feature/super-feature -> commit -> local build -> git push
jenkins : Jenkins cron for origin/feature/*
local other dev : review the feature via pull request
local : fix -> commit -> local build -> push
local other dev : merge the pullrequest in master
jenkins : Jenkins cron origin/master
jenkins : trigger my_project-staging
local : validate deployment and trigger manually the my_project-production
jenkins : deploy to production
I'm not a big fan of using puppet for deployment, it works great for provisionning but it handles badly orchestration of deployments (eg run db migration, in a cluster, remove one member from load balancer, deploy, re-add to balancer). Take a look a tools like ansible, capistrano,...
Well all tools you have described are orthogonal to each other.
typical workflow is
Clone -> commit -> local build -> push -> Jenkins cron -> deply
I have a local git server (centOS) where everyone pushes their work to that repository. Jenkins manages to build whatever in that repository is, overnight. Lately I've got a Git Enterprise account. I've been wondering if there's any way to force Jenkins to 1) Only pulls the code from the local server and 2) Whenever a build was successful, sends the code to git enterprise remote repository.
I'm using Jenkins v. 1.458
well, one option would be to just create a script that does this from bash...but...
You can just add two git repositories under the "source code management" section after installing the Multiple SCMs plugin, and then specify that you want to build REPOLOCALNAME/branch, and then at the end under 'Git publisher' specify you want to merge and push to the remote branch. (ie. BranchToPush=branchname and TargetRemoteName= REMOTEREPONAME)
*Remember, the names are specified under advanced options of the repository when you add it under the SCM section.
*I haven't tested this, there is a chance that it might let you only pull and push, from and to the same repository.
You could set up the push to Github as the last build step that is only run after everything else has succeeded and use the normal mechanisms for retrieving the code from the local git repository. There is no plugin that has this functionality at the moment.