<HTML><BODY><br><br><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;">
        Пятница, 21 июня 2019, 17:20 +03:00 от Alexander Turenko <alexander.turenko@tarantool.org>:<br><br><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15611268320901196507_BODY">## Changes<br><br>
(Updated your branch as we agreed voicely.)<br><br>
Fixed spelling and changed wording in the commit messages.<br><br>
Splitted goals in .gitlab.mk into sections just like you are made it for<br>
.travis.mk and commented these sections.<br><br>
Rewritten 'docker_bootstrap' goal to write docker files in a multiline<br>
way. Reworked tags for these images: use :latest in testing, but always<br>
push both :`md5sum of .travis.mk` and :latest tags.<br></div></div></div></div></blockquote>Ok.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15611268320901196507_BODY"><br>
## Comments<br><br>
I would remove 'master' tag at all, because of several reasons:<br><br>
* It appears over several files and it will be hard to keep it<br>
  consistent.<br>
* We rarely change something here and I don't remember case when we<br>
  remove some dependency.<br>
* It is not obvious that 'master' tag is intended to be used for all<br>
  branches that are based on master, 2.1 for branches based on 2.1),<br>
  etc.<br></div></div></div></div></blockquote>Ok.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15611268320901196507_BODY"><br>
I thinking whether we should use<br>
tarantool/tarantool/testing/debian-<...> for images naming? I would be<br>
more clear why the image is needed and also will allow use to use this<br>
namespace (tarantool/tarantool) for images of other purposes. I don't do<br>
that in my changes.<br></div></div></div></div></blockquote>Fixed, added /testing/ sub-directory into the image name repository.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15611268320901196507_BODY"><br>
Re 'deploy' jobs. I would run the packpack script with environment<br>
variables rather then call its internal makefile inside a docker image<br>
run by gitlab runner.  This is how it is performed for Travis CI.<br></div></div></div></div></blockquote>Fixed.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15611268320901196507_BODY"><br>
I doubt about a hardcoded repository within a virtual machine image. I<br>
suggest to leave only system things in the image (install and setup<br>
packages and so on), but don't do such special tarantool-related things.<br></div></div></div></div></blockquote>Fixed.<br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15611268320901196507_BODY"><br>
I very against of black boxes like these VM images. Nobody knows what it<br>
is. Nobody can reproduce a problem. So, please implement make goals that<br>
will create vm images identical to ones that is used in testing.<br></div></div></div></div></blockquote><p>There are all needed targets at the .gitlab.mk file, just use the same environment<br>of the job from .gitlab-ci.yml that you need and run from tarantool sources, like:<br></p><p>VMS_NAME=osx_14 make -f .gitlab.mk vms_start<br data-mce-bogus="1"></p><p>VMS_USER=tarantool VMS_PORT=2222 make -f .gitlab.mk vms_test_osx<br data-mce-bogus="1"></p><p>NOTE: To run it locally the VBOX should be installed with needed images.<br data-mce-bogus="1"></p><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15611268320901196507_BODY"><br>
Also I would look into vagrant. As I see, there are OS X and FreeBSD<br>
images. We need to check their licenses, BTW. Don't sure about pushing<br>
images, but at least local using should be possible.<br></div></div></div></div></blockquote><p>As discussed voicely currently the Virtual Box will be used and the Vagrant images<br> will be integrated during the issue:<br></p><p><a href="https://github.com/tarantool/tarantool/issues/4308">https://github.com/tarantool/tarantool/issues/4308</a> <br><br data-mce-bogus="1"></p><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15611268320901196507_BODY"><br>
Maybe I forgotten something that we discussed voicely.<br><br>
WBR, Alexander Turenko.<br></div></div></div></div></blockquote><br><blockquote style="border-left:1px solid #0857A6; margin:10px; padding:0 0 0 10px;"><div id=""><div class="js-helper js-readmsg-msg"><div><div id="style_15611268320901196507_BODY"><br>
On Wed, Jun 19, 2019 at 05:56:29PM +0300, Alexander V. Tikhonov wrote:<br><div class="mail-quote-collapse">>     Implement Gitlab-ci testing process<br>
>     <br>
>     Implemented Gitlba-ci testing process additionaly to travis-ci<br>
>     that is currently uses. New testing process was added to make<br>
>     able to control the high load of the testing processes to avoid<br>
>     of flaky fails on timouts, disks layouts and memory swapping.<br>
>     Created 2 stages for testing and deploying packages.<br>
>     Stage test consist of testing jobs for all branches at:<br>
>       Debian 9 (Stretch): release/debug gcc<br>
>       Debian 10 (Buster): release clang8 + lto<br>
>       OSX 14 (Mojave): release<br>
>       FreeBSD 12: release gcc<br>
>     and for release branch has additionally:<br>
>       OSX 13 (Sierra) release clang<br>
>       OSX 14 (Mojave) release clang + lto<br>
>     Deploy of packages is the same as in Travis-CI.<br>
>     Additional manual work is needed if the image's depends was<br>
>     changed at .travis.mk file - in this way need to do:<br>
>       make -f .gitlab.mk docker_bootstrap<br>
>     <br>
>     Fixes #4156<br>
> <br>
> <br>
> Github: <a href="https://github.com/tarantool/tarantool/tree/avtikhon/gh-4156-gitlab-ci-testing" target="_blank">https://github.com/tarantool/tarantool/tree/avtikhon/gh-4156-gitlab-ci-testing</a><br>
> Issue: <a href="https://github.com/tarantool/tarantool/issues/4156" target="_blank">https://github.com/tarantool/tarantool/issues/4156</a><br>
> <br>
> Alexander V. Tikhonov (2):<br>
>   Temporary disabled on_shutdown.test.lua test<br>
>   Implement Gitlab-ci testing process<br>
> <br>
>  .gitlab-ci.yml     | 297 +++++++++++++++++++++++++++++++++++++++++++++<br>
>  .gitlab.mk         |  57 +++++++++<br>
>  .travis.mk         | 107 +++++++++++-----<br>
>  .travis.yml        |   3 +<br>
>  test/box/suite.ini |   2 +-<br>
>  5 files changed, 438 insertions(+), 28 deletions(-)<br>
>  create mode 100644 .gitlab-ci.yml<br>
>  create mode 100644 .gitlab.mk<br>
> <br>
> -- <br>
> 2.17.1<br>
> <br></div><br></div></div></div></div></blockquote>
<br>
<br>-- <br>Alexander Tikhonov<br></BODY></HTML>