JIRA ticket is some elementary change that needs to be reviewed. We don't review the patch, we review ticket (with motivation, implementation details, history of discussion), so reviewer will look at a ticket first.
PR does not have a mark, that it is ready to be merged. Some PRs are created just for research, but Patch Available ticket is something that is ready to be in the product. So if we concentrate on a ticket, from the point of view of a new contributor, - he or she creates a branch, PR and sets ticket to PA, - and the bot will do all necessary mechanic work. No issues with asking newcomers to run (proper) tests. A newbie needs only to follow the first steps in How To Contribute. A reviewer will see a ticket with the bot Visa after 2-3 hours after setting of PA state. But only one concern I have here, I'm not sure I have spare cycles to do this project. I'd rather move towards it in step-by-step mode, doing small changes in each version. Any assistance is appreciated here. вт, 25 сент. 2018 г. в 11:25, Nikolay Izhikov <nizhi...@apache.org>: > Hello, Dmitriy > > > What about the case when committer creates ignite-9679 branch and tests > it> without PR? > > It means, committer is experienced enough to run tests via Team City > interface :). > > > So scanning seems to be possible only in JIRA > > I don't understand you here. > You can retrieve comments filtered by *date*. > You don't have to scan all 1000 PR's one by one. > Anyway 1000 PR doesn't sound like big issue for me. > > My vote goes strong to GiHub user interface. > I think we should have closer integration with GitHub, not Jira. > > Jira is about tickets and project management. > GitHub is about code, commits and patches. > We test patch, not ticket. > > > В Вт, 25/09/2018 в 00:06 +0300, Dmitriy Pavlov пишет: > > Hi Nikolay, > > > > What about the case when committer creates ignite-9679 branch and tests > it > > without PR? > > > > We have 1100+ open PRs and less than 100 open tickets. So scanning seems > to > > be possible only in JIRA. Mention probably will work for GitHub, but it > > needs to be researched. > > > > Two open PRs is not a valid situation in the majority of cases and How To > > Contribute asks to avoid it. The bot can ignore closed PRs and the bot > can > > expect there is only one open PR per ticket. > > > > Sincerely, > > Dmitriy Pavlov > > > > пн, 24 сент. 2018 г. в 23:41, Nikolay Izhikov <nizhi...@apache.org>: > > > > > Hello, Dmitriy. > > > > > > > But it could be a lot of work to handle mentions (probably from the > > > > > > email> account and inbox). > > > > > > Actually, it can be done via GitHub REST API [1]. > > > It has 'since' param, so getting new GitHub comments is a very basic > task. > > > > > > > Patch available ticket > > > > > > I think we shouldn't take a ticket as an entity that should be tested. > > > For me, it's a PR. > > > > > > Moreover, it's a common case when we have several PR in a ticket. > > > And it's a common case when both of them has to be tested. > > > > > > My vote goes to the closer integration with GitHub. > > > > > > [1] > > > > https://developer.github.com/v3/pulls/comments/#list-comments-in-a-repository > > > > > > В Пн, 24/09/2018 в 22:36 +0300, Dmitriy Pavlov пишет: > > > > Hi Nikolay, > > > > > > > > The idea makes perfect sense for me, and we should definitely take > the > > > > > > best > > > > practices from other big Apache projects. > > > > > > > > But it could be a lot of work to handle mentions (probably from the > email > > > > account and inbox). > > > > > > > > I would like to suggest the following algorithm: > > > > > > > > Patch available ticket, which was never checked by the bot will be > > > > processed in the following steps: > > > > 1. check existing run all (by PR or by branch name), if found go to > the > > > > step 3 > > > > 2. run-all to be triggered by PR > > > > 3. results should be analyzed for the presence of possible blockers. > If > > > > there is no blockers go to step 5. > > > > 4. re-run of particular suites containing possible blockers should be > > > > applied to try to get success for very rare flaky failures (<1%). Go > to 3 > > > > (this go to should be done only once). > > > > 5. comment should be added to JIRA ticket containing information > about > > > > results. > > > > > > > > If a ticket was processed by bot early (probably author added some > fixes) > > > > but still in PA state, the bot will check comments list and find > possible > > > > new mentions (made after the previous build complete date). If it > finds > > > > such comments it goes to step 1 (trying to find only new builds > > > > > > available). > > > > > > > > What do you think? > > > > > > > > Sincerely, > > > > Dmitriy Pavlov > > > > > > > > пн, 24 сент. 2018 г. в 21:43, Nikolay Izhikov <nizhi...@apache.org>: > > > > > > > > > Hello, Igniters. > > > > > > > > > > I propose to implement following behaviour: > > > > > > > > > > 1. Execute "Run all" suite for specific PR when the author of PR > makes > > > > > > a > > > > > comment > > > > > "@mtcga.bot Run Tests!" in GitHub comments. > > > > > > > > > > 2. Send a comment with "Run All" results both: to a Jira ticket and > > > > > > GitHub > > > > > comment. > > > > > > > > > > 3. Label PR based on "Run All" results like it done in Apache > Kafka [1] > > > > > > > > > > I've create ticket for this proposal [2] > > > > > > > > > > Thoughts? > > > > > > > > > > [1] https://github.com/apache/kafka/pulls > > > > > [2] https://issues.apache.org/jira/browse/IGNITE-9678
