Thanks Baptiste. I'll detail the XWiki use case.
What we have: * https://ci.xwiki.org/view/Recommended%20Builds/ * We are using a GitHub Organization job type. * We have Jenkinsfiles in each repo of the GitHub organization, which all use a shared global pipeline library (see https://github.com/xwiki/xwiki-jenkins-pipeline/blob/master/vars/xwikiBuild.groovy ). * These Jenkinsfile are executed on each github commits and they trigger different maven builds in the same job * Inside the shared global pipeline library, we also schedule a monthy cron to make sure that even if there's been no commit to make sure we always have SNAPSHOT artifacts available in our Maven repo (we use Nexus and we clean SNAPSHOT artifacts), see https://github.com/xwiki/xwiki-jenkins-pipeline/blob/master/vars/xwikiBuild.groovy#L115 * We also have several "docker" jobs that execute functional tests on various configurations and for various branches. Those are executed once a day or once a week or once a month Now what I'd like to achieve: * Have a single Jenkinsfile per repo and also include what the "docker" jobs do inside our shared global pipeline library so that we don't have to manage branches manually (edit the "docker" jobs every time we add/delete branches). We create/remove branches every month so that would help us make it more maintainable. The issue: * We can trigger the Jenkinsfile execution based on cron triggers inside our scripted pipeline but I need to be able to differentiate what is supposed to be triggered: is it the monthly build to make sure we generate SNAPSHOTs? Is it the docker smoke tests one? Is it the docker on all config one? Is it the docker for unsupported config one? This is why I was thinking that https://github.com/jenkinsci/parameterized-scheduler-plugin could help me. Of course I'd prefer an "official" solution. Do you have an idea of how best I could implement my need? Thanks a lot -Vincent Le mercredi 26 décembre 2018 07:48:41 UTC+1, Baptiste Mathus a écrit : > > Hey Vincent, > > I'm still unsure if fully understood what you're trying to achieve. > > IIUC, for that stage that should happen only once a day, I guess it > depends. If something gets created there, like an artifact, could you maybe > simply check the timestamp of this artifact, and check it's at least 24 > hours old or something, and only run that stage if so? > > What type of job are you using? A multibranch pipeline one? > > Thanks > > Le mar. 25 déc. 2018 à 18:55, Vincent Massol <[email protected] > <javascript:>> a écrit : > >> Thanks a lot Slide. >> >> That's an interesting strategy. The problem I see is that we have several >> crons (and the cron frequencies are configurable). So ideally we would need >> to pass some variable alongside the cron trigger so that we could check >> which cron was triggered and build accordingly. >> >> Apparently this isn't possible right now in core jenkins. I've seen that >> there's this plugin which might allow this strategy: >> https://github.com/jenkinsci/parameterized-scheduler-plugin >> >> A bit of context: We'd like to have the job definition located in a >> shared pipeline library and triggered by a Jenkinsfile so that we don't >> have to manager jobs for the various branches (create new job when branches >> are created, remove job when branch is deleted). >> >> If someone knows a better solution than the >> https://github.com/jenkinsci/parameterized-scheduler-plugin plugin, >> please let me know. >> >> Thanks >> -Vincent >> >> Le mercredi 28 mars 2018 17:56:56 UTC+2, slide a écrit : >>> >>> I do this by checking the thing that caused the build: >>> >>> @NonCPS >>> def findBuildType(build) { >>> def causes = build.causes >>> def isHourly = causes.any { it -> (it instanceof >>> hudson.model.Cause.UserIdCause) || >>> (it.class.name.toLowerCase().contains('gitlab')) } >>> return isHourly ? "Hourly" : "Daily" >>> } >>> >>> >>> We use gitlab, so I look for gitlab in the name of the cause class and >>> this tells me it was kicked off by a push to git. Otherwise, it's a Daily >>> build and I can check that later in my code >>> >>> On Wed, Mar 28, 2018 at 8:48 AM Vincent Massol <[email protected]> wrote: >>> >>>> Hi guys, >>>> >>>> On XWiki we have a Jenkins pipeline committed in our SCM (in a >>>> Jenkinsfile) which looks like this: >>>> >>>> def globalMavenOpts = '-Xmx1536m -XX:MaxPermSize=512m -Xms256m' >>>> >>>> stage ('Commons Builds') { >>>> parallel( >>>> 'main': { >>>> node { >>>> // Build, skipping quality checks so that the result of the build >>>> can be sent as fast as possible to the devs. >>>> // In addition, we want the generated artifacts to be deployed to >>>> our remote Maven repository so that developers >>>> // can benefit from them even though some quality checks have not >>>> yet passed. In // we start a build with the >>>> // quality profile that executes various quality checks. >>>> xwikiBuild('Main') { >>>> mavenOpts = globalMavenOpts >>>> profiles = 'legacy,integration-tests' >>>> properties = '-Dxwiki.checkstyle.skip=true >>>> -Dxwiki.surefire.captureconsole.skip=true -Dxwiki.revapi.skip=true' >>>> } >>>> } >>>> >>>> // If the "main" build has succeeded then trigger the rendering >>>> pipeline >>>> build job: "../xwiki-rendering/${env.BRANCH_NAME}", wait: false >>>> }, >>>> 'testrelease': { >>>> node { >>>> // Simulate a release and verify all is fine, in preparation for >>>> the release day. >>>> xwikiBuild('TestRelease') { >>>> mavenOpts = globalMavenOpts >>>> goals = 'clean install' >>>> profiles = 'legacy,integration-tests' >>>> properties = '-DskipTests -DperformRelease=true -Dgpg.skip=true >>>> -Dxwiki.checkstyle.skip=true' >>>> } >>>> } >>>> }, >>>> 'quality': { >>>> node { >>>> // Run the quality checks. >>>> xwikiBuild('Quality') { >>>> mavenOpts = globalMavenOpts >>>> goals = 'clean install jacoco:report' >>>> profiles = 'quality,legacy' >>>> } >>>> } >>>> }, >>>> 'checkstyle': { >>>> node { >>>> // Build with checkstyle. Make sure "mvn checkstyle:check" passes >>>> so that we don't cause false positive on >>>> // Checkstyle side. This is for the Checkstyle project itself so >>>> that they can verify that when they bring >>>> // changes to Checkstyle, there's no regression to the XWiki build. >>>> xwikiBuild('Checkstyle') { >>>> mavenOpts = globalMavenOpts >>>> goals = 'clean test-compile checkstyle:check' >>>> profiles = 'legacy' >>>> } >>>> } >>>> } >>>> ) >>>> >>>> // If the job is successful, trigger the rendering job >>>> if (currentBuild.result == 'SUCCESS') { >>>> build job: "../xwiki-rendering/${env.BRANCH_NAME}", wait: false >>>> } >>>> } >>>> >>>> >>>> >>>> So we trigger several maven builds whenever a commit is pushed to >>>> GitHub (the xwikiBuild() step is located in a shared pipeline library of >>>> ours). >>>> >>>> Now I have the need to trigger another build in the parallel() step but >>>> that build should execute only once per day (for example). Is there a way >>>> to do this? >>>> >>>> I've googled and the only thing I've found is using the following >>>> syntax: properties([pipelineTriggers([cron('H 23 * * *')])]) >>>> >>>> However it's not clear to me how that would work: whenever a commit >>>> happens the JenkinsFile gets executed and thus if I have the following, I >>>> guess it's going to execute the build at each commit and not only once per >>>> day? >>>> >>>> parallel( >>>> >>>> ... >>>> 'quality-long': { >>>> node { >>>> >>>> properties([pipelineTriggers([cron('H 23 * * *')])]) >>>> xwikiBuild('Quality checks taking long') { >>>> profiles = '....' >>>> properties = '....' >>>> } >>>> }, >>>> >>>> ... >>>> >>>> >>>> >>>> I'd really like to not have to manually create a job using the Jenkins >>>> UI and instead have that job automatically created by the pipeline script. >>>> >>>> Is that possible? >>>> >>>> Thanks a lot >>>> -Vincent Massol >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> You received this message because you are subscribed to the Google >>>> Groups "Jenkins Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send >>>> an email to [email protected]. >>>> To view this discussion on the web visit >>>> https://groups.google.com/d/msgid/jenkinsci-users/2c99dc1f-6092-4607-bd00-314b3ba6e366%40googlegroups.com >>>> >>>> <https://groups.google.com/d/msgid/jenkinsci-users/2c99dc1f-6092-4607-bd00-314b3ba6e366%40googlegroups.com?utm_medium=email&utm_source=footer> >>>> . >>>> For more options, visit https://groups.google.com/d/optout. >>>> >>> -- >> You received this message because you are subscribed to the Google Groups >> "Jenkins Users" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to [email protected] <javascript:>. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/jenkinsci-users/c4e21a5f-f591-4bc4-9332-9b62634dea0f%40googlegroups.com >> >> <https://groups.google.com/d/msgid/jenkinsci-users/c4e21a5f-f591-4bc4-9332-9b62634dea0f%40googlegroups.com?utm_medium=email&utm_source=footer> >> . >> For more options, visit https://groups.google.com/d/optout. >> > -- You received this message because you are subscribed to the Google Groups "Jenkins Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c1729859-1963-4ae2-af94-76a9726ef1eb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
