►
From YouTube: Branch Rules GraphQL Endpoint
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
So
this
feature
we're
as
a
part
of
an
ongoing
effort
to
improve
the
gitlab,
UI
or
ux
we're
creating
a
a
page
is
going
to
be
a
read-only
page
where
they
can
view
all
of
the
the
rules
that
are
related
to
a
specific
branch
in
a
project.
A
A
To
implement
this
back
end
needs
to
add
these
data
points
to
the
graphql
endpoint.
So
let's
talk
a
little
bit
about
how
that
works.
A
A
We
can
also
use
resolvers
to
point
to
different
data
data
sets
which,
in
this
case
we
have
to
because
our
naming
in
the
database
is
actually
slightly
different
from
what
we
want
to
expose
so
we're
exposing
this
field,
Branch
rules,
but
really
in
the
database.
It's
actually
the
protected
Branch.
So
protected
branch
is
the
the
root
node
for
all
of
all
of
these
Associated
rules,
so
from
Branch,
protected,
Branch,
so
yeah
protective
Branch,
not
Branch
protection.
A
So
from
a
protected
Branch
model,
we
have
associations
to
approval
rules
and
also
vulnerability
scans
and
at
some
point,
we're
going
to
have
to
figure
out
how
to
also
connect
security
policies
which
are
kind
of
isolated
at
the
moment
and
have
their
own
flow
yeah.
So
let's
explain
a
little
bit
about
how
we
Define
the
schema
for
graph.
So
this
file
here
is
the
project
type.
So
this
defines
what
we
can
expect
to
return
from
the
project
node
in
graphql.
So
this
is
graphical
I.
Think
you
can
see
this
right.
A
A
Yeah,
so
Branch
rules
to
the
second
line
is
the
type
of
field,
so
the
ID
field,
before
you
I
noticed,
is
actually
a
GID,
that's
a
type
that
we've
defined,
and
this
is
also
a
type
which
I
have
created,
so
I've
created
the
branch
rule
type
and
because
we
are
using
a
collection
here,
it's
not
a
single
record.
We
have
to
use
the
connection
type
from
the
type
and
then
we
can
configure
some
other
stuff
like
null
tree
which
allows
the
field
to
be
nullable.
A
It
tells
the
graph
logic
where
to
pull
the
data
from
so
because
we
have
this
slightly
unusual
setup
where
Branch
rules
are
actually
protected
branches
in
the
database.
We
need
a
resolver
to
tell
a
graph.
You
know
how
to
fetch
that
data.
So
this
is
the
resolver
here.
This
one
is
a
very
simple
resolver.
They
can
be
quite
a
lot
more.
You
know
complex
than
this
in
this
case,
we're
literally
just
telling
it
the
base
object.
That
has
been
passed
in,
which
is
the
project.
In
this
case.
A
A
Stop
me:
if
you
have
any
questions
and
the
gradual
type
each
type
we
Define,
the
name
so
graphql
name
is-
is
defining
what
the
object
will
be
named
within
the
graphql
description,
and
then
it
tells
us
we're
going
to
tell
it
that
it
accepts
protected
branches.
We
could
actually
have
a
list
of
objects
in
here.
In
this
case,
we
only
want
to
present
protective
Branch
records.
A
If
you
want
to
protect
it,
Branch
or
Branch
rule.
We
could
have
you
know
an
array
in
here
with
protective
Branch
comma
transform,
and
then
we
also
do
some
authorization.
Authorization
can
be
done
on
three
levels.
It
can
be
done
on
the
type
itself.
So
that's
going
to
pretend
prevent
anybody
from
fetching
any
types.
If
this
authorization
fails,
it
can
be
done
on
the
field
level,
and
it
can
also
be
done
somewhere
else,
which
I
can't
remember
right
now
so
authorized,
maybe
a
resolver,
maybe
a
result.
Yes,
a
resolver
level
yeah,
that's
right!
A
A
A
A
So
a
node
is
essentially
like
a
has
one
or
it
belongs
to
relationship,
whereas
an
edge
is
a
collection
so
like
it
has
many
relationship
or
hasn't,
belongs
to
many
relationship
and
then
the
different
ways
to
you
know
we
have
to
you
know
we
have
the
way
that
we
Define,
which
type
is
going
to
be,
as
you
specify
the
type
of
field
here,
if
it's
a
singular
type,
we're
just
passing
the
type
record
or
type
class.
B
A
A
A
A
B
Ahead
yeah,
thank
you
for
the
presentation.
I
think
it's
a
good
starting
point
for
people
who
want
to
know
how
to
do
the
graphql
at
gitlab,
because
you
have
some
specific,
like
our
setup,
is
a
bit
like
different
from
the
default
one.
So
I
think
that's
really
useful.
B
And
I
have
one
question
here:
just
because
I
didn't
follow
thoroughly.
The
topic
here,
I
see
now
that
Branch
rules
are
basically
protected
branches
yeah
in
the
moment,
yeah
right
but
I.
Remember
there
were
discussions
here
between
you
and
vasilia
that
regarding
moving
it
into
different
database
like
structure
yeah,
do
we
plan
to
do
it
or
so
did
we
decide.
A
A
Did
actually
write
a
lot
of
codes
to
do
that
and
then
halfway
through
doing
that,
we
realized
that
essentially,
all
of
the
features
that
we
needed
could
already
be
implemented
or
already
are
implemented.
A
However,
the
structures
a
little
bit
unusual,
if
you
look
at
this,
you
know
the
response
from
this
graphql
endpoint.
You
might
expect
a
database
to
be
structured
a
little
bit.
A
But
yeah
everything
was
already
there,
so
we
felt
like
it
was
a
bit
unnecessary
because
we
would
need
to
be
running
a
lot
of
migrations
to
migrate
every
single,
protected
Branch
over
to
a
new
record
in
a
branch
Branch
Rule
table,
and
then
we'd
also
need
to
do
the
finalization
migrations.
Next
next
release
cycle
and
stuff
like
that.
So
for
now
we're
putting
that
on
hold-
and
my
assumption
is
currently
that
we
probably
won't
ever
need
to
do
that.
A
But
if
we
do
in
the
future
the
way
that
we've
built
this
we'll
be
able
to
because
we
have
these
results
are
telling
it
where
the
pointy
will
essentially
be
able
to
add
the
models.
And
then
you
know
reconfigure.
Those
results.
B
A
Cool
okay,
well
I,
guess
I,
probably
recorded.