►
From YouTube: GitLab Handbook: Help my pipeline is failing!
Description
A short presentation and live demo to understanding why your pipeline fails.
A
A
A
A
So
when
your
part
plan
fails,
we've
all
had
this
feeling
of
being
frustrated.
You
know
all
you
did
was
make
a
small
update
and
the
Python
fails
and
it's
it's
sometimes
quite
tricky
to
figure
out
what
went
wrong
to
start
off.
I
want
to
just
quickly
go
over
how
the
gitlab
handbook
pipelines
work
and
for
those
that
don't
know,
pipelining
github
is
essentially
a
bunch
of
jobs
that
get
executed
in
a
specific
sequence.
A
A
So
I
previously
did
a
quick
recording
of
how
to
find
out
why
our
job
is
failing
and
I've
added
the
youtube
link
here,
but
I'm
going
to
do
a
live
demo
today
as
well
on
a
different
issue.
So
I've
started
with
a
example,
mr
just
good
and
I'm,
going
to
open
it
up
and
show
you
what
is
going
on
there.
So
I
open
this,
mr
and
it's
got
a
simple
change
of
adding
a
new
person
to
to
the
team
but
Yama
file
and
at
first
kind
of
like
glance.
You
know
this
all
looks
fine.
A
However,
if
I
have
a
look
here,
I
can
see
here.
It
says
the
merge
result
pipeline
and
failed
I
see
a
bunch
of
great
thoughts,
and
it's
definitely
not
looking
great.
So
if
you
go
to
the
pipeline's
tab,
you
click
on
one
of
these.
You
can
see
the
jobs
for
this
specific
stage
and
I
can
see.
All
of
these
are
failings
with
these.
Definitely
something
not
right
and
also
I
can
see
someone
the
tests
stage,
stead
of
failing
as
well.
A
So
first
thing
you
want
to
do
is
go
and
look
at
one
of
these
jobs
that
are
failing
and
what
you'll
see
here
is
the
output
from
the
job.
Now
a
lot
of
the
time
people
are
overwhelmed
by
what
they
see
here,
because
it
doesn't
make
sense
and
the
key
to
to
reading
these
is
to
look
for
the
part
that
gives
you
actionable
information.
A
If
we
just
look
at
the
output
here,
these
are
just
a
bunch
of
file
paths
and
and
referencing
specific
methods
that
are
being
called
not
in
technical
terms.
This
is
called
a
stack
trace
and
this
this
might
be
useful
for
debugging
the
the
issue
at
a
at
a
more
technical
level,
but
for
the
purposes
of
figuring
out
what
went
wrong
this
isn't
that
useful.
So
what
you
want
to
do
is
you
want
to
kind
of
like
scroll
up
and
see
where
things
start
going
wrong.
A
So
everything
looks
fine
here
and
then
we
get
to
a
point
where
it
says
the
amel
exception:
parsing
that
not
find
expected
key
at
line.
2
587
column
3.
So
it's
definitely
it's
reading
the
ML
file,
and
it's
saying
you
know
something
is
wrong
day
so
that
that
gives
us
an
indication
if
we
look
at
some
of
the
other
jobs
would
like
to
find
a
similar.
A
Eml
files
as
well
gets
a
little
bit
later,
are
on
a
tourist
for
requiring
specific
structure
and
in
in
tation.
So
it's
very
important
to
do
that.
So
what
I'm
gonna
do
just
for
the
sake
of
of
this
demo
is
I'm
quickly,
gonna
edit
this
file
and
go
to
the
bottom,
where
our
needs
and
if
we
look
at
line
2
8
8,
we
can
see
there's
an
extra
in
tation
there.
So
that's
something
that
was
wrong
that
we
needed
to
fix
with
that
being
fixed,
now,
Christmas
cool.
It
thinks
in
education.
A
A
Yeah
there
it's
going
so
while
this
runs
I'm
quickly
going
to
switch
back
to
the
presentation
and
carry
on
with
a
few
slides
and
then
we'll
come
back
to
this.
So
common
reasons
for
pipelines.
Failing
one
of
the
promise
are
your
pipeline
won't
run
because
there's
a
conflict
between
your
branch
and
master.
A
Now
a
conflict
is
essentially
saying
that
you've
changed
something
in
the
file
and
somebody
else
has
changed
that
file
in
a
similar
place
where
you've
changed
it
and
now
kid
doesn't
know
which
version
is
the
correct
one
and
and
so
it
requires
you
to
resolve
it.
So
the
solution
to
to
having
this
issue
is
to
resolve
the
conflict.
A
Now,
thankfully,
getup
has
a
built-in
conflict
resolution
UI,
and
you
can
read
more
about
that
in
the
documentation,
so
you
know
quickly
listed,
but
you
can
basically
it'll
show
you
the
differences
between
the
source
fronds
that
you
the
target
branch
that
you
want
to
merge
it
and
your
changes
and
it's
up
to
you
to
determine
what
is
the
right
version
of
the
changes.
Please
be
careful,
you'll
not
need
boots
demarcation
lines
that
show
you
where
the
errors
are
in.
A
A
Okay,
then
another
problem
is
when
your
branch
is
far
behind
master
and
newer
commits
in
master
fixed,
an
issue
potential.
So
we
recently
had
a
issue
like
this
and
quickly
go
to
it
where
we,
a
change,
happened
in
the
configuration
file
for
the
gate,
lab
CI
and
people
getting
these
yammering
valid
error
messages
on
their
pipelines,
and
so
we
fixed
it
in
master,
but
but
because
their
branches
was
were
when
updated
with
the
latest
fixed,
they
were
still
getting
these
errors
as
they,
even
though
they're
adding
new
changes
to
it.
A
This
solution
here
is
to
merging
the
latest
changes
from
master
or
to
rebase
your
changes
onto
master.
Now
this
is
potentially
a
technical
area
and
I'm
not
going
to
go
into
rebasing
in
this
specific
workshop,
but
we
can
cover
that
at
another
point.
If
it's
needed,
one
of
the
the
things
that
I
would
highlight
is
look
out
for
how
far
behind
your
branch
might
be
in
terms
of
the
number
of
commits
to
to
master.
A
A
Another
common
firm
reason
for
for
here
is
this
changes,
the
team
Dexamyl
or
any
other
data
file
like
with
just
C,
and
it
could
be
a
formatting
issue
like
we
saw
with
the
the
project
indentation
only
there
or
it
could
be
a
validation
constrained
issue,
a
tool
that
I
can
recommend
is
llamo
validator.
So
if
you
have
some
yellow
that
you
not
sure
if
it's
valid,
you
can
paste
it
in
here
you
can
click
validate
and
it
can
tell
you
where
there's
a
problem.
A
So
if
you
want,
if
you're
writing
some
llamo
code,
you're,
not
sure
it
is
correct,
this
is
a
quick
way
to
to
check
it,
especially
if
you're
getting
an
error
message
from
the
pipeline
and
you're
not
sure
what
the
actual
problem
is.
It
might
be
easier
to
just
validate
it
to
like
this,
but
most
of
the
time
you
should
receive,
especially
for
the
validation
constraint,
you'll
receive
a
human
readable
sentence
in
the
the
job
output.
A
That
shows
you
what
went
wrong,
for
instance,
in
this
example
here
it's
me
that
I
could
not
find
unexpected
:
when
scanning
the
key
had
a
specific
line
column,
so
llamo
files
are
notorious.
You
know
for
for
needing
exact,
formatting
and
indentation
and
in
in
addition
to
that,
we
have
a
lot
of
validation
constraints
around
the
actual
values
that
you
put
into
into
those
data
fast.
A
Another
problem
is,
if
you
add,
a
new
file
to
the
root
of
the
website,
so
that
would
be
in
the
in
the
source
folder
in
this
repo.
We
restrict
this
by
using
a
files
file
in
there
in
the
project
Reaper,
and
so,
if,
if
there's
an
intentional
change,
where
you
want
another
top-level
directory
for
the
project,
you
need
to
update
this
files
file
to
show
that
that
it's
expected
to
begin
there.
This
is
more
just
a
safeguard
for
for
people
accidentally
adding
things
that
are
on
detention.
A
Another
one
is
sometimes
there's
another
problem,
either
with
git
lab
a
third
party
service
or
with
the
underlying
infrastructure
used
to
run
the
pipeline's,
for
instance,
in
the
example
I'm
showing
you,
it
says,
HTTP
requests
to
update
a
snippet
failed
with
the
status
code
503,
and
that
means
there's
nothing
wrong
with
the
code
that
you're
actually
trying
to
merge
in.
But
when
the
pipeline
is
running,
it's
trying
to
connect
to
something,
and
it
is
not
having
any
luck.
So
the
solution
here
is
sometimes
retrying
the
job
or
the
pipeline.
A
A
Right
so
here
we
can
see,
it's
finished
running
the
apartment,
but
it's
still
not
happy
we're
still
getting
failures
and
our
lending
is
still
not
working.
So
let's
go
into
this
and
see
what's
going
on
so
again,
let's
go
to
where
it
says:
Oh
oops,
it
seems
like
one
or
multiple
pictures
reference
on
the
team
page.
Do
you
know
it
exists,
and
it's
saying
this
get
to
know.
Tj
pay
check
that
the
picture
line
in
dated
matches
the
file
name
of
where
we
placed
it.
A
For
the
sake
of
time,
I'm
not
gonna
go
through
all
of
the
validation
constrains
in
the
live
demo,
but
I'll
quickly
mention.
We
look
at
the
type,
for
instance,
it
should
be
personal
or
vacancy
yeah.
You
know
there's
a
little
typo,
so
it
would
have
picked
up
an
error
on
that.
So
we
looked
at
the
locality.
We've
got
a
list
of
localities
that
we
validate
against.
We
validate
against
the
rolls
to
make
sure
that
there's
a
job
family
we
validate
the
reports
do
so
this
value
should
actually
match
another
team
members
flow.
In
this
case.
A
It's
not
matching
my
slug
correctly,
so
that
would
have
resulted
in
an
error.
It
validates
whether
the
pitch
exits,
and
so
that's
why
I
threw
that
area
that
we
just
saw,
and
these
various
other
validations
that
it
also
looks
for
so,
but
the
key
thing
is
go
in
to
the
job
where
it's
failing
and
look
for.
The
first
point
where
you
can
find
like
this
makes
no
sense,
and
it's
not
99%.
A
It's
not
going
to
give
you
any
information,
but
going
to
the
point
where,
where,
where
things
look
like,
it
start
going
wrong
and
we
can
see
here
it's
going
wrong
and
we
can
see
there
are
reports
to
injuries
for
Jean,
but
nobody
is
assigned
to
those
for
those
roles.
So
so
that's
one
that
I
just
pointed
out,
so
key
thing
is
going
to
the
job.
Ignore
the
stack
trace,
find
the
first
point
where
you
can
see
some
human
readable
error
message
and
that
will
normally
give
you
a
good
indication
of
what
been
dropped
right.
A
You
can
follow
this
link
to
the
handbook
where
it
talks
about
metric
based
bodies
and
also
how
you
can
sign
up
to
be
a
buddy,
but
in
general
what
you
want
to
do
is
you
want
to
reach
out
in
the
m
our
bodies
slack
channel
or
you
can
go
to
the
team
page
and
search
for
most
request
body,
and
it
will
show
you
team
members
who
have
indicated
that
they
are
replaced
by
these
are
not
happy
to
help
people
with
most
requests.
So
those
are
the
two
ways
that
you
can
identify.
A
A
We
have
a
process
for
that
which
you
can
find
you
now
Hank
and
I'll
quickly
go
through
to
that
page,
but
essentially
it
tells
you
when
you
should
be
able,
when
you
should
be
excluding
an
issue,
and
it
tells
you
where
you
can
go
so
in
the
head
day
we
have
a
handbook
escalation
channel
where
you
can
go
and
reach
out
for
help
in.
If
it's
one
of
these
urgent
scenarios,
we
also
have
a
master,
broken
gate
lab
channel
which
tells
us
whenever
there
is
a
master
pipeline
that
failed.
A
We
get
notified
about
that
and
we
practically
go
and
look
to
see
what
is
wrong.
So
that's
another
way
we
wanted
to
what
could
potentially
be
going
wrong
all
right.
So
hopefully
you
feel
a
little
bit
more
confident
in
handling
in
your
apartment
failures
in
the
future.
As
a
recap:
click
through
to
the
job
that
failed,
fine,
find
the
error
message.
A
Sometimes
it
won't
make
sense,
and
that
is
okay.
You
don't
have
to
resolve
all
the
issues
yourself.
There
are
people
who
are
willing
to
do
this
and
when
it
comes
to
technical
matters
like
rebasing,
if
you're
not
comfortable
doing
that
yourself
yet
feel
free
to
reach
out
to
the
inward
bodies,
they're
always
happy
to
help.
A
A
You
know
we
all
we're
also
looking
to
to
document
out
what
each
of
those
jobs
in
argued
to
have
handbook
pipeline
does,
and
so
we
can
definitely
make
that
more
accessible
for
team
members
to
to
have
an
understanding
of
what's
going
on,
but
living
essentially
in
in
it
from
a
code.
Point
of
view
is
similar
to
how
you
would
go
and
you
would
pull
a
little
fluffy
sulfur
off
a
jacket
or
jersey,
and
you
know
so
what
what
it
does
is.
What
code
point
of
view
is?
A
It
goes,
and
it
looks
for
specific
things
that
you
would
expect
that
might
go
wrong.
For
instance,
we
it
could
look
at
things
like
imitation
of
the
Yama
file.
It
could
look
at
things
like
you
can
correct
values,
and
so
it's
it's
automating
things
that
a
human
would
have
to
validate
to
see
if
it's
correct.
So
so
that's
something
that
that
we
use
software
projects.
A
B
Because
we
use,
we
obviously
use
the
lab
a
lot
within
my
team
and
we're
just
finding,
like
all
of
these
queries
are
being
routes
at
one
specific
person,
so
I
think
if
we
could
be
a
bit
more
in
able
to
figure
it
out
ourselves
that
would
lighten
the
load
for
her.
My
certainly
so
this
was
super
informative.
Thank
you
so
much
honor.
It
appreciate
it.
A
Right,
if
there's
no
further
questions
in,
we
can
end
this
workshop,
like
I,
said
I
will
add
this
recording
on
github,
unfiltered
and
I
will
also
work
on
updating
the
handbook
with
documentation
around
terminology,
like
you
just
mentioned,
as
well
as
these
common
error
scenarios,
so
that
team
members
can
opt
in
salt.
Thank
you
very.