►
From YouTube: 2022-06-09 Working Group: Merge Request Report Widgets
Description
Weekly call for the working group Merge Request Report Widgets
Agenda:
https://docs.google.com/document/d/1bcch8UUkwmgEHFolTWDrQFJtUiiXlv_yQFAGwSSDSUE/edit
A
And
we're
live
yet
another
weekly
meeting
for
the
merge
request
report
widgets
working
group.
Thank
you
so
much
for
coming
and
I'll
go
right
into
the
checklists.
So
remember
we
did
this
a
while
ago.
We
have
a
checklist
at
the
beginning
of
the
agenda.
This
is
just
to
make
sure
that
we're
all
up
to
date
with
what's
happening
with
the
features
and
everything
so
the
blockers
solved.
Yes,
we
don't
have
any
blockers
to
turn
it
on.
A
I
have
an
update
down
below,
so
I
can
talk
about
the
final
checks
feature
flag,
enabling
prod
no
not
yet
feature
flag
enabled
by
default.
Also,
no
working
group
wrap
wrap
up.
The
widgets
have
not
been
released
yet
and
the
documentation
review
then
complete.
A
I'm
going
to
say
no
and
I'll
explain
why.
Why
a
little
bit
below
any
questions
there
before
we
go
on.
A
Okay,
so
well
sorry,
I
actually
thought
these
were
the
announcements.
So
I
have
a
couple
of
announcements.
A
First,
is
that
the
final
rollout
is
ongoing
and
phil
is
doing
the
final
checks
he's
picking
all
the
dris
and
expecting
to
hear
back
from
from
everyone.
We
are
expecting
to
start
turning
on
the
feature
flag
in
production
for
the
specific
projects
by
monday.
A
That's
monday,
the
13th
of
june
I'll
be
pinging
each
missing
dri
on
slack
after
this
call,
so
that
we
can
have
a
couple
days
before
they
jump
on
it,
there's
a
couple
of
like
missing
approvals
and
if
they
don't
hear
back
we'll
just
do
a
little
quick
check
to
see
if
they're
behind
their
own
feature
flag
and
if
they
are
we'll
proceed
without
their
okay,
but
hopefully
we'll
get
there.
They're
they're,
okay,
yeah
any
questions
on
that.
B
I
think
sorry
I
was
going
through
that
list
and
I
still
need
to
kind
of
check
off
license
compliance
license.
Compliance
has
its
own
feature
flags.
I'm
not
worried
about
that.
I
just
need
to
verify
that
the
flag's
working
as
expected,
so
that
you
know
just
when
it's
still
showing
so
I'm
trying
to
find
the
agenda.
B
My
session
decided
to
expire.
That's
where
they
go,
get
my
phone
for
the
two
factor,
but
the
the
demo
project
we
have
behind
a
flag
is,
I
believe,
in
production.
Does
anyone
know
if
there's
license
compliance
on
there
or
should
I
spin
up
a
license
compliant
cause,
I'm
trying
to
see
the
license
compliance
widget
in
context
of
mr
with
other
widgets,
because
all
right
so.
A
So
we
appreciate
that
for
the
new,
so
yeah,
if
you
could
do
that
until
monday,
that
would
be
great
and
just
drop
us
drop
the
line
on
the
on
the
issue
once
we're
good
to
go,
and
if
you
want
to
update
those
those,
mr
demos
they're
still
going
to
be
relevant
for
ongoing,
because
it's
important
to
have
a
couple
of
mrs
that
list
all
of
the
widgets,
because
not
every
project
is
going
to
have
all
the
widgets.
A
A
B
For
security,
we
have
a
security
reports
project
that
has
a
yaml
file
that
uses
like
just
pre-generated
json
reports.
So
I'm
going
to
try
to
put
an
mr
out
to
that
project
that
pulls
in
all
those
security
jobs.
Okay,
to
get
the
widget
showing.
A
C
Thanks
quick
question
on
this:
fernando
because
the
code
quality
widget
is
basically
in
the
exact
same
state,
it
is
tested
just
purely
but
not
with
interaction.
With
the
same
thing
we
could
team
up
for
this
since
it
just
mentioned
the
security
reports,
project
they'd
probably
be
kind
of
the
same
thing.
So
let's
try
to
not
duplicate
our
work
there
and
just
you
know.
B
Yeah
we
could
do
async,
sorry,
let's
sync
up
and
swag
after
this
meeting
sure.
A
Thanks
guys
right,
so
that's
the
the
first
announcement.
A
Where
are
we
right?
The
next
one
is
about
the
the
the
documentations
remember.
One
of
the
things
we've
talked
about
is
one
of
the
last
steps
to
close
off
this
work.
This
working
group
is
to
have
the
documentation,
up-to-date
and
reflective
of
the
work.
We've
done,
there's
some
guidance
for
whoever
wants
to
contribute
new
feature,
new
widgets
and
everything.
A
So
we
want
to
ensure
that
that's
up
to
date,
so
I
just
talked
to
phil-
he's
told
me
that
they
have
updated
the
front
end
docs,
the
front-end
code,
docs,
and
every
time
there
was
a
change
that
the
docs
were
also
up
to
date.
So
I
feel
like
that's
okay,
so
what
I'll
be
doing
I'll,
be
requesting
a
technical
writer
to
do
a
review
and
give
us
sort
of
like
some
hints
about
what's
missing
what
could
be
added
there
and
then
we'll
go
from
there.
A
Cool
discussion
items
so
gian
brought
something
up
on
slack,
I
think,
or
no
on
the
rollout
issue
about
cleanup.
So
once
we
roll
these
out
to
production,
we
will.
There
will
come
a
time
where
we
need
to
remove
the
code.
Sorry,
there
will
come
a
time
where
we
need
to
remove
the
code
from
the
previous
widgets
and
everything.
So
we
wanted
to
have
a
quick
chat
about
how
we
were
thinking
about.
A
We
should
be
doing
this
so
from
what
we're
expecting
from
terms
of
time
frame
we're
starting
to
roll
it
out
in
15
1
to
production,
we're
probably
going
to
only
default
it
in
15
2.
So
we
cannot
remove
it
earlier
than
15
2..
So
at
the
earliest,
once
the
feature
flag,
the
global
feature
flag
is
removed.
All
the
old
code
needs
to
be
removed,
so
that's
probably
going
to
happen
at
least
on
15
3
or
after
does
anybody
have
any
thoughts?
How
we
should
do
this.
A
C
C
Yeah,
I
can
only
speak
for
code
quality,
but
I
don't
expect
any
major
conflicts
or
interactions
with
other
parts
of
the
copa
is
that
should
be
pretty
straightforward.
Okay,.
A
Okay,
so
I'll
pass
that
message:
do
you
have
any
thoughts
for
them.
A
A
A
Okay,
that's
great
and
we'll
go
from
there
and
I'll
relay
that
plan
for
phil
and
we'll
just
follow
that
thanks
fernando
you
have
the
next
point.
B
Yeah,
so
I
added
this
last
also
because
this
is
not
a
blocker.
It's
not
related
to
the
rollout,
it's
more
enhancements
for
license
compliance
and
eventually
enable
the
license
compliance.
So
this
milestone
service
added
some
enhancements
to
our
polling
logic
and
just
a
quick
summary
there's
more
to
allow
for
to
continue
pulling
an
endpoint
until
data
is
available.
So
that's
in
that
was
for
all
that
work
was
for
the
collapse
standpoint
right.
B
We
have
that
we
have
kind
of
the
ability
to
provide
a
resolved
promise
to
the
collapse
and
expanded,
and
the
intent
was
that
the
collapse
state
was
supposed
to
be
a
summary
now
with
these
widgets
it
we're
not
consistent
in
the
way
that
some
widgets,
what
they
do
actually
is
when
they
have
polling
enabled.
B
So
there
are
a
couple
of
them.
Let
me
share
some
code
here
screen
so,
for
example,
security
reports-
I
think
maybe
terraform
what
they
do
actually
is
they
only
fetch
the
collapse
state
right.
So
there's
the
ajax
request
and
then
a
lot
of
them.
What
they
actually
do
is
for
the
expanded
state.
It's
the
same
data.
So
what
they
do
is
they
kind
of
just
resolve
a
promise
and
return.
They
derive
the
full
data,
the
expanded
date
data
off
the
collapse
data.
B
Now
the
reason
they're
doing
that
is.
We
only
have
one
endpoint,
I'm
assuming
for
those
widgets
right
now
license
compliance.
Is
this
special
case
now,
where
it's
we've
kind
of
followed
the
spec?
I
guess
as
it
was
originally
intended,
as
that,
the
idea
that
you
would
have
one
endpoint
for
the
collapse
state.
You
know
much
compact
data
just
enough
for
the
summary
and
then
the
expanded
state,
which
would
have
the
much
more
detailed
heavyweight
response
to
populate
the
widget,
and
we
have
two
endpoints.
B
So
the
problem
was
that
the
pulling
enhancements
were
only
done
for
the
collapse
state.
So
I
have
a
work
in
progress,
mr
to
to
to
add
polling
to
the
expanded
state.
The
problem
is
that
that
expanded
state
relies
on
the
response
headers,
but
when
we
have
the
in
the
cases
for
the
widgets
that
derive
the
full
data
from
the
collapse
data,
we're
not
we're
just
resolving
a
promise,
you
don't
have
any
type
of
response
or
any
header
set.
B
B
I
think
it
would
be
nice
to
have
the
granularity
to
kind
of
enable
that
pulling
logic
for
the
collapse
or
expanded
endpoints,
and
I
was
going
to
implement
that
logic
accordingly,
as
opposed
to
try
to
piggyback
off
of
that
one
global
enable
pulling
flag,
because
right
now,
if
we
just
keep
enable
pulling,
we
would
be
basically
saying
if
we
turn
it
on
we're,
going
to
pull
both
endpoints,
but
then
there's
some
windows
that
don't
actually
hit
two
real
endpoints.
B
They
just
kind
of
derive
data
from
the
first
one,
so
it
kind
of
gets
into
this
kind
of
I
don't
know.
I
I
feel
like
having
the
granularity
to
toggle
pulling
for
expanded
or
collapsed
might
be
more
beneficial
than
just
having
it
trying
to
attempt
to
pull
both
when
both
widgets
aren't
actually
hitting
two
endpoints.
I
don't
know
this.
I
mean
this
is
probably
more
a
question
for
phil,
but
I
don't
know.
A
But
I'm
glad
you
brought
I'm
glad
you
brought
it
up,
because
I
feel
like
that's
an
architectural
decision
that
could
have
impact
later
on,
especially
for
this
cases
it
makes
sense,
but
as
we're
having
more
widgets
come
on
board,
there's
probably
gonna
be
other
use,
cases
other
and
then
yeah
as
you
were
talking.
I
was
already
thinking
yeah
if
I
needed
to
have
such
a
big
payload
on
the
expanded
side,
I'll
probably
just
scram
it
in
the
one
used
by
the
collapsed
one.
A
So
we
don't
want
to
do
that
yeah
as
long
as
it's
an
additional
option,
so
that
this
is
the
default
behavior
or
something.
Then,
if
you
need
this,
you'd
have
the
second
option.
I
feel
like
that's.
Yes,.
B
Yeah
yeah
yeah:
that's
why
I
was
going
for
adding
that
new,
that's
good
yeah.
The
only
reason
I
wasn't
to
roll
it
into
the
one
enable
pulling
one
is
because
then
I
would
have
to
go
back
and
re-factor
all
the
widgets.
You
know
what
they
return
for.
The
full
data
is
only
like.
You
know
the
result,
data
from
the
promise.
I
need
to
then
incorporate
the
response
and
then
move
the
data.
B
That's
returned
now
into
a
nested
like
you
know
the
data
property
can
I
need
the
full
response
and
then
the
data
associated
to
that
response,
and
that
would
be
a
much
more
involved
refactor
and
it
kind
of
changed
the
architecture
of
it
and
then
with
the
rollout,
even
though
this
would
be
an
enhancement,
it
just
kind
of
would
blow
this.
Mr
a
lot
bigger,
so
the
path
of
leaf
the
resistance
was
supposed
to
introduce
a
new
field.
B
What
I
may
do,
though,
as
far
as
mr
because
it's
easy
to
rename
things
in
this
case-
is,
I
might
dis,
differentiate
from
enable
pulling
to
maybe
rename
that
to
enable
collapse
pulling
to
and
then
having
enabled
expanded
polling.
But
I
will
ping
phil
on
this
to
kind
of
get
his
feedback
before
I
get
too
committed
to
an
approach
and
that's
basically,
it.
A
No,
that
sounds
good
to
me.
From
my
perspective,
I
was
thinking
something
yeah.
I
think
the
the
bottom
line
is
for
some
widgets.
This
approach
of
sharing
makes
sense,
but
there
is
a
size
of
which
the
payloads
start
to
make
a
difference
where
it's
too
large
of
a
payload.
We
want
to
have
them
split
by
having
one
for
the
collapse
and
one
for
the
things
so
yeah
make
sense,
go
forward
with
that
and
then
put
forward
up
for
for
phil
to
to
weigh
in.
B
C
Speed
one
thing
that
just
crossed
my
mind
while
we're
speaking
about
this
is
for
you,
andre
because
of
the
testing
of
some
of
those
widgets
insecure
in
collaboration
with
other
extensions
just
for
me,
it
would
be
significantly
easier
to
actually
test
this
on
staging,
but
that
would
include
enabling
the
large
flag
or
the
global
flag
on
staging
for
at
least
a
one
project.
Would
that
be
okay,
or
is
that
a
big?
No?
No.
At
this
point.
A
I
would
recommend
it
what
we've
done.
What
we've
done
in
the
past,
especially
with
even
for
performance
issues,
is
we
have
specific
projects
with
specific
flags
enabled
and
disabled?
We
did
that
for
the
source
code,
rollout
of
an
improvement
under
on
the
repository,
and
that
was
really
beneficial
to
have
one
endpoint.
A
Sorry,
one
project
with
the
feature
enabled
one
project
with
a
feature
disabled
and
then
we
had
site
speed,
running
on
both
of
them
and
we
could
compare
the
metrics
before
we
roll
them
out.
So,
yes,
I
would
recommend
having
that
in
staging.
You
might
even
want
to
turn
it
on
for
more
because
we
still
have
the
the
example,
mrs
that
we
have
they're
in
production.
A
We
have
the
front
end
playground
gitlab,
mr
I
mean
you
can
still.
B
A
C
A
Awesome
right
and
that's
all
for
the
agenda.
Do
we
have
any
other
thoughts?
Topics
concerns
praise,
yeah.
I
would
like
to
share
praise
for
everybody.
That's
been
involved
in
this
final
stages.
I
think
it's
it's
we're
getting
close
to
it,
we're
very
close,
we're
very
close,
but
I
like
to
see
movement
and
it's
we're
getting
there.
So
I
I'm
feeling
good
and
now
it's
going
to
be
the
big
bang
where
we
see
what
people
think
of
this
and
for
context,
there's
been
a
lot
and
marcel.
A
I
know
you
know
about
this,
but
there's
been
a
lot
of
changes
on
the
merger,
guys
page
and
you
as
of
course,
as
merger
quest
users
as
well,
and
we're
just
discussing
this
earlier
with
phil,
where
we
got
a
slew
of
changes
in
the
merge
request.
This
will
just
be
yet
one
more
but
they're
all
lining
up
into
this
set
of
releases.
A
We
have
the
merge,
request,
merge,
widget
restructuring,
just
a
little
merge
bit,
it's
being
reworked,
and
people
are
raving
about
the
results
of
that
we
have
the
merging
class
beautifying
ui
and
the
nav,
and
then
the
sidebar
that's
coming
in
too,
and
now
the
widgets
are
coming
in.
It's
like
a
new
experience,
so
I
cannot
stress
enough
how
important
this
working
group
has
been
to
the
code
review
experience
as
a
host
of
everyone
else's
contributions.