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

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

 



Hi Junio

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

> Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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

> 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




[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