From: "Alexander Tikhonov" <avtikhon@tarantool.org> To: "Alexander Turenko" <alexander.turenko@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v1] gitlab-ci: cleanup submodules Date: Mon, 09 Dec 2019 07:07:59 +0300 [thread overview] Message-ID: <1575864479.101076547@f192.i.mail.ru> (raw) In-Reply-To: <20191209031155.iukodx2tkath4z4u@tkn_work_nb> [-- Attachment #1: Type: text/plain, Size: 3343 bytes --] Alexander, Thanks for a review, please check my comments >Понедельник, 9 декабря 2019, 6:12 +03:00 от Alexander Turenko <alexander.turenko@tarantool.org>: > >All jobs are run in a docker or in a virtual machine. How can we get a >dirty directory for a run? That is not quiet right, yes - we use the docker for running the testing jobs, but the source code comes into the docker using shared path from the real host: /home/gitlab-runner/builds/<uniq name per each job runner>/<number of the parallel job of the runner>/tarantool/tarantool Also we use the following setting: https://gitlab.com/tarantool/tarantool/-/settings/ci_cd git fetch Faster as it re-uses the project workspace (falling back to clone if it doesn't exist) It means that the source code is saving between each gitlab-runner jobs, and only fetching. In this way the submodule may have some files left from the previous checked tag, like we have files left after switching from 2.x releases to 1.10 - at this switching some tests files are left in the sources and it makes the test-run tool tries to recreate the tests result files automatically, like here: https://gitlab.com/tarantool/tarantool/-/jobs/371542808 3367 [385] TAP13 parse failed: Missing plan in the TAP source 3368 [385] [ new ] 3369 [385] small/slab_arena.test [ pass ] 3370 [385] small/slab_cache.test [ pass ] 3371 [385] small/small_alloc.test [ pass ] 3372 [385] small/static.test 3373 [385] TAP13 parse failed: Missing plan in the TAP source 3374 [385] [ new ] > > >I don't mind if it solves some problems, but now I don't understand what >the problems are. > >WBR, Alexander Turenko. > >On Thu, Nov 07, 2019 at 02:13:46PM +0300, Alexander V. Tikhonov wrote: >> Found that durring runs on Gitlab-CI workspaces > >durring -> during > >> some extra files from tests from the submodules >> like src/lib/small/* leaves in subdirectories, >> which produce warning messages at the Gitlab-CI >> run log, to avoid of it the submodules cleanup > >Which kind of warnings? > >> it needed before each Gitlab-CI job. > >it -> is? > >> >> Closes #4258 > >I would treat the issue as a more wide problem, then CI's one (Kirill >met it locally). I propose to left the issue open, but mention it like: > > | Follows on #4258. > >> --- >> >> Github: https://github.com/tarantool/tarantool/tree/avtikhon/gh-4258-clean-ws-full-ci >> Issue: https://github.com/tarantool/tarantool/issues/4258 >> >> .gitlab-ci.yml | 3 +++ >> 1 file changed, 3 insertions(+) >> >> diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml >> index 04bb4b1cc..91326b218 100644 >> --- a/.gitlab-ci.yml >> +++ b/.gitlab-ci.yml >> @@ -4,6 +4,9 @@ stages: >> variables: >> GITLAB_MAKE: "make -f .gitlab.mk" >> >> +before_script: >> + - git submodule foreach git clean -xfd >> + > >1. Run `git clean -xfd` too (not only submodules). >2. Add --recursive after 'foreach' just in case. >3. Enclose 'git clean -xfd' for submodules into quotes: otherwise it > does not work on some git versions (I found that after some update). > >For the reference, my one-liner that always work (at least for me): > >$ git clean -xfd; git submodule foreach --recursive 'git clean -xfd' > >> # Jobs templates >> >> .release_only_template: &release_only_definition >> -- >> 2.17.1 >> -- Alexander Tikhonov [-- Attachment #2: Type: text/html, Size: 22823 bytes --]
prev parent reply other threads:[~2019-12-09 4:07 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-11-07 11:13 Alexander V. Tikhonov 2019-12-09 3:11 ` Alexander Turenko 2019-12-09 4:07 ` Alexander Tikhonov [this message]
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=1575864479.101076547@f192.i.mail.ru \ --to=avtikhon@tarantool.org \ --cc=alexander.turenko@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v1] gitlab-ci: cleanup submodules' \ /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