I'm unable to get colors working when I use Gitlab CI Multi Runner (v0.7.2) on Windows using "cmd" (I didn't try using Powershell). Here is a simple example. It works fine if I execute it on Windows directly but I don't get colours when I use the runner. (The script is in a .bat file that I call in
@echo off SETLOCAL EnableDelayedExpansion for /F "tokens=1,2 delims=#" %%a in ('"prompt #$H#$E# & echo on & for %%b in (1) do rem"') do ( set "DEL=%%a" ) call :ColorText 0a "blue" call :ColorText 0C "green" call :ColorText 0b "red" echo( call :ColorText 19 "yellow" call :ColorText 2F "black" call :ColorText 4e "white" goto :eof :ColorText echo off <nul set /p ".=%DEL%" > "%~2" findstr /v /a:%1 /R "^$" "%~2" nul del "%~2" > nul 2>&1 goto :eof
Any ideas ? Is it a know issue ?
I can confirm that this is also the case with powershell
Stuff I've found:
- Running the test script manually (
python test_color.py) on the build machine works just fine.
- Executing the build locally via
gitlab-runner exec shell --shell=cmd verify-ymlprints the script's colored lines correctly, but not the runner version line. (Note the
←[0:mstuff on the 1st two lines)
- The web interface prints out the runner version in color correctly, but not the script's colored lines.
Versions and whatnot.
- Windows 8.1 Pro, 64-bit
- GitLab Multi-Runner v1.0.4 (014aa8c2)
- executor = "shell"
- shell = "cmd"
- Running the test script manually (
The most likely problem is that python outputs colors in format compatible with Windows Terminal, but doesn't emulate the Unix ANSI terminal.
Not sure if this is resolvable.
Added ~159938 labelToggle commit list
outputs colors in format compatible with Windows Terminal, but doesn't emulate the Unix ANSI terminal.
That's mostly true. The original string actually does have the ANSI codes in it, but when the program is run in a Windows terminal, the
Coloramapackage converts those ANSI codes to win32 calls.
This is an issue that would show up in any language that uses the win32 calls to change the terminal color.
In .gitlab-ci.yml, tell my test runner (
green) to not use Colorama
- This would mean that the ANSI color codes are still present when the output is sent to the webUI
- I've already made a PR for green to get this option enabled.
- This is the easiest option
take the win32 calls that Colorama outputs and convert them to ANSI codes on the webUI end
- Not possible: there are no tokens in the string after Colorama does its thing. Source
Change the way that the web interface gets the build output from the runner
- I'm assuming that the gitlab runner just pipes output from wherever it's running (Windows) to some unix terminal emulator on the web interface. If so, then it's probably not easy to fix the issue.
Running the gitlab-runner on a windows machine.
Correct output for a Windows machine:
Yes, we try to emulate the UNIX ANSI terminal. It's not perfect though, but it's sufficient to have the coloring.
Not sure if this is solvable. If commands outputs the ANSI codes it will work also on Windows.
So maybe the option is to parse the Windows codes and convert them to ANSI ones? (it seems complicated).
@ayufan There are no Windows codes to parse. All Windows coloring is done via win32 API calls.
So yes, I believe that you are correct that this is not solvable on the GitLab end. Users will need to make sure that their Windows application does output ANSI codes when running on GitLab-CI, even when gitlab-runner is on a Windows machine.
I would recommend adding some CI documentation somewhere that conveys the information found in this discussion. If someone tells me where in the docs they'd like it, I'll create the MR myself.
@dougthor42 Please put that in FAQ since this tries to answer how to solve one of the problems: https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/tree/master/docs/faq.
I'm closing it, since the conclusion is that this problem is not solvable and the MR with FAQ update was merged.
Status changed to closedToggle commit list
The problem is solvable, and @dougthor42's PR for green was accepted on April 1. I don't see this as an unsolvable issue. I see it as solvable, and the solutions previously presented were overlooked. Sure his screen grab wasn't pretty in the console, but we're talking about implementing a server-side solution ... so who cares?
Please re-open this and implement in .gitlab-ci.yml, the tell my test runner (green) to not use Colorama option already presented. I would argue that this should be the default option for handling Windows runners, but I'm not familiar with the implications in all scenarios.
PowerShell Specific Solution
In PowerShell, I could just write a
Write-Hostproxy function that catches the color specified in the
BackgroundColorparameters and prepends the ANSI code, but I'm not sure where in the process Colorama is doing its thing. Also, could do the same prepend for
Write-Warning, and maybe even
Write-Progress. The proxy functions could sit in my project, but I would have the same proxy functions in all my projects designed to fix multi-runner output. Ideally the proxy functions should live in this project and be auto-imported by the runner if PowerShell is the default shell.
Otherwise, I could do something kinda hacky and have the
.gitlab-ci.ymlscript section do something like this, as an initial step, for any PowerShell I want to try to fix:
pester_tests: tags: - Pester script: > Invoke-Expression (Invoke-WebRequest "https://gitlab.com/snippets/23951/raw" -UseBasicParsing).Content; Invoke-Pester -EnableExit;
‼That snippet currently isn't populated, but I'll gladely get a sample in there if there's interest ... and remove this line.
I don't currently have the time to dig through the code and become intimate with multi-runner. However, I'll make the proxy function and submit the PR, but I would appreciate feedback on where these
Write-Host.ps1et al. files should live in the project. I'm thinking somewhere in Helpers is appropriate, but I'm just not sure.
Note, this is all speculative at this point. Ok, back to real work for me.