This issue is about preparing a design document of a top level architecture for the plugins that will be developed in the 'Multibranch Pipeline Support for GitLab' Project.
Objectives and expectations based on proposal
Answer questions such as
"How is the user going to use this?",
"What configurations are needed?",
"What are the components of the plugin?"
Create diagrams of API
Write mini user guides as if project is already done
After completion, reality mapping shall be done by a discussion with the key stakeholders in other Branch Source Plugins.
This issue is about preparing a design document of a top level architecture for the plugins that will be developed in the 'Multibranch Pipeline Support for GitLab' Project.
* Objectives and expectations based on proposal * Answer questions such as ** "How is the user going to use this?", ** "What configurations are needed?", ** "What are the components of the plugin?" * Create diagrams of API * Write mini user guides as if project is already done
After completion, reality mapping shall be done by a discussion with the key stakeholders in other Branch Source Plugins.
Thanks Mark. I was already referring to the SCM API and BRANCH API docs. They are verbose and gives a nice picture of how the implementation will be done. I'll check rest of the pointers for more info.
This issue is about preparing a design document of a top level architecture for the plugins that will be developed in the 'Multibranch Pipeline Support for GitLab' Project. * Objectives and expectations based on proposal * Answer questions such as ** "How is the user going to use this?", ** "What configurations are needed?", ** "What are the components of the plugin?" * Create diagrams of API * Write mini user guides as if project is already done
After completion, reality mapping shall be done by through a discussion with the key stakeholders in other Branch Source Plugins.
Some important implementation of classes has been added to the document from the SCM API and Branch API docs. Unfortunately couldn't find more support for design document from any experienced developer of any Branch Source Plugin but with the help of well maintained codebase and javadocs I was able to come up with my versions of implementations idea. The design document doesn't provide a concrete idea of our plugin APIs but it will be updated throughout the course of development. So at the end of the plugin release, this design document will contain all the necessary information a user or other plugin authors require to extend or get inspired.
Per team agreeable, this document is meeting acceptance. Parichay Barpanda says he would like to add a few more items to this body of work. I will leave open until then but it is agreed that this can be closed once that is done.