Re: Workflow improvement

Yep, it's working. Thank you. 2018-09-13 19:09 GMT+03:00 Dmitriy Pavlov : > Hi Dmitriy, > > Sure, I agree with extra permissions assignment. Done. > > Could you please check if you can manage your builds now? > > Sincerely, > Dmitriy Pavlov > > чт, 13 сент. 2018 г. в 16:05, Dmitrii Ryabov : > > >

Re: Workflow improvement

Hi Dmitriy, Sure, I agree with extra permissions assignment. Done. Could you please check if you can manage your builds now? Sincerely, Dmitriy Pavlov чт, 13 сент. 2018 г. в 16:05, Dmitrii Ryabov : > Hi, Dmitriy, > > Can you give me rights to stop my builds on TeamCity? Working on the TCH, I >

Re: Workflow improvement

Hi, Dmitriy, Can you give me rights to stop my builds on TeamCity? Working on the TCH, I run a lot of builds, and I don't like to ask other people to stop builds too often. 2018-09-10 23:53 GMT+03:00 Dmitrii Ryabov : > Hi, Dmitriy, > > I made PRs in my fork for test purposes. Real PRs were made

Re: Workflow improvement

Hi, Dmitriy, I made PRs in my fork for test purposes. Real PRs were made to the GitHub mirror, and one of them is already merged by D. Govorukhin. PR with GitHub statuses [1] is ready for review. PR with JIRA comment will be ready in a few days. [1] https://github.com/apache/ignite-teamcity-bot/p

Re: Workflow improvement

Hi Dmitrii, I deployed change with blockers summary of failures at the top of PR result page. The Bot is migrating entries now, I hope it will be done in 1-4 hours. I noticed your PRs are created in your own fork, not in https://github.com/apache/ignite-teamcity-bot Could you please create unmerg

Re: Workflow improvement

Hi Dmitrii, Great news. I love the fact that you did these improvements. I have limited access to the internet so for now I'm not able to review and merge. I can do it next week. I appreciate your effort. Sincerely, Dmitriy Pavlov пн, 3 сент. 2018 г., 18:20 Dmitrii Ryabov : > Hi, Dmitriy, >

Re: Workflow improvement

Hi, Dmitriy, I created a table with possible blockers [1] for the page with the latest build analysis. Anton K. has reviewed it. Can you check and merge it? Also, I created a button to notify PR about analisis results [2]. I used GitHub statuses (example [3]), but to work it needs a token with pu

Re: Workflow improvement

Not sure I understood what bot statistic reduction means. As far as I understood, you also mean locating failure automatically with re-runs on specific git revisions (hashes). I found it will be a good contribution to TC Bot for both flaky and non-flaky failures detection. E.g failure occurred aft

Re: Workflow improvement

Hi, Dmitriy, Good, I'll create tickets for this steps. Stable suites are a good idea, but also we need to do some actions when a flaky test will appear in stable suite of master branch run. To find out a guilty commit, we should run previous commits on empty TeamCity's queue. This runs will reduc

Re: Workflow improvement

Hi Dmitriy, Sounds like a plan ;) I totally agree. Just one proposal: I would like to avoid hiding any test failures. 2 separate tables named 'Possible Blockers' and 'Other failures' should be completely clear. Comment to PR can contain only first category. We had a private discussion with Anton

Re: Workflow improvement

Hi, Dmitriy, I propose the next steps: 1. Show current 0% tests in a separate table at the top of the analysis results page. Thus, we'll see most suspicious (new or very flaky) tests firstly. Or we can hide other tests under "More >>" button, like top long running tests. 2. Create a button by cli

Re: Workflow improvement

I think we should check not N last runs, but all runs in last N days. A simple rule to detect flaky fails by hands - get test history ordered by TEST_STATUS_DESC and check its date. As I see, we can get list of failures from TC. We don't need to check successfull runs, because they are uninformati

Re: Workflow improvement

Hi Dmitriy, The Bot is able to detect a frequent change of test status, but currently only 50 last runs count. Same is true for the failure rate. This value can be easily changed to 70 or 100, moreover, the auto trigger feature gives us much more builds. We can improve these rules. We can add no

Re: Workflow improvement

I think plugin will be more pretty looking, but comments can contain any information, so they can be more usefull. I agree with your idea to create bot instead of plugin. As for fail rate - I'm not sure it is working as you describe. I'm looking on my runAll [1]. There is `IgniteCacheGroupsTest.te

Re: Workflow improvement

Hi Dmitrii, I'm not sure we're able to install Github apps to Apache mirrors. The simplest solution, what can be as efficient as a plugin, is fake MTCGA bot account in Github, which will provide PR comments using Github program interface. What do you think? A new test failure can be identified b