►
From YouTube: Dependency Proxy UI planning discussion
Description
Discussing how we can move forward with updating the dependency proxy UI given recent backend changes.
A
Cool,
so
I
guess
we
need
to
give
again
the
intro,
so
this
is
a
a
little
bit
of
an
informal
meeting
to
discuss
the
current
progress
of
the
dependency
proxy.
The
back-end
implementation
has
been
made
in
the
past
milestone
and
we
realized
that
there
was
a
little
bit
of
disconnect
on
what
we
have
and
what
we
know
that
we
have
and
what
we
could
work
on.
So
this
is
more
of
an
informal
catch-up
around
it.
B
A
B
Okay,
are
you
seeing
the
the
screen?
Yes
cool?
So
currently,
what
we
have
is
a
page
where
we
show
if
the
dependencies
proxy
is
enabled,
we
show
the
url
and
we
show
how
many
blobs
of
images
there
are
and
the
amount
of
space
they
take
up.
Okay,
but
we
don't
show
really
anything
beyond
that.
Yet
one
thing
I
would
like
to
note
that
I've
been
meaning
to
note
for
a
long
time-
and
this
should
be
a
very
fast
update-
is
on
this
dependency
proxy
url.
B
I
think
we
should
remove
the
https
prefix,
because
this
is
actually
not
a
url.
This
is
the
image
prefix
for
when
you
pull
an
image.
So
when
you
do
like
docker
pull
something
you
use
starting
at
gitlab.com
forward
and
it's
not
actually
a
url,
I
don't
think
that's
a
caused
anyone
confusion.
Yet
surprisingly,
but
it's
something
I
noticed
in
the
last
week
or
two
that
I
realized
we
should
probably
fix
up.
So
I
can.
I
can
open
an
issue
for
that.
I'll
make
a
note
right
now.
So
I
don't
forget.
B
B
A
B
So
what
I
think
we
should
add
here
is
we
should
maybe
list
each
of
the
dependency
proxy
manifests
that
exist
in
a
given
group,
and
we
should
list
out.
We
can
list
out
the
file
name
and
the
digest
and
that
will
give
them
the
image
name.
So
if
they
pulled
alpine
latest,
then
the
file
is
named
alpine
latest,
so
it'll
give
them
the
image
and
tag
that
they've
pulled
as
well
as
the
actual
digest
of
that
image,
which
is
the
unique
identifier.
B
A
C
Right,
yes
to
both
of
your
questions,
we
are
going
to
be
pulling
a
lot
of
the
same
ui
elements
from
the
package
registry
and
container
registering
over
to
this,
and
there
is
a
design
specific
for
the
dependency
proxy.
We
made
a
lot
of
progress
on
it.
It's
been
a
while,
so
they
need
to
be
revisited
if
we
start
moving
into
any
complex
direction.
A
A
A
B
A
B
B
A
B
A
B
A
C
Yeah,
it's
the
same
thing
as
a
container
registry.
The
ideal
performance
would
be,
I
click
the
button
and
it
is
now
gone,
but
if
we
can't
actually
perform
that
we
should
show
in
the
ui
it
has
been
marked
for
deletion
and
then,
when
it
is
actually
removed,
we
can
actually
we
can
take
it
out
of
the
ui
yeah.
A
B
C
When
we
actually
managed
to
schedule
whatever
the
word
for
the
graphql
is,
if
that's
coming
before
the
front
end,
can
we
also
actually
just
let
me
know
when
that's
happening
whatever
milestone
it's
in,
to
make
sure
that
I
have
the
chance
to
put
the
design
together?
I
can
do
it
at
the
same
time,
and
then
we
can
pass
both
the
graphql
stuff
that
we
need
and
the
design
to
the
front
end.
At
the
same
time,
cool.
A
A
A
B
B
A
B
A
Because
do
what
do
we
have
right
now
to
find
these
things?
Nothing
right,
so
we
won't
have
like
finders,
for
example,
now
that
I'm
building
the
packages
graphql,
I
already
have
the
finders
written.
So
it's
just
a
matter
of
saying
you
know,
use
this
finder
sure
and
we
are
happy
about
it,
so
we
will
probably
yeah.
Maybe
we
can
break
it
down
in
steps
and
that's
search
and
sorting
later.
Do
you
think
it
will
be
available
in
regardless
to
do
it
in
multiple
steps.
C
A
A
B
A
B
So
when
you
delete
a
manifest,
there's
no
possible
way
to
delete
the
underlying
blobs.
It's
the
same
thing
with
when
you
delete
a
tag
you
end
up
with
all
like
you
know,
it
doesn't
actually
free
up
all
the
space,
so,
but
luckily,
since
it
is
just
a
cache,
the
idea
is
that
there's
no
harm
in
just
clearing
it
at
any
given
point
in
time.
C
C
B
A
B
A
A
A
A
A
A
A
C
Like
the
expiration
for
the
cache
as
one
of
the
settings
and
the
cleanup
for
the
settings,
or
if
I
would
imagine
the
dependency
proxy
when
it
evolves
to
be
able
to
do
npm,
caching
and
those
other
things
like
that,
part
of
the
settings
will
get
just
as
complicated.
So
there's
no
reason
not
to
put
it
there
now.
A
Yeah-
and
the
reason
is
that
you
know
this
is
moving-
that
button
away
is
technically
a
breaking
change
right,
I
mean
at
least
visual
at
least
documentation.
We
need
to
tell
the
user
this
move
so
the
sooner
we
do
it,
the
least
we
impact
them.
I
don't
know.
Do
we
have
a
usage
statistic
for
the
dependency
proxy
usage
right
now.
B
C
B
C
And
you
call
that
a
really
good
thing
you
go
there.
Maybe
we
could
when
we
move
that
button
and
create
the
settings
and
all
that
we
should
make
sure
the
settings
the
button
the
documentation,
maybe
are
all
released
at
the
same
time,
not
sure
how
that
would
work
officially,
but
like
making
sure
that
we're
we
made
a
big
change,
we're
making
it
very
clear.
This
is:
what
happens?
Your
service
isn't
impacted
it's
exactly
the
same.
We
just
did
this
yeah.
A
So
I
think
I
think
we
have
a
clear
path
here
that
we
should
we
should.
First
of
all,
we
should
have
api
to
get
and
write
this
information,
and
then
the
first,
mr
will
be
take
this
enable
button,
remove
it
from
the
ammo
view.
Add
it
to
the
settings,
write
the
commentation
with
a
change
lock
that
clearly
state
move.
A
On
top
of
it
did
we,
this
might
be
tangential
and
I
apologize
did
we
move
all
of
our
settings
over
to
our
dedicated
page?
No,
not
yet.
We
just
add
the
new
wave
and
the
duplicated
settings.
This
is
for
groups,
so
we
have
the
dependency
proxy
and
there
is
another
settings
that
needs
to
go
there.
I
clean
up
policies.
B
A
B
A
B
C
I
think
one
of
the
next
steps
I
would
like
to
take
in
this
is
to
sync
a
little
bit
later,
once
we
kind
of
moved
on
on
this
with
steve
about
what's
going
to
be
built
next,
so
that
I
can
make
designs
that
match
what's
going
to
be
built
next
and
then
we
can
start
rolling
these
out
more
in
step
and
in
sync,
with
each
other,
as
opposed
to
what
this
gun
felt
like
which
a
lot
was
built,
and
then
we
had
to
kind
of
figure
out.
Yeah.
Add
it
to
the.
A
Ui,
the
good
thing
is
that
if
we
keep
proceeding
with
this
order,
back-end
api
the
moment
that
we
release
an
api
that
will
serve
the
front
and
anybody
else
we
use
the
api.
The
feature
is
basically
released
already
because,
okay,
they
don't
have
a
front-end
to
deal
with
it,
but
all
the
information
are
there.
A
B
Yeah,
I
think
two
things
that
are
worth
like
noting
are
that
whenever
we
work
on
really
any
feature,
if
there's
new
functionality,
we
should
question
like
do
we
need
to
add
graphql
apis
and
do
we
need
to
then
create
a
design
or
front-end
follow-up?
That's
probably
a
good
thing
to
know,
maybe
in
our
process
moving
forward.
A
C
If,
as
we're
building
the
apis-
and
we
identify
that,
if
as
design,
I
could
get
updated
when
there's
a
new
api,
because
then
there's
also
the
conversation
of,
I
didn't
really
consider
that
this
was
going
to
be
a
thing.
But
that
could
be
a
ui
feature
that
we
could
build.
So
we
get
kind
of
both
both
directions
for
that
and.
B
A
B
A
C
C
B
B
C
There
is
actually
a
need
eventually,
that
when
a
protected
branch
releases
a
new
relief
and
is
a
part
of
an
environment
that
is
special,
they
want
this
ability
to
make
immutable
builds.
So
if
they
wanted
to,
they
could
go
back
to
this
special
build
and
just
rebuild
it.
That
means
permanently
caching,
things
that
are
attached
to
that.
So
eventually
there
will
be
a
need
warning
steve
early.