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

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Mar 27, 2023, 10:37 UTC
Message-ID: <d566eb68-6476-a193-2acb-10106a154d3d@gmx.de>
In-Reply-To: <xmqqtu20qinx.fsf@gitster.g>

Hi Junio

On Tue, 13 Dec 2022, Junio C Hamano wrote:

Show 20 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > The hard-coded object IDs break the `linux-sha256` job, as pointed out in
> > https://github.com/git/git/blob/6ab7651d8669/whats-cooking.txt#L522-L537.
> >
> > Please squash this in to address this (Junio, please feel free to
> > cherry-pick this on top of `tl/ls-tree--pattern` to reduce the number of
> > CI failures):
>
> These days, I gather topics with known CI breakages near the tip of
> 'seen', and push out only the good bottom half of 'seen' until such
> a topic gets rerolled, at which time it gets added back to the set
> of topics pushed out on 'seen' again (and then ejected if it CI
> breaks).  I excluded the part with the topic from last night's
> pushout.
>
> By the way do you know anything about xterm-256color error in win
> test(6)?
>
> https://github.com/git/git/actions/runs/3676139624/jobs/6216575838#step:5:196

Unfortunately by the time I got back to this mail, the log had expired. Here is a link to the same symptom in a newer build:

https://github.com/git/git/actions/runs/4523517641/jobs/7966768829#step:6:63

Show 5 quoted lines

> I do not think we hard-code any specific terminal name (other than
> dumb and possibly vt100) in our tests or binaries, so it may be
> coming from the CI runner environment---some parts incorrectly think
> xterm-256color is available there while there is no support for the
> particular terminal?

The TERM is hard-coded in the MSYS2 runtime: https://github.com/git-for-windows/msys2-runtime/commit/bd627864ab4189984cdb0892c00f91e39c4e8243

Note: The MSYS2 runtime merely wants to ensure that `TERM` is set; If it
already has a value, that value remains unchanged.

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.

If these `tput` errors become too much of a sore in your eye, I see two ways forward:

- Set `TERM=dumb` for the Windows jobs

- Use a simple shim like this one in `ci/` (and maybe even in
  `t/test-lib.sh`):

  tput() {
  	printf '\e[%sm%s'"$(test sgr0 != $1 || echo '\x0f')" "$( \
		case $1 in
		bold) echo 1;;
		dim) echo 2;;
		rev) echo 7;;
		setaf) echo 3$2;;
		setab) echo 4$2;;
		esac \
	)"
  }

Personally, I do not really want to work on this, not before much bigger fish are fed first. For example, the friction regarding the CI build times is becoming quite crushing.

Ciao, Johannes