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] > <javascript:>> 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] <javascript:>. >> 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]. To view this discussion on the web visit https://groups.google.com/d/msgid/jenkinsci-users/c4e21a5f-f591-4bc4-9332-9b62634dea0f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
