►
From YouTube: Orchestrated end-to-end tests at GitLab - Part 2
Description
In this video, GitLab Senior Software Engineer in Test, Sanad Liaquat talks in detail about the different steps involved in writing orchestrated end-to-end tests including how to run the tests on local against the GDK and on CI before merging the MRs, how to publish a new version of the gitlab-qa gem and where to add CI jobs for new test scenarios.
Deck: https://docs.google.com/presentation/d/1e_Pkw2OubI_L1eJDrvjKCNo6g-9eDXILLfNmfiXf8xM/edit#slide=id.p1
This is the second video in a two part series on Orchestrated end-to-end tests. The first video can be found here: https://youtu.be/wWC7r3l0u1Y
A
A
Now
we
learned
about
this
third
bullet
point
in
the
first
part
of
this
two-part
series.
If
you
are
looking
to
gain
that
information,
please
do
go
ahead
and
watch
the
first
part
video
pasted
a
link
over
here,
and
if
you
are
looking
for
how
for
information
on
how
to
write
and
to
end
tests,
I've
also
added
some
link
links
on
the
slide.
The
first
link
talks
about
where
to
start.
In
the
second
link,
we
have
a
step-by-step
tutorial
that
guides
you
through
how
to
write
an
end
to
a
desk.
A
A
In
the
first
step,
we
are
going
to
manually
run
the
external
service
in
a
docker
container,
but
our
ultimate
goal
would
be
to
automate
the
orchestration
of
this
service
using
the
gitlab
qa
framework
and
we're
going
to
start
doing
that
in
step.
Two,
where
we
are
going
to
write
a
component
for
this
external
service
and
we
are
going
to
use
that
component
in
the
test
scenario.
We
are
also
going
to
add
some
documentation
for
the
new
scenario
and
any
required
environment
variables.
A
There
would
be
a
slight
modification
required
to
the
existing
tests
that
we
started
off
with
in
step,
one
to
work
with
the
new
test
scenario.
We're
gonna
do
that
in
step
three
in
step,
four,
we
are
going
to
see
how
to
use
the
test
scenario.
We
wrote
in
step
two
to
run
the
tests
on
local
in
step
five,
we
are
going
to
learn
how
to
run
the
test
scenario
on
ci
before
the
imrs
are
merged.
A
Next,
we
are
going
to
learn
about
how
to
release
a
new
version
of
gitlab
qhm
after
the
gitlab
qamar
is
merged.
We're
then
going
to
move
up
to
talking
about
the
different
places
where
we
need
to
add
the
environment
variables
that
we
created
in
step
two
last
we're
going
to
speak
about
the
different
pipelines
where
we
need
to
add
new
jobs
for
running
the
new
test
scenario
that
we
created.
A
A
A
A
A
Now
I
am
not
going
to
go
into
the
details
of
the
test
implementation.
You
can
easily
tell
by
looking
at
the
code
that
this
test
is
ensuring
that
we
can
close
an
issue
in
jira
by
pushing
a
commit
in
gitlab
and
ensuring
we
can
close
an
issue
in
jira
via
a
merge
request
in
gitlab.
One
other
thing
I
would
like
to
point
out
here
is
that
currently
we
have
hard
coded
the
service
url
to
localhost
8080.
This
is
because
we
have
manually
run
the
service
on
that
url
and
port.
A
A
We're
also
going
to
make
some
minor
changes
to
our
gitlab.
Mr
remember
I
mentioned
that
we
have
currently
localhost
8080
hard-coded,
but
now
what
we're
going
to
do
is
that
we
are
going
to
pass
it
on
from
the
gitlab
from
gitlab
qa.
Also,
the
final
version
of
the
gitlab,
mr,
has
been
pushed
to
this
branch
again.
This
branch
is
available
on
a
fork
of
the
canonical
gitlab
project
over
here.
A
A
We
have
mentioned
the
image
here
and
the
most
important
part
of
this
code
is
the
instance
method.
This
instance
method
would
be
called
by
the
test
scenario
that
we
are
going
to
write
next
inside
the
instance
method.
We
call
prepare
that
pulls
the
docker
image
and
creates
the
network
and
then
starts
the
docker
image.
A
I
would
also
like
to
point
out
here
that
we
are
setting
the
hostname
to
an
environment
variable
called
jira
hostname,
and
we
also
need
to
add
this.
This
new
environment
variable
inside
the
env
file.
This
file
is
located
in
lib,
gitlab
qa
runtime
directory
the
three
variables
that
you
are
supposed
to
add
here:
jira
hostname,
jira,
admin,
username
and
java
password.
A
A
A
Now,
when
the
jira
host
name
environment
variable
is
provided
we'll
be
using,
that
else
will
fall
back
to
localhost
in
the
gitlab
qe
project
in
the
gitlabci.eml
file.
We
need
to
create
new
jobs.
For
this
scenario
we
just
created,
we
need
to
add
a
job
each
for
ce
and
e
and
the
corresponding
current
time
jobs.
A
Next,
we
are
going
to
talk
about
how
to
run
the
test
scenario
we
just
created
on
local
inside
docker,
using
gitlab
qa,
now
the
command
to
do.
That
is
this
one
right
here
mentioned
at
the
bottom
of
the
slide
I'll
copy
it,
and
I
mean
the
root
of
the
folder,
where
the
gitlab
qa
project
has
been
checked
out.
A
What
this
command
is
going
to
do
is
it
will
try
to
run
test
integration
jira
against
this
gitlab
image?
It
will
try
to
find
the
gitlab
image
on
local
and,
if
it
doesn't
find
it
there,
it
will
exit
it
will
not
try
to
pull
it
from
the
registry,
because
we
have
explicitly
mentioned
here
to
skip
full
and
obviously
the
reason
for
skipping
pull
is
that
we
have
made
up
this
test
year.
Tag
ourselves.
It
does
not
exist
in
the
registry
now.
A
That
obviously
means
we
have
to
ensure
that
we
have
an
image
with
this
name
and
this
tag
on
our
local.
We
can
do
that
by
pulling
a
gitlab
image
from
the
registry
and
then
re-tagging
it.
One
point
that
I
would
like
to
mention
here
is
that,
if
your
gitlab,
mr,
has
made
changes
to
the
application
code,
such
as
adding
a
selector
to
a
view
pulling
just
any
gitlab
image,
won't
work
as
you
would
need
your
changes
in
the
gitlab
image.
A
A
And
then
go
to
trigger,
get
lab,
docker,
job
and
scroll
all
the
way
down,
and
then
here
I
would
find
the
image
that
was
created
now.
This
image
would
have
all
the
changes
that
I
made
to
the
application
code
now.
This
command
will
also
try
to
look
for
the
gitlab
qa
image,
with
the
same
tag
as
the
gitlab
image,
as
opposed
to
the
gitlab
image.
We
can
create
the
gitlab
qa
image
locally.
A
A
A
Let's
talk
about
how
to
run
the
test
on
ci
to
ensure
they
are
green.
Before
we
can
send
our
mrs
for
review,
we
have
two,
mrs
one
for
gitlab
project
and
the
other
for
the
gitlab
qa
project
and
both
of
them
unfortunately,
won't
run
the
new
scenario
in
the
ci
pipeline,
as
is
the
gitlab.
Mr
won't
run
it
because
it
uses
the
gitlab
qhm
during
the
test,
and
the
gem
currently
does
not
have
the
new
scenario.
A
The
gitlab
qmr
won't
run
the
test,
because,
although
the
new
scenario
and
the
jobs
are
there,
it
uses
nightly
gitlab,
qa
image
and
nightly
currently
does
not
have
the
test
to
solve
this
problem.
We
would
need
the
gitlab
image
created
by
the
trigger
gitlab
docker
job
and
use
it
as
a
release
in
a
new
pipeline
for
the
gitlab
qamr.
A
Let's
see
it
happening,
we
already
saw
how
to
fetch
the
image
from
the
trigger
gitlab
docker
job
earlier.
So
I'm
going
to
skip
that
part.
I've
already
fetched
it
and
I
have
it
on
my
clipboard
I'm
going
to
go
to
my
mr
in
the
gitlab
qa
project,
I'm
going
to
copy
the
branch
name
and
I
would
also
need
the
merge
request
number.
A
A
A
And
here
we
can
see
both
of
the
examples
passed
once
the
gitlab
qamr
merges.
We
would
need
to
create
a
new,
mr
in
the
gitlab
qa
project,
where
we
would
increment
the
gitlab
qa
gem
version
in
the
version.rb
file,
based
on
the
recommendation
from
semword.org
and
when
creating
the
mr,
we
would
need
to
use
the
release,
template
and
just
follow
the
instructions
in
there.
A
A
A
We
already
added
the
job
to
the
gitlab
qa
project
as
part
of
our
gitlab
qamr
other
places
we
can
add,
the
jobs
are
the
nightly
pipeline
and
the
pipeline
common
project
for
sanitary
runs
against
life
environments,
and
with
that
we
conclude
our
session
for
today.
If
you
have
any
questions,
please
reach
out
to
me
at
the
email
address
shown
on
your
screen
right
now,.