Found that on 19.02.2020 APT repositories with packages
for Ubuntu 18.10 Cosmic were removed from Ubuntu archive:

 E: The repository 'http://security.ubuntu.com/ubuntu cosmic-security Release' does not have a Release file.
 E: The repository 'http://archive.ubuntu.com/ubuntu cosmic Release' does not have a Release file.
 E: The repository 'http://archive.ubuntu.com/ubuntu cosmic-updates Release' does not have a Release file.
 E: The repository 'http://archive.ubuntu.com/ubuntu cosmic-backports Release' does not have a Release file.

Also found the half a year old message about Ubuntu 18.10
Cosmic EOL:
 https://fridge.ubuntu.com/2019/07/19/ubuntu-18-10-cosmic-cuttlefish-end-of-life-reached-on-july-18-2019/

Removed the Ubuntu 18.10 Cosmic from gitlab-ci and
travis-ci testings.

(cherry picked from commit 961e8c5f)

Added build + test jobs in GitLab-CI and build + test + deploy jobs on
Travis-CI for Fedora 31.

Updated testing dependencies in the RPM spec to follow the new Python 2
package naming scheme that was introduced in Fedora 31: it uses
python2-' prefix rather then 'python-'.

Fedora 31 does not provide python2-gevent and python2-greenlet packages,
so they were pushed to https://packagecloud.io/packpack/backports
repository. This repository is enabled in our build image
(packpack/packpack:fedora-31) by default. Those dependencies are build-time,
so nothing was changed for a user. The source RPM packages were gathered
from https://rpms.remirepo.net/rpmphp/

.

Closes #4612

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
(cherry picked from commit 9e09b07c)

Added build + test jobs in GitLab-CI and build + test + deploy jobs on
Travis-CI for CentOS 8.

Updated testing dependencies in the RPM spec to follow the new Python 2
package naming scheme that was introduced in CentOS 8: it uses
'python2-' prefix rather then 'python-'.

CentOS 8 does not provide python2-gevent and python2-greenlet packages,
so they were pushed to https://packagecloud.io/packpack/backports
repository. This repository is enabled in our build image
(packpack/packpack:el-8) by default. Those dependencies are build-time,
so nothing was changed for a user. The source RPM packages were gathered
from https://cbs.centos.org

.

Disabled app-tap/pwd.test.lua on CentOS 8 due to systemd-nss issue,
which was not worked around properly. Filed #4592 to resolved it in the
future.

Eliminated libunwind runtime dependency (and libunwind-devel build
dependency) on CentOS 8, because the base system does not provide it.
fiber.info() backtraces and printing of a backtrace after a crash will
not be available on this system. Hopefully we'll fix it in the future,
filed #4611 on this.

Closes #4543

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
Reviewed-by: Igor Munkin <imun@tarantool.org>
(cherry picked from commit e3d9d8c9)

Added Ubuntu 19.10 Eoan Ermine into CI.

Close #4583

Reviewed-by: Alexander Turenko <alexander.turenko@tarantool.org>
(cherry picked from commit c6cd2e62)

Removed the jobs that is interesting to check on gitlab-ci
instead of travis-ci:
  - osx 13 "Sierra"
  - all LTO jobs
  - ASAN job

Part of #4410

(cherry picked from commit 05477787)

The problem was that a tagged revision is not deployed, so after a
release we did an empty commit to trigger deployment. Now it is worked
around by adding extra deployment rules that deploys tagged revisions.
The workaround was suggested by Hiro Asari in [1].

[1]: https://github.com/travis-ci/travis-ci/issues/7780#issuecomment-302389370

Fixes #3745.

Added ASAN tesing in commit process, used clang-8 for
ASAN build under debian-buster image. Added for testing
only the passing test suites, the rest of the tests
not used and will be enabled durring issue #4360. Also
fixed job for testing LTO with clang on debian-buster
in travis-ci, changed it to the same as in gitlab-ci,
changed default clang to clang-8.

Closes #4359

travis-ci APT repository update failed on Debian 10 (Buster)
with command 'apt-get update', like:

