Right now, the example jobs in example-jobs are a mix of cases, hyphens, and so forth. Let's pick a consistent scheme and apply it to all example jobs

to match the convention in the rest of this repo's software

likewise, use_versions should turn into useVersions, and all other configs/variables turned from under_scores to camelCase

create all build flow jobs with a workspace. Near as I can tell, there's no downside, all upside

change this to logRotator { numToKeep(30) }

I propose that the FlowJob automatically add a buildFlowTestAggregator block:

configure { 
it / publishers << 'org.zeroturnaround.jenkins.flowbuildtestaggregator.FlowTestAggregator' {
      showTestResultTrend true
 }
}

@imuchnik
This stems from a conversation I had with Vic this morning about OaH's build flow and how it's not a straightforward list of jobs but instead has a parallel block.

My comment to Vic was to keep this as simple as possible, not get clever or fancy, not reinvent any wheels, and not fall into the trap of the "wrapper" being more complicated than the thing it's wrapping.

I recommended having our build flow builder offer 2 possibilities for creating a flow job: 1) an array of job names; 2) a closure that contains the entire build flow

For #2, I should've said string, based on my now-corrected understanding of buildflow job-dsl (https://jenkinsci.github.io/job-dsl-plugin/#method/javaposse.jobdsl.dsl.DslFactory.buildFlowJob)

Basically, I should be able to do something like:

new BuildFlowBuilder(blahblah, jobs: ["job1","job2"])

Or

new BuildFlowBuilder(blahblah, jobConfig: '''
build("job1")
parallel {
  build("job2")
  build("job3")
}
build("job4")
'''

Or some such thing. But nothing more complicated than that. Basically, make easy things easy (option #1), and hard things possible (option #2), but without making option #2 so onerous (by being clever or fancy) that people rip out their hair.

Thoughts?

Appreciate this maybe more an issue with the https://github.com/cfpb/jenkins-as-code-starter-project repo

I'd like to check out this project but am having issues with the seed job. https://github.com/cfpb/jenkins-as-code-starter-project/blob/master/README.md#creating-the-seed-job states that you will need a multiscm for both the automation and jenkins as code repo. Assuming this is not directing me to checkout both repos to the same top level directory, I have:

ls -ll /var/jenkins_home/jobs/jenkins-dsl-seed/workspace/
total 8
drwxr-xr-x 8 jenkins jenkins 4096 Jan 30 14:52 jenkins-automation
drwxr-xr-x 7 jenkins jenkins 4096 Jan 30 14:52 jenkins-jobs

but when I run this job, looking for jenkins-jobs/jobs/*.groovy I'm getting unable to resolve class BaseJobBuilder errors, which is to be expected. I have tried setting the additionalClasspath: jenkins-automation/src/main/groovy to no avail. My seed jobs is:

job('seed') {
    multiscm {
        git {
            remote {
                name('origin')
                github('cfpb/jenkins-automation', 'https')
            }
            branch('*/master')
                configure { node ->
                    node / 'extensions' << 'hudson.plugins.git.extensions.impl.RelativeTargetDirectory' {
                        relativeTargetDir('jenkins-automation')
                    }
                }
        }
        git {
            remote {
                name('origin')
                github('joshmyers/jenkins-jobs', 'https')
            }
            branch('*/master')
                configure { node ->
                    node / 'extensions' << 'hudson.plugins.git.extensions.impl.RelativeTargetDirectory' {
                        relativeTargetDir('jenkins-jobs')
                    }
                }
        }
    }
    steps {
        gradle 'clean test'
        dsl {
            external 'jobs/**/*Jobs.groovy'
            additionalClasspath 'jenkins-automation/src/main/groovy'
        }
    }
}

It works if I just clone jenkins-automate and run the example jobs from the seed, but I'd rather not fork and hack on this repo and use the jenkins-as-code-starter-project.

Any ideas?

When I set up a job to run the example jobs, the checkmarx job fails with:

ERROR: (ScmUtils.groovy, line 15) No such property: url for class: java.lang.String

The examples.md show usage of BaseJob, but the example has this:

build(factory)

However, factory does not exist in a script.

All other examples of BaseBuilder are inside of other builders, where factory does exist

Please correct this example

We can make the editable email config more useful by turning it into a reusable, parameterized configure block.

The BaseJobBuilder and friends can then use it, as can any other jobs that don't use the builders.

suggested signature something like:

    static Closure editableEmail(List<String> triggers = ["Failure", "Fixed"], List<String> emails=[], sendToDevelopers=false, includeCulprits=false, sendToRecipientList=true) {

    }

The purpose here is to make it really easy to do the thing that we need to do most often with email, which is send an email with default subject, default body, a configurable recipient list, and only to recipients (sending to developers and culprits is often a bad idea because we don't want internal jenkins emails going to external contributors, who might show up in the developers or culprits list)

Jobs that need more configuration can still easily use editable email directly without this helper, which is why it's important we keep this block simple and not load it up with all manner of configurability

I'm trying to use CommonUtils.addExtendedEmail() in a builder of my own. Here's the code:

class QuMatrixJobBuilder {
...
    Job build(DslFactory factory) {
        factory.matrixJob(name) {
            it.description this.description
            CommonUtils.addDefaults(delegate)
            CommonUtils.addExtendedEmail(delegate, emails)
        }
    }
}

And here's the error when I run the seed job:

ERROR: (CommonUtils.groovy, line 41) No signature of method: javaposse.jobdsl.dsl.jobs.MatrixJob.extendedEmail() is applicable for argument types: (java.lang.String, jenkins.automation.utils.CommonUtils$_addExtendedEmail_closure2_closure7) values: [[email protected], [email protected], ...]

Note that CommonUtils.addDefaults() works just fine

Now, if I try it outside the context of a custom builder, and just adding it to an existing job created with one of the JAC builders, I get the same error:

new QuTaskBuilder(
        name: "qu-virtualenv-tester",
).build(this).with {
    CommonUtils.addExtendedEmail(delegate, Config.emails)
}

Same error as above:

ERROR: (CommonUtils.groovy, line 41) No signature of method: javaposse.jobdsl.dsl.jobs.FreeStyleJob.extendedEmail() is applicable for argument types: (java.lang.String, jenkins.automation.utils.CommonUtils$_addExtendedEmail_closure2_closure7) values: [emails redacted, ...]

Hey @imuchnik @Ooblioob. Glad to see continued development! I'm getting ready to set up a CI pipeline and was wondering whether the project is in a state that I can use it? Should I work off the ooblioob fork, or should I stick with the master? Has config changed? Have things settled down with development, or are you finding lots of things you still need to break?

I also saw that you started building some wrappers. Are those jobdsl extensions?

v1.42 was released a few weeks ago as of this writing. Let's update to it.