| It appears that the functionally of the current plugin must be unbundled to a certain extent for it be relevant in the world of pipelines. Trigger on pull request This part deals with setting up the github hook, listening to the pull request events posted from github, filtering out the events on which we do not wish to trigger a build, branches, skip phrases, etc. etc.. The role of this piece is to determine when a build should be triggered. A simple port of this to use the new types should suffice Trigger setup This part of the plugin interacts with github by manipulating the pull request in many ways such as updating the github status, posting comments, one liners on progress and eventual outcomes. This is the functionality that cannot be ported as-is into the pipeline world. Users would need to ability to wrap any step / stage within a trigger setup. For example, we can choose to have one github status that is controlled by the first stage of the pipeline that presumably compiles the code and another status that is controlled by a latter stage of the pipeline that creates a docker image and launches it to run integration tests against it. Note that this might be a useful capability to have even in the pre-pipeline world. However, it becomes a necessity once we move into the world of pipelines Pull request merger This should be thought of as an independent, step in the pipelined world. |
