►
From YouTube: Contributing to Open Match October 2020
Description
Want to make a code contribution to the Open Match project? Lead engineer Scott Redig walks you through it!
A
Hi,
my
name
is
scott
redig.
I
work
at
google
on
dope
match
chain
and
it
is
october
2020.
We
have
some
new
people
who
are
going
to
be
contributing
to
the
open
match
repo.
So
I
thought
I'd
give
a
quick
state
of
the
union.
What
the
code
base
is
where
things
are
that
kind
of
stuff.
By
the
way
you
can
tell
us
october,
because
I
have
my
pumpkin
and
my
spooky
black
cat
she's
she's
a
black
cat
all
year
round,
she's
just
spooky
for
october.
A
A
A
A
A
The
various
images
are,
some
of
them
are
core
components.
Some
of
them
are
testing
and
demo
on
that
kind
of
stuff,
all
to
add
a
new
image.
You
just
add
a
new
folder
to
this
directory.
You
can
see
plenty
of
examples
here
of
how
to
do
it
and
that
will
automatically
add
the
make
targets
and
that
kind
of
stuff
docs.
So
this
is
not
the
full
documentation
for
the
website.
A
You've
added
and
it
doesn't
add,
doesn't
build
up
a
backlog,
but
within
here
there's
some
templates
for
the
release
probably
can
ignore
that
and
then
here
there's
a
development
guide,
so
I'm
not
going
to
go
into
the
individual
commands.
I'm
just
gonna,
I
think,
leave
it
to
this
development
guide.
Here
it
gives
you
commands
to
build
the
code
to
install
the
prerequisites,
and
probably
you
know
the
most
important
ones
here
are
like.
A
How
do
you
actually
build
the
images-
and
you
know
it's
really
simple
here-
and
this
is
the
the
jproc-
is
important
for
building
it
quickly.
Oh,
yes,
it's
right
here.
Okay,
it
gives
you
information
about
that
help,
speed
it
up
and
then
how
you
can
do
deploy
to
kubernetes
and
iterate
and
that
kind
of
stuff.
A
Let's
see
in
examples,
we
have
a
few
different
things
if
you
want
to
produce
an
example
for
a
new
feature,
you
know
awesome
put
it
in
here
one
second:
there
we
go.
Okay,
then
there's
also
the
scale
tests
are
in
examples
for
some
reason
past
that
we
have
install,
which
is
where
any
yaml
or
helm
work
goes.
A
You
can
see
the
home
charts
here
if
you
need
to
modify
them.
Obviously
you
work
in
this
directory
for
the
demos.
We
only
have
the
yaml
to
simplify
things
a
little
bit,
but
for
the
most
part
I
think,
keep
to
home.
You
know
it's
not
the
greatest,
but
it's
important
I'll
get
back
to
internal
in
a
moment.
A
So
this
is
the
match.
Function
is
for
anyone
who
is
developing
a
match
function
in
go,
they
can
go
in
there
there's
some
example
or
sample
query
functions
to
like,
or
you
can
just
use
them
to
help
making
your
writing
match
function
easier.
Obviously,
not
all
match
functions
need
to
be
written
in,
go
because
it's
all
based
on
protobuf
so,
but
this
is
where
we
put
the
stuff
for
that
pb
is
the
compiled
or
like
the
transpiled
from
proto
to
go.
A
A
Third
party
is
imported
stuff.
I
think
you
can
pretty
much
just
ignore
it
and
I
remember,
what's
in
there
at
the
moment,
tools
also
probably
not
super
important
and
then
tutorials.
If
you
want
to
make
a
new
tutorial,
that'd
be
awesome,
I
don't
think
is
expected
here.
We
these
these
line
up
with.
What's
on
the
website
in
the
tutorial
section,
okay,
so
anything
else
here.
A
A
Internal
there
is
probably
the
most
important
folder
in
all
of
internal
is
app
app
corresponds
to
the
different
images
in
command.
As
you
can
see
here,
these
are
the
these.
Are
the
actual
implementations
of
the
different
pieces
of
open
match.
So,
if
we
look
at
the
front
end,
there
is
front
and
go
which
is.
This
is
how
I
start
up
like.
If
I
want
to
start
up
the
service,
you
know
the
calling
command
is
just
basically
call
to
this
wraps
a
little
bit.
A
This
is
how
do
I,
how
do
I,
you
know,
register
the
proto
server
that
I
want
to
run
any
other
function.
I
need
to
run,
and
you
can
see
here
within
the
front
end
service.
These
are
the
actual
calls
to
say,
create
ticket
or
do
the
various
things
there.
There
is
a
pattern
here
which
is
there's
a
front-end
service,
and
then
there
is
another
method
that
has
the
same
name:
that's
not
in
the
service
and
is
more
functional.
A
A
A
A
A
Generally
speaking,
the
server-specific
stuff
goes
into
the
app
the
rest
of
it
kind
of
goes
into
folders
in
this
internal
directory.
Here,
the
the
filter
directory
manages
the
logic
of
the
this
pool
match
these
tickets
and
it's
imported
by
the
quarry,
but
it's
also
just
kind
of
standalone,
because
we
kind
of
wanted
to
define
the
logic
you
know
separately
from
the
implementation,
although
we
ended
up
using
implementation.
A
So
there's
a
clear
place
where
that
is
state
store
is
where
we
include
all
of
the
logic
for
interacting
with
redis.
The
hope
is
that,
if
someone
wanted
to
replace
redis,
this
does-
or
you
know
have
an
interchangeability
of
you-
can
use
redis
or
you
can
do
something
else.
This
provides
an
interface
for
that.
The
interface
is
very
flexible,
though,
as
in,
if
you
needed
to
do
something
else,
just
make
it
do
something
else.
A
There
is
some
way
in
which
the
logic
is
spread
over
both
the
apps
so
like.
When
I
create
a
ticket
someone.
Some
of
the
logic
is
in
the
app
so
like
it
verifies
that
the
ticket
is
well
formed
in
the
app
folder,
and
then
it
passes
it
to
the
redis
implementation
here,
which
actually
calls
redis
and
says
you
know.
I
want
to
serialize
these
bytes
and
put
it
in
redis
this
way.
A
So
if
you
are
adding
new
functionality
kind
of
expects
to
make
a
change
in
app
to
add
like
a
new
call
site
and
then
also
a
change
in
redis
to
do
the
actual
communications
with
redis.
Currently
it
is
only
redis,
so
the
line
is
vague.
I
think
if
we
ended
up
with
a
second
database,
it'd
be
more
clear
of
where
things
need
to
live,
whether
it's
you
know
actually
usable
or
not,
given
the
state
we're
in
we're
just
kind
of
doing
best
effort,
don't
wrack
your
brain
too
much
about
it.
A
A
Okay,
this
is
this:
is
some
testing
stuff
for
end
times?
I
believe
so.
This
is
probably
how
you
want
to
most
think
about
testing
your
changes.
You
can
write
tests
in
front
end.
You
can
write
tests
in
state
store,
but
this
is
this
is
where
you
really
want
to
think
about.
Does
my
logic
work
end-to-end
the
way?
A
Let's
do
ticket
tests
so
if
we
look
at
ticket
tests
and
find
a
short
one
right
so
this
is.
This
is
a
very
simple
test
of
I
wanna.
You
know
I.
This
is
kind
of
a
test.
Helper
om
equals
new
om.
I
just
get
the
test
and
then
I
can
call
on
the
back
end.
You
know
I'm
oh,
and
that
back
end
says
I'm
gonna
call
the
back.
I
want
the
back
end
service,
so
this
is
the
proto
service.
A
I
can
call
release
tickets,
and
this
is
my
you
know
reporter
request
and
then
I'm
validating
that
the
you
know
I
didn't
get
an
error
and
it
just
gave
me
an
empty
response.
So
this
is
a
very
boring
test,
but
it's
like
you
can
call
release
tickets
with
an
empty
request
and
just
nothing
happens.
Basically,
we
have
a
lot
more
complicated
tests
here,
such
as
the
actual
really
stickers
test,
which
you
know
really
runs
to
the
paces
of
create
a
ticket.
You
know
I
try
to
look
at
these
examples.
A
Try
to
follow
the
format
of
them.
We
try
to
make
them
understandable,
but
this
crazy
ticket,
you
know,
make
sure
the
tickets
there
calls
fetch
matches
and
you
know,
runs
the
test
or
runs
a
runs.
A
cycle
you
know,
make
sure
the
ticket
isn't
in
isn't
returned
by
corey
anymore,
because
it's
in
a
pending
match
then
release
the
ticket
back
to
the
pool
and
then
query
again
and
make
sure
it's
available.
So
this
is
kind
of
a
way
to
run.
A
Do
a
full
like
this
is
what
I
expect
the
external
behavior
of
a
match
to
be
a
notable
part
of
this.
That
wasn't
in
the
previous
example
is
that
when
it's
running
in
this
test
environment,
the
match
function
is
not
a
predefined
match
function
but
can
be
set
by
some
functions
on
the
om
struct.
Here
you
know
you
can
say:
well,
I'm
gonna,
I'm
gonna
return
the
the
the
a
match
with
the
ticket
that
I
am
testing
with
here
and
then
in
the
evaluator.
A
A
So
the
really
nice
thing
about
these
tests
is
that
they
run
both
locally
and
in
the
cluster.
So
what
I
mean
by
that
is,
if
you
just
do
a
go
test
on
the
directory
or
on
this
directory
or
just
the
whole
openmesh
directory,
you
will
run
these
tests
locally.
They
will
bring
up
a
fake
redis
instance
in
memory
all
of
the
binaries.
You
know
this
this
space.
Actually,
we
can
see
here.
A
Are
you
know
we
build
each
image
individually,
do
a
helmet
stall
into
the
cluster
and
do
things
that
way
so
that
we're
you
know
we're
testing
all
the
logic
locally,
but
we're
making
sure
that
things
don't
fall
over
in
the
cluster,
the
usually
where
you
could
break
this
is
if
you're
changing
home
or
that
kind
of
stuff,
but
it
should
also
detect
any
you
know
failed
assumptions
of.
Oh,
I
thought
you
know.
A
A
Those
are
actually
run
in
the
test
instance,
so
a
fetch
match
will
call
out
to
the
back
end
and
the
back
end
for
fetch
match
will
call
back
into
the
test
instance,
for
I
want
to
run
the
match
function,
so
the
mmf
and
evaluator
are
still
run
locally,
but
for
in
cluster
testing,
everything
else
is
run
in
the
rest
of
the
cluster
in
separate
pods.
You
can't
get
to
them
other
than
to
call
them
with
rpc.
A
Well,
you
want
to
break
it
down
into
a
couple
pieces
right
there.
I
can
give
actually
a
good
example
here,
which
is
the
filtering,
so
the
filter
tests.
Well,
we
have.
We
have
a
bunch
of
test
cases
here
which
are
reused
elsewhere,
but
the
filter
tests
say
I
have.
I
have
a
unit
of
logic,
that's
a
peer
function
for
does
this
ticket
or
like,
given
this
pool
specification
and
these
tickets,
which
ones
match
right.
A
A
Mix
mixed
value
or
low
value,
if
you
do
a
unit
test
of
it,
because
mostly
what
you're
unit
testing
is
that
you
are
doing
you're,
calling
the
methods
that
you
expect
to
call
with
that.
You
know
you're
just
doing
a
change
detector
test
with
that,
you
don't
know
if
it
actually
works
and
it
actually
will
create
a
ticket.
A
But
if
someone
goes
and
changes
how
quick
tickets
are
created
now
they
need
to
fix
this
test.
Even
if
that
test
still
works
or
even
if
the
new
method
works.
You
know
I
I
can.
I
can
say
I
expect
to
call
redis
with
this
function,
but
I
don't
know
if
redness
actually
behaves
correctly
when
I
call
that
function
and
if
the
state
is
what
I
expect
it
to
be,
and
a
key,
a
key
characteristic
of
this
code
is
that
it
doesn't
have
branches,
except
maybe
air,
handling
right.
A
So
if
you
can
split
your
code
cleanly
in
that
those
places
like
this
is
a
fun
pure
function,
that's
making
choices,
I'm
going
to
need
to
test
it.
This
is
just
a
bunch
of
commands.
I
need
to
run
to
get
the
thing
to
work.
I'm
going
to
use
the
testing
integration
testing
to
test
that
that
is
the
ideal
world.
A
If
sometimes
things
break
down
a
little
bit
either
you
need
to
do
some
wacky
tests
that
are
more
unit
testy
on
code
that
doesn't
really
like
being
interested
or
if
you
can
just
do
a
bunch
of
integration
tests
to
go
over
the.
If
statements
or
logic
that
you
have
to
use
in
your
for
your
code
in
the
n10
tests.