►
From YouTube: Package Demo
Description
High level overview and demo of the Package stage
A
B
A
So
for
anyone,
just
watching
now,
I've
been
given
walking
scott
through
a
little
bit
of
a
demo
of
the
package
stage,
and
we
were
just
talking
about
whatever
there
are
North
Stars
for
the
packaged
stage
and
who
are
users-
and
we
were
just
talking
through
the
developers,
owning
the
code
and
other
dependencies
needing
reliability
and
consistency,
and
now
we're
talking
about
the
system
administrators
who
are
really
in
on
the
implementation
and
management,
and
they
need
tools
to
optimize
and
lower
the
cost
of
storage.
This
is
really
impactful
for
gitlab
comm.
A
The
container
registry
forget
lab
comm
is
costing
us
something
like
almost
forty
thousand
dollars
a
month
right
now,
because
we
don't
have
the
ability
to
run
garbage
collection
in
real
time
for
our
customers.
There's
ways
around
this
a
little
bit.
They
can
run
garbage
collection.
They
could
put
it
their
instance
into
downtime,
because
it's
might
be
easier
for
a
company
to
find
a
few
hours
to
to
run
garbage
collection,
but
for
gitlab
we
don't
have
that
that
luxury.
A
So
that's
a
major
problem
and
the
system
administrators
really
want
group
and
instance,
level
visibility
they
want
to.
They
don't
want
to
have
to
go
into
each
project
and
see
which
dependencies
or
which
images
are
there.
They
want
the
ability
to
manage
everything
from
zoomed
out
ten
thousand
feet
any
questions
so
far
we're
about
to
get
into
the
demo
yeah.
A
Okay,
all
right.
So
the
what
we're
gonna
cover
today
is
on
the
container
registry
will
I'll
show
you
how
to
enable
the
container
registry
at
the
project
level.
I'll
show
you
how
to
view
the
images
and
tags
that
are
in
a
given
container
registry.
I'll
quickly
touch
on
how
I
did
authorization
actually
for
the
docker.
It's
really
simple:
it's
just
your
username
and
login,
and
then
we'll
build
and
push
a
new
image.
A
B
A
So
the
first
one,
okay,
so
here's
my
container
registry
project
it's
already
enabled,
but
if,
if
I
wanted
to
I,
would
just
go
to
by
the
way
this
this
setting
is
set
to
default
to
on.
So
unless
an
administrator
said
set
the
default
to
off
for
all
users
it
would
be
on,
but
they
would
any
user
can
go
in
and
say:
okay,
enable
the
container
registry
or
disable
it
here.
It's
just
a
simple
toggle,
so
let's
say
that
it's
enabled.
A
Where
is
it
so?
Under
this
packages,
page
I
could
go
to
the
container
registry,
and
here
I
could
see
all
of
my.
These
are
the
images
and
then
these
are
all
the
tags
that
are
associated
with
that
image.
So
a
little
bit
of
docker
context,
a
container
is
the
running
version
of
the
name.
Egde
an
image
is
the
non
running
version
and
a
tag
is
a
specific
version
of
that
given
image,
so
a
tag
could
have
something
like
latest
or
it
could
be
tagged
with.
I
was
in
a
little
bit
of
a
space.
A
I
would
just
watch
Spaceballs
with
my
nephew,
so
naming
some
of
them
after
some
of
the
Spaceballs
characters,
but
yeah
like
here,
I'm,
just
naming
these
with
various
tags.
What
our
users
do
typically
is
when
they
build
images
from
CI
pipelines,
they
use
the
commit
short
commit
sha
to
tag
their
images
or
they
use
this
latest
tag
as
another
Avenue
that
we
see
them
going
yet
so
from
this
UI
I
could
delete.
These
I
could
delete
these
from
from
the
UI
and
I.
Could
there
is
now
we
mentioned
a
little
bit
earlier?
A
What
are
some
of
the
UI?
You
know
they
want
a
better
UI.
Well,
there's
really
no
way
for
me
to
sort
these,
so
you
could
see
that
being
a
problem.
There's
no
way
for
me
to
search
for
any
of
these,
so
that
for
for
especially
for
users
that
are
building
many
images,
it's
discovery
is
a
real
problem,
and
then
there.
A
This
is
basically
saying
pull
from
this
docker
image
set
the
working
directory
and
you're,
basically
defining
sorry
and
the
requirements
txt.
It's
like
I
need
flask
and
Redis
in
order
to
run
my
project
and
then
the
docker
file
will
say:
okay
go
get
those
requirements
and
create
an
image
with
all
of
those
things
in
it.
A
So
I
built,
in
this
case
a
simple
application
that
will
just
basically
say
hello,
it's
Tim
and
it
will
show
what
hosts
we're
on
and
and
in
a
in
a
web
browser.
Okay.
So
the
first
thing
I
want
to
do
is
create
a
new
docker
image.
So
to
do
this,
it's
really
follows
the
docker
client
commands.
So
there's
nothing
unique
to
get
lab
about
here.
You
would
do
the
same
thing
if
you
want
J,
frog
or
Microsoft's
accept
this
URL
would
be
different
and
so
I'm
gonna
build
this
image.
A
A
It's
done.
That's
nice,
so
I
just
built
this
image
called
continuum.
That's
pointing
to
container
registry
examples,
the
container
registry
one
and
then
it's
tagged
with
yogurt
and
upside-
and
the
next
thing
I
would
want
to
do-
is
push
that
image,
so
it
actually
shows
up
in
my
get
lab
registry.
Okay,
so
I'm
going
to
do
that,
and-
and
this
may
take
just
a
second
okay.
So
now,
if
I
go
back
to
this
project,
we
should
see
under
this
yogurt
tag,
there
should
be
a
net
new
one
called
upside
here.
It
is
cool
cool.
A
B
A
So
this
I
would
now
this
image
is
running
and
I
could
I
could
show
you
it
running
by
going
to
local
hosts
hello,
it's
Tim
and
then
here's
the
host
name.
So
if
I
were
to
go
to
oops,
let's
open
a
new
tab
and
do
docker
container
LS,
so
here's
my
running
containers
and
you
could
see
that
the
name
f6a
e58
106
seven
and
that's
the
host-
that's
running
this
image
so
right
now,
I
just
essentially
pushed
built
and
pushed
a
new
image
and
now
I'm
running
that
image
from
gitlab
and
running
my
little
application.
A
A
Exactly
yeah,
it's
exactly,
and
you
could
see
that
here
it's
like
I
did
this
docker
container
search.
If
I
were
to
do
docker
image,
search
search,
you
could
see.
I
have
many
images,
but
only
one
container
right
now,
then
that
shows
that
hierarchy.
That
container
is
the
running
instance
of
a
given
okay.
B
A
So
in
in
the
old
days,
what
we
would
have
done
instead
of
using
an
image
as
you
would
have
a
different
virtual
machine
set
up,
so
you
might
have
a
virtual
machine
set
up
to
run
on
Linux
or
you
might
have
want
to
set
up
to
run
on
Ubuntu
or
red
hat
or
something
like
that,
and
then
that's
sort
of
the
base
operating
system
level.
And
then
you
might
have
different
images.
A
B
A
A
Problem
so
I'm
gonna
kill
this
container.
That's
let's
see.
Oh
then
I
was
going
to
show
just
how
to
do
this
from
CI.
So
I
was
actually
Supriya.
Lee
surprised
by
this
when
I
started,
I
assume
that
all
engineers
were
gonna
be
doing
what
I
just
did,
which
was
build
something
using
the
command
line,
but
actually
based
on
the
user
research.
A
B
A
A
Pull
this
image
and
then
push
it
so
build
it
and
push
it
and
then,
when
you're
building
it
does
the
same
thing
except
it
pushes
it
with
this
new
slug.
So
you
could
think
of
the
gitlab,
see
IMO
files
of
recipe
for
what
you
want
to
do
in
your
pipeline,
and
people
do
all
kinds
of
crazy
things
with
this.
They,
when
they're
building
their
images
in
fact,
do
I
still
have
that
CNG.
B
A
A
B
B
A
A
B
A
And
that
was
surprising
to
me
was
to
hear
that
you
know
users
are
using
CI
to
build
their
images
programmatically
and
so
that
that
really
has
led
me
to
a
couple
of
if
it
made
me
think
about
what
do
we
show
in
this
UI,
because
we're
not
showing
anything
really
any
integration
than
the
UI
to
support
that,
and
so
things
look
it
made
me.
I
was
recently
thinking
about
the
data
model
and
what
data
do
we
need
to
show
for
the
container
registry?
A
So
things
like
what
we
have
image
name,
we
do
have
tags,
but
a
B
could
be
useful
to
show
labels
or
the
committe
sha,
which
is
the
the
unique
identifier
from
when
a
your
last
branch
was
updated
or
the
author,
or
actually
being
able
to
show
the
dockerfile
right
next
to
it,
where
you
can
edit
it.
So
you
don't
have
to
go
back
and
forth
some.
B
A
B
A
The
let's
see
a
lot
of
the
the
ones
that
we're
working
on
now
really
go
back
to
secure
and
accessible
and
perform
it
because
we
were
it.
So
it's
only
focused
on
the
container
registry,
but
it
is
really
focused
on.
Is
it
accessible
and
and
does
it
work
and
does
it
work
well
and
right
now?
The
answer
to
that
is
it?
There
are
pieces
of
that
that
don't
work
very
well.
Okay
could.
A
Yeah,
so
one
our
biggest
competitor
in
the
packaged
stage,
for
me,
is
a
frog.
They
have
a
great
product,
they've
been
around
for
a
long
time
at
the
enterprise
level,
and
they
do
things
like
not
only
have
the
registries
or
the
container
registry.
They
also
have
security
and
vulnerability
scanning,
and
they
also
have
things
like
white
listing
and
black
listing
and
approved
packages,
and
they
already
have
caching
and
proxying,
which
is
they're
all
great
features.
A
Okay,
in
my
opinion,
morale
and
from
what
I've
heard
from
users
they're
not
incredibly
happy
with
J
Frogg
all
the
time,
because
it's
very
complex,
because
they've
built
a
single
point
solution
to
solve
every
problem
that
they
possibly
could
over
the
past
six
years.
Yeah
so
I
think
we
have
some
rooms
at
some
room
to
improve
on
what
they've
done
and
it's
not.
They
don't
exactly
apply
to
what
we
do,
because
they
they're
just
announcing
CI
they've,
recently
acquired
shippable
a
few
months
ago
and
they're
just
starting
to
launch
CI.
A
A
A
A
A
Container
registry,
it's
currently
viable
it's
being
used
and
people
when
I
asked
users
what
you
know,
especially
in
the
internal
users.
They
say
they
like
it.
It
works,
they
don't
like
the
UI.
They
don't
like
certain
aspects
of
it,
but
we
can't
get
to
complete
without
having
this
inline
garbage
collection
without
having
a
retention
and
expiration
policy
without
improving
the
UI
and
expanding
on
the
data
model.
A
B
A
That
it's,
it
is
all
over
the
place.
I
think
the
difference
is
how
many
images
are
they
building
so
for
a
small
team,
they're,
probably
building
an
image
with
a
few
tags,
and
it
updates
updated
once
a
month
or
once
every
few
months,
but
for
the
large
enterprises
team,
our
enterprise
teams
that
are
building
images
and
tags
using
CI
they're,
the
heaviest
users,
they're
building
hundreds
of
images
a
week
or
a
month
and
they're
constantly
making
updates
they're,
maintaining
the
storage.
A
So
it
the
there's
advantages
for
both,
but
the
real,
where
we
really
become
sticky
is
once
we
can
get
users
using
CI
to
build
their
images
and
then,
if
we
can
give
them
more
power
to
not
just
to
not
just
build
the
images
but
to
manage
all
of
the
underlying
components
as
well,
so
they
could
lower
their
cost
of
storage,
and
you
know
not
not
keep
things
that
aren't
around
anymore.
So.
A
Yeah
I
want
to
satisfy
the
hardest
demands,
because
I
think
that's.
Where
are
you
know?
That's
if
we
could
solve
those
the
people
who
have
sorry
the
people
who
have
only
are
only
building
a
few
images,
they're
easy
to
satisfy
because
they
don't
really
care
too
much
about
whether
or
not
they
delete
an
old
image
because
they're
only
building
so
many.
But
if
we
could
satisfy
the
needs
of
our
large
enterprise
customers,
then
we
could
build
something
that
that
really
it
that
really
is
valuable
and
that's
the
direction
that
everything
is
going
to
go
anyway.
A
I
mean
if,
if
people
are
using
CI
to
build
their
images,
they
want
all
the
same
functionality
that
exists
or
their
repositories
like
if
I'm,
if
I
submit
a
merger
quest,
I
have
the
option
to
say,
delete
this
branch.
Once
my
merger
quest
has
been
approved,
we
don't
offer
that
same
capability
with
the
container
registry,
which
would
say
like
build
this
image.
But
after
this
branch
of
code
gets
moved
to
the
move,
to
master,
delete
the
image
and
the
bridge
and
no
branch.
B
A
B
A
Here's
an
example
of
what
code
French
does
I
really
like
this
I,
don't
like
necessarily
the
the
UI
and
the
colors
and
everything
but
in
terms
of
just
like
the
data
model,
I
think
it's
really
valuable.
So
we
have
this
right.
We
have
image
name,
we
actually
don't
show
branch
in
there
right
now,
I
think
that's
a
big
mess
yeah!
A
We
do
not
show
the
commit,
which
again
I
think
is
a
big
mess.
We
have
date,
but
we
don't
have
this
sort
of
timestamp
date
unless
you
hover
over
it
I
think
that's
a
mistake
we
could
just
put
in
the
actual
timestamp
and
then
the
way
that
they
display
their
tags,
I
think
is,
is
really
interesting.
So
the
way
that
we
showed
them
the
way
that
we
display
these
tags,
you
actually
have
to
expand,
and
then
you
see
the
list
of
tags
here,
what
code
fresh
does
oops
I
lost
it?
Of
course,.
A
Here
it
is,
then,
you
show
you
the
tags
in
this
way
that
that's
something
that
could
work
and
then
they
have
the
commit
shot
here,
which
I
think
is
really
valuable
as
well,
because
what
I
learned
from
the
research
is
is
a
lot
of
people
are
using
the
commit
shot
to
tag
their
specific
docker
images.
Whether.
A
It's
it's
more,
it's
like
a
unique
identifier
that
gets
tagged
on
and
then
they
have
these
actions
here
like
you
could
launch
the
image
you
could
download
it.
You
can
copy
the
path
to
it,
which
is
really
useful
to
be
able
to
like.
If
I
want
to
copy
the
path
to
this
image,
then
I
can
do
things
like
run
like
when
I
run
docker.
A
B
A
So
right
now
we
in
terms
of
other
container
registries,
we
support
maven,
an
NPM
we're
working
on
Conan.
Now
this
is
for
a
big
enterprise
customer
that
we're
working
with
new
gets
our
most
popular
requested
feature
in
the
package
stage.
We
have
hundreds
of
up
votes
for
this
and
then
distant
after
that
is
composure
and
ruby
gems.
B
B
A
All
do
similar
things,
they
all
basically
take
some
information
you
like
here.
Let
me
show
you
the
NPM
example.
So
for
NPM
there
Pete
there's
always
two
pieces.
There's.
How
do
you
do
authentication
at
the
general
level
and
how
do
you
and
then
we're?
How
do
you
map
your
dependencies,
so
the
NPM
RC
file
is
sort
of
like
my
global
settings
for
NPM,
and
you
can
see
here.
This
is
where
I
would
set
where
what
red?
A
What's
the
address
of
the
registry,
this
is
where
I
put
in
authorization,
although
I
shouldn't
be
showing
this
on
video
right
now,
with
all
my
to
my
token
wide
open,
and
then
this
is
where
you
actually
say
where
you
want
to
upload
a
package
to
and
then
the
the
package
JSON
file.
This
is
where
you
actually
identify.
A
A
A
This
one
so
NPM
published
you
could
think
of
that
the
same
way
as
docker
build
or
in
docker
push
it's
doing
the
same
thing.
It's
basically
pushing
a
set
of
dependencies.
That's
saying
use
use
these
dependencies
in
your
code
and
pushing
it
to
get
lap
okay.
So
if
I
go
to
my
git
lab
spells
project
this
one,
you
could
see
all
of
these
files
and
then
go
to
packages
and
then
list-
and
here
you
could
see
that
I
just
up
now
updated
this
latest
package,
and
you
could
see
it's
that
package.
A
My
spells
302
that
we
just
updated
and
mavin
mavin
does
essentially
the
same
thing
and
but
instead
of
me
even
having
an
NPM
RC
file
and
a
package.json
file,
they
have
the
settings.xml
as
sort
of
your
global
settings,
and-
and
here
you
could
see
again,
I'll
just
hide
hide
that
one
part,
but
you
could
see.
This
is
where
you
put
in
your
authentication
information
and
then
for
the
pom
file
stands
for
project
object
model,
and
this
has
here's
the
dependencies
that
I
want
to
install.
A
B
A
A
Let's
see
this
one,
maybe
so,
if
I,
let's
say
I
know
you
have
that
project
I
do
NPM
in
it
and
what
that
does
is
is
just
create
says
this
is
an
NPM
project,
so
I
could
just
enter
through
all
this
you.
This
is
all
the
metadata
you
saw
in
the
JSON
file,
okay
and
then
I
could
run
this
I,
don't
forget,
and
then
this
will
basically
install
the
package
from
my
NPM
spells
project
that
we
just
built
and
now
it's
there
and
so
now
I
have
access.
A
You
built
this
project
that
include-
or
you
know,
this
JSON
file
and
one
project
and
I
was
able
to
quickly
download
it
and
fetch
it
and
pull
it
into
my
other
project.
So
for
enterprise
users,
you
could
see
how
that
would
be
valuable,
because
now
you
can
say
oh
I,
this.
This
spans
across
everybody
make
make
make
this
available
for
for
everyone
within
the
company.
Okay,.
B
A
They're
both
managed
by
one
historically,
they
were
built
by
different
teams,
but
now
they're,
all
they're,
all
nested.
Under
the
package
team
and
and
Daniel
the
Croft.
The
engineering
manager
we're
trying
to
avoid
specializing
where
people
only
work
on
the
container
registry,
or
they
only
work
on
maven,
because
there
may
be
some
short-term
benefits
to
doing
that,
but
long
term.
A
That's
basically,
the
realizations
that
we've
been
having
between
the
container
registry
and
the
package
registries
are
they're,
basically
doing
the
same
thing,
you're
pushing
a
thing
to
get
lab
and
it's
important
that
there's
visibility
and
that
you
could
download
it
and
then
it
works
with
CI
and
all
of
the
metadata
that
goes
around
it.
So
we're
really
working
to
try
and
imagine
that
data
model
and
then
try
and
imagine
what
what
could
be
the
most
useful
for
our
users,
regardless
of
what
the
integration
is.
The.
B
A
Yeah
he's
great
I,
really
I
really
appreciate
him.
He's
been
great
to
work
with
nice,
so
yeah
I
think
I
mean
I
could
go
into
you,
know,
building
maven
and
and
NPM
pipelines
and
which
would
basically
be
this.
What
we
saw
for
docker
I
could
just
go
in
and
and-
and
you
know,
rerun
or
run
this
pipeline,
which
one
is
this:
this
is
for
maven,
so
I
could
run
pipeline
and
then
I'll
just
use-
let's
say
I,
don't
know,
build.
A
B
A
B
B
A
Don't
think
so,
I
think
the
reality
is
my
real
goal.
Right
now
is
to
make
the
container
registry
better
to
take
it
to
complete
and
then
to
make
the
other
integrations
that
we
do
for
new
Ghidorah
or
whatever
it
is
I
want
to.
First
were
like
carving
this
path
with
NPM
and
maven,
and
we're
saying
okay:
this
is
the
core
functionality.
This
is
what
how
it
needs
to
work
and
then,
once
we
do,
that,
I
want
it
to
be
like
just
cranking
a
wheel
to
add
other
integrations.
We
know
what
the
maturity
path
is.