From: "SZEDER Gábor" <szeder.dev@gmail.com>
To: Yang Zhao <yang.zhao@skyboxlabs.com>
Cc: Git Users <git@vger.kernel.org>
Subject: Re: [PATCH 01/13] ci: also run linux-gcc pipeline with python-3.7 environment
Date: Thu, 12 Dec 2019 18:15:16 +0100 [thread overview]
Message-ID: <20191212171516.GL6527@szeder.dev> (raw)
In-Reply-To: <CABvFv3J8JjXGeAXSWDmK5zDav8qYNQ6Ce-8dPGAmuySGj8xvNg@mail.gmail.com>
On Thu, Dec 12, 2019 at 09:04:24AM -0800, Yang Zhao wrote:
> On Thu, Dec 12, 2019 at 6:13 AM SZEDER Gábor <szeder.dev@gmail.com> wrote:
> >
> > > The CI scripts as it is currently does not separate compiling and testing for
> > > non-Windows builds. I don't see a good way to only run a specific set of tests
> > > given a particular environment without re-architecturing the CI pipeline.
> >
> > Building git and running the test suite is encapsulated in the
> > 'ci/run-build-and-tests.sh' script, while installing dependencies is
> > encapsulated in 'ci/install-dependencies.sh', just in case Azure
> > Pipelines Linux images don't contain both Python 2 and 3 (Travis CI
> > images contain 2.7 and 3.5) So I don't think it's necessary to touch
> > 'azure-pipelines.yml' or '.travis.yml' at all.
>
> Yes, and this is implemented as a single step as far as the CI
> pipeline is concerned. It does not produce a build artifact that can
> then be loaded into multiple environments for running tests.
I don't understand what artifact should be loaded into what
environments...
> Unless there's a very good reason to _not_ use Azure Pipeline's
> built-in Python version selection support, I believe it's more
> desirable in the long-run to leverage the feature rather than maintain
> some custom solution.
Azure Pipelines's built-in Python version selection support only works
on Azure Pipelines, therefore it's more desirable to have a general
solution.
next prev parent reply other threads:[~2019-12-12 17:15 UTC|newest]
Thread overview: 33+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-12-07 0:33 [PATCH 00/13] git-p4: python3 compatibility Yang Zhao
2019-12-07 0:33 ` [PATCH 01/13] ci: also run linux-gcc pipeline with python-3.7 environment Yang Zhao
2019-12-10 10:30 ` SZEDER Gábor
2019-12-10 19:11 ` Yang Zhao
2019-12-12 14:13 ` SZEDER Gábor
2019-12-12 17:04 ` Yang Zhao
2019-12-12 17:15 ` SZEDER Gábor [this message]
2019-12-12 19:02 ` Yang Zhao
2019-12-07 0:33 ` [PATCH 02/13] git-p4: make python-2.7 the oldest supported version Yang Zhao
2019-12-07 0:33 ` [PATCH 03/13] git-p4: simplify python version detection Yang Zhao
2019-12-07 0:33 ` [PATCH 04/13] git-p4: decode response from p4 to str for python3 Yang Zhao
2019-12-07 0:33 ` [PATCH 05/13] git-p4: properly encode/decode communication with git for python 3 Yang Zhao
2019-12-07 0:33 ` [PATCH 06/13] git-p4: convert path to unicode before processing them Yang Zhao
2019-12-07 0:33 ` [PATCH 06/13] git-p4: open .gitp4-usercache.txt in text mode Yang Zhao
2019-12-07 0:33 ` [PATCH 07/13] git-p4: convert path to unicode before processing them Yang Zhao
2019-12-07 0:33 ` [PATCH 07/13] git-p4: open .gitp4-usercache.txt in text mode Yang Zhao
2019-12-07 0:33 ` [PATCH 08/13] git-p4: use marshal format version 2 when sending to p4 Yang Zhao
2019-12-07 0:33 ` [PATCH 09/13] git-p4: fix freezing while waiting for fast-import progress Yang Zhao
2019-12-07 0:33 ` [PATCH 10/13] git-p4: use functools.reduce instead of reduce Yang Zhao
2019-12-07 0:33 ` [PATCH 11/13] git-p4: use dict.items() iteration for python3 compatibility Yang Zhao
2019-12-07 0:33 ` [PATCH 12/13] git-p4: simplify regex pattern generation for parsing diff-tree Yang Zhao
2019-12-07 0:33 ` [PATCH 13/13] git-p4: use python3's input() everywhere Yang Zhao
2019-12-07 1:09 ` [PATCH 00/13] git-p4: python3 compatibility Denton Liu
2019-12-07 7:29 ` Yang Zhao
2019-12-07 16:21 ` Ben Keene
2019-12-07 19:59 ` Yang Zhao
2019-12-09 15:03 ` Ben Keene
2019-12-09 18:54 ` Ben Keene
2019-12-09 19:48 ` Johannes Schindelin
2019-12-10 14:20 ` Ben Keene
2019-12-09 20:21 ` Yang Zhao
2019-12-13 17:10 ` Ben Keene
2019-12-07 7:34 ` Yang Zhao
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=20191212171516.GL6527@szeder.dev \
--to=szeder.dev@gmail.com \
--cc=git@vger.kernel.org \
--cc=yang.zhao@skyboxlabs.com \
/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
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.