Tarantool development patches archive
 help / color / mirror / Atom feed
From: "Alexander V. Tikhonov" <avtikhon@tarantool.org>
To: Alexander Turenko <alexander.turenko@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH v3] gitlab-ci: save failed test results artifacts
Date: Thu, 24 Sep 2020 07:24:09 +0300	[thread overview]
Message-ID: <20200924042409.GA3997@hpalx> (raw)
In-Reply-To: <20200924034031.htguqxtq3svnx2om@tkn_work_nb>

Hi Alexander, thanks for the review, just commented your questions to
make it clear.

On Thu, Sep 24, 2020 at 06:40:31AM +0300, Alexander Turenko wrote:
> Nothing contradicts with my vision (I became a bit more far from details
> now). LGTM. Several comments below (no need to re-review with me if
> you'll want to make changes according to those comments).
> 
> WBR, Alexander Turenko.
> 
> >  .vbox_template: &vbox_definition
> >    stage: test
> >    after_script:
> > -    - ${GITLAB_MAKE} vms_shutdown
> > +    - >
> > +      scp -r -P ${VMS_PORT} ${VMS_USER}@127.0.0.1:tarantool/test/var/artifacts . ;
> > +      ${GITLAB_MAKE} vms_shutdown
> > +  <<: *artifacts_files_definition
> 
> Nit: Using literal style indicator (the pipe symbol instead of the angle
> bracket) would look more intuitive and does not require the semicolon.
> (The folded style ('>') replaces newlines with spaces and it should be
> used when this behaviour is wanted I think.)
>

I did use it after investigation and found the following, [1] - where
in the gitlab-ci issue disscussion was told to use '>' instead of '|',
and previous discussion [2], where it was described.

[1] - https://gitlab.com/gitlab-org/gitlab-runner/-/issues/166
[2] - https://stackoverflow.com/questions/3790454/how-do-i-break-a-string-over-multiple-lines/3790497#3790497

> >  static_build_cmake_osx_15:
> > -  stage: test
> > +  <<: *osx_definition
> >    tags:
> >      - osx_15
> >    script:
> 
> Nit: This change is not mentioned in the commit message.
>

That is absolutely the same code. It was used to inherit 'after_script'
part:

.osx_template: &osx_definition
  <<: *artifacts_files_definition
  stage: test
  script:
    - ${GITLAB_MAKE} test_osx
  after_script:
    # Artifacts can't be used from outside the project directory, check:
    #   https://docs.gitlab.com/ee/ci/yaml/README.html#artifactspaths
    # "Paths are relative to the project directory ($CI_PROJECT_DIR)"
    # "and can’t directly link outside it."
    - cp -rf ${OSX_VARDIR}/artifacts .

'script' part would be overwritten from '&osx_definition':
  script:
    - ${GITLAB_MAKE} test_osx
to:
  script:
    - ${GITLAB_MAKE} test_static_build_cmake_osx


> > diff --git a/.travis.mk b/.travis.mk
> > index d8f97ef5c..577970d8f 100644
> > --- a/.travis.mk
> > +++ b/.travis.mk
> > @@ -242,11 +242,11 @@ INIT_TEST_ENV_OSX=\
> >  		launchctl limit maxproc || : ; \
> >  		ulimit -u ${MAX_PROC} || : ; \
> >  		ulimit -u ; \
> > -		rm -rf /tmp/tnt
> > +		rm -rf ${OSX_VARDIR}
> 
> Just in case: should not we set some default value for this variable in
> case we'll run this rule outside of CI (or in CI, which is not GitLab
> CI)?

Right, it' better to have, corrected .gitlab.mk:

diff --git a/.travis.mk b/.travis.mk
index 577970d8f..c09f1c4cb 100644
--- a/.travis.mk
+++ b/.travis.mk
@@ -9,6 +9,7 @@ MAX_FILES?=65534
 MAX_PROC?=2500
 OOS_SRC_PATH="/source"
 BIN_DIR=/usr/local/bin
+OSX_VARDIR?=/tmp/tnt

 CLOJURE_URL="https://download.clojure.org/install/linux-install-1.10.1.561.sh"
 LEIN_URL="https://raw.githubusercontent.com/technomancy/leiningen/stable/bin/lein"

  reply	other threads:[~2020-09-24  4:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23  6:40 Alexander V. Tikhonov
2020-09-24  3:40 ` Alexander Turenko
2020-09-24  4:24   ` Alexander V. Tikhonov [this message]
2020-09-25 15:48 ` 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=20200924042409.GA3997@hpalx \
    --to=avtikhon@tarantool.org \
    --cc=alexander.turenko@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH v3] gitlab-ci: save failed test results artifacts' \
    /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