I am building a new Jenkins job to install the package once a new build is ready.
If I set the Jenkins job run at every hour, how to avoid install the same build?
Example:
Build 1.139.506 just ready
Then Jenkins kins job trigger installation for build 1.139.506
At next hour, Jenkins job is triggered again.
If build is still 1.139.506, then stop job, no installation needed.
Else, repeat step to install new build.
There are different ways to achieve what you need.
Use an SCM repository and do polls on the repo. So Jenkins will only run the Job if the source code changes.
Use an SCM and tag the source when you release a new version, in this case, you can run the Job if a new tag is created in the SCM.
Save the last deployed version somewhere and check if the current version is different from the last deployed version.
Check the deployment environment for the deployed version and check if the current version is different, if so run the Job, else skip.
Related
I am using Jenkins, which is the only one allowed to publish to our maven repository, and gradle-release plugin to tag a version and move to new snapshot version. I noticed the tagged version wasn't getting built because the push happens after the new snapshot version is committed -- hence Jenkins builds the new snapshot version and skips the tagged version. Is there a way to configure the gradle-release plugin to first do a push after the tagged version and then do another push for the new snapshot version?
I looked into the source code of the plugin and installed it locally to see how it works. It turns out that the createReleaseTag task and commitNewVersion tasks actually perform separate pushes. I also checked the commits and found that they had different timestamps. I reckon that while our GitLab may have fired two calls to the Jenkins webhook, the short time in between the two commits is insignificant that by the time Jenkins pulls the changes for the one triggered by createReleaseTag, the newer commit created by commitNewVersion will have already been pulled along.
The solution I have in my mind now is to either create separate Jenkins jobs for the branches and tags, or to introduce some time delay in between createReleaseTag and commitNewVersion.
Update Jan 12, 2017
I settled on using the https://wiki.jenkins-ci.org/display/JENKINS/Release+Plugin where the Jenkins job pulled from both master and develop branches. The Jenkins release plugin added a Release page where the release version and next snapshot version can be inputted and submitted to do the ff:
Check out master
Run default job (which should run tests)
Run release task
Check out new tagged version
Run publish task
I'm setting up a development environment where I have Jenkins as CI server (using pipelines), and the last build step in Jenkinsfile is a deployment to staging. The idea is to have a staging environment for each branch that is pushed.
Whenever someone deletes a branch (sometimes after merging), Jenkins automatically removes its respective job.
I wonder if there is a way to run a custom script before the automatic job removal, then I would be able to connect to the staging server and stop or remove all services that are running for the job that is going to be deleted.
The plugin multibranch-action-triggers-plugin might be worth a look.
This plugin enables building/triggering other jobs when a Pipeline job is created or deleted, or when a Run (also known as Build) is deleted by a Multi Branch Pipeline Job.
In Jenkins, I have a "Build" job setup to poll my git repo and automatically build on change. Then, I have separate "Deploy to DEV", "Deploy to QA", etc. jobs that will call an Ant build that deploys appropriately. Currently, this configuration works great.
However, this process favors deploying the latest build on the latest development branch. I use the Copy Artifact plugin to allow the user to choose which build to deploy. Also, the Ant scripts for build/deploy are part of the repo and are subject to change. This means it's possible the artifact could be incompatible between versions. So, it's ideal that I ensure that the build and deploy jobs are run using the same git checkout.
Is there an easier way? It ought to be possible for the Deploy job to obtain the git checkout hash used from the selected build and checkout. However, I don't see any options or plugins that do this.
Any ideas on how to simplify this configuration?
You can use Parameterized Trigger Plugin to do this for you. The straight way is to prepare file with parameters as a build step and pass this parameters to the downstream job using the plugin. You can pass git revision as a parameter for example or other settings.
The details would vary for a Git repo (see https://stackoverflow.com/a/13117975/466874), but for our SVN-based jobs, what we do is have the build job (re)create an SVN tag (with a static name like "LatestSuccessfulBuild") at successful completion, and then we configure the deployment jobs to use that tag as their repo URL rather than the trunk location. This ensures that deployments are always of whatever revision was successfully built by the build job (meaning all unit tests passed, etc.) rather than allowing newer trunk commits to sneak into the deployment build.
I have build job with "Subversion" type of "Source Code Management".
Jenkins start update of SVN repository and then executes some build scripts.
But I do not want to update repository at once as I started this job.
I would like to run some check script and only then update repository or skip update step according to some conditions.
Is it possible to do it using some plugins or standard configuration of Jenkins?
PS.
I do not want to update repository from script manually.
You could use a multijob https://wiki.jenkins-ci.org/display/JENKINS/Multijob+Plugin
Phase A: poll for changes periodically in a script.
Phase B: run your checks
phase C: run the build - including checkout.
As each job runs in its own workspace by default you could even do a SCM poll/checkout in A which would not impact the job in C
I am creating a build that has 3 (sub builds) using the Parameterized Trigger Plugin to fire the builds I need built in a specific order.
The main build is using the Jenkins GIT plugin to monitor the repos I need so it can be triggered by a push to the branch I've declared.
The thing is, when I create the build at first (This is done through autojenkins) and trigger it to build, it builds but then in the middle of the first build a second build is scheduled and in the middle of the seconds build a third build is then scheduled, effectively building the same project 3 times in a row, although there has been no changes to the repos.
The reasons for build 2 and 3 are the same: Started by an SCM change but there is nothing to see in the polling log.
Can this behaviour be explained somehow?
Any help is greatly appreciated!
Here's some info on Jenkins:
Jenkins v 1.529 running on Ubuntu 12.04 on Amazon
Jenkins GIT plugin v 1.5.0
Parameterized Trigger Plugin v 2.20