►
From YouTube: GitLab-EE 13.10 - JH 13.10 and repo tour
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
The
majority
I'll
actually
be
focusing
on
showing
off
the
forked
repos
that
exist
for
the
omnibus
for
jihu
and
the
cng
images
project
and
walking,
through
kind
of
aimed
at
information
sharing
for
the
distribution
team,
how
those
repos
are
set
up
differently
than
our
own
in
terms
of
building
and
stuff,
like
that,
so
we'll
go
ahead
and
jump
in.
So
I
have
a
gitlab
ee
instance
running
here
in
my
vm
just
a
test
instance:
nothing
special
about
it
just
installed
by
default,
I'm
gonna
go
ahead
and
install
the
jh
package.
A
B
A
Is
different,
the
and
otherwise
that's
the
only
like
metadata
difference
between
the
two
at
the
for
this
version.
There
is
one
additional
difference
is
that
the
maintainer
is
also
with
this
latest
release.
1311
that
came
out
today.
The
maintainer
has
also
been
swapped,
and
that
just
represents
a
difference
in
which
which
company
is
actually
building
them.
So,
while
we
were
building
the
images,
the
retainer
is
us
that
corresponds
to
our
package,
signing
key
and
now
for
1311
the
package.
A
A
Future
plan
changes
are
are
for
enhancing
support
for
things
like
tencent
cloud
and
ali
cloud
and
stuff
like
that,
so
it
won't
just
be.
It
won't
just
be
cosmetic
in
the
future,
but
largely
for
the
for
our
projects
for
omnibus
and
cng.
It's
it's
likely
just
the
build
process
that
differs
in
the
build
packaging
and
stuff
like.
A
B
B
B
A
Yeah,
so
the
cosmetic
difference
you
can
see
here
is:
the
logo
has
been
changed
out
to
be
the
gitlab
g2
logo
and
then
functionally,
I
shouldn't
say
just
cosmetic,
but
I
I
mean
like
no
core
functionality
has
been
changed,
but
the
license
code
has
also
been
changed,
so
it
actually
uses
a
different
licensing
key.
So
a
gitlab
ee
license
uploaded
to
this
doesn't
actually
activate
any
of
the
ee
features.
You
need
a
gu
license
to
activate
ee
features
here
in
this
product.
A
And
and
that's
that's
it
in
terms
of
differences
at
the
moment,
mostly
just
a
package
name
and
a
logo
for
now,
as
as
the
difference
in
the
actual
package,
so
let's
go
ahead
and
jump
over
to
the
repos,
which
is
really
where
the
majority
of
the
work
has
gone
in.
So
here
I
am
in
the
gitlab
jh,
I'm
gonna
skit
lab
repo.
So
currently
this
is
a
mirror
of
our
omnibus
gitlab.
A
Brings
up
their
sas
and
brings
up
all
their
services.
This
will
probably
swap
to
be
a
mirror
of
their
omnibus
get
lab
repo.
So
what
will
happen
is
in
in
their
sas
service,
they're,
mirroring
our
omnibus
and
then
here
in
gitlab.
This
becomes
our
mirror
of
their
changes
type
thing
as
they
do
any
of
their
build
work
in
their
sas.
A
But
at
the
moment
this
is
the
the
working
project.
It's
publicly
viewable
publicly
available
here,
and
this
is
where
changes
go
in.
So
in
terms
of
the
changes,
the
the
mirroring
mirrors,
all,
of
course,
it
mirrors
all
protected
branches
from
our
omnibus
git
lab
and
those
none
of
those
branches
or
any
of
the
code
in
those
branches
are
changed,
so
master
isn't
changed.
None
of
the
stable
branches
are
changed.
A
What
we
did
instead
was
create
new
branches
in
this
repo
for
any
of
the
jihu
related
stuff,
and
then
we've
changed
some
of
the
project
settings
to
make
better
use
of
those
branches.
So
you'll
see
we
have
instead
of
master,
we
have
a
main
jh
and
that's
our
default
branch,
so
that's
being
used
instead
of
mastering.
So
that's
just
the
the
jh
specific
changes
merged
on
top
of
master
and
that
gets
merged
semi-regularly
and
then
everything
else
is
in
separate
branches
and
separate
tags.
A
A
A
So
this
was
one
method,
and-
and
this
is
this
is
the
whole
file
here.
This
is
one
method
and
that
we,
this
was
done
this
way
with
a
change
to
the
main
level
see.
I
felt
this
actually
had
to
run
not
only
in
this
repo,
but
also
in
dev
at
the
time,
we're
no
longer
running,
builds
and
devs.
So
some
of
this
configuration
can
change
at
this
point,
but
over
in
the
cng
images
side,
where
we
also
do
releases,
we
were
doing
releases
not
from
deb.
A
We
were
actually
doing
releases
right
from
this
project
in
gitlab.com,
so
we
were
able
to
model
the
ci
more
like
how
the
jihu
team
are
likely
to
model
it
on
their
own
instances.
So,
once
again,
you'll
see
we
have
the
branching.
Is
the
same,
we
have
the
main
jh,
but
rather
than
make
any
changes
to
the
cimo
file,
so
there's
zero
changes
to
this
file.
A
A
A
So
that's
how
this
one
was
done
being
that
was
built
in
here
going
forward,
probably
though
there
won't
be
any
like
include
of
the
top
level
file.
Now
that
the
build
systems
are
completely
separate,
the
jihu
team
is
building
from
their
own
devops
instance.
Probably
they
will,
just
as
as
they
have
different
build
needs.
They'll,
probably
just
you.
A
My
recommendation
is
for
them
to
just
use
the
rci
files
as
examples
of
how
to
set
up
their
build
systems,
and
so
they
will
probably
instead
look
like
a
duplicate
somewhat
of
a
duplicate
of
ours,
but
with
the
things
they
don't
need
of
ours
removed
and
the
things
that
they
need.
Added
added
and
the
the
reason
for
that
is
is
in
this
current
system.
A
Changes
that
we
make
to
our
ci
files
are
likely
to
break
or
potentially
break
their
build
system
unnecessarily,
and
we're
hoping
to
avoid
that.
So
the
idea
is
while
a
lot
of
the
like
the
actual
build
code,
that's
being
run
should
be
the
same,
and
we
do
want
that
shared
and
to
be
when
we're
building
code
or
when
we're
making
changes.
A
A
Yeah
and
that's
that's
basically,
basically
yet
the
majority
of
the
changes
actually
are
just
the
ci
file
in
omnibus
we
put
in
a
couple
like.
Basically,
all
the
changes
had
to
be
around
anything
where
we
had
hard-coded
that
things
can
only
be
ce
or
ee
in
terms
of
version
checks
were
the
only
things
changed.
A
Most
of
those
changes
actually
are
upstreamed
and
are
not
specific
to
this
repo,
I'm
back
in
the
on
the
s1
here,
but
one
change
that
is
specific
to
the
repo
is
in
projects
we
have
in
our
main
repo.
We
have
just
these
these
two
that
represent
the
two
different
packages
and
in
the
jihu
repo
we
have
one
more
and
like
this
is
the
extent
of
of
the
changes
in
it.
So
you'll
see,
like
I
mentioned
before,
that
the
the
maintainer
has
recently
changed,
but
otherwise,
like
this.
A
A
A
A
And
I
think
that's
about
it.
There's
not
there's
not
too
much
magic
going
on
in
these
in
these
repos.
At
this
point
other
than
the
ci
files
themselves
are
probably
the
most
like
are
probably
the
most,
I
wouldn't
say
happy,
but
the
most
non-standard
thing
going
on
in
the
repos.
Everything
else
changes
that
we've
needed
have
been
pretty
much
upstream
to
be
more
flexible,
like
upstream
to
our
own
ripples,
to
be
more
flexible
in
the
idea
that
there
could
be
more
than
just
two
packages.
A
I
would
say
going
forward
as
a
as
a
cleanup
task
for
our
projects
that
came
that
resurfaces.
Part
of
this
is
when
looking
at
the
differences
between
having
to
do
this
ci
file
for
omnibus
versus
cng
omnibus,
if
we
jump
back
into
the
the
ci
file,
you'll
notice,
there's
not
really
content
in
this
font,
like
it's
just
different
jobs.
A
There's
not
really
different
content
like
there's
a
few
different
environment
variables,
but
there's
a
different
content,
and
that's
because
we
already
in
all
minibus,
we
already
genericized,
all
of
our
build
stuff
to
you
know,
run
one
command
and
it
figures
out
whether
it's
ce
or
ee.
So
that
just
meant
that
those
things
also
like
those
that
code
paths
were
just
updated
to
like
figure
out
if
they're
c
e
e
or
j
h-
and
there
was
no
other
work
here
in
the
cng
images.
A
A
Like
we
haven't
gone
through
and
de-duplicated
the
work,
and
by
duplicated
I
mean
like
basically
it's
all
the
same:
minus
typically
like
one
line
of
of
difference
of
the
j
of
the
ee
versus
ce,
and
it's
usually
just
like
the
from
images
build
our
pointing
to
a
specific
version
is
typically
the
only
difference
between
our
ce
and
e.
So
as
like
a
future
cleanup
to
allow
the
jihu
team
to
eliminate
all
this
content,
because
this
shouldn't
really
have
to
be
like
specific.
A
A
lot
of
the
stuff
shouldn't
have
to
be
specific
to
their
their
stuff.
It's
just
duplication
and
to
also
clean
up
our
duplication
would
be
good
to
do
something
similar
to
what
we've
done
in
omnibus,
which
is
like
all
all
this
sort
of
build
logic
should
be
not
in
the
ci
file
itself,
but
in
like
library,
files
or
build
scripts,
or
something
like
that
in
the
omnibus
we
use
rake
and
we
have
them
built
into
rape
tasks,
for
example.
A
A
B
B
B
A
A
Answering
phase
sharing
and
knowledge
sharing
with
with
the
team
over
there
as
they
are
preparing
to
bring
up
so
they've
already
brought
up
their
build
system
so
as
they
continue
to
tweak
their
build
systems
or
run
into
issues
with
them.
But
then
I
think
they're
bigger
they
kind
of
have
that
under
control
at
the
moment,
so
the
bigger
one
they're
working
on
is
bringing
up
their
actual
sas
gitlab
cn.