Get:1 http://deb.debian.org/debian buster InRelease [118 kB]
Get:2 http://security.debian.org/debian-security buster/updates InRelease [39.1 kB]
Get:3 http://deb.debian.org/debian buster-updates InRelease [46.8 kB]
Reading package lists... Done
N: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Version' value from '' to '10'
E: Repository 'http://security.debian.org/debian-security buster/updates InRelease' changed its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
N: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Version' value from '' to '10.0'
E: Repository 'http://deb.debian.org/debian buster InRelease' changed its 'Suite' value from 'testing' to 'stable'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.
E: Repository 'http://deb.debian.org/debian buster-updates InRelease' changed its 'Suite' value from 'testing-updates' to 'stable-updates'
N: This must be accepted explicitly before updates for this repository can be applied. See apt-secure(8) manpage for details.

The cause of the issue was:

According to Debian Project News published 1st of July, Debian 10 "Buster"
was scheduled to transition from testing to stable on 2019-07-06.
It looks like the transition was in fact performed as scheduled, and so the
testing distribution should now be catching up witn unstable, to eventually
become Debian 11 "Bullseye". You might be experiencing some temporary side
effects because of this transition of the Debian mirrors.
If you want to stay with Debian 10 "Buster", now would be a good time to switch
your /etc/apt/sources.list to use the release name buster instead of testing.
Otherwise, you'll soon be getting the raw bleeding-edge stuff from unstable,
and you might accidentally get a partial upgrade to proto-"Bullseye".
Also, this is a reminder for anyone using the word stable in their
/etc/apt/sources.list to consider whether to change it to stretch and stay with
the old version, or read the Release Notes and perform the recommended upgrade
steps.

To fix the issue it had to accept interactively the changes in the repositories
NOTE: apt instead of apt-get can accept the changes interactively

apt update -y

either accept only the needed changes for 'version' and 'suite'

apt-get update --allow-releaseinfo-change-version --allow-releaseinfo-change-suite

Seems that the only 'version' and 'suite' accept is better than blind
accept of the all changes.

Closes #4331

Implemented GitLab CI testing process additionally to existing Travis
CI. The new testing process is added to run tests faster. It requires to
control a load of machines to avoid flaky fails on timeouts. GitLab CI
allows us to run testing on our machines.

Created 2 stages for testing and deploying packages.

The testing stage contains the following jobs that are run for all
branches:

* Debian 9 (Stretch): release/debug gcc.
* Debian 10 (Buster): release clang8 + lto.
* OSX 14 (Mojave): release.
* FreeBSD 12: release gcc.

And the following jobs that are run of long-term branches (release
branches: for now it is 1.10, 2.1 and master):

* OSX 13 (Sierra): release clang.
* OSX 14 (Mojave): release clang + lto.

The deployment stage contains the same jobs as we have in Travis CI.
They however just build tarballs and packages: don't push them to S3 and
packagecloud.

In order to run full testing on a short-term branch one can name it with
'-full-ci' suffix.

The additional manual work is needed when dependencies are changed in
.travis.mk file ('deps_debian' or 'deps_buster_clang_8' goals):

 | make GITLAB_USER=foo -f .gitlab.mk docker_bootstrap

This command pushes docker images into GitLab Registry and then they are
used in testing. Pre-built images speed up testing.

Fixes #4156

Made fixes:

- Added CMAKE_EXTRA_PARAMS environment to docker's container
  runs to enable -DENABLE_LTO=ON/OFF cmake option.

- Added CC/CXX environment to docker's container runs to set
  clang for cmake. Also the additional environment variables
  {CC,CXX}_FOR_BUILD were postponed, because we didn't
  run cross-compilation at the moment, for more info check:

    https://docs.travis-ci.com/user/languages/cpp/#choosing-compilers-to-test-against

- Changed LTO docker's image to 'debian-buster' due to LTO needed
  higher versions of packages, check for more information commit:

    f9e28ce4 ('Add LTO support')

- Fixed sources to avoid of failures on builds by GCC with LTO:

