►
From YouTube: GitLab Code Coverage Badge: Speed Run
Description
In this video I show how to setup the Code Coverage calculation on a simple Java project to be used as a Project Badge, display in a Merge Request and use with a simple bash file in a compare job.
This sample project can be found here: https://gitlab.com/jheimbuck_gl/java-code-coverage
The blog on how to publish code coverage reports to GitLab pages can be found here: https://about.gitlab.com/blog/2016/11/03/publish-code-coverage-report-with-gitlab-pages/
A
Hi
I'm
James
I'm,
a
product
manager
for
the
testing
group
it-get
lab
today,
I'm
gonna
do
a
quick
speedrun
or
to
show
off
how
you
setup
code
coverage
within
a
project,
so
you
can
see
it
as
a
badge
and
then
how
you'll
see
the
difference
in
code
coverage
in
a
merger
quest.
So
what
you're
looking
at
here
is
just
a
copy
of
the
project
that
I've
been
using
on
most
of
these
speedruns
quick
little
Java
project
just
show
some
things
off,
so
let's
go
ahead
and
start
in
our
web
IDE.
A
A
A
A
A
A
So
there's
a
way
that
you
could
publish
that
index
study
Gmail
that
we're
creating
from
the
plug-in
as
part
of
our
script,
and
you
can
link
to
that
I'll
link
to
it
below
the
video
in
the
notes,
another
post
that
someone
has
put
together
showing
how
to
publish
that
report
into
get
lab
pages
so
that
you
can
link
to
it.
That's
a
great
little
tutorial
how
to
set
that
up
and
add
a
badge
all
right.
A
We
have
a
badge
there
so
right
now
our
coverage
is
unknown
if
our
coverage
was
already
calculated
and
there
was
an
artifact
to
parts
from
it
would
display
it
here.
But
since
we
haven't
merged
the
scene,
yet
it
doesn't
have
anything
to
look
at.
So
let's
go
back
to
our
merge
request
and
see
how
it's
doing.
A
All
right
looks
like
we're
good.
We
have
a
coverage
value
already
in
our
pipeline,
so
now
this
is
going
to
start
to
display
in
all
of
our
merge
requests
for
recalculating
coverage.
So
go
ahead
and
merge
this
in
and
once
that's
done
running,
see
a
badge
value
back
Paige
so
go
ahead
and
pause
the
video,
while
this
is
finishing
up,
running
the
merge
request
and
then
we'll
be
back
to
see
what
our
coverage
value
is
for
the
project.
A
Alright,
our
pipeline
is
green
and
we
can
see
now
that
we
have
a
coverage
value
of
50%.
So
that's
exciting
weather
coverage
badge
now
so
I
didn't
record
this
demo
or
this
walkthrough
to
show
how
to
do
that
or
after
all,
blog
posts
already
on
get
lab
about
how
to
do
that.
I
did
this
as
a
setup,
because
I'm
often
asked
and
I've
seen
a
lot
of
issues
requesting
the
ability
to
fail
a
merge
request.
A
If
that
code
coverage
value,
that's
calculated
is
going
to
decrease
with
the
change
and
we
haven't
built
that
feature
into
get
lab.
Yet
it's
something
that
we're
considering
and
how
we
can
really
do
a
value
add
for
it.
In
the
meantime,
though,
it's
actually
pretty
simple
to
setup
with
just
some
bash
scripting
and
some
changes
into
the
gate
lab
C
IMO.
So
by
no
means
take
this
as
the
definitive
way
on
how
to
do
this.
This
is
my
first
attempt
at
a
bash
script
and
incorporating
it
into
my
gait
lab
C
IMO.
A
So
it's
not
efficient,
it's
not
very
elegant.
Hopefully
you
can
build
on
this
and
do
much
much
better,
but
let's
go
ahead
and
go
through
that
process
and
make
a
little
bash.
That's
kind
of
fail.
A
job
fail,
a
triplane
if
the
code
coverage
is
going
to
decrease
with
our
change.
So
first
thing,
I'm
going
to
do
is
add
a
new
file.
A
So
I've
already
written
the
script
for
this
and
I'll
walk
through
it.
Real
quick,
take
a
look,
so
all
this
does
is
it
uses
some
of
the
variables
that
are
available
to
us
as
being
part
of
get
lab,
so
we
are
going
to
just
grab
a
project
ID
and
our
latest
pipeline
and
grab
the
coverage
value
out
of
the
JSON
response.
That
comes
there
store
that
into
a
value
I'm
doing
a
little
bit
of
echo
in
here.
Just
as
I
was
debugging
this
to
make
sure
I
got
all
the
right
stuff.
A
You
could
obviously
clean
that
up
yourself
and
then
do
the
same
thing
for
master,
because
I
want
to
compare
to
the
master
branch.
That's
what
I'm,
using
as
my
default
branch
in
this
approach,
and
so
at
the
end
of
the
day,
what
I'm
doing
is
just
comparing
those
two
values.
As
long
as
the
latest
is
greater
or
equal
to
the
master
value,
it's
going
to
go
ahead
and
be
happy
and
give
me
a
green
pipeline,
or
at
least
a
green
job.
Otherwise
it's
just
going
to
fail.
A
A
A
A
Hey
we're
back
after
emerged
and
murti
into
my
java
app
and
I'm
just
adding
this
little
ad
function
right
here
to
show
what
we're
going
to
what
we're
gonna
do
when
we
add
some
code,
but
don't
add
tests
for
it,
so
I'm
gonna
go
ahead
and
commit
this
and
we'll
just
let
this
in
real
time.
So
you
can
see
how
quick
the
secondary
job
runs
here
most
of
the
weight
on
this
is
on
the
maven
build.
A
A
All
right,
we
can
see
our
test
job
finished
up
and
you
can
see
the
content
of
the
HTML
here.
Let's
browse
to
that
real
quick,
just
to
show
you
what
is
in
pack,
this
is
just
specific
to
the
plugin
that
we're
using
and
the
artifact
that
it
creates.
But
this
is
the
content
that
we
follow,
that
other
demo
we
can
see
published
over
to
github
pages.
A
A
You
can
see
the
same
comparison
happen
there,
but
we
have
31
percent
coverage
on
our
pipeline
from
a
job
and
that
compares
to
50
percent
for
a
master,
and
so
we
failed.
So
that's
just
an
example
of
what
you
can
do
with
a
little
bit
of
shell
scripting
or
a
little
bit
of
bash
scripting
and
the
gait
lab
see
IMO
file
I
hope
that
you
find
some
better
ways
more
efficient,
more
elegant
ways
to
make
that
happen.