Alexander, thanks a lot for review!
  
>Среда, 6 мая 2020, 12:08 +03:00 от Alexander Turenko <alexander.turenko@tarantool.org>:
> 
>> Keep perf results as gitlab-ci artifacts
>
>Nit: Let's add some prefix: I would use 'gitlab-ci'. Using of prefixes
>is convenient and allows to traverse over commits faster.
ok.
>>
>> Gitlab-ci pipeline modified in order to keep performance results into gitlab-ci artifacts.
>
>Nit: Keep commit message body lines within 72 symbols.
ok.
>>  
>> Closes #4920
>>  
>> Github:  https://github.com/tarantool/tarantool/tree/opiskunov/gh-4920-perf-artifacts
>> Issue:  https://github.com/tarantool/tarantool/issues/4920
>
>Nit: Don't include issue no / branch into a commit message, only within
>a email. Place them under '---' to distinguish from a commit message
>itself.
ok
>> ---
>>  .gitlab-ci.yml | 43 +++++++++++++++++++++++++++++++++++++++++++
>>  1 file changed, 43 insertions(+)
>>  
>> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
>> index fd265aa..4b05fa5 100644
>> --- a/.gitlab-ci.yml
>> +++ b/.gitlab-ci.yml
>> @@ -201,12 +201,22 @@ perf_sysbench:
>>    variables:
>>      <<: *perf_vars_definition
>>      BENCH: 'sysbench'
>> +  artifacts:
>> +    when: always
>> +    paths:
>> +      - Sysbench_result.txt
>> +      - Sysbench_t_version.txt
>
>I would deploy a directory with result as an artefact or use globs
>(GitLab CI supports both). gitlab-ci.yml should not lean on hardcoded
>bench-run paths. Can we formalize bench-run contract for performance
>measurement results? Maybe, `${benchmark}_results` directory? Or
>`${benchmark}_${conf}_results` if names intersection may be troublesome.
I will use wildcards for this.
 
 
--
Oleg Piskunov