From: Alexander Turenko <alexander.turenko@tarantool.org> To: "Alexander V. Tikhonov" <avtikhon@tarantool.org> Cc: tarantool-patches@freelists.org Subject: [tarantool-patches] Re: [Re: Re: [PATCH v2 1/2] Gitlab-ci updated after reiview - w/o perf] Date: Sun, 23 Jun 2019 03:00:34 +0300 [thread overview] Message-ID: <20190623000034.nikvvi22ddibvtov@tkn_work_nb> (raw) In-Reply-To: <20190622235857.rvmop5w4hjz5kbqa@tkn_work_nb> Hi! Please, send answers for reviews to my @tarantool.org e-mail. I passed through your answers and looked into the actual code. Some old comments are still actual, I commented them here. Also I leave several comments re things that are not more actual just to clarify my initial ideas (where it seems that we misunderstood each other). WBR, Alexander Turenko. > >> +variables: > >> + VERSION_SUFFIX: "master" > >> + IMAGE_TEST: "${CI_REGISTRY}/${CI_PROJECT_PATH}:debian-stretch_${VERSION_SUFFIX}" > >> + IMAGE_TEST_LTO: "${CI_REGISTRY}/${CI_PROJECT_PATH}:debian-buster_${VERSION_SUFFIX}" > > > >This suffix does not resolve any problems with changed dependencies. So, > >we should either remove it for now or really resolve the problem: say, > >use $(md5sum .travis.mk | awk '{ print $1 }') as a tag name. > > > Not possible to use scripts for variables, neither use API to remove images from registry. Not resolved. Now I fixed it myself. See [1]. [1]: https://www.freelists.org/post/tarantool-patches/PATCH-v4-02-Implement-Gitlabci-testing-process,1 > >> + FLAG_LTO: "-DENABLE_LTO=ON" > > > >I think -DENABLE_LTO-ON is more self-descriptive then this variable > >name. There is no need to extract it to a variable. > > > Fixed, set name to: 'DENABLE_LTO_ON' I mean that there is no need in this variable at all. Please, inline the variable value. > >> +debian10_lto: > >> + only: > >> + refs: > >> + - master > >> + - /.*/ > > > >As we discusssed voicely: /.*/ should not be here in a final patch. We > >however can provide an ability to run full testing on a branch different > >from master. Say, match /.*-full/. > > > >(The same is applicable for all such patterns below.) > > > Working on. Please, don't forget. It is not done for now as I see. > >> +freebsd_release: > >> + stage: test > >> + tags: > >> + - vms_freebsd > >> + variables: > >> + VMS_NAME: 'Freebsd' > > > >I would include a version number into the virtual machine name (and the > >job name too). > Fixed. VMS_NAME still does not contain an OS version. Is it hard to change? > >> +# build sources with different flags and test > > > >It is the title for the set of goals below? Looks as a comment for one > >goal. Also here I see that bootstrap, submodules update and runnign > >tests are doing, but not build sources. It seems the comment is not > >precise. > > > Right, the comment for a set of goals there below. So it should be separated from the next block of code with an empty like. Consider examples: | # comment for the next block | line 1 | line 2 | # comment for several blocks below | | line 1 | line 2 | | line 3 | line 4 Aside that more decorations often used to visually indent a file sections. I had rewrote docker_bootstrap goal and split .gitlab.mk to sections. See [1]. So this is now fixed. Please, be attend: you don't answer re 'the comment is not precise' part of my review comment. But this is anyway fixed already with my changes. > >Is there real need in this flag (some specific case when it is needed)? > >What will going on CentOS 6 if we'll run into this case? > > > Once I got the broken repository some how, '--force' flag fixed it, on CentOS 6 will need to fix it manually. It seems we now going to run submodules update outside of containers / virtual machines, but okay, let's leave both attempts to update the submodules: with --force and w/o it. > >> +deps_freebsd: > >> + # don't use bad py27-msgpack-python > > > >Can you link exact problem description here or in the commit message? > Removed, obvious message. It is not obvious for me why py27-msgpack-python is 'bad'. It seems we just don't need it, yep? > >> +runtest_freebsd: build_freebsd > >> + cd test && /usr/bin/python test-run.py --force $(NO_PARALLEL_TESTING) || true > > > >Volkswagen mode? > Currently FreeBSD testing is not ready and will fail pipeline, the issue in github exists, > but we really need the test result to check the new fails. So, please, use skipcond's to disable some tests on FreeBSD. This is very misleading to have a testing job that always report 'ok'.
parent reply other threads:[~2019-06-23 0:00 UTC|newest] Thread overview: expand[flat|nested] mbox.gz Atom feed [parent not found: <20190622235857.rvmop5w4hjz5kbqa@tkn_work_nb>]
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190623000034.nikvvi22ddibvtov@tkn_work_nb \ --to=alexander.turenko@tarantool.org \ --cc=avtikhon@tarantool.org \ --cc=tarantool-patches@freelists.org \ --subject='[tarantool-patches] Re: [Re: Re: [PATCH v2 1/2] Gitlab-ci updated after reiview - w/o perf]' \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: link
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox