►
From YouTube: 2022-08-04 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
All
right
we
are
live,
welcome
to
yet
another
call.
Another
weekly
call
for
the
working
group
for
the
merge
request,
report,
widgets
and
savage.
You
have
the
first
point.
A
B
Yeah
thanks,
so
the
idea
of
of
walking
through
the
code
is
because
we
need
so
I
submitted
emr
well,
the
core
logic,
at
least
the
skeleton
for
the
refactoring
of
the
mrvideo
fernando
revealed
it,
and
so
we
asked
for
feedback
to
the
team
and
we
so
far
we
received
little
feedback.
B
Therefore
the
idea
was
to
walk
through
the
the
changes
show
them
here
and
then,
if
anyone
at
least
watches
the
video
afterwards,
they
can
see
what
has
been
done
so
far.
B
B
B
So
what
I
did
is
so
I
created
here
like
well.
First
of
all,
let
me
tell
you
that
if
you
check
the
mr,
I
have
left
plenty
of
comments
to
describe
the
the
steps
and
the
thinking
behind
this,
but
basically
I'm
just
gonna
do
something.
I'm
not
gonna
go
through
the
changes
here
because
it
may
be
complicated,
so
I'm
just
gonna
go
here
and
yeah
and
walk
through
the
code
to
show
how
it
works.
So
we
have.
B
Yeah,
so
we
have
two
widget
apps.
This
is
basically
where
we
register
our
applications,
so
one
is
for
for
the
ce
version,
the
other
one
is
for
the
ee
version
and
the
ce
version.
As
of
now,
it's
it's
empty
because
I'm
developing
the
the
the
ee
version
of
the
security
reports-
and
here
there
is
a
computed
property,
a
returns
array.
It's
basically
it's
the
name
of
the
components
that
are
going
to
be
mounted
and
then
the
widget
component
takes
care
of
it
widget
app
this
one.
B
B
This
is
the
security
reports,
so
we
have
here
two
methods
that
the
version
one
consumers
should
be
familiar
with:
fetch,
expanded
data
and
then
fetch
collapse
data.
And
then
we
pass
that
to
dmr
widget
component
as
a
handler,
and
then
we
pass
the
data
as
a
view
model
so
that
the
dmr
widget
it.
Basically,
it
handles
fetching
the
data
displaying
the
errors.
B
So
we
just
passed
the
error
text
and
then
the
loading
text,
and
then
that
logic
is,
is,
is
handled
within
the
container
and
afterwards,
since
this
is
a
view
model,
it's
it's.
Basically,
it
emits
an
event
and
then
once
the
data
is
fetched,
we
we
have
the
updated
version
of
the
data,
so
it's
basically
collapsed
and
expanded.
So
if
you
check
here,
it's
just
collapsed
and
extended
a
typo
here,
expanded
data.
B
As
for
the
rest,
so
I
think
one
thing
that
is
worth
mentioning
is
that
this
supports
slots
so,
for
instance,
the
summary
text
here
I
can
provide
a
summary
slot
and
then
I
can
do
whatever
I
need
to
do
same
goes
for
the
content,
but
for
the
other
widgets,
which
are
using
the
the
more
the
extension
api,
they
can
also
pass
the
the
the
object
or
like
the
content,
for
instance
like
this
and
skip
the
slot,
so
they
can
provide
the
javascript
object
that
we
do
provide
today
with
the
version
one
and
in
the
future,
mrs
it's
gonna
be
handled,
so
there
shouldn't
be
too
much
refactoring
for
for
those
digits.
B
So
basically,
this
is
the
idea
and
then
the
rest
is
just
tiny
details.
I'm
not
going
to
go
through
them,
but
this
is
how
I
use
I
consume
the
the
dmr
widget.
This
is
how
it's
going
to
look
like.
So
if
you
have
any
feedback,
the
vmr
link
is
in
the
agenda,
so
please
provide
your
feedback
over
there.
Otherwise,
I
think,
for
now
we
can
move
forward
with
that.
C
I
was
just
going
to
add
that
I
guess
this
is
partly
a
question,
but
it's
the
intent
here
also
over
time
to
build
up,
for
example,
a
set
of
view,
components
that
can
be
used
in
each
of
these
slots.
So,
for
example,
like
child
components
that
are
conformant
to
the
design
spec.
C
So
we
don't
re-implement
the
wheel
every
time,
but
we
have
a
core
set
of
components
that
we
can
do
and
if,
for
some
reason
we
kind
of
need
an
escape
hatch,
we
can
insert
whatever
we
want
into
the
slot,
and
then
we
would
conform
that
one
off
by
in
the
code,
reviews
making
sure
it
kind
of
conforms
to
the
spec.
B
Yeah,
absolutely
that's
a
very
good
point.
We
had
a
recent
chat
with
with
jeremy,
and
so
the
idea
is
that
for
common
things
like,
for
instance,
there
is
a
banner
that
can
be
reused
so
that
that's
going
to
go
here
in
the
widget.
We
can
have
a
components
section
and
then
we
can
use
that
one.
B
So
it's
going
to
be
banner.view
and
then
we
can
reuse
that
so
it's
already,
it's
already
gonna
have
the
design
skilled
and
then,
when
we
had
the
chat
with
with
jeremy,
so
there
is
a
gitlab
ui
component.
That's
gonna
come
up
in
the
future,
which
is
going
to
be
like
the
widget
and
we
are.
The
widget
is
going
to
consume
that
gitlab
ui
component,
which
is
obviously
which,
which
also
is
going
to
have
its
own
components.
B
So
yes,
in
short,
the
answer
is
yes,
we
are
going
to
reuse
components
here
so
for
four
common
things.
If
something
is
too
specific
to
the
widget,
then
they
can
they.
The
developer
can
put
that
in
the
widget's
own
folder.
C
No,
that's
awesome,
and
thanks
for
so
much
for
leading
these
efforts,
I
think
after
the
v1
rolled
out
it
gave
us
the
time
to
to
use
it
and
kind
of
see
the
pros
and
cons,
and
I
think
this
solution
will
kind
of
mitigate
a
lot
of
those
problems
we
had.
Is
there
I
don't
know,
is
there
a
plan
across
groups
to
migrate
over
to
version
two
or
is
it
because
the
way
I
looked
at
it
this
this
working
group
and
initiatives
were
twofold
right
number
one
was
design
consistency.
C
A
The
well,
I
agree,
I
think
we
should
only
have
one
implementation
when
this
proposal
from
savage
came
forward.
We
had
that
discussion
and
I
I
I
totally
see
that
secure
the
security
widget
is
the
first
one
to
fully
ex
use
that
update,
but
the
idea
is
to
then
migrate,
all
the
other
ones.
From
what
I
understood.
A
It
wouldn't
be
a
heavy
lifting
of
to
move
each
individual
widgets
now
and
then
we
can
discuss
whether
we
can
leave
that
up
to
the
dris
to
be
scheduled
or-
or
I
don't
know,
if
savage,
you
have
some
capacity
to
rewrite
them.
So
since
you
have
the
the
knowledge,
but
for
the
first
time
I
would.
I
would
be
okay
in
accepting
the
implement
the
existence
of
two
implementations
of
the
template,
rendering
for
the
time
being.
A
But
but
ideally
we
would
be
unifying
that
and
deprecating
the
first
version,
so
the
methods
would
be
going
away
and
we'd
be
all
having
the
widgets
in
the
version
two
and
then
documentation
will
be
updated
and
everything
so
now
who?
Who
will
take
up
on
that
task
of
rewriting
the
v2,
the
all
widgets
to
v2?
That's
still
up
to
be
discussed.
I
guess
I'm
guessing
the
priorities
to
get
the
v2
out
the
door
so
that
we
can
ship
the
secure
widget.
But
after
that,
it's
kind
of
like
up
to
be
decided.
A
I
guess
from
that
perspective
and
I'm
I'm
stepping
back
a
little
bit.
I
think
it's
important
to.
We
are
wrapping
up
the
working
group
because
the
goals
have
been
achieved.
The
exit
criteria
have
been
achieved,
but
we
won't
be
going
away
like
code
review
will
still
be
around
we'll
also
be
available
to
answer
requests
and
everything
like
that.
But
then
the
dris
also
have
the
responsibility
to
maintain
their
code
base
of
the
widgets.
A
B
Can
I
jump
in
here
sure
so
yeah?
So
as
of
now
the
the
the
what
you
have
reviewed?
It
doesn't
have
that
functionality,
but
probably
I
missed
it
mentioning
that,
but
so
I'm
build.
What
I
have
in
mind
is
building
this
v2
backwards
compatible.
So
when
you
pass
the
the
extension
api
configuration
that
we
passed
today,
we're
gonna
have
a
component
in
the
widget
which
renders
that
data.
So
it
should
just
it
should
just
be
moving
the
register.
B
Extension
part
from
the
from
the
mr
digit
options
to
the
and
then
create
this
the
same
component
using
the
dmr
visit
component
and
pass
the
same
data,
so
it
should
in
theory
there
shouldn't
be
any
need
for
for
refactoring
the
logic
because
we're
gonna
we
we're
gonna
support
the
extension
version,
one
at
the
extension
api
version.
One
anyways.
C
Okay,
yeah
thanks
for
that
detail,
so
it
sounds
like
we'd
be
able
to
to.
Essentially
you.
B
Just
pass
the
property
yeah
exactly
just
pass
down
the
props
and
it
should
handle
the
version
one
as
well,
because
that's
also
required
also
for
a
right
now.
There
is
an
an
ongoing
work
for
the
generic
report,
so
the
back-end
should
be
able
to
display
a
generic
report
which
doesn't
match
any
any
in
any
of
the
existing
widgets
today,
and
the
data
is
going
to
be
dynamic
and
they're
using
the
extension
api
for
that
which
we
recently
built.
So
we
need
to
support
that
anyways.
A
B
Plan,
dr
fernando
reviews,
it
feel
we're
gonna.
A
Feel
great
solid
reviews
on
the
two
rounds:
sweet
heads
up:
he
will
be
out
of
office
next
week
so
plan
for
for
that,
at
least.
So.
That's
that
all
right.
My
next
point
regarding
the
topic
of
closing
the
working
group,
because
we've
established
that
all
these
efforts
can
live
outside
of
the
context
of
the
working
group,
even
that
the
exit
criteria
has
been
satisfied.
A
I
have
been
looking
into
it.
The
the
the
version
that
has
the
new
widgets
on
by
default
has
been
delivered
to
customers.
A
A
So
with
that,
I
think
we'll
put
that
on
hold
until
until
tim's
back
tim
zalman.
When
he's
back,
I'm
gonna
brief
him
on
the
updates,
we've
done
and
kind
of
like
check
with
him,
whether
he's
supportive
of
closing
on
the
working
group
and
then,
if
so,
we'll
start
the
the
procedures
to
close
on
the
working
group.
So
I
I
do
expect
to
do
that
next
week.
I
think
I
checked.
I
think
he
will
be
back
on
the
yeah
on
the
fifth
after
the
fifth
so
after
tomorrow.
A
So
next
week,
early
on
I'll
I'll
get
I'll.
Do
my
do
my
diligences
and
start
to
get
that
conversation
going
so
that
by
thursday
we
can
provide
an
update
to
the
rest
of
the
group,
whether
we're
closing
down
right
away
or,
if
there's
anything
else,
that
he
would
like
us
to
take
care
of
any
questions.
C
Yeah
so
license
compliance
was
one
of
those
secure
stage,
widgets
that
wasn't
that
had
its
own
separate
feature
flags,
I
didn't
roll
out
with
the
global
one,
and
that
was
intentional.
That
was
intentional.
We
just
needed
more
time
we're
missing
out
some
back
end
stuff,
which
has
been
completed.
So
I'm
wrapping
up
my
testing,
but
the
plan
was
to
enable
com.
C
Prime
later
today
it's
already
been
enabled
on.com
for
the
test
project,
but
rolling
it
out
globally,
and
it
should
go
into
self-managed
this
milestone.
That
is
one
of
the
massages
security
widget.
I
think
licensed
compliance
is
the
only
other
security
one
secure
stage
one
I
forget
the
one
that
yannick
was
working
on.
I
don't
know
code
quality
was
under
secure,
but
that
was
the
only
call
out.
I
had.
A
That's
great
great
news:
yeah,
I
don't
know
which
one
that
is
either.
I
know
that
yannick
is
a
drf
for
code
quality
and
that's
basically
it.
I
think
so.
C
A
Okay,
great
news,
though
moving
forward,
then
any
other
comments
there
can
we
move
on.
A
Okay,
so
that
concludes
our
public
part
of
the
of
the
meeting
I'll
I'll
stop
the
recording
here.
If
I
can
yes,
I
can
I'll
stop
the
live
stream
here
and
we'll
carry
on
the
discussion
in
private,
because
it's
a
confidential.