►
From YouTube: GitLab Single Project Package Registry Demo
Description
A quick walk through of how you could publish all of your packages to one project, or projects that are separated in ways that make sense for you. This does not go into depth in how to create new packages, but rather how to set the remote for Maven, NPM, and Conan packages to be published to the same project regardless of where the package's originating code lives.
A
Hey
everyone,
my
name's
Steve
Abrams
and
I-
am
a
back-end
engineer
on
the
package
team
at
gitlab
and
today
I'm
going
to
show
you
how
you
can
use
a
variety
of
the
different
features
for
get
lab
packages
in
order
to
create
a
single
project
that
holds
all
of
your
packages
for
a
specific
given
use.
So
let's
go
ahead
and
get
started
here.
A
A
So
maybe
you
just
have
a
reason
like
you
want
all
of
your
NPM
packages
in
one
place
or
all
of
your
private
packages
in
one
place,
or
maybe
you
just
want
everything,
NPM,
maven
and
Konan,
but
for
a
given
department
or
section
of
your
organization
to
all
kind
of
live
in
one
one
place.
This
demonstration
should
give
you
an
idea
of
how
you
can
do
something
like
that,
so
we're
going
to
start
out
with
maven.
A
So,
first,
let's
go
ahead
and
create
a
new
project
actually,
and
this
project
is
going
to
be
our
registry,
so
we
need
project
on
git,
lab
and
I'll
call
it
my
package
registry-
and
so
here
you
want
to
decide
whether
or
not
the
project
is
private
or
public
and
so
be
sure
that
you're
aware
that
any
packages
that
live
within
this
project
will
also
share
that
visibility.
So
if
you
make
this
project
public,
like
I'm,
going
to
do
for
this
demonstration,
all
of
the
packages
that
live
in
that
project
will
also
be
public.
A
If
we
take
a
look
at
our
current
package
section,
we
can
see
there's
no
packages
yeah.
So,
let's
start
out
with
maven,
and
so
I've
already
got
some
projects
ready
to
go
from
maven
kunin
and
NPM
I'm
not
gonna,
go
into
how
to
create
new
packages
in
each
one
of
them,
I'm
going
to
show,
if
you
have
one
ready
to
go,
how
you
can
push
them
all
to
the
same
place
so
with
maven.
There's
a
few
steps
that
we
need
to
be
able
to
publish
packages.
A
So
the
first
step
is
we
need
to
enable
the
registry,
as
you
saw,
my
registry
was
already
enabled.
If
you
didn't
see
this
tab
for
packages,
then
you
will
need
to
enable
it
which
you
can
do
by
just
going
to
your
settings
and
permissions,
and
once
we
have
that
we
need
to
authenticate
to
the
registry,
and
so
we
can
do
this
with
a
personal
access
token
and
so
I'm
going
to
just
copy
this
content
here
that
will
go
into
a
settings,
dot,
XML
file
and
let's
go
ahead
and
move
over
to
the
maven
practice
project.
A
That
I've
got
here
very
simple
basic
project.
It's
already
got
a
pom
Excel
and
we're
going
to
create
that
settings.xml
and
paste
it
in
here,
and
it
looks
like
the
only
thing
we
need
here
is
a
personal
access
token,
and
just
to
make
a
point
here.
Is
you
don't
have
to
use
this
specific
type
of
authentication
for
this
to
work?
A
So
let's
go
ahead
and
create
a
personal
access
token.
You
can
do
that
by
going
to
your
user
settings
and
to
your
access
tokens
and
then
for
package
registry.
We
want
to
create
a
scope
of
API
our
token,
with
the
scope
of
API
I'm,
just
gonna
call
this
package
registry
tests.
Okay,
so
I
remember
to
relocate
later
here
we
go
copy
that
and
place
that
back
in
our
code
here
cool.
A
So
the
second
step
we
need
to
take
care
of
in
order
to
publish
a
maven
repository.
Is
configuring
the
project
to
use
the
correct
remote
pretty
much
so
we
need
to
point
to
this
project
to
the
gate
lab
registry.
We're
going
to
do
this
at
the
project
level,
we're
pushing
it
and
pulling
it
from
a
given
project.
So
we'll
copy
this
block-
and
this
goes
into
our
pom.xml.
A
And
it
looks
like
this
section
that
we
need
a
few
things
or
we
just
need
one
thing
at
the
project:
ID
in
three
different
places,
and
you
can
see,
we've
got
our
two
distribution
repositories,
the
snapshot
and
then
the
regular
repository,
which
are
the
same
in
this
case
and
then
the
actual
sort
of
registry
repository
I
guess
you
could
call
it
so.
This
is
when
you're
pulling
packages
for
this
project.
A
A
Right
and
it
looks
like
it
is
uploading
and
we
have
a
success
so
now
we
can
go
back
to
our
project
and,
of
course,
the
project
content
doesn't
change
because
we
didn't
do
anything
there.
We
want
to
look
at
our
package
list,
and
here
it
is
so
it's
my
maven
package
and
we
can
go
in
there
and
see
all
of
our
files.
A
Alright.
Next
up,
let's
take
a
look
at
NPM,
so
we
have
an
NPM
project
here
that
we
would
like
to
publish
a
portion
of
so
this
project,
we're
kind
of
going
with
the
idea
that
maybe
we
have
this
existing
project
that
has
a
package
that's
published
elsewhere,
but
we've
gotten
to
the
point
where
we
have
a
sub
component,
this
alert
component
and
we
want
to
publish
it
as
its
own
package
to
get
lab
separately.
So
it
has
its
own
package
JSON
and
it
will
have
its
own
configuration.
A
A
When
naming
your
package,
you
do
need
to
scope
and
PM
packages
to
live
in
the
namespace
of
your
organization
or
your
personal
namespace.
So
for
the
example
of
my
project,
mine
is,
in
my
personal
name,
space
on
gate
lab,
which
is
sa
rooms.
Yours
might
be
your
company's
top-level
group
or
your
own
personal
namespace,
and
then
from
there
we
can
add
whatever
package
name.
We
want
as
our
package
some
making
my
fancy
allure
component.
A
Alright-
and
so
this
needs
a
few
things
first,
we
want
to
set
our
registry
to
our
scope,
and
so
this
first
section
is
pointing
to
say
this:
is
the
registry
we're
using?
The
second
section
is
going
to
say
when
we
download
packages
we
need
an
auth
token
and
then,
when
we
upload
packages
for
this
last
section,
we
are
looking
at.
You
know
which
specific
project
are
we
uploading
it
to.
So
we
need
a
project
ID
here
and
then
we
need
our
token
so
I'm
going
to
grab
our
token
directly.
It's
the
same
personal
access
token.
A
And
so
this
is
what
is
allowing
us
to
publish
to
the
same
project
is
we're
using
the
same
project
ID
when
we
set
the
remote
in
NPM
to
publish
this
package
just
like
how,
when
we
used
maven
in
the
pom
dot
XML,
we
used
that
remote
in
order
to
publish
maven
to
that
same
project
all
right.
So
once
we
have
that,
let's
go
back
and
check
the
docs
to
see
what
else
we
need.
A
A
And
there
we
go,
looks
like
it
was
successful
and
we
can
check
back
with
our
registry
here
and
there
we
have
it
alright,
so
one
two
down
one
to
go.
Next
up
we're
going
to
take
a
look
at
Conan
and
so
I
have
a
conan
project.
Here
we
can
take
a
look
at
what
that
looks
like
it's
basic
hello,
world
type,
C++
project
I've
already
generated
the
conan
file
and
created
the
project
so
from
here
once
we
have
the
package
we're
going
to
see
how
we
can
push
it
to
that
same
project.
A
Availability,
so
the
way
that
you
name
the
conan
package
will
determine
what
project
it
belongs
to
and
you
have
to
have
permission
to
access
that
project
of
course.
So
if
we
look
at
this
naming
conventions
in
the
docs
here,
and
so
we
see
that
recipes
or
maims
must
be
the
plus
separated
project
path.
So
because
conan
has
a
use
for
these
slashes,
we
can't
use
the
project
name
as
it
is,
so
we
we
separate
it
by
pluses.
A
So
let's
go
ahead
and
create
a
package,
and
so
this
works
a
little
bit
differently,
because
Conan
doesn't
necessarily
need
all
of
the
configuration
files
that
we
had
for
me
been
an
NPM.
There
are
ways
to
do
this
using
configuration
files
or
commands
to
enter
them
into
your
own
coding.
Configuration
so
feel
free
to
do
that,
I'm,
going
to
kind
of
take
the
simplistic
route
and
just
create
a
new
package
here,
so
you
can
do
Kona
and
create,
and
so
usually
you
would
print
you
would
do
your
usual
or
user
and
channel
here.
A
All
we
really
need
to
do
is
set
up
a
remote
ahead
of
time,
and
so
Conan
only
has
one
remote
at
the
moment,
and
we
can
see
that
here
with
Conan
remote,
add
get
lab,
and
then
we
point
it
at
the
main
gate
lab
repository,
which
in
our
case
is
just
get
lab
comm
if
you're
using
a
self-managed
instance,
it
would
be
your
domain
I've
already
added
that
remote,
so
I
can
just
start
using
it.
As
we
see
here
for
being
able
to
authenticate
against
the
Conan
registry.
A
All
we
do
is
we
can
use
that
same
personal
access
token,
and
we
can
supply
it
as
the
and
password
environment
variable
with
our
commands.
This
can
also
be
set,
if
you
add
a
user
using
the
conan
commands,
but
for
the
purpose
of
this
demonstration.
I'll,
just
do
it
in
line
like
this,
so
we're
going
to
use
our
conan
login
username,
which
is
equal
to
our
git
lab
username,
and
then
we've
got
our
conan
password,
which
is
going
to
be
our
personal
access
token
that
we've
been
using.
A
A
Let's
take
a
look,
and
there
is
our
hello
packaged
version
0.1
that
we
just
created
alright,
and
so
you
can
see.
The
the
benefit
here
is
that
we've
created
a
single
project
that
holds
packages
of
various
types,
various
names
that
the
code
does
not
live
in
this
project.
It
may
not
even
live
on
git
lab,
but
it
allows
us
to
put
them
all
in
one
place.
So
that
way,
if
we
wanted
to
use
these
or
if
we
wanted
to
just
have
one
remote
for
all
of
our
different
projects,
you
know
company-wide.
A
We
could
just
use
this
project
remote,
which
is
unique
to
this
project
ID,
and
so
you
can
set
up
a
private
project
and
put
all
your
private
packages
there,
a
public
project
project
for
all
your
public
packages,
and
you
can
kind
of
divide
them
up,
however,
works
best
for
you.
Hopefully,
this
is
a
helpful
feature
for
you.
I
thought
it
was
a
pretty
cool
way
to
use
our
functionality
and
let
us
know
what
you
think,
thanks
for
watching.