►
From YouTube: Ops Cross Stage ThinkBig - 2021-07-08
Description
Our teams discuss a critique of the current state of GitLab CI
A
Hello,
everyone-
this
is
the
ops
section
cross
stage,
think
big
for
the
8th
of
july
and
today's
theme
is
a
gitlab
ci
critique.
We
had
a
couple
of
suggested
reads
that
were
suggested
for
the
session
on
limitations
or
problems
with
modern
ci
and
gitlab
ci,
and
our
goal
with
this
conversation
is
to
explore
potential
problems
with
the
way
rci
works
and
point
out
possible
solutions
for
the
future.
C
A
A
I
think
it's
really
interesting
how
they
they
highlighted
some
issues
in
templating
and
importing
different
pre-made
pieces
into
into
gitlab
ci,
and
I
think
some
of
that
is
already
the
direction
of
our
of
that.
Our
pipeline
altering
team
is
going
towards,
but
I
think
it's
really
interesting
how
they
built
an
open
source
extension
almost
to
get
lab
in
a
way
that
very,
very
closely
matches
what
what
our
teams
are
thinking
as.
A
A
A
C
C
Things
to
be
super
complex
over
time,
and
and
perhaps
if
we
can
answer
that
question
we
can
figure
out
how
to
make
things
less
complex
because,
like
they
talk
about,
you
know,
gamble
files,
all
the
things
you
have
to
do
and
takes
a
lot
of
skills
and
knowledge
to
actually
set
things
up,
and
we
are
working
on
some
of
those
items.
But
it's
it's
like.
C
A
Yeah,
I
don't
have
that
much
experience
with
the
ci,
especially
being
a
designer,
but
from
my
experience
in
past
organizations
that
have
used
gitlab
ci,
specifically,
it
can
be
really
hard,
especially
in
a
large
organization
where
different
teams
have
different
stacks
and
different
ways
of
working
to
just
find
the
entry
point
right.
How
do
I
start
a
new
project
and
yemo?
Like
just
say?
A
B
Well,
a
previous
org
that
I
worked
at
one
of
the
projects
that
the
cicd
team
for
lack
of
a
better
term
did
was
create
a
scaffold,
so
it
was
in
part
a
scaffolding
of
here's,
a
new
project.
Here's
a
new
repository
but
part
of
that
workflow
of
creating
it
was
picking
hey.
Am
I
building
a
go
project?
Am
I
building
a
javascript
project
because
those
are
two
big
languages
and
then,
where
am
I
deploying
to?
Am
I
deploying
into
data
center
and
mode
deploying
in
aws?
B
And
as
you
went
down
that
path
of
aws,
you
can
start
to
pick
a
few
more
things
and
that
would
start
to
cobble
together
what
your
build
pipeline
and
deploy
pipeline
had
to
look
like
dynamically,
so
that
at
the
end
of
two
minutes
you
had
a
fully
fledged
project
that
the
pipeline
would
run.
It
would
spin
up
a
hello
world
that
the
teams
forego
and
javascript
had
put
together
so
that
you
had
code,
you
knew
it
would
compile
you
know
built.
B
D
I
would
say
from
from
my
experience
I
I
really
struggled
to
get
started
with
gitlab
ci
years
ago,
just
to
like
say
hey.
This
is
like
what
do
I
want
to
run
want?
Do
I
want
to
run
the
test?
Yeah?
It's
okay.
Is
it
go?
Is
it
c
plus
plus?
Is
it
python?
Is
it
php?
Whatever
language
we
have
like
100
languages,
we
need
to
cover
and
then
it's
then
it's
something
you
also
want
to
look
into
how
to
integrate
a
unit
test.
And
after
a
while,
you
figure
out.
D
Oh
there's
a
junit
integration
in
gitlab
and
there
is
a
regex
you
need
to
pass
and
I've
built
trainings
for
that
to
educate
everyone,
but
still
it's
it's
a
learning
experience
and
you
also
need
to
invest
time
into
effect,
ring
the
yaml,
which
is
actually
like,
cicds
code,
because
it's
not
perfect.
Yet
you
start
off
with
like
one
job
two
jobs,
and
then
you
figure
out
how
to
use
extends,
which
is,
in
my
opinion,
super
complicated.
D
D
I
would
say
in
the
process-
and
you
really
don't
know
where,
to
start
and
and
one
of
the
things
I
would
love
to
see,
is
sort
of-
maybe
ai
or
machine
learning
things
you
analyze
the
source
code
and
based
on
that,
you
make
a
proposal
of
saying:
hey,
not
maybe
not
use
the
template,
because
the
template
is
just
like
the
first
step
but
suggesting
of
saying
hey.
This
is
a
ci
cd
stage
or
a
pipeline.
D
D
D
Maybe
you
want
to
start
using
this
template
and
by
the
way
here
is
from
gitlab
provided
in
the
registry
container
images
you
could
use
for
getting
there,
but
it's
the
problem
in
in
in
the
product
can
be
it's
too
much
and
warner,
and
the
the
second
article
mentions
that,
with
with
java
you
it's
not
just
java,
it's
like
different
dependencies.
It's
web
development,
it's
back-end
development.
You
have
a
database
back
and
there's
so
many
different
dependencies.
D
B
I
don't
know
where
to
start,
though
other
than
I
know
it's
java,
but
the
java
template
just
doesn't
give
me
enough,
or
the
gradle
template
just
doesn't
give
me
enough
to
get
going.
Instead,
I
want
a
more
robust
solution,
but
not
clippy,
to
walk
me
through
because
there's
questions
I
don't
know
answers
to,
potentially
that
I
want
that
tool
to
figure
out
for
me
like
some
of
the
dependency
stuff
and
some
of
the
the
things
that
I
don't
know
I
need
yet
to
deploy
to
the
place
that
I
want
to
deploy.
Is
that?
D
D
Another
dependency,
another
requirement
could
be
that
you
can
do
it
offline
outside
of
ci
cd,
but
that's
like
a
second
problem
or
second
feature
request.
The
main
thing
is
when
you,
when
there's
a
problem
with
the
clcd
pipeline,
you
want
to
analyze
it
and
fix
it
fast
and
also
understand
the
components
in
there.
So
it
shouldn't
be
like
you
have
50
stages
and
then
10
jobs
in
in
each
and
then
it's
like.
D
D
I
think
the
the
pipeline
editor
is
a
huge
investment
into
making
it
more
easy,
more
approachable,
especially
with
the
side
slider,
which
instructs.
You
gives
you
some
some
insights
and
some
pointers
and
also
the
default
template.
But
my
vision
is
that
it's
not
just
a
template
which
is
read
from
from
a
file
somewhere.
It's
an
opinionated
template
already
of
saying:
hey,
you
have
python
code
in
there.
D
Let's
propose
something
around
python:
it's
not
just
insert
the
script
in
there,
but
we
it
needs
lots
of
effort,
but
we
we
have
a
pre-built
tool
chain
for
you
right
now.
This
is
the
container
image
or
this
is
like
how
it's
how
it's
being
done,
and
this
works
for
most
of
the
cases.
Let's
say
I
don't
know,
80
90
something
around
that.
D
The
other
thing
which,
which
works
really
great,
is
the
the
the
built-in
ci
templates
and
the
possibility
to
add
your
own
custom
templates
to
it.
I
think
that's
a
premium
feature
to
to
add
your
own
custom
templates,
but
in
the
end
it's
it's
a
convenient
way
to
do
it.
I
would
say-
and
it's
easy
well,
it
is
easy.
It's
a
bold
word.
It's
it's
a
good
way
to
follow.
Along
of
saying,
hey
the
gitlab
developers
are
adding
these
templates
and
I
can
like
build
my
own
templates
based
on
them.
D
D
D
So
the
documentation
needs
some
improvements
and
making
it
more
discoverable
like
thinking
of
I
don't
know
marketplace
sounds
a
little
odd,
but
adding
making
it
more
visible
in
the
interface,
but
also
from
an
automation
perspective,
making
it
easy
to
deploy
that
using
the
api
or
using,
I
don't
know
the
python,
gitlab
module
or
ansible,
or
something
else
to
to
automatically
build
the
ci
cd
pipeline,
because
you
don't
want
to
click
and
write
yammer.
If
you
want
to
generate
it.
A
A
We
have
so
making
it
easier
to
write,
yaml
and
add
more
suggestions
since
that's
what
we
have,
but
I
think
it's
also
interesting
how
how
these
articles
approach,
the
idea
that
we
should
have
more
structured
sections
right
where
scripts
are
not
necessarily
just
wrappers
to
some
something
that's
running
in
there,
but
we
actually
have
semantics
defining
what
is
running
on
each
stage,
and
these
semantics
are
recognized
by
gitlab
and
the
system
works
differently
based
on
on
what
each
piece
means
right.
If
it's
a
deploy
job,
then
it
works
in
a
certain
way.
A
D
Yeah,
I
think
it's
an
interesting
idea,
because
no
also,
we
we
think
of
as
the
icd
pipeline,
of
a
queue
of
jobs
and
these
are
executed
and
they
have
a
they
have
a
defined
scope
depending
on
the
stage
or
you
are
defining
the
stage
where
they
are
in
and
sometimes
the
stage
doesn't
make
sense
or
you're
lazy
and
keep
everything
in
the
test
stage.
But
the
job
does
something
different.
D
So
this
could
be
like
a
detection
of
proposing
proposing
the
the
best
practices
I
kept.
I
just
kept
thinking
of
like
finding
a
different
way
to
create
a
cicd
job
and
registering
it
so
like
I'm
thinking
of
a
little
bit
of
iot
and
pops
up
you're,
throwing
in
something
and
then
basically
the
scheduler
or
the
runner
says,
hey
I'm
executing
this
and
for
some
reason
it
it.
D
D
It
it
defines
it
where
it's
executed
and
says:
okay,
we
have,
I
have
specific
groups
or
zones
which
define
what
the
current
scope
of
the
of
the
job
execution
is
and
not
just
the
stage
where
this
has
been
defined
in
it.
Doesn't
it
doesn't
really
comply
with
what
we
have
built
now
with
the
yammer
configuration?
D
D
D
Two,
but
two
ways
to
do
it
right
is
also
not
good.
That
creates
friction
in
the
product,
but
it
could.
It
could
be
an
interesting
way
of
saying
hey,
maybe
in
five
years
we
are
no.
I
cannot
say
that
loud
we
are
deprecating
the
current
configuration
and
we
migrate
to
a
new
model
of
dynamic,
ci
cd,
but
I'm
not
sure
if
the
market
is
ready
for
that.
D
A
So
basic
templating
may
help
some
subset
of
users
or
or
users
that
are
less
less
used
to
working
with
ti
and
yemo,
while
dynamic
pipelines
might
help
more
advanced
users,
but
at
the
end
of
the
day,
especially
in
a
big
project
where
I'm
on
a
repo
they're,
all
in
the
same
interface
they're
all
in
the
same
big
emo
file
right.
So
it's
harder
to
provide
different
levels
of
assistant
and
experience
to
different
users.
That
may
be
on
the
same
interface.
D
No
worries
yeah-
that's
definitely
true-
with
with
experienced
users
wanting
to,
for
example,
to
generate
code
for
the
child
pipelines
which
is
currently
possible,
and-
and
this
is
something
which
blows
your
mind,
because
it
involves
maybe
some
bash
scripting
and
some
some
other
scripting,
where
you
do
not
even
think
about
from.
Like
the
beginner's
perspective
of
saying,
parent-child
pipelines,
I
don't
need
that.
D
I
have
no
idea
how
this
works,
so
it's
I
think
it's
it's
definitely
worthwhile
to
define
the
target
group
or
you,
the
persona
who's
been
using
it
and
focusing
focusing
on
the
beginner
which
we
are
currently
doing
with
the
pipeline
editor
and
the
templates
and
everything
else
around
it,
but
also
allowing
advanced
users
to
go
there
and
also
I've
seen
people
expanding
on
on
auto
devops.
So
I
haven't
been
using
it
in
my
past
job.
D
I
kept
learning
it
while,
while
here
and
I've
seen
that,
for
example,
they
also
build
features
being
used
by,
I
think
by
archived.org,
which
was
a
hashitalks
talk
a
while
ago,
where
they
just
keep
using
the
detection
of
the
source
code
and
then
building
it
with
heroku
ish,
built
and
and
running.
The
web
application
in
a
container,
for
example,
if
we,
if
we
find
or
if
we
like,
expand
on
this
idea
of
saying
hey,
we
have
like
auto
ci
template
ci
platform,
suggestion
something
around
that
this
could
be
interesting.
D
D
D
We
are
running
a
syntax
check
on
the
code,
we're
running
the
code
quality
then
to
building
the
code
and
later
on
thinking
around
how
we
can
deploy
it.
If
you
don't
have
kubernetes
configured,
okay,
maybe
you
wanna
add
aws
you
want
to
like
this
is
described
in
in
the
second
blog
post
as
well.
How
do
you
deal
actually
with
terraform
and
provisioning,
aws
or
multi-cloud,
or
something
else
this
is
like,
gets
really
complex
and
provide
providing
the
best
suggestion?
There
is
super
hard
on
the
other
side.
A
So
it's
like
the
basic
step:
oh
you're,
using
ruby,
here's
a
ruby
template,
but
even
even
before
talking
about
ai
ml,
I
think
there's
a
huge
opportunity
in
personalization,
just
by
better
understand
the
use
case
for
each
user
and
then
drilling
down
on
the
specifics
of
those
use
case
right
so
just
by
knowing
okay
you're
using
ruby.
All
right
are
you
in
our
monorepo
or
mute
repo?
Yes
or
no?
Are
you
deploying
to
aws
to
gcp
or
to
a
dc
just
by
drilling
down
those
dc
decision
trees?
A
We
can
already
make
much
much
more
specific
suggestions
that
are
not
necessarily
like
each
one
of
these
will
generate
a
full
template,
but
even
like
at
some
point
suggest
blocks
of
functionality
blocks
of
of
code
to
go
into
the
ammo
and
from
from
what
I
see
being
being
designed
and
prototyped
on
the
ci
pipeline
altering
team,
I
think
that's
the
direction
they
want
to
go,
but
it's
it's
a
vast
landscape.
So
it's
hard
to
to
get
there.
D
D
Is
there
something
which
we
can
do
in
not
only
providing
the
ci
templates
as
in
yammer,
but
also
like
have
a
repository
or
have
have
a
location
which
provides
you
with
a
skeleton
of
building
ruby
code
packaging,
ruby
code
using
using
the
same
ideas
around
creating
a
docker
image
using
the
container
registry,
because
it's
already
there
but
guiding
guiding
the
user
in
that
direction?
Because
at
the
point
where
they
they
are
adding
ci,
cd
or
ci?
They
don't
know
about
the
container
registry.
Yet
they
might
not
even
know
about
containers.
D
This
is
like
the
the
lightning
bulb
you
want
to
see
in
the
head
of
the
users,
and
it
should
be
as
easy
as
possible,
but
also
as
convenient
as
possible,
because
if
you
catch
the
error,
it
should
be
hidden
somewhere
in
the
cicd
job
logs,
and
I
don't
want
to
navigate
there.
I
want
to
immediately
see
what's
wrong
with
the
build.
I
want
to
see
it
in
the
merge
request.
I
don't
want
to
click
on
something
so
like
that
the
feedback
loop
on
the
execution
side.
This
goes
into
pipeline
execution.
D
Actually,
then,
this
also
needs
to
get
better,
and
I
know
that
the
team
is
working
on
that,
or
also
like
touches
pipeline
efficiency
pipeline
monitoring
pipeline
insights,
because
when
the?
U,
when
users
started
their
journey
with
ci,
they
also
want
to
see
what
what
is
happening.
The
pipeline
editor
provides
you
with
a
preview
of
how
it
looks
like,
but
my
my
vision
of
my
idea
would
be
like.
I
also
want
to
like
simulate
what
is
being
executed.
D
Like
you
simulate.
I
don't
know
if
you're
familiar
with
the
with
the
concept
of
a
business
process
in
monitoring
where
you
define
a
tree
of
dependencies
more
or
less,
and
if
you
change
something
in
the
tree
like
move
one
leaf
to
the
right
hand,
side
from
the
left
and
make
it
broken,
does
it
affect
the
entire
health
state
of
the
of
the
business
process?
D
They
just
see
a
pipeline,
and
then
they
say
if
this
stage
or
if
this
job
is
broken,
I
want
to
simulate
and
just
make
make
it
red
what
happens
to
to
the
entire
pipeline
view,
or
I
want
to
say,
hey.
The
duration
is
now
10
minutes
or
something
else.
How
does
this
add
up
to
the
whole
process
pipeline
timing
out
always
something
else
so
like
the
the
environment
sandbox
and
you
can
like.
D
Maybe
it
goes
a
little
bit
too
deep
into
like
chaos,
engineering,
your
pipeline,
you
you're
building,
but
guiding
the
user
step
by
step.
There,
I
think
is,
is
key
and
with
short
iterations
of
short,
not
short,
but
doing
it
step
by
step
in
in
the
product
is
also
a
good
idea,
because
chaos
engineering
is
like
one
year
ahead
or
three
years
ahead,
somehow
but
yeah
getting
getting
there
with
smaller
steps
is.
This
would
be
a
great
idea.
A
Yeah,
I
think
a
lot
of
the
frustration,
not
necessarily
complexity,
but
the
frustration
with
not
just
ci,
but
many
other
configuration
methods
is
just
how
long
the
feedback
cycle
is
right.
So
if
you
have,
I
don't
know,
maybe
three
four
errors
in
your
process,
where
you
have
to
fix
that.
In
order
for
for
your
configuration
to
work,
you
might
have
the
same
number
of
errors,
but
if
the
feedback
loop
is
much
shorter,
then
then
you
might
fix
all
those
four
in
30
minutes
instead
of
two
hours,
and
that
makes
a
lot
of
difference.
D
And
and
regarding
the
the
first
blog
post,
for
example,
which
is
it's
super
complex
to
to
get
started
with
one
one
thing
I
struggled
with
with,
for
example,
using
github
actions,
the
first
time
was
that
I
needed
to
define
that
the
condition
when
to
do
something,
because
otherwise
it
doesn't
do
anything,
and
I
was
sitting
and
said.
I
have
no
idea
why.
Why
should
I
be
using
that
or
why
should
I
be
doing
that
where,
in
contrast,
gitlab
ci
runs
everything
when
defined,
which
which
is
one
of
the
convenience
things
the
other
one?
D
Is
I
don't
understand
why
I
needed
a
checkout
action
in
github
actions?
I
have
no
idea
because
I
want,
when
I
run
a
job,
that
the
environment
is
prepared
for
that
I
even
maybe
want
to
have
if
I
don't
define
anything,
the
pr
the
all-in-one
build
image
like
git
port.
The
workspace
image
provides
you
with
a
rust
compiler,
with
whatever
compiler
whatever
is
needed.
D
I
don't
want
to
invest
my
maybe
I
want
to
do
that
later
on,
but
I
want
to
build
on
best
practices
on
a
docker
or
on
a
container
which
has
all
the
build
tools
installed.
For
me,
we
provide
that
for
for
several
languages
and
also
terraform
and
stuff,
but
I
think
it's
one
of
the
one
of
the
key
things
will
be:
how
much
convenience
do
you
provide
for
your
users
to
keep
them
in
your
ecosystem?
D
You
want
money
from
that
in,
I
think,
maybe
maybe
with
special
support
or
something,
but
in
the
end
it's
I
don't
want
to
learn
how
I
can
configure
c
cache
with
c
plus
plus,
to
make
my
build.
My
ci
builds
more
effective.
I
I
need
to
do
that,
but
it's
super
complicated,
because
there
are
three
different
ways
to
do
it,
and
only
one
works
in
docker
and
stuff
like
that.
D
There
are
so
many
errors
you
can
make
yeah
it's
when
you're
sitting
there
and
if
you,
if
you
give
me
something
which
just
works
and
also
says
hey
by
the
way,
these
are
the
best
practices,
and
this
is
documented-
and
you
can
do
this
this
this.
It's
like,
oh
and
I
keep
start.
I
keep
building
on
that
because
my
company
says
you
cannot
use
the
gitlab.com
registry
for
your
container
images.
You
end
up
dm
set,
please
use
your
own,
but
I
can
use
what's
already
there.
The
knowledge
transfers
is
one
key
factor.