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:
We keep iTerm2's backward escape starter of [ and ending the string with \a
We strip the starting File= and the trailing :BASE64 section.
We use 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 artifacts
width and height are optionally supported
inline is no longer required
While 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.
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
, not1337
. 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
andheight
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.