Re: What's cooking in git.git (Jan 2020, #04; Wed, 22)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Wed, Feb 05, 2020 at 01:01:50PM -0800, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes:
> 
> >> Do they have to shout that loudly in the name?
> >>
> >> We could rename these jobs to e.g. 'linux-clang-py2' and the like, but
> >> I think it would bring little benefit, if any.  In our Travis CI
> >> builds these Linux/OSX Clang/GCC jobs come from the build matrix,
> >> therefore the jobname is not visible on the Travis CI web interface or
> >> API, only in the build logs.  There are some pages on Azure Pipelines
> >> that do show the jobname (and some that could, but hide it instead),
> >> but it's just too convoluted (or sometimes even impossible, well, for
> >> me anyway) to get there.
> >>
> >> And if the requested Python binary can't be found, which will
> >> eventually happen with 'python2', then the non-zero exit code of
> >> 'which' will abort the build, no matter how the job is called.
> >
> > I am mostly worried about contributors whose PRs break for "magic"
> > reasons. If it is not clear where the difference between `linux-gcc` and
> > `linux-clang` lies, that can cause unintended frustration, and I do not
> > want to cause that.

I'm not worried about that.  If a contributor doesn't touch any of our
Python scripts, then I don't see why using a different Python version
in the build would cause any issues.  And if they do modify one of the
Python scripts, then they should make sure that their modifications
work both with Python 2 and 3 in the first place.

> So, what, if any, decision have we reached?
> 
> If linux-gcc and linux-clang labels are not visible, linux-clang-py2
> and osx-py3 would not be, either, so...

The 'linux-gcc' and 'linux-clang' labels are not visible on Travis CI,
because those jobs as part of the build matrix, and, consequently, we
can't set the a 'jobname' environment variable for them in
'.travis.yml'.  If we were to include additional jobs for the Python
scripts, then for those we can (and should!) set
'jobname=linux-python' or something, and that would be visible on the
Travis CI web interface, just like e.g. 'jobname=StaticAnalysis'.




[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]

  Powered by Linux