From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <alexander.turenko@tarantool.org>
Received: from smtp32.i.mail.ru (smtp32.i.mail.ru [94.100.177.92])
 (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits))
 (No client certificate requested)
 by dev.tarantool.org (Postfix) with ESMTPS id 2387F445320
 for <tarantool-patches@dev.tarantool.org>;
 Tue, 28 Jul 2020 14:50:32 +0300 (MSK)
Date: Tue, 28 Jul 2020 14:49:37 +0300
From: Alexander Turenko <alexander.turenko@tarantool.org>
Message-ID: <20200728114937.6gkhs2gyp6dronrr@tkn_work_nb>
References: <743d88188d0de8e36d4bd7a7630eab9d8bf8aa1e.1595854211.git.avtikhon@tarantool.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <743d88188d0de8e36d4bd7a7630eab9d8bf8aa1e.1595854211.git.avtikhon@tarantool.org>
Subject: Re: [Tarantool-patches] [PATCH v1] gitlab-ci: save failed test
	results files
List-Id: Tarantool development patches <tarantool-patches.dev.tarantool.org>
List-Unsubscribe: <https://lists.tarantool.org/mailman/options/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=unsubscribe>
List-Archive: <https://lists.tarantool.org/pipermail/tarantool-patches/>
List-Post: <mailto:tarantool-patches@dev.tarantool.org>
List-Help: <mailto:tarantool-patches-request@dev.tarantool.org?subject=help>
List-Subscribe: <https://lists.tarantool.org/mailman/listinfo/tarantool-patches>, 
 <mailto:tarantool-patches-request@dev.tarantool.org?subject=subscribe>
To: "Alexander V. Tikhonov" <avtikhon@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org

> Needed for #5050

As I stated in [2] there is nothing about CI artefacts in #5050. There
is [3] about this.

> +.artifacts_reject_files_template: &artifacts_reject_files_definition
> +  artifacts:
> +    when: always
> +    paths:
> +      - "test/*/*.reject"

Are we need it when a job passes? Maybe save artefacts only for failed
jobs?

I would set `expire_in` into some large value (it is not possible to
store an artefact infinitely, gitlab docs lie), because we not always
start to investigate a flaky fail within 4 weeks. See [1] (it suggests
`expire_in: 1000 yrs`).

I also commented [2] and it seems the proposed changes will affect this
PR.

> +  variables:
> +    VARDIR: ${OSX_VARDIR}
> +  after_script:
> +    - rm -rf test/var ; mkdir test/var && cp -rfp ${OSX_VARDIR}/*.reject test/var/.
> <...>
> -		rm -rf /tmp/tnt ; \
> -		cd test && ./test-run.py --vardir /tmp/tnt --force $(TEST_RUN_EXTRA_PARAMS)
> +		rm -rf ${VARDIR} ; \
> +		cd test && ./test-run.py --vardir ${VARDIR} --force $(TEST_RUN_EXTRA_PARAMS)

I don't understand what is going on here, but I hope that we can drop it
after PR #218 (see [2]) changes.

> diff --git a/test-run b/test-run
> index d92032233..0e8da635b 160000
> --- a/test-run
> +++ b/test-run
> @@ -1 +1 @@
> -Subproject commit d92032233e10db8934ae5fed17fe3f3ae8293645
> +Subproject commit 0e8da635b76416e2ae0704c285e2bf42279f53ae

I'll update the test-run submodule separately as I always do.

[1]: https://gitlab.com/gitlab-org/gitlab/-/issues/22761#note_251722017
[2]: https://github.com/tarantool/test-run/pull/218
[3]: https://github.com/tarantool/test-run/issues/90