Re: win-test: unknown terminal "xterm-256color", was Re: [RFC PATCH 6/6] ls-tree: introduce '--pattern' option

[Jeff King <peff@peff.net>]

On Mon, Mar 27, 2023 at 01:42:11PM -0700, Junio C Hamano wrote:

> > And to save on bandwidth/time (in a desperate attempt to counter the
> > ever-growing runtimes of Git's CI builds), I liberally exclude files from
> > the "minimal subset of Git for Windows' SDK", e.g. `/usr/lib/terminfo/`
> > and `/usr/share/terminfo/`. That's why `tput` cannot figure out what to do
> > with this `TERM` value.
> 
> Ah, so it is not like "you ship vt100 but not xterm-color yet the
> runtime insists you are by default on xterm-color", so "set it to
> something your terminfo database understands" would not work.  I am
> not sure what unintended fallouts there would be from setting it to
> dumb, though.  Our tests are designed for unattended testing, and
> they are even capable of running without control terminal, so it
> should be OK to force TERM=dumb, I guess.

We already force TERM=dumb in test-lib.sh, so the tests themselves
should behave the same. The original terminal is only used for colorized
output from the test harness itself. But I don't think we'd colorize
anyway in CI, since stdout is not a terminal (and we tend to further go
through "prove" anyway).

So it should be fine to just set TERM=dumb everywhere. What actually
confuses me is that we try to do so already:

  $ git grep -B1 dumb ci/lib.sh
  ci/lib.sh-# GitHub Action doesn't set TERM, which is required by tput
  ci/lib.sh:export TERM=${TERM:-dumb}

Pushing a stripped-down workflow file to just run "echo $TERM" shows
that it seems to already be set by Actions to "dumb" on ubuntu-latest,
but is xterm-256color on windows-latest.

So maybe we just want to make the line above unconditionally set $TERM?

-Peff