►
From YouTube: GitLab 14.0 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
heimbach,
the
product
manager
for
the
testing
group
in
the
verify
stage
of
gitlab
today
I'll
be
previewing
work.
The
team
will
be
doing
in
the
upcoming
14.0
milestone
you'll,
find
a
link
to
the
14.0
kickoff
page
for
gitlab,
with
links
to
these
items
in
the
verify
stage
direction
page
that
has
the
direction
of
all
of
our
future
work
in
the
comments
below
the
video,
and
you
can
always
reach
me
at
jheimbuk,
at
gitlab.com
or
through
comments
on
these
issues
or
any
issue
with
the
group
testing
label
in
the
gitlab
project.
A
So
I'm
sharing
with
you
today
already
the
fortino
planning
issue
and
in
140
the
team
is
really
focused
on
delivering
several
breaking
changes
that
we've
previously
announced
in
some
of
our
release
posts.
Some
of
the
key
ones
for
us
are
a
rename
of
the
default
browser
performance
testing
job
to
better
allow
for
the
load,
performance,
testing,
job
to
work,
update
to
the
code,
climate
rubocop
engine
by
default,
we're
working
on
a
change
to
avoid
duplicate
pipelines
and
merge
requests
by
default.
A
This
is
a
change
in
the
workflow
rules,
in
conjunction
with
our
friends
in
ci,
and
an
update
to
the
ruby.gitlab
ci
yaml
to
always
use
the
latest
instead
of
the
hard-coded
2.5
version
of
ruby.
But
breaking
changes
aren't
all
that
we're
working
on
as
previously
announced.
The
team
is
working
on
several
features
to
improve
the
code
review.
A
Experience
like
iterating
on
the
code
quality
and
mr
diff
feature
to
show
the
inline
annotations,
not
just
at
the
file
level
that
there
are
code
quality
violations
and
working
on
can
being
able
to
configure
restriction
of
coverage
through
the
merge
request.
Approval
rules
so
that'll
be
available
to
all
tiers
from
core
through
to
ultimate
and
then
we're
also
working
with
a
member
of
the
community
on
a
better
way
to
retrieve
up-to-date
container
images
for
the
code
quality
scan
so
you're
not
hitting
limits
on
docker
hub
if
you're
set
up
for
the
free
account
and
then.
A
Finally,
I
want
to
mention
that
the
testing
group
is
handing
off
the
code
quality
category
to
the
static
analysis
group
in
the
secure
stage
as
the
feature
roadmap
and
the
customer
expectations
around.
That
experience
are
just
much
better
aligned
with
the
work
that
they're
already
doing
so.
This
will
allow
the
testing
team
to
increase
our
focus
on
bringing
performance
testing
earlier
in
the
pipeline,
so
shifting
that
left
for
a
faster
feedback
experience
for
a
developer
by
enhancing
the
feature
sets
in
load
performance
and
browser
performance
testing.
A
We
look
forward
to
hearing
from
the
wider
community
about
what
problems
we
should
address
first
there,
in
addition
to
the
immediate
roadmap
that
we
have
set
forth.
As
always,
I
welcome
feedback
through
discussion
of
these
issues.
This
video
or
you
can
always
email
me
at
jheimbuck
gitlab.com
about
these
or
any
other
issues
in
our
backlog.
Thanks.