►
From YouTube: Leveraging Auto DevOps for Java Applications
Description
When relying on private project package registries and Auto DevOps, there are a few things you'll need to have setup to be successful. The aim was to outline the needs in this video.
https://gitlab.com/gitlab-gold/tpoffenbarger/simple-maven-app
A
Hi
everyone,
my
name
is
tim
poffenberger
and
I'm
a
solutions
architect
with
git
lab,
and
I
was
wanting
to
map
out
a
use
case
of
two
java
applications.
Two
separate
repositories.
One
of
them
is
going
to
build
a
java
library,
that's
going
to
be
used
by
the
other
project.
The
other
project
is
going
to
build
a
docker
file.
A
In
order
to
do
this,
we
can
leverage
the
get
lab,
maven
template
so
simply
including
template,
maven
dot,
get
lab
yemold
and
then
setting
up
our
palm.xml
and
ci
settings.xml
file.
The
ci
settings.xml
file
is
going
to
leverage
the
job
token
so,
and
we're
just
going
to
give
this
the
label
of
the
maven
and
this
information
is
going
to
be
relevant.
A
For
this
palm.xml
file,
which
will
then
leverage
this
environment
variable
ci
project
id
during
the
build
process.
So
now
what
we're
going
to
do
is
upon
successful
completion.
We'll
actually
see
that
there
is
this
package
got
published.
The
ci
job
token
is
really
great
when
you're
utilizing
stuff
within
that
particular
project.
A
If
you
wanted
to
use
this
dependency
on
a
separate
project,
what
we'll
have
to
actually
do
is
set
up
a
an
access
token
in
this
project,
so
within
the
the
dependency
project
or
the
library
project,
we're
going
to
go
ahead
and
create
a
project
access
token.
So
you
can
see
that
I
have
the
scope
of
read
api.
This
is
the
only
scope
that
needs
to
be
available.
Just
a
few
things
to
note
repository
is
your.
Your
git
repository
registry
is
only
for
container
registry.
A
I
think
that's
an
important
thing
to
note:
it's
not
package
registries,
so
I'm
going
to
head
on
over
to
so
everything
got
published
I'm
going
to,
and
you
can
actually
see
that
the
pipeline,
what
the
pipeline
looks
like
it's
just
deploying
that
out
and
then
so
now
we're
in
the
application.
So
simple,
maven
app.
What
is
going
to
happen
here
is
we're
going
to
leverage
autodevops
to
build
autodevops,
utilizing
heroku
to
build
a
container
that
will
then
run
this
given
application.
A
So
one
of
the
things
initially
that
I
did
was,
I
took
that
ci
variable
and
I
put
it
in
our
gitlab
ci
settings.
So
if
I
go
to
settings
and
ci
variable-
and
now
you
can
see
that
there's
this
project
token,
which
is
referring
to
the
project
token
from
the
simple
maven
dep
project
and
this
project
token,
is
then
going
to
be
set
here,
and
this
is
going
to
be
useful
for
a
couple
of
reasons,
and
I
have
this
gitlab
yaml
file,
this
emo
file
is
a
little
bit
more
involved.
A
A
For
that
build
process
to
take
place,
we're
also
overriding
gymnasium,
which
is
our
dependency
scanning
tool,
as
well
as
spot
bugs,
which
is
our
static
analysis
tool
and
we're
providing
the
hyphen
s
for
settings
and
our
settings.xml
file.
So
it
knows
the
settings.xml
file
to
use
and
let's
take
a
look
at
that
file
right
there.
Now
the
settings.xml
file
is
going
to
have
a
property
set
for
private
token,
and
it's
going
to
leverage
that
environment
variable
of
ci
project
token.
A
And
that
is
important
for
this
palm.xml
file.
There's
two
things
that
I
want
to
call
out.
This
palm.xml
file
has
two
repositories
set
up
in
it.
One
of
them
is
going
to
be
the
the
maven
central
repository
and
then
the
maven
repository.
This
is
important
to
note,
because
it's
going
to
try
this
repository
first
and
if
it
fails,
then
it
will
go
ahead
and
resolve
the
dependencies
from
that
secondary
repository,
utilizing
the
credentials
that
project
access
token
that
we
that
we
grabbed
from
the
first
project
and
what
the
successful
pipeline
looks
like.