►
From YouTube: 13.4 Release Kickoff - Verify:Testing
Description
Kickoff Page: https://about.gitlab.com/direction/kickoff/#verify
Issues discussed in the video:
* Group Code Coverage Project Selection: https://gitlab.com/gitlab-org/gitlab/-/issues/215130
* Show Job Coverage Data in the pipeline MR View: https://gitlab.com/gitlab-org/gitlab/-/issues/15399
* Sort JUnit Report by Status and Duration: https://gitlab.com/gitlab-org/gitlab/-/issues/228950
We love feedback and you can reach me at jheimbuck@gitlab.com or mention me on GitLab.com using @jheimbuck_gl
A
I'm
going
to
be
highlighting
the
next
iteration
for
us,
and
that
is
going
from
all
of
the
data
being
available
to
just
select
project
data
being
available
in
the
designs.
Here
we
see
that
you'll
be
able
to
pick
projects
in
the
same
sort
of
picker
that
you
would
use
for
labels
and
issues
or
other
areas
around
the
gitlab
ui.
A
If
you
need
to
then
pull
that
data
down
and
slice
and
dice
it
further
we're
making
just
that
select
data
available
for
download
as
a
csv
and
you'll
be
able
to
choose
your
time
frame
as
well.
This
data
will
be
available
going
back
90
days
and
will
start
being
collected
from
when
we
release
release
the
feature.
I'm
going
to
turn
it
over
to
juan
to
talk
about
a
couple
of
iterations
on
some
usability
and
some
improvements
that
we're
making
in
thirteen
four
so
want
to.
Let
you
share.
B
Sure
all
right
so
yeah,
so
in
this
milestone,
we
are
also
tackling
some
usability
issues
that
we
we
have
had
for
a
long
time
that
are
affecting
our
users.
Hopefully,
this
is
gonna,
make
our
features
easier
to
to
use,
and
it's
gonna
allow
our
customers
to
browse
and
find
problems
with
the
tests
faster.
B
So
one
of
those
improvements,
it's
gonna,
be
basically
the
ability
to
sort
the
junior
the
day
unit
report
by
status
by
duration,
which
is
gonna,
allow
them
to
find
both
of
failed
tests
and
also
a
slow
tests.
So
this
is
going
to
give
them
a
little
bit
more
power
when
it
comes
to
browsing
this
table
of
tests.
B
The
the
other
thing
that
we're
going
to
be
working
on
is
this
very
interesting
issue
that
has
been
like
open
for
a
while,
and
it's
it's
actually
very
interesting
because
it's
it
as
we
have
been
growing
and
our
customers
have
been
growing
their
use
cases.
It's
becoming
more
evident
that
we
needed
this.
It's
basically
the
idea
of
providing
a
broken
down
coverage
value
for
each
job.
That
is
calculating
a
test
coverage
right
now.
We
just
gig
the
customers.
B
On
average
for
all
their
coverages
and
what
we're
gonna
try
to
do
with
this
is
basically
allow
them
to
see
multiple
jobs
that
provided
the
input
for
that
crash
data
and
be
be
able
to
visualize
those
things.
So
essentially,
the
design
is
gonna,
not
change
a
lot
in
the
when
it
comes
to
the
merge
request
pipeline,
but
we're
just
gonna
add
like
a
new
affordance
that
it's
going
to
allow
them
to
see
those
coverages
and
and
see
how
they're
changing
per
job
yeah.
B
All
right
I
apologize
about
that.
I
don't
know
what
was
going
on,
but
the
designs
are
here
so
basically,
as
I
was
mentioning
the
job,
the
jobs
are
gonna
be
listed
in
the
merge
request
pipeline
and
on.
However,
we're
gonna
provide
the
different
values
for
each
job
and
and,
of
course
like
this
is
the
broken
down
coverage
that
is
being
seen
here
by
by
values
right.
So
that's
more
or
less
what
I
was
saying
before
and,
of
course
we're
not
getting
rid
of
the
deltas.
B
A
Pretty
much
it
thanks:
mom,
that's
those
are
great
iterations
and
usability
improvements
looking
forward
to
those.
So
as
always,
we
welcome
feedback
through
discussion
and
these
issues
that
we'll
link
to
in
the
video
through
comments
in
the
video
or
you
can
email
me
at
jheimbach
gitlab.com
about
these
or
any
other
issues
in
the
testing
backlog.
Thanks.