►
From YouTube: Verify:Testing 14.3 Milestone Refinement Kickoff
Description
Walkthrough of the 14.3 planning issue focusing on the theme of the milestone (artifacts!) and how we'll be improving some MR Widget functionality in design during the milestone. The planning issue can be found here: https://gitlab.com/gitlab-org/ci-cd/testing-group/-/issues/63
A
Hey
team:
I
wanted
to
walk
through
our
14-3
planning
issues.
We
care
of
refinement
this
week
for
this
milestone.
So
the
big
thing
to
note
this
milestone
happens
during
contribute,
so
we're
gonna
likely
be
slimming
down
what
I'm
going
to
talk
about
today
as
we
get
closer
and
we
understand
what
the
size
of
these
things
are
and
the
efforts
involved.
I
haven't
updated
our
capacity.
We
didn't
have
a
great
14
one,
we're
all
taking
some
well-deserved
time
off
and
have
some
big
stuff
on
our
plate.
No
worries
there.
A
So
as
we
talk
about
the
theme
and
the
milestone,
it's
really
about
artifacts
artifact
maintenance,
focusing
on
delivering
better
outcomes
to
users
when
artifacts
are
created
by
making
sure
we're
reporting
the
right
size
of
what's
being
stored,
deleting
those
things
as
soon
as
possible
when
appropriate,
really
keeping
them
only
when
they
should
be
and
parsing
them
faster
on
upload.
So
we
have
a
few
issues
related
to
that.
A
Some
of
the
key
ones
here,
though,
are
recalculating
all
artifact
size.
Writing
a
script
to
do
that,
to
make
sure
things
are
done
correctly
and
that
all
of
our
artifacts
are
actually
being
reported
correctly
about
how
much
their
space
they're
taking
up
and
then
destroying
projects
on
time
when
something
ages
out
is
taking
a
while,
if
there's
a
lot
of
artifacts
and
choices
associated
with
it,
to
get
it
all
deleted.
A
So
we
need
to
focus
in
and
execute
on
that
there's
also
a
couple
of
issues
I
don't
have
them
listed
here
around
the
parser
for
coverture
files.
We
have
one
that
includes
an
mr
from
a
customer
to
increase
the
limit,
but
we
also
have
one
to
implement
the
saks
parser
for
the
cobra
tour
parser.
This
should
allow
much
larger
sizes
and
resolve
that
customer's
problem.
So
we'll
probably
want
to
focus
on
the
saks
parser
first
and
then
do
some
performance
testing
with
the
larger
files
the
customers
already
provided.
A
Hopefully
we
can
get
them
involved
in
that
as
well,
and
then
the
last
one-
and
this
is
really
a
stretch-
is
the
test
execution
summary
data
for
projects.
So
this
is
going
to
be
a
data
point
for
that
project.
Quality
view
that
we're
working
on
solution,
validation
on
now,
it's
something
that
we
should
generate
we're
going
to
need
it,
even
if
our
validation
takes
us
a
different
direction.
We've
validated
that
this
data
that
shows
up
in
the
test
report
is
valuable
to
users.
They
don't
want
to
dig
into
pipelines
to
get
it.
A
So,
even
if
our
solution
that
we
have
today
is
that's
not
implemented
having
this
data
available
to
us
that
we
can
make
available
through
graphql
or
the
api
is
a
positive
thing
for
us,
so
we
should
go
and
implement
that
endpoint,
but
that
is
a
stretch
we
have
a
ton
of
artifact
work
in
front
of
us.
I
also
want
to
focus
on
the
design
issues.
The
ux
team
is
kicking
off
right
now
doing
a
bunch
of
design
around
mr
widgets,
so
I
just
pinged
hayana
in
this
issue.
Performance
changes
as
a
percentage.
A
This
applies
to
or
is
really
focused
in
on
what
we
call
the
browser
performance
experience.
The
user
in
this
case
wrote
their
own
performance
report
and
is
using
it
that
way,
but
still
we
know
that
we
know
that
these
are
integers.
We
can
run
that
or
run
that
math
do
that
calculation
understand
it's
something
increase
or
decrease
and
report
that
so
we're
going
to
try
to
loop
that
in
to
part
of
that
redesign
and
that
will
be
happening
with
the
design
implementation.
A
That
would
happen
in
a
later
milestone,
I'll
keep
working
on
refining
the
planning
issue.
If
you
have
questions
go
ahead
and
drop
a
comment
on
it,
I
will
put
a
link
into
the
youtube
video,
as
well
as
into
slack
or
drop
a
comment
on
the
youtube,
video
and
I'll
go
try
to
take
a
peek
at
that
later.
Thanks
cheers.