1)  src/box/memtx_rtree.c: In function ‘mp_decode_rect’:
    src/box/memtx_rtree.c:86:24: error: ‘c’ may be used uninitialized
      in this function [-Werror=maybe-uninitialized]
        rect->coords[i * 2] = c;
                            ^
    src/box/memtx_rtree.c:74:10: note: ‘c’ was declared here
      coord_t c;
              ^

2)  src/box/sql/func.c: In function ‘quoteFunc’:
    src/box/sql/func.c:1103:3: error: ‘b’ may be used uninitialized
      in this function [-Werror=maybe-uninitialized]
       sql_result_text(context, sql_value_boolean(argv[0]) ?
       ^
    src/box/sql/vdbeapi.c:217:7: note: ‘b’ was declared here
      bool b;
           ^

3)  src/box/tuple_update.c: In function ‘update_read_ops’:
    src/box/tuple_update.c:1022:4: error: ‘field_no’ may be used
      uninitialized in this function [-Werror=maybe-uninitialized]
        diag_set(ClientError, ER_NO_SUCH_FIELD_NO, field_no);
        ^
    src/box/tuple_update.c:1014:11: note: ‘field_no’ was declared here
       int32_t field_no;
               ^

4)  src/httpc.c: In function ‘httpc_set_verbose’:
    src/httpc.c:267:2: error: call to ‘_curl_easy_setopt_err_long’
      declared with attribute warning: curl_easy_setopt expects a long
      argument for this option [-Werror]
      curl_easy_setopt(req->curl_request.easy, CURLOPT_VERBOSE, curl_verbose);
      ^

5)  src/lua/httpc.c: In function ‘luaT_httpc_request’:
    src/lua/httpc.c:128:64: error: ‘MEM[(int *)&parser + 20B]’ may be used
      uninitialized in this function [-Werror=maybe-uninitialized]
      lua_pushinteger(L, (parser.http_minor > 0) ? parser.http_minor: 0);
                                                                    ^
    src/lua/httpc.c:67:21: note: ‘MEM[(int *)&parser + 20B]’ was declared here
      struct http_parser parser;
                         ^
    src/lua/httpc.c:124:64: error: ‘MEM[(int *)&parser + 16B]’ may be used
      uninitialized in this function [-Werror=maybe-uninitialized]
      lua_pushinteger(L, (parser.http_major > 0) ? parser.http_major: 0);
                                                                    ^
    src/lua/httpc.c:67:21: note: ‘MEM[(int *)&parser + 16B]’ was declared here
      struct http_parser parser;
                         ^

Close #4215

Fixes #4194.

It is important to have testing jobs that build the project with both
-Werror and -O2 to keep the code clean. -O2 is needed, because some
compiler warnings are available only after extra analyzing passes that
are disabled with lesser optimization levels.

The first attempt to add -Werror for release testing jobs was made in
da505ee7 ('Add -Werror for CI (1.10
part)'), but it mistakely doesn't enable -O2 for RelWithDebInfoWError
build. It is possible to fix it in this way:

 | --- a/cmake/compiler.cmake
 | +++ b/cmake/compiler.cmake
 | @@ -113,10 +113,14 @@ set (CMAKE_C_FLAGS_DEBUG
 |      "${CMAKE_C_FLAGS_DEBUG} ${CC_DEBUG_OPT} -O0")
 |  set (CMAKE_C_FLAGS_RELWITHDEBINFO
 |      "${CMAKE_C_FLAGS_RELWITHDEBINFO} ${CC_DEBUG_OPT} -O2")
 | +set (CMAKE_C_FLAGS_RELWITHDEBINFOWERROR
 | +    "${CMAKE_C_FLAGS_RELWITHDEBINFOWERROR} ${CC_DEBUG_OPT} -O2")
 |  set (CMAKE_CXX_FLAGS_DEBUG
 |      "${CMAKE_CXX_FLAGS_DEBUG} ${CC_DEBUG_OPT} -O0")
 |  set (CMAKE_CXX_FLAGS_RELWITHDEBINFO
 |      "${CMAKE_CXX_FLAGS_RELWITHDEBINFO} ${CC_DEBUG_OPT} -O2")
 | +set (CMAKE_CXX_FLAGS_RELWITHDEBINFOWERROR
 | +    "${CMAKE_CXX_FLAGS_RELWITHDEBINFOWERROR} ${CC_DEBUG_OPT} -O2")
 |
 |  unset(CC_DEBUG_OPT)

