Wanted to accommodate scheduled build starting 12AM every 3 hrs till 3PM on every weekday(mon-fri). It should be triggered build only if anything is committed into github repository.
Please provide the exact code as few code is working for multi-branch but not for above schedule.
Sorry what do you mean by the scheduled "build"?
Do you want the Multi-Branch to check for more branches on your given interval?
If so you can only do it by "Scan Multibranch Pipeline with defaults Triggers"
Do you want to issue a build on the branch when there is change on it?
Noted that the option in
the mult-branch folder > "Scan Multibranch Pipeline with defaults Now" and get all current branches > status > the jobs > View Configuration
is read only.
So, to alter the option, from https://issues.jenkins-ci.org/browse/JENKINS-33900?focusedCommentId=326181&page=com.atlassian.jira.plugin.system.issuetabpanels%3Acomment-tabpanel#comment-326181
, I think you should use the Jenkinsfile to do theSCM for every job.
So, for all jobs you need to configure for SCM poll,
include a Jenkinsfile on Git for each of them (Don't forget to install the pipeline-model-definition plugin and all its dependent plugins):
pipeline {
triggers {
pollSCM('H 0-15/3 * * H(1-5)')
}
agent any
stages{
stage('Build') {
steps {
echo 'Building.. or whatever'
}
}
}
}
That should do the job, at least it works for me``
Hope it helps
Related
I have multi-branch pipeline job in Jenkins:
http://illinXXXX:XXXX/job/OC/configure
and I checked the option for Discard old builds as below:
I would have expected, that each new run after this change, it will delete old build from the server for each Repository inside that pipeline. however, I see all builds are still there, which causing me a File system issue.
Jenkins link:
http://illinXXX:XXXX/job/OC/job/productconfigurator-ms/job/master/
From server:
jenkins#XXXXX:jenkins/jenkins-production/jobs/OC/jobs/productconfigurator-ms/branches/master/builds>
I see builds from 541 to 1039
Jenkins ver. 2.176.1
The interface you pasted is for the Orphaned items. Orphaned items refer to deleted branches, where no Jenkinsfile is available.
For the Multibranch pipeline, the instructions to build each branch are inside that branch's Jenkinsfile. This is where you need to define these limits.
Use the following in your Jenkinsfile (from above, in master branch):
options {
buildDiscarder(logRotator(numToKeepStr: "100"))
}
Make sure to use string (as in "100") and not number (as in 100).
Parameters:
daysToKeepStr: history is only kept up to this many days.
numToKeepStr: only this many build logs are kept.
artifactDaysToKeepStr: artifacts are only kept up to this many days.
artifactNumToKeepStr: only this many builds have their artifacts kept.
You may need to run your master pipeline manually once for it to work.
This is the equivalent of scripted-pipeline:
node('some-label') {
properties([
buildDiscarder(
logRotator(
artifactDaysToKeepStr: "10",
artifactNumToKeepStr: "50",
daysToKeepStr: "10",
numToKeepStr: "50")
)
])
stage('Maven Compile') {
}
stage('Some other steps') {
}
}
In freestyle Jenkins jobs, there is a post-build step called "JIRA: Update relevant issues". This job will add comments in the the appropriate JIRA tasks (based on commit messages) saying whether the build succeeded or failed.
[![JIRA: Update relevant issues][1]][1]
[1]: https://i.stack.imgur.com/aBJVZ.png
I am wanting to do the same thing from a pipeline job.
As far as I can tell, there's nothing built-in that does all of that in one step like the post-build step for freestyle jobs does.
I am able to use the jiraComment pipeline step to add comments to Jira items, but I still need to figure out from the commit messages which Jira items need to be updated.
I am trying to use the jiraIssueSelector pipeline step to do that.
When I put the following in my Jenkinsfile:
def issueKeys = jiraIssueSelector(issueSelector: [$class: 'DefaultIssueSelector'])
echo "${issueKeys.size()}"
And run it against a commit with the commit message "DEVO-2398 DEVO-2399", it gives me the output
[Pipeline] jiraIssueSelector
[Pipeline] echo
0
The jiraIssueSelector is not finding any jiraIssues in the commit message.
When I run a freestyle job with the JIRA: Update relevant issues post-build step against that same git commit, it finds both Jira issues. I get the following output:
[JIRA] Updating issue DEVO-2399
[JIRA] Updating issue DEVO-2398
So my question is twofold:
Is there an easier way to replicate the functionality of the Jira post-build step in pipeline than by combining jiraComment and jiraIssueSelector?
Assuming that there is not, what am I doing wrong with jiraIssueSelector? Why is it not finding any Jira issues in the commit message when there the Jira post-build step is able to find them just find them just fine?
So I have a pipeline with multiple stages and with each stage there are couple of build job processes. When I run the pipeline and there is a failure in any one of the builds the stage fails and doesn't build the other builds in the stage. How can I get around this so it builds the remaining jobs in the stage?
you can use the convention
try {
// your build steps
} finally {
// always run...
}
We are just starting out using Jenkins Multi-branch pipelines. I like the idea of Jenkins automatically creating a new Jenkins job when a new branch is created. It will make sure that all releasable development is being built in Jenkins. We have about 40 or 50 projects that get branched for almost every release, and creating those 40 or so jobs every time we branch is error prone work.
However, I see there are two types of pipeline builds in Jenkins:
Regular Pipeline builds: You specify the location and branch in your Jenkins job. However, you can specify whether you want to use the script inside your Jenkins job configuration, or a script from your source repository. This would allow us to maintain a single Jenkinsfile for all of our jobs. If we change something in the build procedure, we only have to edit a single Jenkinsfile.
Multi-Branch Pipeline builds: Jenkins will automatically create a new Jenkins job for you when a new branch is created. This means we no longer have to create dozens of new Jenkins projects when a new branch occurs. However, it looks like the Jenkinsfile must be located on the root of the project. If you make a basic change in your build procedure, you have to update all Jenkins projects.
I'd like to be able to use the Multi-branch Pipeline build, but I want to either specify where to pull up the Jenkinsfile from our repository, or include a master Jenkinsfile from a repository URL.
Is there a way to do this with Jenkins Multi-branch pipelines?
If you have common build logic across repos, you can move most of the pipeline logic to a separate groovy script. This script can then be referenced in any Jenkinsfile.
This could be done either by checking another checkout of the repo that the the groovy script is in to another directory and then doing a standard groovy load or, probably the better approach would be by storing it as a groovy script in the Jenkins Global Script Library - which is essentially a self-contained git repo within Jenkins
(see https://github.com/jenkinsci/workflow-cps-global-lib-plugin/blob/master/README.md for more details).
We had a similar requirement, and created a global groovy method in a script that was maintained in Git and deployed to Jenkins' Global script library under /vars/ when it changed:
e.g. the script 'scriptName.groovy' has
def someMethod(){
//some build logic
stage 'Some Stage'
node(){
//do something
}
}
That way the common function could be called in any Jenkinsfile via
scriptName.methodName()
We have a Jenkins server, using jenkins-build-per-branch to sync from git whenever a (php or java) project has a valid pom.xml. We use maven versioning strategy to manage our artefacts, and git-flow as a branching strategy / tool. We also use the jenkins option "Build whenever a SNAPSHOT dependency is built" wherever possible.
The problem we have is when building a -SNAPSHOT artefact - all hell breaks loose and everything wants to build at once. (Building a 'develop' -SNAPSHOT causes all downstream 'feature' AND 'develop' branches to start)
Ideally we would like to find some way that we don't cross pollenate between feature and develop builds when jenkins launches downstream jobs.
Has anyone tried this? Would something like the Conditional+BuildStep+Plugin help? https://wiki.jenkins-ci.org/display/JENKINS/Conditional+BuildStep+Plugin
This is an old question but it's still relevant 6 years later. There is a "threshold" field on the Build whenever a SNAPSHOT dependency is built setting that provides some control over which builds will trigger
From the pipeline-maven-plugin README:
Threshold based on the Maven lifecycle phase reached in the Maven
build of the upstream job (package, install, deploy). By default, only
the maven builds who reach the deploy phase will trigger downstream
builds.
For example, in a scripted pipeline's withMaven() you can set a pipelineGraphPublisher with lifecycleThreshold: 'deploy' like:
withMaven(
maven: MAVEN_VERSION,
jdk: JAVA_VERSION,
mavenOpts: MAVEN_OPTS,
globalMavenSettingsConfig: globals.MAVEN_SETTINGS_ID,
options: [
pipelineGraphPublisher(
lifecycleThreshold: 'deploy',
includeSnapshotVersions: true
)
]) {
sh("mvn ${PHASE}")
}
Then any SNAPSHOT build that executes a lifecycle phase below deploy (e.g. package or install) will not trigger a downstream job. Note that deploy is already the default so this example isn't particularly useful, but it shows how to use the setting and you may want to set this to another phase.
That's part one done, but now you need a way to conditionally execute different Maven lifecycle phases for the builds that you do want to trigger downstream builds vs. the ones that you don't want to trigger downstream builds. We do this based on the branch name so that Pull Request and Release branches don't trigger upstream packages:
/**
* Return the correct Maven goal for the current branch
*
* Because the pipelineGraphPublisher's lifecycleThreshold in the withMaven() call above is set to 'deploy', pipelines
* that run the 'install' goal will not trigger downstream jobs; this helps us minimize superfluous Jenkins builds:
*
* https://github.com/jenkinsci/pipeline-maven-plugin/blob/master/README.adoc#trigger-downstream-pipeline-when-a-snapshot-is-built
*/
String getGoalForCurrentBranch() {
if ( env.BRANCH_NAME ==~ /(^PR-(\d+)$)|(^releases\/v.*)/ ) {
echo("Pull Request or release branch detected! Executing Maven 'install' goal rather than 'deploy' goal to avoid triggering downstream Jenkins jobs")
return 'install'
}
return 'deploy'
}
You can then call this getGoalForCurrentBranch() method wherever you're executing mvn to determine which lifecycle phase is executed:
withMaven(
...
sh("mvn ${getGoalForCurrentBranch()}")
)
Most branches will execute mvn deploy and will trigger a downstream Jenkins job, but Pull Request branches will execute mvn install and will not trigger a downstream job.
The caveat to this is that you may have other things that depend on certain lifecycle phases. In the above example, Pull Request branch artifacts won't get deployed to your artifact repository (e.g. Nexus). In our case this is actually the desired behavior but you'll need to determine what's acceptable for you and tweak your threshold accordingly.
In the dependent projects you can disable the "Build whenever a SNAPSHOT dependency is built" hook via
if (branchName.indexOf("mule4auto") >= 0) {
println "for mule4auto do not build when mulestac is build";
// for mule4auto do not build when mulestac is build, wait for
// mule4auto-converter project has run (commited something).
} else {
tempPipelineTriggers += [
snapshotDependencies()
];
}
println "triggers: tempPipelineTriggers=${tempPipelineTriggers}";
Additionally you may need to disable the fingerprint for the specific branches which should not be build (mule4auto in our case):
// see https://github.com/jenkinsci/pipeline-maven-plugin/blob/master/README.adoc
def tempMavenOptions = [];
// disable Archiving (fingerprinting should still work)
tempMavenOptions += artifactsPublisher(disabled: true);
if (branchName.indexOf("mule4auto") >= 0) {
println "Disable fingerprint for mule4auto to prevent jobs building when mulestac4 SNAPSHOT is build";
tempMavenOptions += dependenciesFingerprintPublisher(disabled: true);
tempMavenOptions += pipelineGraphPublisher(disabled: true);
}
// see https://plugins.jenkins.io/pipeline-maven
withMaven(
// Maven installation declared in the Jenkins "Global Tool Configuration"
maven: toolMaven,
jdk: toolJdkToBeUsed,
options: tempMavenOptions
) {
println "JAVA_HOME ${JAVA_HOME}";
println "MAVEN_HOME ${MAVEN_HOME}";
....
})
(both in destination pipeline)
I do not see an option like "Build whenever an upstream dependency is built" in our Jenkin's jobs. It's called "Build whenever a SNAPSHOT dependency is built" here (Jenkins v1.592 with its latest plugins). Is that what you mean?
There's also this last sentence in its inline help: "If this behavior is problematic, uncheck this option." :-)
I don't know whether Conditional BuildStep Plugin would help in this case. We use it but not to achieve such.
Depending on how long your jobs run I'd suggest to:
use the Build whenever ... in conjunction with Advanced Project Options → Quiet period if the jobs don't run long (let's say a few minutes)
deactivate the build-whenever-all-and-everywhere as suggested and use Post-build Actions → Build other projects or Trigger parameterized build on other project to establish a real up-/downstream build flow if your jobs run longer