►
From YouTube: 2022-05-05 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
welcome
everyone.
Yet
another
weekly
call
from
the
merch
request
report,
widgets
working
group
and
I'll
go
straight
to
the
announcements.
A
So
one
of
the
efforts
we
have
been
doing
is
to
prepare
the
rollout
of
the
of
the
feature
for
all
the
witches
to
go
out
to
go
live
in
order
to
do
that,
it
could
be
really
useful
to
have
someone
that
is
in
the
know
of
each
widget.
So
last
week
we
started
an
effort
to
identify
the
dris
for
each
one
of
the
widgets,
and
I
just
wanted
to
to
mention
that
the
progress
has
been
great
thanks.
Everyone
who
helps
coming
up
with
the
name
of
the
dris.
A
I
think
we
have
pretty
much
everyone
we're
just
closing
the
final
one,
but
just
going
to
give
an
update
that
this
is
going
to
be
committed
to
the
documentation
of
the
handbook,
not
not
necessarily
the
working
group,
because
once
the
working
group
extinguishes,
the
dris,
will
live
on
as
the
contact
people
for
those
widgets
something
happens.
The
widget
breaks
there's
an
incident
somewhere.
Somebody
wants
to
reach
out,
they
know
who
to
call,
and
even
if
you're.
So.
A
This
is
not
the
same
thing
as
being
on
call
it's
just
that
we
know
who
to
knack
and
if
you're
not
online
they'll,
probably
knock
your
team
or
your
manager
or
whoever
right,
but
at
least
they
know
more
or
less.
They
have
a
contact
person
to
check
for
this.
More
immediate
need
for
the
rollout
which
will
be
led.
Phil
will
take
care
of
like
coordinating
a
little
bit.
A
B
Sure
so
this
is
just
a
follow
up
from
I.
I
guess
I
wasn't
in
last
meeting,
but
I
was
going
to
mention
that
license
compliance
is
its
own
feature
flag.
So
the
intention
of
this
was
to
allow
the
rest
of
the
group
to
push
forward
with
releasing
all
the
other
widgets
and
licensing
clients
is
taking
a
little
bit
longer
because
it's
basically
we're
waiting
on
some
back
end
stuff
to
be
added
to
the
collapsed
endpoint.
B
So
the
idea
being
that,
if
we
so
they're
independent
flags,
so
we
can
roll
out
all
the
existing
widgets
and
then,
when
we're
ready,
we'll
toggle
it
on
for
license
compliance
and
it
looked
like
it
was
rendering
correctly.
A
follow-up
to
that
is
that,
in
the
process
of
working
on
the
widget
license
compliance
wizard
extensions.
I
ran
into
I'm
going
to
share
my
screen
here,
a
problem
where
I
guess
the
pulling
behavior.
Doesn't
we
have
an
edge
case?
Essentially
so
what
happens
is
with
enable
pulling?
B
It
looks
like
it
pulls
the
the
url
for
the
collapse
state
and
it
looks
like
behind
the
scenes.
You
know
it
will
pull
until
we
get
200
or
well.
Not
200
a
successful
status
code,
then
we
fire
the
success.
I
guess
callback
handler
and
we
run
the
code.
B
The
problem
is
that
there
are
a
lot
of
status
codes
that
quantify
as
quote-unquote
successful,
and
one
of
them
is
a
204
which
is
no
content
and,
as
far
as
I
know,
this
any
of
the
widgets
that
have
polling
enabled
well,
actually,
even
if
polling
is
disabled,
like
the
thing
is
it
it
will
for
the
license,
compliance
sorry
for
the
secure
stage
widgets
they
all
return,
204s
after
a
pipeline
run
or
during
a
pipeline.
B
While
a
pipeline
is
running
and
the
reason
for
that
is,
you
know
we
will
run
a
bunch
of
security
jobs
in
the
pipeline
and
once
the
pipeline
completes,
there's
like
a
post-processing
stage
where
the
artifacts
in
the
pipeline
are
parsed.
So
there's
this
kind
of
window
of
where
you
know
we're
getting
the
the
pipeline's
running
and
we
haven't
parked
the
results.
B
So
it's
returning
204s
and
what
will
happen
is
right
after
you
create
a
merge
request,
while
the
pipeline's
running
you'll
keep
seeing
this
loading
state
and
that's
what's
pulling
off
because
it
requests
once
if
you,
if
you
turn
on
polling,
it
will
fail
on
the
first
poll.
I
think
because
the
204
is
no
content
and
what
we
have
here
is
like
this
code.
B
Snippet
I
had
to
change,
or
this
is
a
proposal
for
making
a
change,
but
when
data
was
undefined,
you
know
we
do
object.keys
and
we
call
that
undefined
and
it
would
cause
an
exception
and
then
they
would
just
fail
silent.
While
you
would
fail,
it
would
catch
the
exception
and
then
show
this
error
state,
and
this
behavior
applies
to
all
the
secure
stage.
Widgets
the
implementation
details
for
that
are.
B
Dive
in
here,
real
quick,
so
the
ones
that
are
impacted
are
any
of
the
widgets
that
hit
these
endpoints,
which
is
pretty
much
all
the
secure
ones,
because
you'll
see
for
each
type
of
report
type
that
we
hit.
We
call
report
response
and
then
this
is
the
logic
here.
You
know
if
the
pipeline's
active
return
to
a
four
node
content,
if
it's
parsing
to
a
for
no
content,
the
only
time
it
will
show
200
with
actual
data
is
after
the
pipeline
is
completed
and
it
has
run
and
then,
like.
B
I
sorry,
I'm
kind
of
jumping
around
a
lot
here,
but
does
that
kind
of
make
sense
so
far
is
that
we
don't
handle
right
now
with
holding
enabled
204s,
and
there
are
a
lot
of
other
caveats
too,
which
is
like
we
don't.
We
have.
We
have
this
notion
of
like
a
loading
state
and
then
show
results.
You
know
a
populated,
widget
or
error.
In
reality
we
actually
kind
of
have
one
additional
state,
so
it's
the
initial
page
load
right
and
then
you'll
show
the
widget
loading
because
it
has
to
make
that
initial
requested
server.
B
At
that
point
we
don't
know
if
the
data
is
ready,
we
won't
get
a
200.,
we
don't
know
if
the
the
server
may
return
an
error
code.
We
don't
know
if
it's
going
to
return
a
successful.
You
know
204,
but
the
pipeline's
running
we're
kind
of
inferring
by
two
or
four
status
quo.
That's
that
it
like
the
pipeline's
still
running.
B
So
we
kind
of
need
in
between
state
where,
like
okay
initial
page
load,
show
the
widget
loading
like
hey,
you
know,
you
know
loading
results
and
then,
if
the
pipeline's
running
have
it
returned
and
have
it
still
keep
spinning
and
say
like
hey
pipeline,
currently
running
or
something
along
the
lines
of
like
waiting
for
pipeline
to
complete
and
parse
results?
B
And
then,
when
we
get
to
200,
then
we'll
switch
over
to
the
actually
populated
widget,
because
what
we
end
up
happening
is:
if
we
don't
do
that
and
let's
say
we
apply
the
patches
suggested
to
handle
the
204.
Basically,
what
it's,
the
patch
that
I
have,
what
it
does
essentially
is:
if
we
get
a
successful
status
code,
but
no
data,
it's
kind
of
inferring
that
you
know
we
will
just
re,
keep
polling
until
we
do
have
data.
B
So
when
we
do
have
data
and
object
that
keys
that
theta
is
greater
than
zero,
then
we'll
stop
the
pulling.
If
I
make
that
change
and
we
don't
account
for
a
different
loading
state,
what
will
happen
is
we'll
have
the
initial
page
load.
This
will
keep
showing
loading
while
the
pipeline
is
running
and
after
pipeline
is
completed,
but
we
haven't
parked
results
yet,
and
what
will
happen
is
on
the
next
poll.
B
You
know
it
will
show
no
detected
license.
Sorry,
it
will
show
on
the
200.
It'll
show
no
licenses
detected
and
then
that's
pulled.
It
will
show
the
the
updated
results
after
the
parsing.
B
A
B
Yeah,
I
I'm
trying
to
so
what
I
was
for,
and
maybe
I
could
put
like
a
rough
draft,
mr
and
then
just
you
know,
share
it
with
you
and
then
maybe
we
could
work
on
finding
something
that
works.
I
think
this
is
one
of
those
things
where
maybe
might
make
sense.
If
I
just
kind
of
put
a
proposal
like
just
a
draft,
mr
together
and
just
kind
of
like
approve
a
concept,
but
the
idea
was
that
we
have
the
you
could
specify
that
the
the
strings
right
for
the
loading
state.
B
My
proposal
is
that
we
have
another
one,
that's
kind
of
like
a
string
that
we
would
show
while
it's
getting
204s
or
well,
while
it's
a
successful
status
code
with
no
data.
The
problem,
though,
is
you
know
I
don't
know
if
204
no
content
is
standard.
Like
I
don't
know
what
that
means
in
terms
of
like
is
that
always
standard?
Is
it
commonly
accepted
at
204
means
we're
waiting
on
data?
Or
does
that
mean
you
know
something
is
completed,
but
there's
no
data
generated.
B
You
know
so
like
I,
the
behavior
is
also
dependent
on
on
what
that
means
to
us
and
that
204
no
content,
meaning
a
pipeline
is
still
running,
might
be
specific
to
how
secure
is
interpreting
that
status
code
and
not
we're
doing
it
at
git
lab.
So
the
problem
is
that
the
way
the
polling
logic
is
implemented.
B
A
B
Just
know
if
it's
successful
or
failure,
the
other.
A
A
C
Why
I
asked
it
because
I
was
about
to
say
so:
we
fixed
the
initial
book
with
the
poll
and
not
work
with
204,
and
then
I
guess
we
go
back
to
ux
and
say:
do
we
want
to
change
the
text
here
I
mean
to
me
whether
it's
passing
or
loading,
it
still
seems
like
it's
loading
and
it
don't.
You
know
where
to
change
the
text
right,
yeah.
B
Yeah
so
yeah,
so
that's
a
good
point
and
there's
a
reason
for
that.
Why
I
suggested
that
intermediate
step
and
again
that
is
a
ux
question
and
I
actually
think
some
ux
folks
here
to
get
feedback.
But
the
problem
is,
if
keep
in
mind
that
that
loading
state,
if
you
have
a
pipeline
that
runs
in
20
seconds
or
you
know
that
that's
I
mean
that
it
may
show
the
the
results
within
20
seconds.
But
what,
if
you
have
a
python,
that's
two
hours?
B
Your
pipeline
may
run
for,
let's
say
four
hours.
Let's
say
it's
gonna
keep
showing
that
spinner
like
like
what
is
this
frozen?
Is
it
just
hanging
in
there?
So
that's.
Why,
like
the
initial
page
load,
is
like
it's
more
of
a
loading
like
hey
loading,
getting
the
status
from
server
kind
of
like
that's
the
intention,
and
then
the
results
would
be
yeah.
A
The
way
I
see
that
like
what
what
we
probably
if
we
want
to
have,
I
think,
that's
a
valid
question
and
I
think
we
definitely
should
address
it.
I'm
not
entirely
sure
if
it's
the
base
widget
that
should
address
that.
If
we
think
about
it,
it's
a
204
or
whatever,
when
it's
still
preparing
it
doesn't
have
the
data.
A
If
you
want
to
present
that
information
to
the
user
that
it's
it's
ongoing,
you
would
probably
be
the
whoever
has
the
domain
knowledge
to
know
whether
it's
a
long
or
a
short
pipeline
and
then
eventually
say.
If
the
pipeline
has
started
like
more
than
15
seconds
ago
or
more
than
30
seconds
more
than
3
minutes,
you
would
show
a
different
200
result
with
the
message
saying:
the
report
is
being
computed,
it's
taking
a
while,
but
that
would
be
a
200
for
the
widget.
The
widget
only
knows
the
it's
not
ready,
yet
it's
ready.
B
B
We
all
know
that
we
already
know
that
at
the
end
point,
because
you
know
we're,
we
know
enough
to
say
it's
a
204,
so
maybe
we'll
the
solution
is
leave
the
widgets
as
they
are,
do
a
200
at
the
secure
endpoints
and
then
with
the
field.
It's
just,
you
know,
add
a
status
field
and
that
could
be
pipeline
running
and
then
from
there.
We
could
yeah
because
otherwise
we're
kind
of
baking
in
assumptions
into
the
face.
Widget.
Basically.
A
B
Did
have
I
guess
that
might
make
the
sec
I'll
I
just
want
to
if
we
have
time
to
go
through
this
one,
this
one,
maybe
not
so
relevant.
Now
that
you
we're
going
maybe
they're
out
of
doing
the
200
with
the
status
of
the
pipeline,
but
had
we
stayed
with
accounting
for
the
204?
What
would
have
happened
is
that
we
have
two
endpoints
right.
We
have
the
collapse
and
uncollapse
the
intention.
There
is
that
there
are
similar
endpoints,
but
they're
different.
One
only
shows
enough
information
from
the
summary
view,
which
is
more
condensed.
B
You
don't
want
to
fetch
all
the
things
if
you
don't
expand
the
widget
right.
So
when
we
had
two
different
widgets
and
again
this
might
be
secure
specific,
so
we
may
not
want
to
handle
it,
but
for
the
license,
compliance
endpoint,
we
had
to
collapse
and
uncollapse,
and
they
show
the
difference.
Is
that
one
shows
just
the
count
of
licenses?
The
other
one
returns
the
array
of
licenses.
B
B
If
we
had
solved
the
204
problem
originally,
then
you
know
we
we
would
pull
until
we
have
data
for
the
collapse
state
for
the
uncollapsed
state.
When
you
expand
the
widget,
it
would
make
a
new
request,
because
those
are
the
caching
works
at
the
endpoint
level,
because
they're
technically
two
different
urls,
we
would
have
the
204
no
content
and
a
cache
miss
again
on
the
expanded
state.
So
the
question
was:
was
there
enough
justification
to
enable
to
add
the
ability
to
pull
the
expanded
state?
B
A
B
A
C
B
A
B
B
Megabytes
every
polling
step
right
sure.
I
think
I
think
it's
also
like
I,
I
think
now
based
off
of
the
fact
that,
if
we're
going
to
rework
it
to
do
a
200
and
out
of
fuel,
this
is
like
pipeline
status.
B
I
don't
think
we'll
have
to
do
this
one
or
the
other
one,
because
we're
shifting
you
know
we're
shifting
to
the
back
end,
providing
you
know,
or
you
know,
providing
the
data
we
need
in
the
way
we
need
it.
Yeah,
okay,
the
only
thing
I
will
say
then,
with
that
said,
regardless
of
which
approach
we
take,
even
though
I'm
leaning
towards
the
back
end
being
reworked.
There
are
some
implications
there.
I
don't
know
you
know.
B
Deprecate,
the
you
know,
we're
changing
the
response
and
how
it
works,
and
I
don't
know
you
know
we
may
have
if
it's
a
breaking
change,
we
have
to.
We
just
release
15
0s,
so
I
you
know
the
concern
now
is
that
with
any
of
the
secure
stage,
widgets,
even
the
ones
that
are
merged
into
master.
Now
that
aren't
behind
an
individual
feature
flag
they
may
be.
I
don't
they'll
still
exhibit
this
behavior,
because
until
we
handle
204s,
if
we
don't
do
anything
about
those,
then
I
think
we
can
do.
A
B
I
I
guess
what
I'm
saying
is
without
that,
and
even
if
so,
if
we
handle
it,
that's
cool,
but
without
that
the
secure
stage
widgets
that
aren't
behind
individual
feature
flags
would
end
up
having
this
kind
of
error,
state
and
yeah,
and
it
and
it's.
The
thing
is
why
we
didn't
catch
in
development.
It's
because
it
was
kind
of
the
root
cause
of
it
was
kind
of
confusing.
B
I
spent
like
a
week
trying
to
figure
it
out,
but
the
thing
is,
if
you
refresh
the
page,
it
will
load
just
fine,
so
so
develop
like
in
the
development
stage.
You
may
see
this
occasionally
be
like.
Oh,
maybe
it's
network
latency
or
something
you
refresh
and
it's
gone.
The
reason
for
that
is
because,
on
the
second
load,
it's
ready
that
endpoint
was
cached
and
you
don't
get
a
204
anymore.
So
the
criteria
very
specific.
B
It's
like
right
after
you
create
a
merge
request,
while
the
pipeline's
running
or
if
you
have
a
merge
request
that
hasn't
had
that
page
loaded.
I
think
the
cache
I
think
it's
a
couple
hours
so
like
if
you
like,
go
away
from
your
computer,
come
back
and
refresh
the
page.
You
would
see
that
exception
one
time
and
you
refresh
the
page
like
what
the
heck's
going
on
or
try
to
debug
it
and
it's
gone.
B
So
that's
why
it
was
like
one
of
those
bugs
that
would
kind
of
come
and
go
until
we
realized
it's
like
okay,
it's
just
204,
so
so
to
summarize
the
secure
widgets
that
aren't
behind
the
feature
flag.
B
Now,
if
we
don't
accommodate
for
204,
we
should
flag
them
out
separately
or
which
sounds
easier
is
to
support
the
204
and
and
the
proposed
and
the
and
the
my
attempt
here,
like
here's,
the
patch,
it's
very
simple,
the
only
thing
to
keep
in
mind
and
why
I
rolled
it
back
from
mr
was
do
merging
images
I
didn't
know
I
didn't
want
to
hold
up
my
other.
Mr.
The
only
thing
keep
in
mind
is
that,
because
if
the
data
is
empty,
it
starts
pulling
again.
B
There
are
some
unit
tests
that
have
to
be
kind
of
updated
to
mock
out
for
that,
because
what
would
happen
is
the
unit
test
would
hang
because
they
would
keep
pulling
in
particular,
the
the
unit
tests
that
test
the
loading
state
would
hang,
because
when
I
made
this
change
so
I
didn't
get
to
go.
I
didn't
finish
updating
all
those
unit
tests,
so
that's
like
one
gotcha
and
here's
an
example
of
that.
B
So
we
have
this
like
metrics
extension
and
it
does
the
initial
loading,
but
it
continues
to
pull
in
the
background
and
the
test
kind
of
hangs
because
it's
still
polling
so
we
have
to
then
after
we
do
the
test
assertion
kind
of
return,
200
eventually,
so
that
the
test
results,
I
don't
know,
maybe
there's
another
way.
B
We
mock
it
out
better,
but-
and
these
are
all
the
when
we
make
that
change-
we
probably
want
to
make
sure
that
handling
204
doesn't
cause
any
regressions
for
all
these
other
widgets
that
uses
pulling
it's
my.
A
Suggestion
because
it
feels
like
a
proper
issue
like
a
proper
effort,
not
just
something
we
hammer
it
out,
so
we're
already
closed
off
for
feature
15-0.
We
might
put
this
on
for
15-1
if
somebody
wants,
if
you
want
to
get
something
together
before
that,
fernando
we're
happy
to
review
it,
but
it
sounds
like
the
tool
for
support.
It's
a
no-brainer
seems
like
a
fair
thing
to
do.
It's
just
that
it's
a
little
bit
more
involved
than
just
adding
them
sure.
A
Yeah,
I
think
either
one
of
the
two
will
have
to
take
into
account
the
rollout
I'll.
Add
it
phil.
Can
you
add
a
comment
to
the
rollout
issue
about
this?
Just
saying
that
we're
tackling
that
this
204?
You
can
link
to
that
comment
that
from
the
left
so
yeah
you
have
the
the
issue
for
the
robot
quick
question
on
this.
Are
we
sure
that
this
only
affects
the
secure
issues.
B
B
A
As
they're
respecting
the
the
nature
of
http
code,
we
should
recover,
but
so
far
I
haven't
seen
that
happen,
otherwise
it
would
have
picked
up
before
but
yeah.
I
think
it
we.
This
is
just
another
example
of
making
the
code
more
robust
of
the
base
widget
where
whatever
happens
in
the
future,
somebody
might
use
this
code
as
well
you'll
be
covered.
So
thanks
for
that.
B
Yeah
and
and
as
I
follow
I'll
have
to
bring
up,
this
affects
all
the
analyzers.
So
we
have
multiple
analyzer
groups
within
secure
stage,
I'll
have
to
bring
it
up
at
the
stage
level
meeting
I'll
cc
my
manager
and
and
see
if
I
could
get
some
support
from
him
to
kind
of.
A
Yeah,
if
the,
if
the
the
thing
that
we
talked
about
having
a
200,
giving
a
message
about
the
things
being
like
cooked
or
whatever,
it
might
be,
your
option
to
create
a
separate
endpoint
that
it's
more
like
verbose
or
intermediate
state,
or
something
to
not
replace
this
with
a
breaking
change.
A
B
A
Thanks
for
bringing
it
up
and
we're
out
of
points
in
the
agenda,
anybody
has
any
other
points
to
discuss,
yeah
so
phil
that
next
week
just
should
there
should
be
a
bit
more
information
on
the
rollout
on
this
particular
thing
of
the
204s
and
everything.
But
from
what
I
can
see,
the
rollout
should
then
be
happening
sometime
in
51
right,
not
right
away.