►
From YouTube: GitLab 13.11 Kickoff - Verify:Testing
Description
Kickoff Page: https://about.gitlab.com/direction/kickoff/#verify
Ops Direction: https://about.gitlab.com/direction/ops/#verify
We love feedback and you can reach me at jheimbuck@gitlab.com or mention me on GitLab.com using @jheimbuck_gl
A
Hi,
I'm
james
hembach,
the
product
manager
for
the
testing
group,
the
verify
stage
at
gitlab
today,
I'm
joined
as
always
by
hayanna
the
ux
designer
for
our
team,
we're
going
to
be
previewing
the
work,
the
team's
going
to
be
doing
in
the
upcoming
1311
milestone,
which
will
release
in
april
of
2021
you'll,
find
a
link
to
the
1311
kickoff
page
and
with
links
to
these
items
in
the
verify
stage
direction
page
with
discussion
of
our
future
work
in
the
comments
below
the
video.
A
As
always,
you
can
always
reach
out
to
me
at
jheimbuk,
gitlab.com
or
through
comments
in
these
issues.
Any
of
the
issues
anything
that's
labeled
group
testing
in
the
gitlab
project.
So
I'm
already
sharing
my
screen,
showing
our
planning
issue
for
1311
and
we've
been
using
themes
lately
and
so
speaking
to
the
theme
in
this
milestone.
We're
going
to
be
focusing
on
items
that
improve
developer
workflow
with
our
code
quality
feature
and
specifically
we're
going
to
focus
on
the
code
review
portion
of
that
workflow
with
a
couple
of
items.
A
A
common
theme
that
we've
heard
from
developers
is
that
it's
hard
to
know
what
to
pay
attention
to.
In
a
merge
request,
when
it
comes
to
the
code
quality
and
specifically
it's
hard
to
find
violations
that
actually
need
fixing.
So
to
address
this,
we
have
one
small
iteration
and
an
mvc
issue.
So
two
separate
issues
of
a
new
feature
in
the
milestone.
A
So
a
small
implementation
issue
is
just
sorting
violations
by
severity
or
do
that
in
the
two
places
the
code
quality
violations
already
show
up
today
within
the
merge
request
widget
if
you're
looking
at
it
there
and
within
the
pipeline
page
view
so
you'll
see
the
highest
severity
issues.
First,
things
that
you
should
probably
address
and
they
won't
be
lost
in
a
list
of
35
pages
of
violations
that
you
might
have.
A
B
So,
let's
let
me
start
sharing
the
screen
and,
as
you
know,
this
quarter
we're
working
together
with
products
on
a
kr
to
increase
the
system,
usability
scale
score
of
gitlab
to
72.5,
if
I'm
not
mistaken,
and
we're
working
on
improvements
around
visibility
of
system
status
and
also
system
performance.
So
this
is
a
way
for
us
to
understand
the
overall
ability
of
a
product
and
to
track
changes
over
time
testing.
As
james
just
mentioned,
we
are
contributing
to
these
improvements
towards
the
merger
quest
widget.
B
The
first
one
show
a
file
has
code
quality
data
on
merge,
request,
diff
view
it's
around
adding
a
batch
in
the
in
the
merge
requests
for
files
that
modified,
and
that
has
changed.
They
have
changed
in
the
code
quality
violation.
This
will
give
users
a
quick
way
to
see
how
new
code
quality
violations
impact
the
overall
project.
B
So
in
this
issue,
let
me
quickly
show
you
the
ui,
it's
a
very
small
change
that
we
can
iterate
later
on
and
we'll
add
at
a
glance,
a
ui
item,
ui
component,
letting
users
know
that
hey
this
file
here
has
been
updated
and
the
number
of
quality
validation
has
changed.
B
So
next
up,
we
have
code
quality
in
the
div
merge
request.
It's
a
highly
requested
feature:
we're
looking
to
enable
users
to
see
the
code
violations
in
the
prior
to
accepting
the
merge
requests.
So
this
is
the
prototype
ui.
Let
me
zoom
in
so
you
can
see
we'll
be
adding
this
well
icons,
these
ui
components
similar
to
what
we
are
displaying
today
in
the
secure
widget,
so
that
users
have
a
clear
and
visible
way
to
identify
vulnerabilities
in
the
code.
B
So
when
you
hover
you'll
be
able
to
see
that
it's
a
code,
quality
alert
and
the
type
major
if
music
simply
blocks
the
code
and
then
users,
when
they
click
they'll,
have
the
ability
to
see
a
modal
see
the
file
in
the
for
description
of
what
this
vulnerability
looks
like.
So
we
have
a
full
implementation
issue
schedule
for
14.1.
You
can
see
this
the
depth
issue
with
all
dui
added
here
and
how
the
code
coverage
types
will
affect
the
interface,
so
I'm
going
to
pass
it
over
back
to
james.
B
A
I
am
really
excited
about
this
feature
because
it'll
show
you
within
your
change,
what
you've
actually
introduced
or
what
is
around
your
change.
That
is
a
code
quality
violation.
So
you
have
that
context,
so
you
can
go
back
in
and
change
things
that
you're
familiar
with
to
improve
the
quality
of
the
overall
project
without
digging
into
files
you
haven't
seen
in
years
potentially
so.
The
last
thing
I
want
to
touch
on
is
a
problem
that
we've
heard
about
with
the
changes
with
docker
hub
and
the
rate
limiting
the
code.
A
Quality
jobs
are
really
ramping,
folks
up
ramping
up
the
amount
of
times
that
you're
hitting
docker
hub.
So
when
I
help
address
that
in
this
milestone,
making
it
easier
easier
to
leverage
the
code,
quality
or
code,
climate
image
variable
and
the
code,
climate
version
environment
variables,
so
you
can
utilize
internal
repositories
or
mirrors
to
mirror
those
docker
images,
so
you're
not
having
to
download
those
containers.
A
Every
time
you
run
the
scan,
which
is
the
prototypical
or
the
the
default
behavior,
it
should
make
the
scans
run
faster
and
reduce
the
number
of
times
that
you're
hitting
that
docker
hub
limit.
Potentially
so
as
always,
we
welcome
feedback
through
discussion
on
these
items.
This
video,
you
can
always
email
me
at
jheimbuk
gitlab.com
about
these
are
other
issues
in
our
testing
backlog.
Thanks
so
much.