►
From YouTube: Touring a Jsonnet generated GitLab CI configuration
Description
Craig Furman provides an overview into how we utilize Jsonnet to generate a decently sized GitLab CI configuration.
This is primarily utilized: https://gitlab.com/gitlab-com/gl-infra/k8s-workloads/tanka-deployments
More about Jsonnet: https://jsonnet.org/
Other places where we utilize Jsonnet: https://gitlab.com/gitlab-com/runbooks
A
B
Hi
starbucks
craig
didn't
prepare
this
at
all,
so
be
prepared
for
a
bumpy
road
with
lots
of
ums
and
ours.
I'm
just
getting
all
my
stuff
ready.
So
I'll
share
my
screen
all
right.
Maybe
I
need
to
make
this
font
size,
bigger.
B
B
We
have
you
know,
test
environments
for
things,
staging
environments
and
soon
we'll
want
to
move
prometheus
in
here,
which
is
another
kind
of
cluster
local
thing
like
at
least
one
per
cluster
and
the
aims
of
this.
The
aims
of
this
repo
are
to
be
able
to
share
oh
yeah.
So
if
anyone
doesn't
know,
tanka
is
jsonnet
based
it's
actually
and
if
anyone
doesn't
know
what
json
is.
Jsonnet
is
a
simple
one
of
these.
Like
configuration
languages,
it's
a
full-fledged
programming
language,
but
quite
stripped
back
and
oriented
around
serializing
json
documents.
B
It
can
also
serialize
like
yaml
and
ini,
but
it's
essentially
a
programming
language
without
a
whole
lot
of
standard
libraries
for
things
that
you
might
expect
like
interacting
with
files
and
networks
and
all
that
and
it's
instead
just
oriented
oriented
around
functional,
transforms
of
data
structures
for.
B
B
B
Yeah,
absolutely
it's
it.
It
is
quite
simple,
but
the
documentation
is
sometimes
like
a
little
lacking.
On
the
other
hand,
I'm
sure
we'll
see
that
right.
So
what
are
our
objectives?
We
want
to
have
a
bunch
of
things
we
deploy.
So
tank
deployments
is
new
ish.
We
haven't
got
around
to
moving
tons
of
stuff
into
it.
It's
only
got
five
workloads
like
some
of
these
things
like
cisco,
patch,
evicted,
pod,
reaper
and
thanos.
B
Because
we
don't
want
to
reinvent
the
ci
deployment
wheel
and
use
things
like
gitlab
ci
includes,
which
can
be
a
bit
like
annoying
to
sync
up
between
lots
of
different
repositories,
and
we
want
the
opportunity
to
frictionlessly
share
jsonnet
libraries
between
these
various
unrelated,
like
or
semi-related
releases,
without
having
to
coordinate
like
json
bundler
version
bumping
things
like
that,
it's
just
kind
of
easier,
but
that
comes
with
a
a
price
tag
which
is,
if
you
want.
B
If
you
want
a
sort
of
minimal
clean
ci
pipeline
that
doesn't
run
like
hundreds
of
steps
for
your
various
projects,
then
then
you
have
to
work
at
it,
a
bit
like,
even
with
even
with
git
labs
like
nice
ci
system.
B
So
we
we
very
quickly
figured
out
that
using
gitlab
ci's
own
yaml
abstractions
was
maybe
gonna,
be
in
no
offense
to
the
verified,
maybe
going
to
be
like
a
bit
more,
a
bit
more
work
than
stepping
back
and
building
our
own
abstractions
to
serialize
the
gitlab
ci
yaml.
Instead,
and
because
this
project
was
already
json
it
heavy,
we
made
gitlab
ci
dot,
gitlabci.jsonnet.
B
Instead
and
before
diving
into,
can
you
see
the
terminal
by
the
way
on
my
other
window?
Have
I
been
sharing
the
right
thing?
This
whole
time.
B
A
B
B
Yeah
awesome:
I
was
checking
out
she
had
the
right
screens
the
concerto,
rather
than
dive
into
that.
Let's
first
look
at
how
we
want
the
pipeline
to
look
so
going
back
to
this
environments
directory
right,
we've
got
pieces
of
software
like
evicted,
pod,
reaper,
jaeger
van
ostern
house,
and
each
one
of
these
has
the
sort
of
pet
name
of
of
one
of
our
kubernetes
clusters.
So
gprod
is
google
production.
B
At
least
I
assume
the
g
stands
for
google
rather
than
gitlab
it
does
yeah
just
just
checking
that
maybe
it
stood
for
gitlab
the
whole
time-
and
I
I
forgot
about
that.
But
yeah
we've
got
g
stage
g
prod
pre,
which
is
a
kind
of
like
in
for
test
environment.
For
anyone
who
doesn't
know
dev
is
the
exception.
Dev
is
actually
just
a
you
know:
relatively
agnostic,
sort
of
mini
cubed
k3d
compatible
release.
B
That's
that
contributors
reaper
meant
to
try
to
use
for
iterating
on
something
local
before
before
pushing
to
a
shared
thing
like
pre
or
g
stage,
and
each
each
of
these
environment
directories
contains
what's
called
a
tanker
environment
which
is
effectively
a
description
of
some
like
one
or
more
evidence
resources
to
deploy
to
our
namespace
in
a
cluster.
B
When
master
is
merged.
We
want
to
produce
diffs
again
and
then
possibly
manually
gate
the
apply
step,
the
cube
cattle
apply
of
those
resources
we
actually
at
the
moment.
We
do
have
that
manual
gating
for
prod
environments,
so
gprod
and
our
ops
cluster,
which
is
the
kind
of
production,
operational,
observability
control,
plane,
kubernetes,
environment,
where
we
run
things
like
san
os
query.
B
But
we
we
just
auto,
deploy
staging
and
free
and
all
the
non-prod
environments
without
without
any
gating,
because
you
know
how.
B
That's
I
realize
that
this
is
already
in
in
the
helm
repos,
but
we
we
didn't
have
that
in
tanker
we
were
clicking
buttons
in
pre,
so
you
know
we
didn't.
We
want
to
do
that
anymore,
so
we
removed
the
gate
yeah.
There
is
some
other
nuance
to
tanker
called
pruning
which
is
like
apply,
but
for
deletion,
which
is
these
days
in
line
with
apply.
So
we
can
think
of
this.
B
As
we've
got
a
bunch
of
directories
structured
like
this
software
named
and
environment
names
and
when
they're
diffed
by
a
commit,
we
want
to
dif
only
those
environments
and
for
master
commits.
We
want
to
apply
only
those
environments
so
that
produces
pipelines
that
look
like.
B
This,
let
me
try
and
find
something.
B
All
right,
that's
a
bad
example.
Actually
we
can
maybe
come
back
to
that
as
a
later
example,
because
this
is
this
is
another
use
case
for
dynamic
pipelines.
B
I'm
looking
for
a
non-master
pipeline,
so
when
I
mentioned
about
changes,
we'll
come
back
to
this,
but
often
often
for
the
diff
stages.
Very
many
jobs
are
run.
All
of
the
jobs
are
run
because
of
a
gitlab
ci
documented
quirk
in
which
new
branches
don't
have
change
rules
applied
to
them.
They
end
up
triggering
truth.
Like
every
change
is
rule
this.
This
is
actually
something
I
have
an
open
issue
for.
The
verify
team
are
considering
fixing,
I
think,
which
is
good.
B
B
Yeah,
we're
not
gonna
be
able
to
see
the
effect
of
nice
changes
rules,
but
we
can
see,
for
example,
a
master
pipeline
here
in
which
we
have
various
kind
of
generic
steps.
We
have
one
diff
step
per
environment
in
this
case.
It's
running
them
all.
You
have
to
take
my
word
for
it.
Sometimes
when
we
get
really
lucky,
we
do
especially
master
pipelines,
do
see
only
some
of
these
running,
but
this
is
all
of
them
in
this
case.
So.
A
B
B
We'll
get
we'll
get
like
more
detail
exactly
what
triggers
what
we
dig
into
the
file
and
then
because
this
is
a
master
pipeline.
We
have
the
apply
phase.
B
We
want
manual
gating
for
some
environments
like
gprod
and
ops,
but
not
all.
We
want
jobs
to
run
as
independently
as
possible.
So,
for
example,
we
want
the
jaeger
g
stage
apply
to
run
when
the
jaeg
jaeger
g
stage
diff
finishes
without
waiting
for
everything
else
in
the
diff
stage.
Using
gitlab's
directed
acyclic
graph
feature
needs
keyword
and
that's
really
all
we
need
to
see
about
our
like
main
kind
of
pipeline.
B
So,
starting
from
the
bottom
right,
we
call
json
it's
manifest.
Yamldoc
function
with
a
gitlab,
ci
conf
object,
so
this
gitlab
ci
conf
is
some
like.
You
know:
json
object
that
has
all
the
various
structures
that
make
up
a
gitlab
ci.
It's
got
a
stages
section.
B
Unfortunately,
jsonic
manifest
yaml
doesn't
include
any
options
for
like
pretty
printing
like
removing
quotes
where
it
can
more
white
space.
Things
like
that
indentation.
So
it's
kind
of
a
very,
very
verbose
like
standard
demo,
but
yeah.
We
don't
really
look
at
the
yammer
very
much
exactly
yeah.
We
even
pre-pen
this
string
at
the
top
do
not
hand
edit
this
explanation
here.
B
We
have
a
workflow
section
this
I
might
be
able
to
remove
this.
This
works
around
a
this
works
around
a
bug
in
github
ci,
in
which,
when
a
pipeline
configuration
reaches
a
certain
complexity
threshold,
mr
pipelines
and
commit
pipelines,
start
being
kind
of
arbitrarily
double
triggered,
and
you
can
use
the
workflow
rules
to
pin
one
or
the
other,
but
I
think
this
might
have
actually
been
fixed
recently,
so
I
might
try
removing
this
then
going
back
down.
We've
got
some
jobs.
B
You
know,
like
you,
know,
formatting
checking
with
the
generated
codes
up
to
date.
That
kind
of
thing
that's
not
particularly
interesting.
These
jobs
are
just
fairly
vanilla.
You
know
whatever
yeah,
then
we've
got
these
interesting
parts
here,
we've
got
these
tanker
jobs
functions
being
called
passing
in
various
things
like
like
thanos
g-stage.
You
know
jaeger-pree
some
of
these
that
have
extra
params.
B
B
Let's
jump
to
thanos
g-stage
diff
in
the
yaml.
First,
apologies
for
the
constant
jumping.
So
what
do
we
want
to
do
right?
We
want
to
run
some
image
that
contains
tanka.
We
want
to
I'll
come
back
up
to
rules.
You
want
to
run
some
scripts.
You
know
like
log
into
the
cuban
environment,
vendor
stuff,
blah
blah
blah
run
a
diff.
B
B
B
B
Environment
stan
oscar
stage
and
like
not
have
it
as
an
m4
because
we're
generating
this
config
anyway.
But
you
know
whatever.
A
B
B
We
want
to
only
run
this
job
when
one
of
these
things
has
changed
like
at
least
one
of
these
things
has
changed.
So
this
isn't
all
environment
standard
g
stage
star.
So
if
we
actually
change
this
environment
and
then
we've
got
a
bunch
of
like
pessimistic
constraints,
we
want
to
err
on
the
side
of
running
jobs.
So
if
we
change
the
vendored
json
dependencies,
the
tanker
uses
that
we
can't
necessarily
tell
which
environment
it's
really
targeting.
B
If
we
change
the
ci
config
run
every
job
and
if
we
change
any
of
our
shared
like
common
libraries
under
live,
because
we
unfortunately
don't
have
a
mechanism
for
for,
like
reverse
bubbling
like
oh,
we
changed
this
part
of
live
and
that's
used
here
here
and
here
we
only
need
to
run
these
jobs.
That's
way
too
complicated.
We'd
rather
spend
the
money
on
on
running
for
jobs.
So
we
are
on
the
side
of
running
jobs,
so
commits
the
change.
Some
core
stuff
will
end
up
diffing
everything.
B
B
We
push
commits
to
gitlab.com,
but
because,
uniquely
unlike
other
customers
of
gitlab.com
us
on
the
gitlab
infra
team
are
like
operating
crucial
components
of
gitlab.com,
so
we
tend
to
operate
that
from
another
gitlab
server,
a
private
one,
ops.getlab.net
lots
of
people
watching
this
video
will
know
that
we
push
mirror
to
ops.gitlab.net
and
on
there.
B
Crucially,
I'm
going
to
try
and
not
leak
secrets,
which
I
think
is
possible
because
I
think
I
shouldn't
leak
them,
because
this
should
be
started
out.
Yep
good
here,
we've
got,
I'm
not
going
to
click,
reveal
values,
we've
got
tank
deployments
run
and
I'll.
Tell
you
a
secret.
It's
set
to
one
right
there
and
we
don't.
We.
A
Don't
surprise,
I'm
surprised
that
you
don't
use
the
there's
a
referenced
ci
variable
that
lets
you
know,
which
instance
you're
on
I'm
surprised
you
don't
just
leverage
that
as
a
mechanism.
A
Url
you
mean
ye,
I
think
that's
right
like
there's
like
an
instance,
url
that
says:
hey,
I'm
ops.gitlab.net
or
I'm
gitlab.com.
B
Yeah,
it's.
I
think
we
do
that
in
the
helm,
repos
yeah.
That
would
also
work
just
fine.
I
mean
realistically
we're
very
unlikely
to
change
our
server
urls.
B
B
So
if
you're,
if
you're
watching
this
on
the
internet
going
to
attack,
gitlab
you've
got
to
attack
the
op
server,
not
the
dot,
com,
server
and
yeah-
that's
that's
the
gist
of
it
so
because
of
the
complex
rules
stanza
because
of
the
need
to
control.
B
Like
you
know,
I
know
I've
replaced
tanker
end
with
this,
but
because
of
the
need
to
kind
of
template
a
little
bit
of
stuff,
we
very
quickly
realized
that
doing
that
with
the
amp
with
the
abstractions
provided
in
the
gitlab
ci
yaml
was
maybe
not
going
to
be
quite
as
nice
as
just
simply
serializing
this.
B
So
tanker
jobs
is
a
you
know:
meaty
ashjasonic
function,
that's
starting
at
the
bottom.
Looking
at
what
it
returns,
it
returns
an
object
with
these
jobs,
so
software
here
would
be
like
thanos
cluster
would
be
g-stage,
for
example,
put
the
stage
in
you
put
your
oh.
B
B
And
this
is
this
is
another
reason
actually
by
the
way
that
pushed
pushed
me
towards
gitlabci.json
instead
of
using
like
yamalanka's
and
yaml,
includes
because
rules
is
an
array,
unlike
the
old
only
except
syntax.
There
wasn't
really
a
nice
way
to
try
this
out
somewhat
and
we
would
have
had
I
mean
there's
about
a
thousand
lines
in
here
right.
We
would
have
had
many
hundreds
of
lines
of
repetition
trying
to
duplicate
the
rules
like
like
this
one
and
things
like
that.
So
it's
a
bit
drier
here.
B
B
Yeah
we
could,
even
here
you
can
see
we're
using
a
json,
it
extension
so
we're
mixing
in
to
this
base
job.
We
we,
you
know
this
is
maybe
a
bit
overboard,
but
like
json,
it
makes
it
really
easy.
So,
rather
than
even
duplicate
things
like
image
tags
and
variables,
we
just
extracted
that
out
into
an
object
and
reference
it
from
both
the
diff
and
the
apply
job
down
here.
A
B
And
that's
really
about
it,
because
now
now
we've
actually
covered
this
whole
file.
Like
it's,
it's
a
meaty-ish.
It's
like
305
lines
of
json.
There
are
no
imports,
though
so
there's
all
the
context
is
here
yeah
and
it's
so
far
generated
about
a
thousand
lines
of
ci
yaml
and
we
are
nowhere
near
done,
but
just
repo
we're
gonna
bring
in
a
lot
more
stuff,
so
we're
gonna
balloon.
This
config
out
potentially
maybe
hit
some
api
maximum.
A
B
A
B
You
we'll
look
at
the
make
file
so
make
generate.
Ci
config
runs
json
dash,
dash
string,
dot,
gitlab
ci
json,
redirecting
to
gitlab
ci
yaml.
A
B
And
we
have
a
ci
step
that
checks
that
that
the
generated
code
matches
the
final
result.
Now,
of
course,
you
know
you're
contributing
to
the
ci
config.
You
can
just
remove
this
chart
right,
but
so
it
should
work
most
of
the
time
the
string,
so
json
is
pretty
simple.
The
only
reason
for
this
is
to
say
that
I'm
not
json,
it
usually
generates
json.
A
A
Documentation
is
maybe
not
the
greatest,
so
if
we
haven't.
B
I
would
start
with
the
jsonnic
tutorial
on
json.org
this.
This
kind
of
has
everything
in
it.
It's
done
by
example,
which
is
nice,
there's
really
not
a
huge
amount
to
jace
on
it.
It's
you
know
it's
a
smallish
programming,
language,
similar
to
q
or
daal.
If
you've
seen
those
that
they're
called
kind
of
configuration
languages
these
days,
a
niche
for
a
niche
for
people
who
intentionally
perhaps
don't
want
all
of
the
bells
and
whistles
of
a
general
purpose.
B
Programming
language,
like
you,
know,
python
good
for
this
kind
of
thing,
so
I
read
the
tutorials:
it's
not
super
long,
and
then
you've
got
the
jsonnet
standard
library,
the
only
and
then
beyond
that,
like
once
you
practice
with
that
a
bit
and
looked
at
our
existing
json
it,
which
we
use
based
on
it
in
a
few
places
in
gitlab
infra,
we
use
it
in
tanker
deployments.
We
use
it
quite
liberally
in
the
run
books
repository,
which
is
actually
a
mono
repo
for
way
more
than
just
run
books.
B
We
use
it
as
the
basis
of
our
metrics
catalog,
which
generates
prometheus
configuration
and
dashboards
for
our
various
services
yeah.
Beyond
that,
it's
really
just
the
context
you're
running
json
in
like
if
you're
running
tanker,
which
this
video
has
like
broadly
not
been
about
like
you've,
seen
me
just
calling
out
to
json
it
here.
If
you're
using
tanker,
then
technically
you're
you're,
not
like
shelling
out
to
a
json
executable.
Your
your
json
is
consumed
by
an
in
in
process
json
interpreter
inside
the
tank
executable,
but
that's
usually
a
fairly
minimal
consideration.
A
Gotcha
well
excellent.
I
don't
have
any
further
questions.
Do
you
have
anything
else
that
you
want
to
quickly
gloss
over.
B
No,
I
think
that's
about
it
from
my
part.
I
have
a
meeting
to
run
off
to
in
two
minutes
perfect,
so
I
think
you.