Hello Andrei and al,
The simple pull-request plugin is described in more
details in the link kindly posted by Joseph P (thank you Joseph). I
have added some ideas to the
detailed proposal.
Regarding student participation, you should read the information for students:
https://jenkins.io/projects/gsoc/students/It can help to look at existing plugins to learn how to write plugins. I will shamelessly points to a plugin I previously mentored as I think its code is well organized and it has lots of unit tests: the
external workspace manager plugin. But I am sure there are other good plugins out there that I am not familiar with.
I
am hoping the plugin can work with Bitbucket Server, Cloud and Github
(all three). I am also proposing that certain report types be supported
by convention. For example, if JUnit XML Reports exist in a conventional
location, they should automatically be published.
The plugin is
different than existing pull-request plugins in a couple of ways. My
idea is that the Simple Pull-Request Plugin does not detect branches and
does not create a job for each pull-request automatically. Instead, all
the pull-requests destined to a given branch run in the same job. This
way the job has a history of all the pull-requests destined to a given
branch. So it is one job per destination branch. Also, the plugin does
not automatically detect pull-requests (it does not poll). Instead jobs
wait to be triggered externally. For example a build could be triggered
from the command line (as rudimentary as curl), or it could be
triggered from Bitbucket using the
pull-request notifier. I am not sure whether users should create the jobs themselves, or if there should be some kind automation when it comes to creating jobs. I see the operation of the build, and the jobs creation as two independent activities. The focus of the plugin as proposed so far is to implement the operation of the build.
Of course this proposal welcomes comments and suggestions from the community.
Best,
Martin