►
From YouTube: AMA with Jason - Principles of .gitlab-ci.yml Syntax
Description
AMA with Jason Yavorska, GitLab Director of Product, CI/CD
https://docs.google.com/document/d/1t0Gc_r76_xCXotYu1cm9LBFs54XXy8oX9_C_uteK4jA/edit#
A
Hey
everyone,
my
name
is
kenny
johnston.
I
am
here
with
jason
yovorska
our
director
of
product
covering
ci
cd
jason's
last
week
at
gitlab
is
this
week
and
I
was
trying
to
think
of
topics
that
I
would
really
love
to
pick
jason's
brain
about,
and
the
one
that
I
came
up
with.
That's
we're
going
to
just
discuss
today
is
principles
of
gitlab
ci
yaml
syntax,
I
guess
is
the
best
word
and
jason.
You
can
kind
of
help
me
with
the
language
to
make
sure
I'm
on
point.
A
But
I
kind
of
wanted
to
ask
you
more
questions
and,
in
my
mind,
if
this
results
in
a
great
discussion
that
then
I
can
take
or
others
can
take
to
document,
here's
kind
of
like
the
principles
upon
which
we
continue
to
iterate
on
our
cie
email
definition.
That
would
be
the
best
outcome.
So
anyone
else
on
this
call,
I
I
seated
with
a
bunch
of
questions
that
I
just
had
about
this
topic
for
jason,
but
feel
free
to
jump
in
and
add
your
own.
A
B
B
That's
used
for
that,
but
there
are
others,
and
then
you
add
your
own
keywords
and
data
structures,
and
things
like
that
and
interface
points
between
your
application,
and
so
we
specifically
don't
have
a
dsl,
because
one
of
the
I
guess,
important
principles
that
we've
kept
with
with
our
configuration
is
that
it
isn't
so
complex
as
if
you
were
to
implement
it
as
a
programming
language.
If
you
were
going
to
go
down
that
road,
I
think
it
would
just
be
better
to
implement
it
in
a
real
full
programming
language.
B
A
B
We
also
have
a
feature
called
dynamic
child
pipelines
and
well
just
dynamic
pipelines
in
general,
where
you
can
run
a
typically
a
yaml
templating
language
and
generate
the
yaml
config
at
runtime,
so
that
sort
of
gives
you
at
least
in
theory,
the
benefit
of
having
still
a
simple.
You
know
configuration
language
that
doesn't
have
loops
and
and
logic
built
into
it,
but
are
also
able
to
admit
it
when
you
need
to
do
something.
Custom.
A
B
Yeah,
it's
very
very
rare,
rare
enough
that
I
can't
even
think
of
of
one
that
we've
done,
but
I'm
sure
we've
you
know
gotten
rid
of
something
or
other.
The
problem
is,
is
that
people
write
pipelines
and
then
expect
them
to
just
kind
of
run
without
having
to
maintain
them
and
whenever
we
deprecate
something
we
create
a
administrative
kind
of
like
operational
cost
for
everybody,
who's
updated
a
pipeline
and
a
lot
of
times.
B
So
when
you
delete
things
like
that,
you
typically
need
to
provide
some
kind
of
auto,
auto
on-ramp
or
auto
translation.
So
what
we're
more
likely
to
do
is
to
discourage
a
particular
keyword,
potentially
implement
it
on
the
back
end,
so
that
we
introduce
a
new
keyword
and
if
you
use
the
old
keyword,
you
actually
go
through
the
new
code
path
because
we
sort
of
like
translate
it
on
the
back
end,
and
so
in
that
way
we
can
deprecate
things
but
yeah.
It's
really
hard
to
ever
actually
just
say
like
yeah.
B
C
Yeah,
my
follow-up
is,
if
you
have
decided,
if
maybe
you
have
decided
to
make
a
change,
is
there
any
way
to
automate
the
process
for
users,
maybe
that
that
you
can,
with
the
click
of
a
button
during
the
during
the
gitlab
update
you
can
let
administrators
run
a
process
where,
where
you
kind
of
update
all
the
pipelines
that
are
in
your
instance
or
yeah,
or
do
that
for
something
like
gitlab.com?
Is
there
something
like
this.
B
We
could
we
could
build
something
like
that
for
sure.
We've
never
done
it
in
the
past,
there's
some
complexities
there
and
that
well.
We've
got
gitlab.com,
of
course,
where
the
scale
is
just
huge
and
if
you
imagine
kind
of
going
through
a
situation
where
we
told
everybody,
hey
we're
gonna
update
all
of
your
pipelines
and
it
should
work.
But
but
we
can't
guarantee
it
it
would
it
wouldn't
it
wouldn't
really
go
everywhere
and
even
on
an
instance
just
giving
somebody
a
migration
script
that
says
here.
B
This
is
just
gonna
run
and
it
will
auto
translate
and
then
most
of
them
will
work
or
even
all
of
them
will
work.
Hopefully
it's
just
kind
of
like
a
logistically
complicated
thing
to
execute,
but
it
is
possible-
and
you
can
imagine
you
know
if
we
ever
did
a
v2
syntax
or
something
like
that
where
we
just
kind
of
needed
to.
B
We
reached
a
point
where
we
needed
to
say:
okay,
there's
a
fundamental
change
within
the
syntax
that
we
need
to
make
we're
going
to
break
things
in
into
two
portions
and
maybe
we'll
continue
to
support
the
legacy
ones
and
we'll
support
the
new
ones.
Then
we
might
make
some
kind
of
you
know
automatic
migration
script
for
for
pipelines
that
can
just
translate
from
one
to
the
other,
but
for
small
things.
B
Typically,
it's
better
to
do
what
I
mentioned,
where
you
just
kind
of
like
handle
it
on
the
back
end
for
them
as
best
you
can
or
if
that's
not
possible,
then
just
discourage
it
document
it
so
that
people
know
yeah.
You
read
this.
This
still
works,
but
you
shouldn't
do
it
because
you
know
for
these
reasons
and
here's
what
you
should
use
instead
and
how
to
use
it.
A
Cool,
thank
you.
I
didn't
have
any
other
questions
about
deprecation.
Anybody
else
have
any
before
I
move
on
to
the
next
one.
Okay,
so
I'm
gonna
adjust
my
language
really.
I
think
the
line
is.
How
would
you
evaluate
whether
the
syntax
is
getting
too
complex
where
it's
nearing
a
dsl,
and
you
mentioned
you
just
mentioned
like
maybe
in
some
future
we
would
reach
the
point
where
we
needed
a
v2.
I
would
imagine
some
of
that
would
be
simplification.
B
We
could
be
running
into
problems
on
being
able
to
deliver
new
features
and
that
it
just
becomes
so
difficult
to
deliver
new
features
related
to
the
gitlab
ci
ammo,
because
we're
maintaining
all
of
this
stuff
and
interconnected
and
it's
to
it
becomes
too
complex
for
us
to
use
and
interact
with
the
other
path
is
where
it
becomes
too
complex
for
customers
to
interact
with
the
gitlab
ciemo.
Syntax
page
is
already
quite
long.
B
It
is
a
reference
page,
so
it's
meant
to
be
a
little
bit
long,
but
there
will
come
a
point
where
there's
just
so
many
different
things
that
you
can
do
to
start
that,
maybe
we
would
say:
okay,
there's
going
to
be
a
v2
syntax,
that's
oriented
around
making
things
simpler
to
start
and-
and
that
may
become
a
moment.
But
again
it's
a
it's
a
you
want
to
try
to
avoid
that
as
best
you
can,
and
so
all
the
conversations
should
be
around.
How
can
we
not
have
to
do
this?
B
How
can
we
make
it
so
that
it's
you
know
easier
to
use
the
syntax
we
have?
How
can
we
document
it
better?
How
can
we
guide
people,
because
at
that
point
you
split
the
the
user
base
into
two
halves
potentially
and
you're
gonna
be
maintaining
both
for
a
while
you're
going
to
be
documenting
both
it's
just
it's
going
to
be
a
pain
and
it
will
be
hard
to
ever
shut
off
the
old
one,
for
the
same
reason
that
I
said
that
it's
difficult
to
ever
deprecate
anything
permanently.
B
Because
would
we
ever
get
to
a
point
where
we
said
well
we're
going
to
turn
off
anybody
who
was
using
git
lab
ci
before
2002
or
sorry
2020,
maybe,
but
would
have
to
be
really
really
important
and
really
game
changing
and-
and
I
don't
know
what
that
might
be
yet
so
in
the
meantime,
it's
better
to
just
kind
of
manage
the
complexity,
avoid
avoid
adding
complexity
as
much
as
possible,
avoid
adding
new
keywords
as
much
as
possible.
Try
to
build
new
features
on
top
of
existing
keywords.
B
But
yeah
I
mean
arguably
it's
potentially
already
too
complex
and
and
that's
what
some
of
the
team
is
working
on
on
the
pipeline
authoring
side
in
order
to
reduce
that
complexity
and
figure
out
how
we
can
make
it
simpler
to
get
started
and
then
maybe,
once
that
work
is
done.
Maybe
once
we've
got
like
the
next
six
months
of
that
thinking
and
features,
then
we'll
have
a
better
idea
of
what
we
were
able
to
do.
What
we
weren't
able
to
do
and
whether
you
know
something
bigger,
is
going
to
be
needed.
A
Yeah
any
sorry,
I
already
have
that
follow-up,
but
I
just
want
to
ask
one
related
to
that
pipeline
authoring
statement.
Would
you
exp
you
talked
about?
There
were
kind
of
like
two
possible
sensing
mechanisms
that
would
tell
us
it's
getting
too
complex.
The
first
one
would
be:
is
our
own
engineering
effort
so
painful
in
order
to
add
new
capabilities
and
the
second
one
is:
are
users
experiencing
pain?
A
B
Think
so
yeah,
so
within
ci
we
have
kind
of
that
two
halves
of
the
user
split
and
the
the
people
who
interact
with
running
pipelines
and
need
to
see
if
they're,
successful
and
troubleshoot
them.
If
not,
and
I
think
that
the
complexity
there
can
be
maintained
and
we
can
just
make
that
better
and
better
and
better-
and
we
won't
reach
a
point
where
it's
like
well,
it
needs
to
do
so
many
complicated
things
that
that
we
don't
know
how
to
manage
the
complexity
anymore.
B
I
think
that
that
will
always
be
sort
of
maintainable
for
various
reasons.
It's
it's
just
kind
of
like
a
simpler
flow,
whereas
when
you're
authoring
the
pipelines,
there's
so
much
possibility
of
what
you
might
how
you
might
approach
solving
the
problem,
it's
really
closer
to
a
programming
language
than
than
you
know,
interacting
with
a
running
system
kind
of
so
I
do
suspect
to
answer
your
question
that
we
would
be
hearing
from
users,
but
maybe
particularly
like
in
new
user
adoption,
that
you
know
this
is
too
complicated
to
get
started.
B
I
have
no
idea
what
I'm
doing.
Maybe
demand
for
professional
services
would
go
up
and
say
like
look.
We
can't
figure
out
how
to
you
set
up
pipelines
with
gitlab
like
please
give
us
some
expert
who
can
get
this
started
for
us.
We're
definitely
not
all
the
way.
To
that
point.
Some
companies
might
like
that.
Just
because
it's
nice
to
have
an
expert
and
you
can
have
confidence
but
nobody's
like
we
looked
at
this.
We
cannot
figure
it
out
yet,
but
that
could
come
hopefully
not.
B
Maybe
it's
discarding
it
and
trying
to
do
the
right
thing,
so
that
would
be
a
slightly
different
migration
path,
another
one
where
it's
just
a
new
syntax
that
we've
invented.
Maybe
it's
compatible
enough
that
we
can
write
a
migration
script
like
miguel
was
touching
on
where
we
can
try
and
translate
between
the
two
and
even
automatically
do
it.
So
it'll
really
depend
on
what
the
what
the
v2
is
and
what
was
the
other
part
to
your
question.
D
E
B
I
think
it's
related
to
defining
the
relationships
between
things
so
related.
It's
related
to
the
dag.
The
dag
was
a
part
of
trying
to
solve
this
problem
of
what
are
the
dependencies
between
different
jobs
and
how
do
they
relate
to
each
other.
Rules
was
the
other
portion
of
this
that
says,
like
you
know,
based
on
you,
can
imagine
these
very
complex
web
webs
of
dependencies
where
this
job
should
only
run.
If
this
other
job
existed
and
also,
if
this
other
one
passed,
then
it
shouldn't
run.
B
But
if
the
other
one
failed,
then
it
should,
and
it
depends
on
it-
needs
the
artifacts
from
like
these
other
three
jobs
that
are
actually
in
a
whole.
Other.
You
know,
branch
of
the
the
build
process
and
defining
that
those
relationships
in
a
very
simple
way
is
really
really
hard.
The
tag
is
good
and
it's
better
than
what
we
had
before.
B
To
start
with,
we
only
had
the
stages,
and
you
would
just
try
and
put
everything
in
the
next
stage,
but
they
would
sort
of
end
up
in
a
situation
where
you
were
making
many
many
stages
and
kind
of
doing
it
all
by
hand
and
then
moving
things
by
hand
in
order
to
like
optimize
the
timing
and
things
like
that,
and
it
was
really
annoying.
So
we
made
the
tag
which
lets
you
just
say.
This
depends
on.
This
depends
on.
B
This
depends
on
this
and
just
build
out
the
tree
structure
essentially,
but
then
that
tree
structure
you're
sort
of
doing
it
in
text
so
you're
not
really
able
to
visualize
it
as
you're
doing
it.
The
pipeline
authoring
team
is
working
on
visualization
aspects
in
order
to
to
make
that
easier,
and
then
how
that
interacts,
with
rules
to
say
when
the
job
should
run
under
what
scenarios,
depending
on
where
it
is
in
the
tree.
I
think
that's
where
the
biggest
complexity
is
for
pipelines.
B
At
the
moment,
everything
else,
and
even
that
like
for
the
basic
use
cases,
is
easy,
but
we
have
some
customers
who
are
doing
things
like
they've
got
a
thousand
dependencies
all
related
to
each
other
in
these
complex
ways
and
when
you're
managing
that
it
it
isn't
easy,
you
can
do
it,
but
it's
yeah.
Some
poor
person
has
to
maintain
all
of
that
and
have
it
all
in
their
head
and
it's
not
easy.
B
Idea,
actually
I
like
that,
there's
a
few
people
who
jump
to
mind
I'll,
probably
forget
somebody
and
I'll
feel
really
bad
about
it
in
an
hour
when
I
remember
with
them,
but
camille
obviously,
is
probably
the
number
one
expert
for
the
gitlab
ciamo
syntax.
He
built
the
runner
he
built
ci
like
he
was
here
at
the
very
beginning
and
has
seen
it
all
develop.
B
We've
also
got
experts
in
different
sub
areas
like
for
rules
for
khan.
Is
the
engineer
who's
the
who's?
Really
just
an
expert
in
that
he
really
understands
it.
Deeply
fabio
is
the
is
the
lead
engineer
and,
and
also
knows
it
really
really
well
now,
and
then
we
also
got
some
like
heavy
users
at
the
company
who
know
it
steve
on
the
runner
team
is
somebody
that
I
go
to
for
advice,
jay
gorsh.
B
Also
on
the
I
don't
know,
if
he's
on
the
ci
or
the
pipeline
authoring
team,
these
days
are
maybe
floating
but
he's.
Also,
an
expert
josh
in
product
is:
does
a
lot
of
authoring
of
gitlab
ci
animals
and
and
knows
how
stuff
works.
Also,
anybody
who's
maintaining,
of
course,
the
get
lab
gitlab
ciamels
for
building
gitlab
and
for
www
and
for
the
the
core
product
as
well.
B
B
B
Yeah,
it's
it's
detectable
already
today
and
we
measure
depth
so
and
we
limit
depth
so
fast,
recursion
like
where
you've
just
got
like
one
job.
That
starts
another
job
and
just
kind
of
loops
that
will
be
detected
and
it
will
stop.
If
you
have
something
that's
like
really
slow
where
it
like,
runs
for
six
hours
and
then
starts
itself,
it
may
run
for
quite
a
quite
some
time.
I'm
actually
not
100
sure
how
we're
detecting
and
stopping
that.
F
I
definitely
did
it
recently
testing
something
locally,
but
I
don't
know
if
it's
cheap,
like
by
recently
I
mean
like
a
month
ago.
So
I
don't
know
if
more
stuff
has
rolled
out,
but
this
was
like
through
multi-pipeline
projects,
so
I
posted
about
it.
So
people
know
if
it's
still
getting
worked
on.
I
don't
totally
know
where
it
is,
but
yeah
if
you're
sneaky,
you
can
do
it.
B
Yeah
there's
an
api
endpoint.
That
starts
a
pipeline,
which
is
the
multi-project
pipeline
endpoint,
and
you
could
just
call
that
at
the
end
of
your
job
and
it
would
just
whenever
your
job
finishes.
It
would
just
start
another
copy
yeah.
I
don't
know
how
you
would
accidentally
do
that,
but
that
is
probably
possible.
A
A
I'm
wondering
how
you
think
about
if
you
were
to
look
at
a
new
feature
that
would
that
implies
the
need
for
some
new
syntax
or
some
new
keyword,
how
you
would
think
about
well,
actually,
this
this
could
actually
this
could
fit
in
an
existing
keyword.
We
might
just
extend
it
in
some
way,
yeah.
How
would
you
walk
through
that
process?.
B
B
But
what
we
ended
up
doing
was
adding
on
to
the
parallel
keyboard,
which
we
already
had,
and
parallel
was
just
a
a
keyword
that
would
run
you
know,
10
copies
of.
If
you
wanted
of
the
same
job,
it
would,
and
you
would
typically
use
it
if
you've
got
like
a
test
job,
and
you
would
tell
it
you
know,
each
of
these
jobs
should
do
one
tenth
of
the
total
test
suite.
B
So,
instead
of
introducing
a
new
keyword
which
it
would
add,
complexity,
we
said
okay.
Well,
what?
If
we
like?
Look
at
that
as
a
you
know,
a
one-dimensional
matrix,
so
it's
just
kind
of
like
a
matrix
of
one
job
is
what
we've
set
up
there
and
if
we
modify
the
syntax
to
allow
for
taking
additional
kind
of
dimensions
on
the
on
on
the
matrix.
So
that's
what
we
did
I'm!
This
is
kind
of
a
hard
one
to
speak
abstractly
about,
hopefully
it's
coming
across
clearly
yeah,
but
anyway,
yeah
go
ahead.
I
wonder.
A
If
part
of
it
is
tied
with
miguel's
point
that,
like
consult
with
existing
cia
experts,
I'm
like
we're
losing
a
lot
of
expertise
in
you,
any
new
pm
or
team
member
who
would
come
across
something
it's
not
going
to
look
exactly
like
that,
but
something
similar
I'm
trying
to
think
of
how
to
guide
them
to
make
sure
we're
considering.
First,
maybe
it's
just
before
you
consider
adding
any
new
keyword.
B
Yeah,
the
other
thing
is
that
these
tend
to
be
popular
issues
when,
whenever
it's
introducing
something
totally
new,
it
tends
to
be
an
issue.
That's
become
very
popular
if
we're
looking
at
it.
Otherwise
we'd
be
doing
incremental
things
in
the
meantime,
so
there
tends
to
be
a
lot
of
really
really
smart
customers
in
in
those.
So
how
we
came
for
that
parallel
keyword
was
just
collaboration
in
the
issue.
B
B
B
That
would
work,
but,
like
I
don't
know
it
just
seems
like
there
must
be
some
better
way
to
do
that
and
if
you've
got
that
feeling
trust
it
and
keep
challenging
each
other
to
try
and
find
something
more
clever,
because
you
can't
undo
it
once
you
ship
it.
We
can't
deprecate
things.
So
if
you
ship
something
that's
sort
of
awkward
to
use,
there's
going
to
be
people
using
it.
It's
going
to
be
very
hard
to
ever
turn
it
off.
A
Cool
we
talked
to
the
top
about
avoiding
becoming
a
kind
of
like
complete
programming
language,
but
there
is
some
logic
in
the
rules,
keyword
and
then
also
in
a
dag
for
dependencies.
How
like?
What
guardrails
would
you
put
in
to
avoid
us
becoming
a
kind
of
like
complete
programming
language
that
you
were
suggesting?
We
should
avoid.
B
Yeah
I
mean
you
just
got
to
constrain
it,
so
dag
actually
doesn't
have
any
logic,
but
the
rules
keyword
does
for
sure.
It
allows
you
to
set
if
statements
essentially
within
the
job,
but
it
doesn't
allow
you
to
do
it
in
a
kind
of
open
sense
like
you
might
be
able
to
in
a
dsl
in
a
dsl.
You
might
be
able
to
just
say
something
like
if
this
variable
is
set,
then
you
know
run
all
of
these
set
all
of
these
variables
that
are
going
to
be
used.
B
A
B
B
If
given
total
freedom
and
yeah,
it's
tough
because
they're
not
wrong,
but
it's
sort
of
harmful
to
the
commons.
If
you
just
kind
of
like
take
all
of
the
guardrails
off
so
yeah,
the
the
dynamic
generation
of
the
gitlab
ciam
was
one
off-ramp
for
those
kinds
of
users
where,
if
they
really
are
just
kind
of
bouncing
up
against
the
limitations
of
the
ammo
syntax,
then
they
can
dynamically
generate
it,
and
you
know
what
they
might
need
to
do
to
express
their.
B
That
just
emits
the
gitlab
cim,
so
that's
one
way
that
we
kind
of
help
those
users,
the
other,
is
to
take
it
as
an
opportunity
to
deeply
understand
what
their
problem
is
and
and
give
features
that
help
them,
which
again
is
not
really
what
they're
asking
for,
but
it
often
it
often
gets
us
a
better
feature
for
more
people.
It's
how
we
that
was
the
dag,
essentially
is
we.
B
B
So,
instead
of
doing
everything
inside
of
the
gitlab
ciem
I'll
just
write
a
script
and
then
call
that
from
a
job,
and
then
that
can
do
more
complex
things,
but
then
you
miss
some
of
the
you
know
visualization
like
if
you,
the
extreme
case
of
that,
would
be
if
somebody
just
had
one
job
in
their
entire
pipeline.
That
ran
a
very
complex
script.
That
did
everything
and
then,
if
you
looked
at
gitlab,
all
you
would
see
is
one
job
and
there
wouldn't
be
very
much
information
in
there.
B
It
would
just
run
for
a
really
long
time
and
then,
when
it
was
done,
all
of
it
would
be
done
something
we
could
potentially
do.
There
is
allow
for
that
script
if
they
were
to
go
that
route
to
show
more
of
its
status
inside
of
git
lab
like
create
virtual
jobs
and
show
virtual
status.
That's
related
to
that
job,
but
I
don't
know:
we've
never
gotten
close
to
going
down
that
route,
but
it's
something
that
you
could
imagine
for
that
kind
of
use
case.
A
A
I
had
the
last
question
on
in
the
dock.
If
others
have
any
feel
free
to
chime
in
mine.
Was
you
have
spoken
to
me
eloquently
about
the
it's
like
one
of
the
reasons
why
we
want
to
avoid
the
dsl
is
because
others
who've
gone
down
that
path
have
just
it's.
I
actually
don't
know
what
the
pitfall
is
when
it
happens,
but
I'd
love
to
hear
more
about
it,
but
you've
kind
of
warned
that
others
who've
gone
down
the
make
it
a
dsl
has
caused
significant
pain.
B
Look
at
it
and
really
kind
of
just
read.
It.
Look
at
the
pipeline
that
ran
and
figure
out
what
went
wrong
or
where
at
least
where
it
went
wrong,
and
it's
so
much
easier
to
maintain
and
make
little
tweaks
and
improvements
and
and
keep
things
working
rather
than
if
you
just
implement
the
whole
thing
arbitrarily
in
code
and
you
kind
of
have
to
understand
the
whole
thing
in
order
to
figure
out
how
to
make
it
work.
So
so
yeah,
that's
the
that's.
A
Do
you
think
that's
one
of
the
principles?
It's
we
haven't
said
that
in
this
conversation,
or
have
I
expressed
it
before,
but
that
maintainability
by
having
it
be
readable
and
easily
understandable
by
someone
who
is
outside
of
the
authoring
group
like
we
should,
we
should
strive
to
create
a
syntax
for
a
ci
that
allows
anyone
to
look
at
it
and
if
it's
so
complex
that
somebody
looking
at
the
pipeline,
yaml
definition
can't
immediately
understand
what's
going
on,
then
that
we
should.
B
Yeah,
that's
nicely
put:
you
shouldn't
need
a
team
of
experts
to
write
your
gitlab
cia
animals
when,
but
when
I
think
about
the
pipeline
authoring
group
at
companies,
it's
the
people
who
fill
in
it
it's
like,
so
it
can
be
a
lot
of
different
people.
Sometimes
it's
the
expert
engineer.
Sometimes
it's
the
guy
who
just
started
or
gal
who
just
started
and
it's
different
people.
Sometimes
it
is
dedicated
but
yeah.
B
It
just
needs
to
be
simple,
because
nobody
managing
the
build
system
is
not
producing
values
for
the
customer
for
the
users
of
these
companies
so
the
less
time
they
spend
on
it
the
happier
they
tend
to
be
and
if
we're
finding
that
people
are
spending
a
lot
of
time
having
to
do
it
or
having
to.
If
you
need
a
build
engineering
team
in
order
to
make
gitlab
work,
then
we've
really
gone
down
the
path
of
complexity.
To
a
point
where
we
need
to
make
an
adjustment
right
away.
A
A
Cool
just
before
I
turn
off
the
live
stream.
Thank
you,
jason
for
participating,
I'm
going
to
take
this
document
and
consider
writing
with
probably
dove
and
tao
a
like
principles
of
cienel
syntax
that
we
can
start
iterating
on
I'll
share
it.
So
anyone
who
wants
to
contribute
to
it.
I
would
appreciate
it
cool
thanks.
So
much
kenny,
yep
thanks.
Everybody.
B
I'll
also
mention
I
have
a
general
ama
on
wednesday,
so
if
anybody-
maybe
it's
either
wednesday
or
thursday,
so
ping
me,
if
you
don't
already,
have
an
invite
it's
on
the
ops
calendar
and
that
can
that
will
just
be
an
ama
for
any
topic.
Any
question
at
all
that
anybody
wants
to
ask
so
small
plug
for
that.