However I think that a build type (and so `tarantool --version`) should
not show whether -Werror was passed or not. So I have added
ENABLE_WERROR CMake option for that. It can be set like so:

 | cmake . -DCMAKE_BUILD_TYPE=RelWithDebInfo -DENABLE_WERROR=ON

Enabled the option in testing Travis-CI jobs with the RelWithDebInfo
build type. Deploy jobs don't include it as before.

Fixed all -Wmaybe-uninitialized and -Wunused-result warnings. A few
notes about the fixes:

* net.box does not validate received data in general, so I don't add a
  check for autoincrement IDs too. Set the ID to INT64_MIN, because this
  value is less probably will appear here in a normal case and so is the
  best one to signal a user that something probably going wrongly.
* xrow_decode_*() functions could read uninitialized data from
  row->body[0].iov_base in xrow_on_decode_err() when printing a hex code
  for a row. It could be possible when the received msgpack was empty
  (row->bodycnt == 0), but there were expected keys (key_map != 0).
* getcwd() is marked with __attribute__((__warn_unused_result__)) in
  glibc, but the buffer filled by this call is not used anywhere and so
  just removed.
* Vinyl -Wmaybe-uninitialized warnings are false positive ones.

Added comments and quotes into .travis.yml to ease reading. Removed
"test" word from the CentOS 6 job name, because we don't run tests on
this distro (disabled in the RPM spec).

Fixes #4178.

Fixes #4174.

Debian Wheezy is EOL since 31st May 2018, mirrors are disabled now.

Development branch is now named master, so
update conditions for extended extended checks on
Travis.
Also, set new repo name.

Fixes #4027.

Fixed Mojave Mac build with setting MACOSX_DEPLOYMENT_TARGET environment
variable for LuaJIT's Makefile. This variable specifies the minimum
version of OS X on which the target binaries are to be deployed.

The reason why we need to set MACOSX_DEPLOYMENT_TARGET to at least 10.6
is that 10.4 SDK (which is set by default in LuaJIT's Makefile) is not
longer included in Mac OS X Mojave 10.14.

See also https://github.com/LuaJIT/LuaJIT/issues/484

We already set -Wl,-macosx_version_min,10.6 (-macosx_version_min and
MACOSX_DEPLOYMENT_TARGET are synonymous), but it affects only a linker.
We possibly should remove -macosx_version_min, because it superseded by
MACOSX_DEPLOYMENT_TARGET, but it should be done with verification that
the original problem really fixed by the new way to set a deployment
target. This is not part of this patch.

Removed virtualenv usage in CI for OS X (so pip just installs packages
into a system), because OS X Mojave 10.14 does not offer virtualenv by
default.

Fixed #3797

These distributions are past EOL.

Disabled LTO builds, tarballs and packages building on short-term
branches.

Removed 'allow_failures' on coverage / debug build.

Replaced matrix expansion with the list of jobs (because Travis-CI
documentation says it does not support condition jobs with matrix
expansion).

Fixes #3755.

Closes: #3761

The idea behind this change is to have 2x (and maybe later 3x, 4x, ...)
bucket for alpha and beta releases. See more details about the release
process in the documentation: [1].

[1]: https://tarantool.io/en/doc/2.0/dev_guide/release_management/

Main branch was renamed to master.
Update .travis.yml accordingly.

Replaced targets generation using a matrix expansion + exclusion list
with the explicit targets list. Gave meagingful names for targets.

Fixes #3673.

We made a mistake when tagging 1.7.5, which confused git describe.
Now we have added more tags and the hack with removal can be deleted.

- Remove old versions of Fedora and Ubuntu
- Add Fedora 26 and Fedora 27

Patch removes Ubuntu Precise from Travis's testing matrix,
since it uses really outdated GCC v.4.6.x.

Switched from ubuntu zesty to artful, since zesty is EOLed on 13Jan2018

Remove all non-LTS versions of Ubuntu.