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
signature.asc
Description: This is a digitally signed message part
