It appears that having the ghprb trigger be pipeline compatible might solve my problems. Most of the other triggers seem to have been ported <https://github.com/jenkinsci/pipeline-plugin/blob/master/COMPATIBILITY.md#triggers> to be pipeline compatible.
On Saturday, August 13, 2016 at 9:02:07 PM UTC+5:30, Arvind Jayaprakash wrote: > > I seem to have developed a love/hate relationship with Jenkins 2.x > pipelines and some of the concepts that it imposes. Hence, I'd like to hear > how best operate in the new world. The one thing I'd like to make clear > before I get into the details is that I am suggesting that this the only > right way to do things; all I am looking to hear is Jenkins 2.x would be > able to support this as one of the many models. > > Firstly, let me describe the development model that I'd like to work with. > The setup I have is very similar to how a lot of github bases open source > projects operate i.e. the main repo very rarely has any branches. All > development is done by forking the code, making any number of branches > within forks and finally submitting a pull request to the *main/parent* git > repository. There is a fairly elaborate acceptance criteria for a pull > request to be accepted into the mainline and this is the workflow that I'd > like to trigger and run as a pipeline. The way I have been doing this until > now is by having a github pull request builder > <https://wiki.jenkins-ci.org/display/JENKINS/GitHub+pull+request+builder+plugin> > > triggered job that sets of a series of steps within a freestyle job and > then having downstream jobs associated with it. It is not clear as to how > one would setup something using the pipeline construct. > > Secondly, I do not wish to provide the flexibility of defining the > pipeline (at least in it's current form) to individual developers. The > design choice of needing a Jenkinsfile in the each git repo (and branch) > seems equivalent to allowing developers to define their own freestyle jobs > in Jenkins 1.x. The model that I have been following is to have a > predefined set of templates (setup using the Job DSL > <https://wiki.jenkins-ci.org/display/JENKINS/Job+DSL+Plugin>) from which > the developer can choose along with a minimal set of parameters such as the > path of the git repo, the email addresses for notification, choice of JRE, > etc. etc. to instantiate specific jobs for their code bases. I'd like to > retain this degree of control/standardization as we move into Jenkins 2.x. > > In short, I am looking for a way by which I can confine myself to the fork > model of git development, pull request based triggers, and job definitions > as pipelines, with the pipeline definition residing on jenkins (and not the > developer's source tree). > > -- 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/e53a5746-f373-4701-b206-d7ad3e7e1de2%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
