[tarantool-patches] Re: [PATCH v4 0/2] Implement Gitlab-ci testing process

[Alexander Turenko <alexander.turenko@tarantool.org>]

## Changes

(Updated your branch as we agreed voicely.)

Fixed spelling and changed wording in the commit messages.

Splitted goals in .gitlab.mk into sections just like you are made it for
.travis.mk and commented these sections.

Rewritten 'docker_bootstrap' goal to write docker files in a multiline
way. Reworked tags for these images: use :latest in testing, but always
push both :`md5sum of .travis.mk` and :latest tags.

## Comments

I would remove 'master' tag at all, because of several reasons:

* It appears over several files and it will be hard to keep it
  consistent.
* We rarely change something here and I don't remember case when we
  remove some dependency.
* It is not obvious that 'master' tag is intended to be used for all
  branches that are based on master, 2.1 for branches based on 2.1),
  etc.

I thinking whether we should use
tarantool/tarantool/testing/debian-<...> for images naming? I would be
more clear why the image is needed and also will allow use to use this
namespace (tarantool/tarantool) for images of other purposes. I don't do
that in my changes.

Re 'deploy' jobs. I would run the packpack script with environment
variables rather then call its internal makefile inside a docker image
run by gitlab runner.  This is how it is performed for Travis CI.

I doubt about a hardcoded repository within a virtual machine image. I
suggest to leave only system things in the image (install and setup
packages and so on), but don't do such special tarantool-related things.

I very against of black boxes like these VM images. Nobody knows what it
is. Nobody can reproduce a problem. So, please implement make goals that
will create vm images identical to ones that is used in testing.

Also I would look into vagrant. As I see, there are OS X and FreeBSD
images. We need to check their licenses, BTW. Don't sure about pushing
images, but at least local using should be possible.

Maybe I forgotten something that we discussed voicely.

WBR, Alexander Turenko.

On Wed, Jun 19, 2019 at 05:56:29PM +0300, Alexander V. Tikhonov wrote:
>     Implement Gitlab-ci testing process
>     
>     Implemented Gitlba-ci testing process additionaly to travis-ci
>     that is currently uses. New testing process was added to make
>     able to control the high load of the testing processes to avoid
>     of flaky fails on timouts, disks layouts and memory swapping.
>     Created 2 stages for testing and deploying packages.
>     Stage test consist of testing jobs for all branches at:
>       Debian 9 (Stretch): release/debug gcc
>       Debian 10 (Buster): release clang8 + lto
>       OSX 14 (Mojave): release
>       FreeBSD 12: release gcc
>     and for release branch has additionally:
>       OSX 13 (Sierra) release clang
>       OSX 14 (Mojave) release clang + lto
>     Deploy of packages is the same as in Travis-CI.
>     Additional manual work is needed if the image's depends was
>     changed at .travis.mk file - in this way need to do:
>       make -f .gitlab.mk docker_bootstrap
>     
>     Fixes #4156
> 
> 
> Github: https://github.com/tarantool/tarantool/tree/avtikhon/gh-4156-gitlab-ci-testing
> Issue: https://github.com/tarantool/tarantool/issues/4156
> 
> Alexander V. Tikhonov (2):
>   Temporary disabled on_shutdown.test.lua test
>   Implement Gitlab-ci testing process
> 
>  .gitlab-ci.yml     | 297 +++++++++++++++++++++++++++++++++++++++++++++
>  .gitlab.mk         |  57 +++++++++
>  .travis.mk         | 107 +++++++++++-----
>  .travis.yml        |   3 +
>  test/box/suite.ini |   2 +-
>  5 files changed, 438 insertions(+), 28 deletions(-)
>  create mode 100644 .gitlab-ci.yml
>  create mode 100644 .gitlab.mk
> 
> -- 
> 2.17.1
>