►
From YouTube: GitLab CE and EE in Ruby Code
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).
B
Cool
so
yeah
thanks
very
much
for
for
having
me
so
a
couple
of
weeks
ago,
I
was
assigned
this
ticket
generalized
patch
endpoint
of
protective
branches,
API.
A
B
Myself
and
Igor
Igor
helped
me
a
lot
with
it.
It
was
one
of
the
first
PRS
or
first
sorry,
first
issues
that
I
worked
on
and
he
kind
of
given
that
it
was
looking
at
Community,
Edition
and
Enterprise
Edition.
He
seemed
to
think
that
it
might
be
a
good
idea
to
kind
of
you
know,
presented
the
team
and
see
if
people
are
aware
of
some
of
the
some
of
the
contacts
around
working
with
Enterprise
versus
Community
Edition
code.
B
So
for
a
lot
of
you,
this
might
be
pretty
much
like
day-to-day
sort
of
stuff,
but
for
me
I
guess,
and
maybe
some
others
on
the
team-
and
maybe
not
so.
Basically,
we
have
this
endpoint
for
protected
branches,
apis
or
patch,
and
you
can
see
here
in
the
code,
so
this
is
are
in
the
documentation.
This
is
before
we
made
our
change.
B
B
So
after
we
made
our
change,
we
now
have
here
on
the
right
hand,
side
you'll
see
this
is
for
15.6
and
we
have
our
patch
endpoint
and
instead
of
the
whole
endpoint
being
for
premium
customers,
only
we
have
our
only
our
our
premium
attribute
here
is
marked
as
premium.
So,
how
does
this
work?
How
do
the
two
different
code
bases
interact?
How
do
we
go
about
a
tune?
Something
like
this?
B
So,
there's
a
really
good
blog
post
about
this,
which
explains
how
gitlab
has
come
to
use
the
Community,
Edition
and
Enterprise
Edition
and
what
it
was
formally
so
as
far
as
I
can
tell
formally,
it
was
two
different
repositories
and
Memoirs
would
get
kind
of
pushed
from
one
to
the
other
and
maintaining
that
and
keeping
the
specs
functioning
in
that
context
was
proving
quite
difficult
as
the
project
got
more
complex.
B
So
some
of
you
guys
in
the
engineering
team
might
be-
you
may
have
been
here
for
when
this
was
done,
but
they
kind
of
decided
as
far
as
I
entitled
to
move
to
just
having
the
Enterprise
Edition
as
the
single
Repository
and
break
out
the
Enterprise
Edition
code
into
a
separate
folder
within
their
repo.
So
if
we
look
here
at
Ruby
mine,
you
can
see
on
the
right
hand
side
here
in
the
root
of
the
project.
B
We
have
an
ee
folder,
so
that's
where
all
our
Enterprise
Edition
code
goes
and
that
effectively
gets
injected
into
the
core
of
the
product.
So
for
this
particular
issue
that
I
was
working
on
and
obviously
this
is
before.
We've
made
any
of
our
changes
I'm
here
on
the
tag
15.5
and
we
can
see
we
have
our
patch
endpoint
and
we
can
see
so
for
this
API
and
then
we
look
at
the
protected
branches,
API
endpoints.
Here
we
can
see
at
the
bottom.
We
have
API
protected
branches.
Excuse
me
prepend,
but
mod
API
protected
branches.
B
B
All
of
the
endpoint
was
only
available
to
Enterprise
Edition
customers.
So
the
way
this
works,
the
prepared
with
Mod,
is
quite
well
documented
in
the
guidelines
for
implementing
ee
features
and
there's
a
lot
of
different
ways.
We
can
override
CE
methods,
so
we
can
take
C
code
and
we
can
manipulate
it
override
it
and
call
it.
You
know
and
extend
it
in
this
way
and
there's
a
few
things.
We
need
to
look
out
for
like
using
or
flagging
that
we
have
overwritten
methods
here.
B
I
guess
it's
finally
forgotten
or
being
careful
with
guard
Clauses
Etc,
so
this
is,
if
you're
encountering
this
sort
of
stuff.
Obviously
this
document
is
well
worth
a
read
and
it
kind
of
it's
quite
thorough,
it'll
guide
you
in
the
right
direction.
B
So
we
ended
up
kind
of
moving
that
whole
patch
endpoint
here
into
the
protected
branches,
API
I'm,
making
a
few
other
changes
along
the
way,
but
mostly
it's
very
similar.
We
added
in
the
patch
endpoint
and
then
we
added
our
params
separately.
So
in
this
API
service
here
we
have
our
Prime
our
attributes
down
the
bottom
and
in
the
Enterprise
Edition
is
the
Enterprise
Edition
API
service.
B
Here
on
the
left,
you
can
see
that
we
override
the
attributes
and
if
we
have
the
Enterprise
Edition
permission,
we
add
our
code
owner
approval
required
into
the
attributes.
So
that
effectively
is
the
check
to
see.
Does
the
user
have
the
ability
to
to
use
Enterprise
Edition
features
and
we
can
kind
of
isolate
it
down
to
a
singular
attribute.
I've
noticed
here
that
I,
probably
or
I,
think
I
should
have
added
the
override
flag
on
top
of
this
method
as
well.
B
So
that's
something
I
probably
have
to
come
back
and
clean
up
so
effectively.
Then
what
that
allows
us
to
do
is
add.
Another
param
like
allow
Force
push
into
the
core
of
the
of
the
product,
which
is
like
non-enterprise
Edition
code
and
utilize
instead
of
duplicating
Azure
another
patch
endpoint,
we
can
just
use
the
same
one
and
in
that
way
we've
kind
of
3D
edition
attributes
and
Enterprise
Edition
attributes
put
together,
so
that's
kind
of
it.
We
have
it's
quite
short.
B
Sorry
I
think
that
the
technical
challenge
of
why
gitlab
decided
to
they
kind
of
implement
the
system
like
this
is
really
interesting
and
there's
these
two
blog
posts
kind
of
describe
it
in
a
lot
of
detail
and
they
describe
some
of
the
issues
they
were.
The
team
were
running
into
before
they
made
the
change,
and
then
you
know
effectively
how
Ruby
solved
the
problem
by
allowing
us
to
add
our
modules
in
separately.
B
C
I
do
have
not
necessarily
a
question
but
I
I
noticed
in
so
the
update
I've
also
been
working
on
protective
branches,
but
for
the
graph
apis.
So
I
have
quite
a
lot
of
insight
into
this.
So
in
the
ee
version,
access
levels
like
push,
merge
and
unprotect
yeah
also
allow
also
allow
us
to
specify
a
user
or
a
group,
but
I'm
not
saying
that
in
your
code.
Is
that
something
that
we
should
be,
including
in
this
endpoint.
B
Yeah
I
think
there's
a
follow-up
there's
a
follow-up
ticket
for
this,
which
I'm
currently
working
on,
which
isn't
merged
at
which
we
are
allowing
access
levels
to
be
specified
so
effectively.
This
is
like
the
kind
of
lay
in
the
groundwork
for
those
attributes
later
on
yeah,
so
I
actually
have
an
MR
for
that
at
the
moment.
On
my
opinion,
I
think.
A
B
And
you
know,
as
far
as
I'm
aware
at
the
moment
you
just
you
know
you
write
specs
for
Enterprise
Edition
code
and
then
you
write
respects
for
Community
Edition
code,
and
there
should
be.
You
know
you
should
be
reasonably
able
to
isolate
them
like
that.
There
is
some
detail
about
that
in
the
documentation
here
as
well.
B
A
A
Well,
my
next
question:
maybe
you
might
be
able
to
help
us
with
Amy
so
so,
when
a
customer
has
a
cell
I,
don't
know
or
maybe
not,
but
when
a
customer
has
a
self-hosted
environment
and
if
they're
on
the
Community
Edition
do
we,
you
know
when
we
look
at
the
documentation,
we
see.
Oh,
this
is
a
premium
feature.
Do
we
somehow
segregate
the
documentation
or
do
they
have
documentation?
It
says
you
have.
These
are
pretty
features.
A
D
A
C
C
Request,
yeah
yeah
so
currently
there's
some
difference
between
all
the
different
pages,
so
we
have
patch
products,
ID
protected
branches
name.
So
in
here
we
have
two
parameters:
ID
and
name
in
some
of
these
Pages.
We
have
a
table
that
describes
just
those
parameters
for
the
URL
and
then
in
other
Pages
like
this
one.
We
don't
have
that,
but
we
have
a
mixture
of
both
the
URL
parameters
and
the
body
parameters,
but
we're
not
really
describing
like
where
they're
inserted.
D
I
am
currently
dependent
on
my
Engineers
to
get
this,
but
yeah
I
have
been
cleaning
up.
Some
of
the
API
related
pages
and
creates
are
in
okay,
I,
don't
know
if
they're,
actually
in
worse
shape
than
the
rest
of
the
API
docs,
but
they're,
definitely
old
high
Igor.
Thank
you
and
I
personally
would
like
to
see
us
spell
out.
Both
both
sets,
both
both
the
parameters
and
all
of
all
of
the
responses.
A
Well,
it's
it's
not
it's!
It's
not
bothering
and
Amy
I'm
just
going
to
say
you
know
now
that
we're
actually
on
the
record.
Thank
you
so
much
for
taking
this
initiative,
because
I
don't
think
you'll
find
that
I
think
we'll
find
that
you're
going
over
and
above
on
this,
and
it's
really
appreciated,
because
clean
documentation
is
very
important.
It
is
yeah.
A
Well,
what
you
can
do
is
we
can
create
the
issues
and
and
treat
them
as
stretches
for
the
research
I
think
that
okay
worked.
E
Just
a
quick
note:
maybe
we
need
to
wait
a
bit
on
this
one,
since
you
mentioned
Sean
that
we
have
this
work
group
for
API.
Maybe
we
will
receive
some
insights
from
that
work
group,
so
maybe
not
to
do
redundant
work.
We
can
wait
on
this
one
and
see
what
insights
they
have
on
their
documentation
as
well
and
on
the
API
that
we're
using
that's
a
great
point.
I'm.
A
So
Gavin,
thank
you
very
much
for
your
presentation.
It
was
very
interesting
and
very
informative.
Maybe
you
can
drop
the
links
in
the
in
the
document.
You
look
like
you.
Do
it
every
day,
thanks
very
much
I,
better,
stop
the
recording,
I
guess.