►
From YouTube: Remote hierarchy for the GitLab package registry (project vs group vs instance level endpoints).
Description
An overview of what we mean when we talk about project/group/instance level endpoints with the package registry and why it affects naming restrictions.
A
Everyone,
my
name's
Steve
Abrams,
I'm,
a
back-end
engineer,
I'm,
a
packaged
team
at
get
lab,
and
today
I'm
gonna
talk
a
little
bit
about
project
versus
group,
versus
instance,
level,
endpoints
with
regards
to
the
package
registry
and
that's
kind
of
a
mouthful.
So
this
is
a
topic
that
comes
up
a
lot
when
we're
implementing
new
package
registries
and-
and
it
pretty
much
involves
how
do
we
scope
users
views
when
they're
downloading
packages
and
that
might
all
sound
a
little
bit
confusing.
A
A
And
so
right
now
we
have
Conan.
Maven
and
NPM
are
our
three
package
registries
that
are
available
or
three
repositories
that
are
available
on
the
get
lab
registry,
and
so,
let's
take
a
look
at
maven,
because
I
think
it's
sort
of
the
the
one
that
currently
has
the
most
options,
and
so,
if
you've
worked
with
the
maven
package
registry,
you've
seen
that
we
have
project
group
and
instance,
level
endpoints,
and
so
what
does
that
mean?
A
So
when
you
configure
your
pom
dot
XML
to
set
your
remote
repository,
the
remote
itself
actually
includes
your
project
ID,
and
so
this
makes
sense.
When
you
publish
a
project
or
when
you
publish
a
package,
it
belongs
to
a
project
on
git
lab.
So
like
from
the
technical
standpoint.
That
means
there's
a
table
in
the
database,
that
is,
for
the
projects
and
there's
a
table
for
packages,
and
the
package
table
has
a
project
ID
in
it.
So
it's
it's
directly
associated
with
what
the
project
and
that's
what
we
want.
A
When
you
push
up
a
package,
you
want
to
be
able
to
associate
it
with
a
given
project.
However,
things
get
a
little
bit
different
when
you're
installing
packages
when
you're
installing
packages
you're
not
referring
to
the
project
ID
or
anything
in
particular,
you're,
just
referring
to
the
package
name,
and
so
how
is
get
lab
going
to
figure
out
which
package
in
particular
you're
talking
about
and
whether
or
not
you
have
access
to
it?
And
so
the
permissions
on
git
lab
all
revolve
around
project
and
that's
why
we
kind
of
placed
the
package
within
the
project.
A
So
if
you
have
permissions
to
a
project,
then
you
have
permissions
to
the
packages
that
belong
to
that
project,
so
I'm
going
to
go
ahead
and
try
to
draw
a
little
bit
of
what
I'm
talking
about
here.
We'll
see
how
good
this,
how
all
this
works
out
so
I'm
going
to
start
out
and
I'm
gonna
draw
what
I'm
going
to
call
the
instance,
and
so
this
square
I'll
add
a
label.
Here
is
a
little
bump
with
the
size.
A
A
So
if
you
work
on
get
lab
comm
you,
you
probably
belong
to
some
groups
where
all
of
your
projects
live,
and
so
let's
go
ahead
and
use.
Maybe
the
shape
here
to
represent
a
few
different
groups
and
we'll
just
create
a
few
of
them
and
within
groups
there
might
even
be
subgroups,
so
this
group
might
contain
other
groups
and
that
can
kind
of
descend
as
far
as
you
really
want
just
to
kind
of
demonstrate.
What
that
looks
like
and
then
within
the
groups
we
have.
A
A
A
And
so
all
these
different
projects
may
may
or
may
not
have
packages
it
just
depends
and
when
you're
dealing
with
them,
when
you're
uploading
them
you're
uploading
them
to
a
project
which
you
have
permissions
to
upload
them
to.
So
when
we
talk
about
downloading
them,
however,
there's
three
sort
of
options.
So
we
have
the
instance
view
the
group
view
and
the
project
view
and
that's
sort
of
just
the
scope
at
which
you
can
see
all
of
these
packages.
A
So
let's
say
that
you
have
a
project
view,
so
that
means
that
you
are
having
a
remote
and
we
can
look
at
this
directly
from
maven.
So
if
we
go
to
the
maven
project
level
endpoint,
so
we
can
see
that
for
the
downloadable
repository
endpoint
here,
this
is
the
remote
that
is
used
so
when
maven
makes
API
calls
or
requests
to
get
lab
to
get
these
packages,
it's
sort
of
pre
fixing
all
of
its
requests
with
this
and
you'll
notice
that
it
includes
the
project
ID.
A
A
All
right
so
I
add
a
little
arrow
there,
and
that
means
that
you
enter
your
project
ID,
which
is
this
projects
ID
and
when
it
is
going
to
when
you,
when
you
go
to
install
packages
using
maven,
it's
only
searching
within
the
scope
of
this
one
project.
So
there's
no
way
to
even
know
about
the
packages
in
this
project.
There's
no
way
to
know
about
the
packages
in
this
group
or
you
know
in
other
places
it
within
get
lab.
A
So
well
what?
If,
as
an
organization,
you
have
a
group
and
you
want
to
be
able
to
distribute
all
of
your
packages
and
make
them
available
to
users.
So
in
that
case
you
might
come
and
use
the
maven
group
level
endpoint,
and
you
can
see
here
so
the
upload,
the
distribution
section
is
the
same.
It
still
distributes
the
package
to
a
single
project,
but
for
downloads,
it's
now
using
a
group
ID.
A
The
entire
group-
and
so
if
you
this
endpoint
when
you're
installing
packages
of
a
given
name,
you
can
see
these
three
packages,
so
you
have
access
to
them,
but
you
can't
see
packages
within
another
group,
so
the
benefit
of
doing
something
like
this
is,
if
you're,
using
a
very
generic
name
for
your
package.
Maybe
it's
just
a
statistics,
passing
package
and
you
just
named
it
statistics.
A
You
know
that
there's
only
one
package
named
statistics
within
your
project,
so
when
you
connect
to
that
remote,
there's
no
chance
that
you're
gonna
have
any
trouble
finding
that
package
and
being
able
to
install
it
and
use
it
and
similar
with
a
group.
It's
likely
that
you
control
everything
within
your
group
or
someone
does
at
your
organization
and
if
you
have
any
naming
conflicts,
they'll
be
managed
at
some
level
by
someone.
A
So
this
might
be
the
statistics
package
and
it
doesn't
mess
with
anyone,
elses
statistics
package
and
then
the
real
benefit
here
is:
if
you're
working
on
an
instance
like
get
lab
comm,
there
might
be
many
people
that
want
a
package
named.
Statistics
like
this
might
be
a
completely
different
organization
and
they
have
a
statistics
package.
A
It
wouldn't
be
very
fair
for
them
to
not
be
able
to
name
it
statistics
just
because
you
have
yours
name,
statistics
so
within
their
group,
if
they
use
their
group
level,
endpoint
they'll
be
able
to
download
and
use
that
package
as
well.
So
the
last
step
is
looking
at
the
instance,
and
so
the
instance
level
you
can
see
has
no
reference
to
a
group
or
a
project.
It
is
just
get
lab
comm
or
it
would
be
your
self-managed
domain.
So
this
is
a
way
to
access
all
of
the
packages
in
a
given
instance.
A
A
So,
if
I
create
a
package
and
put
it
into
a
private
project,
certainly
that's
not
going
to
be
publicly
available
to
anyone
that
hooks
up
to
get
lab,
comm
and
tries
to
search
for
packages,
but
if
I'm
making
an
open-source
project
with
an
open-source
package,
this
is
a
way
for
me
to
share
it
and
for
people
to
connect
and
get
to
it
or,
if
you're
running
your
own
self-managed
instance.
This
is
how
you
might
manage
all
of
your
packages,
because
it's
it's
your
instance.
You
know
everything.
A
A
A
But
if
you're
searching
get
lab
comm
for
a
package
name
statistics,
how
does
it
know
which
one
to
use
so
when
you're
using
an
instance
level,
end
point,
you
have
to
be
using
packages
that
are
named
in
a
way
that
is
completely
unique,
and
so
this
is
where
you
see
we
have
some
naming
restrictions
on
the
instance
level.
So
if
you
have
a
project
that
lives
at
the
path,
github
org
slash
gitlab,
then
you
have
to
name
it
git
lab
or
in
slash
get
lab.
A
You
can't
name
it
fubar,
and
that
makes
sense
because
if
I
named
my
package
fubar
and
someone
else
wanted
to
name
their
package
fubar,
then
that
would
create
a
conflict
at
the
instance
level,
and
we
want
to
avoid
that
we're
working
on
ways
to
to
fine
solutions.
That'll
you
know
loosen
this
restriction
because
it
is
a
pain
point
for
many
people
and
so
hopefully
we'll
find
some
solutions
in
the
future.
That
will
make
everyone
happy,
especially
because
these
restrictions
also
still
occur
on
a
self-managed
instance
where
they
might
not
necessarily
apply
to
the
same
extent.
A
So
hopefully,
this
kind
of
gives
you
an
idea
of
how
these
different
end
points.
Project
level,
group
level
and
instance
level.
Give
you
different
views
into
what
packages
you
can
access.
Let's
take
a
look
at
how
the
other
available
package
types
kind
of
play
into
this,
and
so
you
may
have
run
into
in
the
development
documentation,
chart
sort
of
showing
the
availability
of
you
know.
Maven
has
project
group
and
instance,
level
cone
and
only
has
instance,
level
and
NPM
only
has
group
level
which
will
kind
of
get
into
what
all
that
means.
A
So,
let's
take
a
look
at
Conan
next,
so
for
Conan
we
only
have
instance
level.
It's
it's
just
the
initial
implementation.
We
plan
on
adding
group
and
project
level,
but
it
should
look
very
familiar
when
you
add
the
Conan
remote,
it
is
the
entirety
of
the
instance.
So
it's
get
loud,
calm,
there's
no
reference
to
a
group
or
a
package.
So
what
that
means
is
that
or
yeah
a
group
or
a
project?
Sorry.
A
So
in
Conan
we
have
a
naming
restriction
similar
to
maven,
where
a
portion
of
the
package
name
the
username
of
the
Conan
recipe
as
they
call
it
must
be
the
plus
sign
separated
project
path.
So,
since
Conan
already
restricts
you
to
only
having
two
slashes,
we
can't
just
add
the
the
path
of
gitlab
org,
slash,
gitlab
c
e.
We
have
to
remove
that
slash
so
for
the
username.
It's
get
lab,
org,
plus
gillip
ze,
and
then
once
we
once
someone
requests
this
package,
we
can
find
that
this
package
belongs
to
this
project.
A
The
authentication
section
with
the
NPM
RC
file
is
where
we'll
we'll
see
the
registry
and
remotes
that
were
connecting
to
you,
and
you
can
see
that
here
we
have
the
uploading
portion,
so
we
upload
it
based
on
project
ID,
and
that
was
also
mirrored
when
you
look
at
the
uploading
packages
section.
You
had
a
configuration
to
your
package
JSON
file,
and
that
includes
a
project
ID.
So
that's
saying
that
when
you
publish
this
package,
you're
publishing
it
to
this
remote
endpoint.
That
includes
your
project
ID.
So
it
will
be
added
to
that
project.
A
A
That
kind
of
mixes
up
this
whole
mindset
that
I've
been
kind
of
showing
you
where
NPM
projects
or
sorry
NPM
packages
have
to
have
a
scoped
name,
and
what
that
means,
if
you're
familiar
with
NPM,
is
that
you
have
a
scope
which
is
the
at
sign
scope
and
then
slash
your
package
name
and
so
forget
lab.
If
we
go
to
the
naming
convention,
which
there's
a
section
here,
what
that
means
is
that
if
you
have
a
group
or
name
space,
you
need
to
use
the
top-level
namespace
or
group
as
your
scope.
A
A
But
here
so
we
have
a
you
know.
Top
level
named
face
a
foo,
a
group
name
of
bar,
and
then
the
project
is
named
buzz,
so
you
can
see,
the
scope
can
be
has
to
be
foo,
but
the
package
name
itself
can
be
anything.
So
what
this
means
is
that
when
you
download
a
package
from
get
lab
first,
we
find
the
group
check
your
permissions,
and
then
we
find
the
specific
package
within
the
group
or
its
descending
subgroups.
A
So,
even
though
we're
connecting,
at
the
instance
level
based
on
that
remote
because
of
these
naming
restrictions,
it's
kind
of
acting
like
a
group
level
endpoint,
and
so
this
is
something
that
we
also
plan
on
expanding
our
future.
Functionality
for,
to
you
know,
add
the
additional
endpoints
to
identify
group
ID
and
project
ID,
so
that
you
have
a
little
bit
more
freedom
here
with
your
naming
and
with
how
you
handle,
or
your
installs
and
downloads.