summaryrefslogtreecommitdiff
path: root/.gitlab-ci.yml
Commit message (Collapse)AuthorAgeFilesLines
* Merge 10.7 into 10.8Marko Mäkelä2022-07-281-2/+4
|\
| * Fix Ninja builds on Gitlab-CI by limiting parallelismAnson Chung2022-07-181-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In previous versions it was stated that MDEV-25968 was causing other jobs in the pipeline to fail if not run with "-j 2" but this bug was not affecting fedora-ninja. This is still true for the public gitlab runners. However, running the fedora-ninja job on custom runners with more processors without the "-j 2" flag will cause the compiler to crash. When running the build with 2,4,8,16,32 threads, build times were consistent indicating that the typical bottleneck is I/O and not CPU cores. Therefore, "-j 2" is not a big drawback and it was chosen in order to remain consistent with the other builds affected by MDEV-25968. All new code of the whole pull request, including one or several files that are either new files or modified ones, are contributed under the BSD-new license. I am contributing on behalf of my employer Amazon Web Services, Inc.
* | Merge 10.7 into 10.8Marko Mäkelä2022-03-111-4/+4
|\ \ | |/
| * Fix failing Gitlab-CI by fixing CentOS 8 repo urlsOtto Kekäläinen2022-03-091-2/+2
| |
| * Fix failing Gitlab-CI by adding pcre2-devel as a build dependencyOtto Kekäläinen2022-03-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | The commits a73acf6c068a39d0bb9437e05b0b60a87e46bba8 and 4d74bac8bc8c14c2b217391b3b8860f3dc701202 updated the PCRE library to a new version, which in turn requires CMake 3.0. That does not exist in CentOS 7 nor 8, so builds started failing. Actually the build should not be downloading anything at all. The root cause was that pcre2-devel was missing from the dependencies. This was originally not detected, as the download fallback had masked the issue.
* | Extend the Gitlab-CI pipeline to run mini benchmarkOtto Kekäläinen2022-01-221-1/+30
|/ | | | | | | | | | | Implement new mini-benchmark script for simple CPU bound benchmark for the duration of 5 minutes. The script can be run stand-alone or as part of a CI pipeline. Extend Gitlab-CI to run mini-benchmark on every commit to catch if there are severe performance regressions. Also bump MARIADB_MAJOR_VERSION to 10.8 which is needed on the 10.8 branch.
* Misc improvements to the Gitlab-CI pipeline for MariaDBOtto Kekäläinen2021-09-291-49/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | - Add new Ninja and Clang build jobs. This helps to ensure those toolchains also work in addition to default CMake/gcc. - Generate dependencies.dot/png to illustrate the CMake/Make/Ninja build dependencies. Viewing this image and identifying bottle necks in parallelism can help make the build run faster. - Enable CUnit tests now as they are fixed on 10.6 (MDEV-25820). - Limit parallel builds to 2 CPUs (full parallelism needs MDEV-25968) on CMake/Make. Now only the Ninja builds run full parallel builds as only Ninja is smart enough to prevent builds failing on resource over-consumption. - Enable Gitlab-CI cache for job 'centos8' for ccache so that it builds faster. Don't use Gitlab-CI cache for other jobs, as it would too easily use up all free tier storage on Gitlab.com and force users to get a paid account just for MariaDB builds. - On other jobs clean away ccache, as it only had a 5% hit rate on single builds with no downloaded cache. - Dump full database contents during the test install so that one can use diff to compare the database contents at different stages and thus track/debug potential bugs in mariadb-install-db and mariadb-upgrade code. Bugfixes: - Zero out ccache stats before each run so that 'ccache -s' would actually show the stats for the latest run.
* Implement simple Gitlab-CI pipeline for MariaDB with RPM buildsOtto Kekäläinen2021-07-141-0/+270
As Travis-CI has stopped offering free testing for open source projects, and they don't seem to have any plans to revert their new restrictions, MariaDB no longer has a good CI system outside contributors could run independently for basic validation before submitting Pull Requests. Implement a simple Gitlab-CI pipeline that runs basic RPM builds on one old, one less old and one very new distro release and then do some basic tests on the RPM packages to validate they installed and the server actually runs.