Hi - Inline
Sent from my iPhone > On Jan 28, 2019, at 1:12 PM, Sijie Guo <guosi...@gmail.com> wrote: > > both adding tag or checkbox are developer driven. but it is easier to > achieve with current github pull request builder in Jenkins. > so I think the responsibility of this approach is kind of spreading across > contributors and committers. It is also a way to educate > pulsar contributors to understand better pulsar codebase and its build > system. > > However if we want to automate the process, one way I can think of is > introducing some kind of `pulsarbot`. One suggestion is to bring this question to bui...@apache.org mailing list and see if others have solved this problem in some way. > > - DONT run precommit jobs automatically (java, cpp, integration and docs) > - use Github hook to listen on activities of a pull request > - pulsarbot check the Github diff when a pull request is created or updated > - pulsarbot trigger corresponding precommit jobs to run > > But that is going to be a huge task to implement this mechanism. I am not > sure it is worth to do initially and who has enough time dedicated to this. Regards, Dave > > - Sijie > >> On Mon, Jan 28, 2019 at 12:26 PM Joe F <joefranc...@gmail.com> wrote: >> >> +1 to Sanjeev's suggestion >> >> On Mon, Jan 28, 2019 at 12:15 PM Sanjeev Kulkarni <sanjee...@gmail.com> >> wrote: >> >>> If developers are in charge of checking the checkbox, it might lead to >>> errors. Any way to make it automatic? Since docs are restricted to >> certain >>> areas of repo, maybe we can have some rules around that? >>> >>>> On Mon, Jan 28, 2019 at 12:12 PM Sijie Guo <si...@apache.org> wrote: >>>> >>>> Hi all, >>>> >>>> Currently for every documentation change, we have run 3 precommit jobs, >>>> java, c++ and integrationt tests. None of them is actually testing the >>>> documentation change and it is wasting jenkins resources and make the >>> merge >>>> process for documentation changes take much longer time. >>>> >>>> So I am proposing : >>>> >>>> - add a separate precommit job for documentation-only changes. e.g. >>>> `Jenkins: Documentation Tests` >>>> >>>> - provide a checkbox in description >>>> * [ ] documentation-only change >>>> * [ ] code-only change >>>> >>>> - if `[x] documentation-only` is checked, then java, c++ and >> integration >>>> tests will be skipped. >>>> - if `[x] code-only` is checked, then documentation tests will be >>> skipped. >>>> >>>> >>>> I would like to see what other people think about this. >>>> >>>> - Sijie >>>> >>> >>
