buildkite / terminal-to-html Goto Github PK
View Code? Open in Web Editor NEWConverts arbitrary shell output (with ANSI) into beautifully rendered HTML
Home Page: http://buildkite.github.io/terminal-to-html
License: MIT License
Converts arbitrary shell output (with ANSI) into beautifully rendered HTML
Home Page: http://buildkite.github.io/terminal-to-html
License: MIT License
iTerm’s hyperlink format differs from that supported by us, which makes interoperability a bit weird.
iTerm 2’s links look like this:
printf '\033]8;;https://buildkite.com\aBuildkite\033]8;;\a'
Our links look like this:
printf '\033]1339;url=https://buildkite.com;content=Buildkite\a’
Valid links in Buildkite’s style don’t render at all in iTerm 2, whilst due to being surrounded by ANSI escape codes, iTerm 2’s links fall back to just being text.
Bonus points: If we felt really fancy, we could even make use of the extra provision for a key-value parameter to enable a fix for #32:
printf '\033]8;target=_blank;https://buildkite.com\aBuildkite\033]8;;\a'
cc @sj26 @keithpitt
The problem (as described to me by @keithpitt) is terminal (and its ecosystem) need to support the common use case of being able to see output as it happens, including being able to display in-browser those clever npm/yarn/docker spinners and progress bars and so forth.
Keith and I discussed a few ideas:
BK sends the browser raw ANSI, the browser parses it and displays it to the user. Bor-ing.
Terminal is responsible for parsing the ANSI and turning it in to a set of instructions (eg left; up; color 3; write bob
) that are then sent to the browser for interpretation.
Terminal parses the ANSI, renders it to an internal buffer, and at a set interval (once per second? faster? when a certain amount of input is read?) sends the lines to the browser. The browser receives the lines and either adds them to the DOM (if it's a new line) or replaces it (if it's an existing line).
Terminal would stream JSON blobs (with one blob per newline) that would look something like this:
{ line: 1, html: "<span class=..." }
...
{ line: 50, html: "Loading.. 10%" }
{ line: 50, html: "Loading.. 20%" }
{ line: 50, html: "Loading.. 30%" }
My command line tool values proper typography, and so it uses curly quotes (“ ” ‘ ’
) whenever appropriate ;-)
However, this causes output in the build log like ���foo���
when I expect “foo”
. Can that be fixed?
Hi,
Can you please add Orange color?
fg - 38
bg - 48
While iTerm2 images are working, buildkite itself has a 1mb limit on build logs, which means that using the image inlining for showing screenshots of failed browser tests in builds would quickly exceed this limit.
I propose a new "standard" for referring to images that are part of the build artifacts.
The iTerm2 standard currently looks like:
\x1b[1337;File=name=1.gif;width=100%;height=50px;inline=1:BASE64\a
Ours could be:
\x1b[1338;name=output/1.gif;width=100%;height=50px\a
Notes:
[
and ending the string with \a
File=
and the trailing :BASE64
section.1338
, not 1337
. A significant problem with this proposal is that it is less leet.name
is required and points to the file's location relative to buildkite's artifactswidth
and height
are optionally supportedinline
is no longer requiredWhile the iTerm2 syntax currently causes terminal to inline the image using src="data...
", this would merely refer to the file on disk using a prefix that could be specified at program startup.
Porting imgcat to use this would be quite simple. Porting the iTerm2 image handling code in terminal would also be simple.
Cursor Up [{COUNT}A
Moves the cursor up by COUNT rows; the default count is 1.
Cursor Down [{COUNT}B
Moves the cursor down by COUNT rows; the default count is 1.
Cursor Forward [{COUNT}C
Moves the cursor forward by COUNT columns; the default count is 1.
Cursor Backward [{COUNT}D
Moves the cursor backward by COUNT columns; the default count is 1.
The github.com/buildkite/terminal-to-html
uses Go modules and the current release version is v3
. And it’s module path is "github.com/buildkite/terminal-to-html"
, instead of "github.com/buildkite/terminal-to-html/v3"
. It must comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation. Quoting the specification:
A package that has opted in to modules must include the major version in the import path to import any v2+ modules
To preserve import compatibility, the go command requires that modules with major version v2 or later use a module path with that major version as the final element. For example, version v2.0.0 of example.com/m must instead use module path example.com/m/v2.
https://github.com/golang/go/wiki/Modules#releasing-modules-v2-or-higher
GO111MODULE=on, run go get
targeting any version >= v3.3.0 of the buildkite/terminal-to-html
:
$ go get github.com/buildkite/[email protected]
go: finding github.com/buildkite/terminal-to-html v3.3.0
go: finding github.com/buildkite/terminal-to-html v3.3.0
go get github.com/buildkite/[email protected]: github.com/buildkite/[email protected]: invalid version: module contains a go.mod file, so major version must be compatible: should be v0 or v1, not v3
run go get github.com/buildkite/terminal-to-html
, the version will stuck in v3.2.0:
$go get github.com/buildkite/terminal-to-html
go: downloading github.com/buildkite/terminal-to-html v1.0.2
go: downloading github.com/buildkite/terminal-to-html v3.2.0+incompatible
go: github.com/buildkite/terminal-to-html upgrade => v3.2.0+incompatible
SO anyone using Go modules will not be able to easily use any newer version of buildkite/terminal-to-html
.
This would push them back to not being managed by Go modules (instead of incorrectly using Go modules).
Ensure compatibility for downstream module-aware projects and module-unaware projects projects
I see these dependencies in your go.mod file, which need modle awareness. So you'd better not use third-party tools(such as: Dep, glide, govendor…).
github.com/buildkite/terminal-to-html/v3
You also need to update the import path to:
import github.com/buildkite/terminal-to-html/…
Patch the go.mod
file to declare the module path as github.com/buildkite/terminal-to-html/v3
as per the specs. And adjust all internal imports.
The downstream projects might be negatively affected in their building if they are module-unaware (Go versions older than 1.9.7 and 1.10.3; Or use third-party dependency management tools, such as: Dep, glide,govendor…).
If you don't want to break the above repos. This method can provides better backwards-compatibility.
Release a v2 or higher module through the major subdirectory strategy: Create a new v3 subdirectory
(github.com/buildkite/terminal-to-html/v3) and place a new go.mod file in that subdirectory. The module path
must end with /v3
. Copy or move the code into the v3 subdirectory. Update import statements
within the module to also use /v3
(import "github.com/buildkite/terminal-to-html/v3/…"). Tag the release with v3.x.y
.
If the standard rule of go modules conflicts with your development mode. Or not intended to be used as a library and does not make any guarantees about the API. So you can’t comply with the specification of "Releasing Modules for v2 or higher" available in the Modules documentation.
Regardless, since it's against one of the design choices of Go, it'll be a bit of a hack. Instead of go get github.com/buildkite/terminal-to-html@version-tag
, module users need to use this following way to get the buildkite/terminal-to-html
:
(1) Search for the tag
you want (in browser)
(2) Get the commit hash
for the tag
you want
(3) Run go get github.com/buildkite/terminal-to-html@commit-hash
(4) Edit the go.mod file to put a comment about which version you actually used
This will make it difficult for module users to get and upgrade buildkite/terminal-to-html
.
[*] You can see who will be affected here: [12 module users, e.g., kube-score/web, buildbarn/bb-browser, csweichel/werft]
https://github.com/search?q=buildkite%2Fterminal-to-html+filename%3Ago.mod
You can make a choice to fix DM issues by balancing your own development schedules/mode against the affects on the downstream projects.
For this issue, Solution 2
can maximize your benefits and with minimal impacts to your downstream projects the ecosystem.
To repro:
Set up a buildkite pipeline that runs
npm install chalk
node -e 'console.log(require("chalk").bold("Hello World"))'
The text should be bold, but isn't.
The escape sequence used is:
ESC
[
1
m
See https://en.wikipedia.org/wiki/ANSI_escape_code#SGR_parameters
1 Bold or increased intensity
Use case: For example, the text "Browser console:" here is supposed to be bold to make the logs easier to read
iTerm2, VS Code terminal support this.
Attached is a sample log output from a docker pull
command.
When you run cat sample.txt
you see this:
❯ cat /Users/keithpitt/Downloads/sample.txt
+ docker push 061442450191.dkr.ecr.eu-central-1.amazonaws.com/lol/thingy:9a5a7e9
The push refers to a repository [061442450191.dkr.ecr.eu-central-1.amazonaws.com/lol/thingy]
07e62ecb726a: Layer already exists
331743f747fb: Layer already exists
2543649889c9: Layer already exists
10f91d26a1a9: Layer already exists
4dd2f6cdfbcf: Layer already exists
d75290d8c3ab: Layer already exists
a4c405a1d61b: Layer already exists
d79093d63949: Layer already exists
87cbe568afdd: Layer already exists
787c930753b4: Layer already exists
9f17712cba0b: Layer already exists
223c0d04a137: Layer already exists
fe4c16cbf7a4: Layer already exists
9a5a7e9: digest: sha256:e0271b89d75b4bf43d89eda0de850770f8f0a026fc7d7e967124cbad3d41f5d3 size: 3052
When you run it through terminal, you get:
❯ cat sample.txt | godep go run cmd/terminal-to-html/*.go
223c0d04a137: Layer already exists
fe4c16cbf7a4: Layer already exists
9a5a7e9: digest: sha256:e0271b89d75b4bf43d89eda0de850770f8f0a026fc7d7e967124cbad3d41f5d3 size: 3052%
Something weird is going on, and I believe I've tracked it down to our up
handling. Specifically our A
instruction here:
Now during my testing, if I added this 1 line:
The problem went away. I don't think the adding of the character is fixing the issue, but when we append
a ton of other internal other stuff takes place:
I spent half a day on this on Friday, and got sucked into a wormhole. The hard thing is not knowing what the correct behaviour is in a shell. So I'll need to pair with someone this week (probably @sj26) and get it fixed up.
It looks like this tool used to be a Ruby library.
Where did the Ruby code go? And does it still work?
SInce we can include images, I suppose links should not be too difficult.
Proposed syntax:
printf '\033]1337;url='"$1"';content='"$2"'\a\n'
The use case would be to enrich test failure backtraces so that each line is a link to the file on GitHub.
This input:
out.txt
Should look like this:
(Terminal.app and iTerm 2 with standard ANSI colors)
So the "2 - 6" has no color and the little bolts don't blink.
So imgcat.sh
and the iTerm standard expect the filename to be base64 encoded:
http://iterm2.com/images.html#/section/home
$ ./utils/imgcat.sh fixtures/meme.png | less
ESC]1337;File=name=Zml4dHVyZXMvbWVtZS5wbmc=;size=55110;...
But it seems we expect it to be plain text:
$ ./utils/imgcat.sh fixtures/meme.png | terminal-to-html
*** Error parsing iTerm2 image escape sequence: can't determine content type for "Zml4dHVyZXMvbWVtZS5wbmc=&q
https://github.com/buildkite/terminal/blob/0f479d49667660a99390bfb7a601f50a4e36fe0f/image.go#L44
I believe all we need to do base64 decode the name field value before we set it.
We are using the Agent ansi-timestamps
experiment, which injects timestamps into the ANSI output using Application Program Commands. These should be rendered as invisible, much like control characters. It appears this isn't happening:
When rendered directly in iTerm2, we see the correct output (even with the ansi timestamps inline):
I suspect this will be affecting lots of different types of progress bars when ansi-timestamps is enabled.
I suspect this is because the handling of the APCs is appending an element to the virtual screen, which will then increase the X count, meaning it throws out any ANSI control characters that are clearing the progress bar part way through with backspace control chars (vs erasing the whole line).
Add a checksum for an archive of a binary
It is good to have it so when we download your binary, it would be possible to validate the checksum and make sure that this binary is what we download without any issues.
Would be nice to have it.
Erase End of Line [K
Erases from the current cursor position to the end of the current line.
Erase Start of Line [1K
Erases from the current cursor position to the start of the current line.
Erase Line [2K
Erases the entire current line.
Discovered while trying to work out why our build output was coming up as if we'd hit the 1mb log limit .. and then find that instead terminal is respecting the ANSI code to clear the screen and/or the scrollback buffer.
Given the context where terminal is used, I don't think it should do this. At the very least it should instead clear the current line -- or if there's a way wrangle it in buildkite, insert a banner of some sort.
I've looked at making the code in the build not do this, but in doing so I keep finding issues like this one (facebook/create-react-app#2495) where the project author is optimising for the console experience - but when viewing the BK log we generally want the whole thing.
(edit) In our case the code is outputting a 2J - clear screen without clearing scrollback - but the way it's represented in the BK build output is to make it look like the scrollback is gone as well.
The v3.3.0 release added a go.mod
and go.sum
but isn't properly versioned so it cannot be used with Go Modules.
Go has a good writeup about how you need to specially handle versions 2 and greater here:
Currently, the output renders like this:
some text <span class="c123">and this
this is colored</span>
The problem with this approach, is that if you wanted to wrap each line in a <div>
, we've just broken our markup.
<div>some text <span class="c123">and this</div>
<div>this is colored</span></div>
If we have colors that span multiple lines, we should include <span>
elements on each line, line so:
some text <span class="c123">and this</span>
<span class="c123">this is colored</span>
In the process of testing #68, I was unable to build the code in a Go 1.9 docker image. I was able to build after updating the Go image version to 1.12 in the Dockerfile and adding GO111MODULE=on
as an environment variable.
It may be worth noting that I was using podman instead of docker, however I don't think that would cause this issue.
It appears as though some of the colours aren't properly rendered, and clearing the background colour doesn't actually clear the background colour. As you can see from the expected screenshot (both using the same code), the background should end after P
but it continues, and the yellow text isn't being shown.
$ go install github.com/buildkite/terminal/cmd/terminal-to-html
can't load package: package github.com/buildkite/terminal/cmd/terminal-to-html: cannot find package "github.com/buildkite/terminal/cmd/terminal-to-html" in any of:
/usr/local/Cellar/go/1.7.5/libexec/src/github.com/buildkite/terminal/cmd/terminal-to-html (from $GOROOT)
/Users/ticky/go/src/github.com/buildkite/terminal/cmd/terminal-to-html (from $GOPATH)
Up until recently, the tarball https://github.com/buildkite/terminal/archive/v3.1.0.tar.gz had SHA-256 sum ba8e7566a7fe5c62089fa56191c80bf15b121ae369d0c17f6f80669d3bbbb23f
. All files contained were prefixed with terminal-3.1.0/
.
As of recently, the link above redirects to https://github.com/buildkite/terminal-to-html/archive/v3.1.0.tar.gz. The checksum is now 5d0203bb4dd007ad607df7d0eecbe50ff4bdaa0e56e1ad2ea1eb331ff2ae5be6
and the prefix of files contained within has also changed: terminal-to-html-3.1.0/
.
I'm not saying the repository should be renamed back; just wanted to give you guys a heads-up about this.
Ref: #29
So the link feature is awesome:
One little downside: I wish I could specify target="_blank"
because output pages are quite big and take a while to load, so it's a bummer when you forget to open the link in a new tab and that you have to load the output page again after.
@toolmantim @keithpitt @mipearson what do you think?
I tried to implement it myself, but my go is really not good :/
Our pipelines often produce video renderings of our simulations. It would be very useful if we could embed the videos in the log output, similar to how images are handled.
Add some kind of ability to see the rendered output with stylesheet and all.
It could be as simple as a --layout
flag which outputs the HTML container and CSS as well as the terminal output, so you can do:
mycommand | terminal --preview > /tmp/preview.html && open /tmp/preview.html
In all our Buildkite builds using sbt (the build tool for Scala projects), sbt prints this message many times during the process:
tput: No value for $TERM and no -T specified
Since I can't reproduce this any any other environment, this may be an issue with the tty used by Buildkite. Do you have any idea of what the problem might be and how can I fix it?
Similar to how buildkite/agent does it
failed MSpanList_Insert 0x535000 0x17258359846e 0x0
fatal error: MSpanList_Insert
runtime stack:
runtime.throw(0x4ac06b)
/usr/src/go/src/runtime/panic.go:491 +0xad fp=0x7ffeefbff1c0 sp=0x7ffeefbff190
runtime.MSpanList_Insert(0x4d2648, 0x535000)
/usr/src/go/src/runtime/mheap.c:692 +0x8f fp=0x7ffeefbff1e8 sp=0x7ffeefbff1c0
MHeap_FreeSpanLocked(0x4cf240, 0x535000, 0x100)
/usr/src/go/src/runtime/mheap.c:583 +0x163 fp=0x7ffeefbff228 sp=0x7ffeefbff1e8
MHeap_Grow(0x4cf240, 0x8, 0x0)
/usr/src/go/src/runtime/mheap.c:420 +0x1a8 fp=0x7ffeefbff268 sp=0x7ffeefbff228
MHeap_AllocSpanLocked(0x4cf240, 0x1, 0x0)
/usr/src/go/src/runtime/mheap.c:298 +0x365 fp=0x7ffeefbff2a8 sp=0x7ffeefbff268
mheap_alloc(0x4cf240, 0x1, 0x12, 0x0)
/usr/src/go/src/runtime/mheap.c:190 +0x121 fp=0x7ffeefbff2d0 sp=0x7ffeefbff2a8
runtime.MHeap_Alloc(0x4cf240, 0x1, 0x10000000012, 0xfb39)
/usr/src/go/src/runtime/mheap.c:240 +0x66 fp=0x7ffeefbff308 sp=0x7ffeefbff2d0
MCentral_Grow(0x4d6fb8, 0x0)
/usr/src/go/src/runtime/mcentral.c:197 +0x8b fp=0x7ffeefbff370 sp=0x7ffeefbff308
runtime.MCentral_CacheSpan(0x4d6fb8, 0x0)
/usr/src/go/src/runtime/mcentral.c:85 +0x167 fp=0x7ffeefbff3a8 sp=0x7ffeefbff370
runtime.MCache_Refill(0x531000, 0x12, 0x0)
/usr/src/go/src/runtime/mcache.c:90 +0xa0 fp=0x7ffeefbff3d0 sp=0x7ffeefbff3a8
runtime.mcacheRefill_m()
/usr/src/go/src/runtime/malloc.c:368 +0x57 fp=0x7ffeefbff3f0 sp=0x7ffeefbff3d0
runtime.onM(0x3c5130)
/usr/src/go/src/runtime/asm_amd64.s:273 +0x9a fp=0x7ffeefbff3f8 sp=0x7ffeefbff3f0
runtime.mallocgc(0x120, 0x31bb80, 0x0, 0x0)
/usr/src/go/src/runtime/malloc.go:178 +0x849 fp=0x7ffeefbff4a8 sp=0x7ffeefbff3f8
runtime.newobject(0x31bb80, 0x531000)
/usr/src/go/src/runtime/malloc.go:353 +0x49 fp=0x7ffeefbff4d0 sp=0x7ffeefbff4a8
runtime.newG(0x28faa)
/usr/src/go/src/runtime/proc.go:233 +0x2a fp=0x7ffeefbff4e8 sp=0x7ffeefbff4d0
allocg(0x4bfc20)
/usr/src/go/src/runtime/proc.c:925 +0x1f fp=0x7ffeefbff4f8 sp=0x7ffeefbff4e8
runtime.malg(0x8000, 0x4bfde0)
/usr/src/go/src/runtime/proc.c:2106 +0x1f fp=0x7ffeefbff528 sp=0x7ffeefbff4f8
runtime.mpreinit(0x4c0400)
/usr/src/go/src/runtime/os_darwin.c:137 +0x27 fp=0x7ffeefbff540 sp=0x7ffeefbff528
mcommoninit(0x4c0400)
/usr/src/go/src/runtime/proc.c:201 +0xc9 fp=0x7ffeefbff568 sp=0x7ffeefbff540
runtime.schedinit()
/usr/src/go/src/runtime/proc.c:138 +0x55 fp=0x7ffeefbff590 sp=0x7ffeefbff568
runtime.rt0_go(0x7ffeefbff5c8, 0x1, 0x7ffeefbff5c8, 0x0, 0x0, 0x1, 0x7ffeefbff7e0, 0x0, 0x7ffeefbff81b, 0x7ffeefbff84c, ...)
/usr/src/go/src/runtime/asm_amd64.s:95 +0x116 fp=0x7ffeefbff598 sp=0x7ffeefbff590
This issue appears to be fixed by some combination of Go 1.9 and building on High Sierra.
Erase Down [J
Erases the screen from the current line down to the bottom of the screen.
Erase Up [1J
Erases the screen from the current line up to the top of the screen.
Erase Screen [2J
Erases the screen with the background colour and moves the cursor to home.
We are using tput
to handle escape codes for us, for example:
has_tty() {
stty 2>/dev/null >/dev/null
}
ansi_header() {
if has_tty ; then
echo
echo >&2 -e "$(tput sgr 0 1)$(tput bold)$(tput setaf 4)--- $@$(tput sgr0)"
fi
}
ansi_success() {
if has_tty ; then
echo >&2 "$(tput setaf 2)$@ ✔$(tput sgr0)"
fi
}
ansi_failure() {
if has_tty ; then
echo >&2 "$(tput setaf 1)$@ ✗$(tput sgr0)"
fi
}
it seems that tput sgr0
outputs ESC[m
, rather than the `ESC[0m'. Apparently in absence of the 0 value, 0 should be assumed.
The result of this is that our ansi styles aren't correctly reset when converted to html.
I've added an example called "pikachu.ansi". Currently, it doesn't output the colors, not sure why yet. I think theres some color merging stuff in ANSI that I don't know about yet.
Ref: #29
So I tried to use the new links, but unfortunately my plan was to use it to improve our test failure backtraces with links to GitHub. Ultimately it would work, but I'm not willing to lose the backtrace colorization I put in place:
Not sure what the best syntax would be to chose the link color. Ideally I could use regular ANSI color code in it:
echo -e '\033]1339;url=https://google.com/;content=\033[33mHello World\033[0m\a'
But here's what it gives me right now
@keithpitt @toolmantim @mipearson do you guys think it makes sense or am I pushing it?
would love this available using
brew install terminal-to-html
would support updates to the compiled binaries for darwin using brew upgrade
along with all my other dev tools.
could do the same thing for windows using chocolatey
and linux using apt
https://github.com/buildkite/terminal-to-html/releases/tag/v3.2.0 seems to just be the git tag at the moment, not a changelog with attached binaries like https://github.com/buildkite/terminal-to-html/releases/tag/v3.1.0.
why? better googleability for one.
This tool writes a unified diff to stdout
https://github.com/bazelbuild/bazel-gazelle#fix-and-update
I wish I could colorize it like GitHub does in their markdown flavor so added/removed regions are green/red respectively.
In order to see proper colors for the first 16 colors in the 8-bit color range, I had to add the following to my css file (based on terminal.css):
.term-fgx0 { color: #000000; }
.term-fgx1 { color: #800000; }
.term-fgx2 { color: #008000; }
.term-fgx3 { color: #808000; }
.term-fgx4 { color: #000080; }
.term-fgx5 { color: #800080; }
.term-fgx6 { color: #008080; }
.term-fgx7 { color: #c0c0c0; }
.term-fgx8 { color: #808080; }
.term-fgx9 { color: #ff0000; }
.term-fgx10 { color: #00ff00; }
.term-fgx11 { color: #ffff00; }
.term-fgx12 { color: #0000ff; }
.term-fgx13 { color: #ff00ff; }
.term-fgx14 { color: #00ffff; }
.term-fgx15 { color: #ffffff; }
I got the color codes from the wikipedia page: https://en.wikipedia.org/wiki/ANSI_escape_code#8-bit
When I tried to install using go get:
$ go get github.com/buildkite/terminal-to-html/cmd/terminal-to-html
# github.com/buildkite/terminal-to-html/cmd/terminal-to-html
gopath/src/github.com/buildkite/terminal-to-html/cmd/terminal-to-html/terminal-to-html.go:92:17: cannot use cli.StringFlag literal (type cli.StringFlag) as type cli.Flag in array or slice literal:
cli.StringFlag does not implement cli.Flag (Apply method has pointer receiver)
gopath/src/github.com/buildkite/terminal-to-html/cmd/terminal-to-html/terminal-to-html.go:97:15: cannot use cli.BoolFlag literal (type cli.BoolFlag) as type cli.Flag in array or slice literal:
cli.BoolFlag does not implement cli.Flag (Apply method has pointer receiver)
gopath/src/github.com/buildkite/terminal-to-html/cmd/terminal-to-html/terminal-to-html.go:102:13: cannot use func literal (type func(*cli.Context)) as type cli.ActionFunc in assignment
$ go version
go version go1.10.4 linux/amd64
It'd be nice to include an example of the typical setup and development workflow
It's pretty bad. I can provide test cases for anyone interested.
--- FAIL: TestRendererAgainstCases (0.00s)
terminal_test.go:273: renders APC escapes as processing instructions
input "\x1b_bk;x=llamas\\;;y=alpacas\a"
received "<?bk y=\"alpacas\" x=\"llamas;\"?>"
expected "<?bk x=\"llamas;\" y=\"alpacas\"?>"
FAIL
This spec fails intermittently, presumably due to go not guaranteeing order of several of its types.
In the following line of code s.otherColors == s.otherColors
should read s.otherColors == o.otherColors
return s == o || (s.fgColor == o.fgColor && s.bgColor == o.bgColor && s.otherColors == s.otherColors)
/src/github.com/buildkite/terminal/style.go:16:72: identical expressions on the left and right side of the '==' operator
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.