Add support for Declarative Multibranch Pipeline

[jhg03a]

If you only have one branch that you're merging PR into, you can follow these instructions. If you must support multiple branches, the closest I could find was this solution. It has the downside that, assuming you fix the error included, you still have to run the job once to set the build properties. If you're using GHPRB for whitelisting who's PR automatically build, that's not going to work for you.

In recent updates to the declarative syntax, the options directive in the pipeline root can no longer take $class configuration. You also can't use the script configuration because blocks are explicitly disallowed in the options directive and you also can't supply arguments. The Properties directive also only works when not using multibranch pipelines.

The more correct solution is to add a new extension point for triggers so it becomes a valid choice for the triggers{} directive. Currently only the legacy JobDSL format is supported.

[jhg03a]

If you're using the scripted pipeline format, this would be another option.

[jhg03a]

One advantage of this over the existing single job pipeline is that existing Jenkins concepts like last successful build function like they were designed instead of collapsing all builds into an unrelated sequence.

[chrylis]

This seems like it may be a blocker for me. I'm trying to let the Blue Ocean GitHub plugin automatically pick up my repositories but also use ghprb to execute fully-merging builds on the trigger phrase. I can't use the githubPullRequest block inside triggers for a pipeline.

[eplodn]

@jhg03a I've managed to run a multibranch declarative pipeline using github-pipeline plugin and webhooks. Updates to PRs and comments are triggering the builds.

[jhg03a]

That's probably true, but does that plugin have the ability to protect the CI infrastructure the same way as ghprb? If you trust all your contributors fully or your CI encapsulates every aspect in a disposable jail somehow it's a non-issue. I need one of my committers or general infra stewards to look at PRs and approve them for CI runs to protect against a malicious Jenkinsfile PR that just does a deleteDir() outside their workspace.

[eplodn]

We're working on a private repo so it's not an issue for us. Just thought I'd leave it here for people looking for the solution.

[jhg03a]

Seems like GHPRB isn't actively getting updated anymore and they're trying to move over to 'github-branch-source-plugin'. However it doesn't solve the same issues yet. I found an open issue that I think addresses the core concept of GHPRB. https://issues.jenkins-ci.org/browse/JENKINS-44611