From: Alexander Turenko <alexander.turenko@tarantool.org> To: "Alexander V. Tikhonov" <avtikhon@tarantool.org> Cc: tarantool-patches@dev.tarantool.org Subject: Re: [Tarantool-patches] [PATCH v2 1/2] gitlab-ci: save failed test results files Date: Mon, 21 Sep 2020 05:18:13 +0300 [thread overview] Message-ID: <20200921021813.t7pfdtlpupv6fnbk@tkn_work_nb> (raw) In-Reply-To: <ab7df4e9efa6ffcea626f76e3a9fc0b8708f9d10.1600329681.git.avtikhon@tarantool.org> > + <<: *artifacts_reject_files_definition > + > +.pack_artifacts_reject_files_template: &pack_artifacts_reject_files_definition > + <<: *artifacts_reject_files_definition > + after_script: > + - > > + for f in `ls build/usr/src/*/tarantool-*/test/*/*.reject` ; do Nit: 'for f in path-with-star-globbing; do' would do almost the same and I would suggest to use the simpler form (it also does not depend on an external tool and does not involve forking), but this way we should handle 'no such files' case explicitly. See example here: https://github.com/tarantool/tarantool/commit/080beba063b05b184d7befcb15a8bcf32e7424f6 | for file in @TARANTOOL_ENABLEDDIR@/*.lua; do | instance=`basename $file .lua` | [ "${instance}" = "*" ] && break # skip empty directory | <...> | done When the glob is not matched, it falls into the loop with the 'as is' value (with star symbols). We all like bourne shell for those funny pitfalls. > + d=`dirname $f | sed 's#^build/usr/src/.*/tarantool-.*/test/##g'` ; > + mkdir -p test/$d 2>/dev/null ; > + cp $f test/$d/. ; > + done ; > + rm -rf test/var ; mkdir -p test/var ; > + cp -r build/usr/src/*/tarantool-*/test/var/artifacts test/var/. Nit: The period at the end looks unusual, but don't change anything. The patch would be a way simpler if test-run would collect everything that is necessary to upload within the artifacts directory. In fact, reject files are already there: test/var/artifacts/<worker_name>/<test_name>.result. But if you want to organize them in an another way, I would do this on the test-run side (somewhere within test/var/artifacts). Related code: [1]. See, the reject file is just copied, not moved. [1]: https://github.com/tarantool/test-run/blob/461731d71cf27faa6295bc759941f402fedc88e4/lib/test.py#L254
next prev parent reply other threads:[~2020-09-21 2:18 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2020-09-17 8:04 [Tarantool-patches] [PATCH v2 0/2] " Alexander V. Tikhonov 2020-09-17 8:04 ` [Tarantool-patches] [PATCH v2 1/2] " Alexander V. Tikhonov 2020-09-21 2:18 ` Alexander Turenko [this message] 2020-09-23 6:45 ` Alexander V. Tikhonov 2020-09-17 8:04 ` [Tarantool-patches] [PATCH v2 2/2] gitlab-ci: set opensuse jobs to test group Alexander V. Tikhonov 2020-09-25 15:50 ` Kirill Yukhin
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=20200921021813.t7pfdtlpupv6fnbk@tkn_work_nb \ --to=alexander.turenko@tarantool.org \ --cc=avtikhon@tarantool.org \ --cc=tarantool-patches@dev.tarantool.org \ --subject='Re: [Tarantool-patches] [PATCH v2 1/2] gitlab-ci: save failed test results files' \ /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