►
From YouTube: Support Ops - Zendesk - Sync Repos
Description
Jason Colyer, Support Operations Manager, takes us through how the Zendesk sync repos work.
A
Greetings
all
my
name
is
jason
collier,
I'm
the
support
operations
manager
here
at
kit
lab
and
today
we're
going
to
go
over
how
the
sync
repos
work
for
zendesk.
We
like
to
do
as
much
of
our
work
through
the
sync
repos
as
possible.
They
allow
for
version
controlling
they
allow
for
easy
rollbacks.
They
allow
for
an
approve
or
review
approved
process.
A
A
So
what
you
see
right
now
is
the
zendesk
macros
project.
This
is
where
we
hold
all
of
the
macros
that
are
synced
into
zendesk.
I
picked
one
at
random,
so
you
know
there's
no
specific
reason.
It's
this
one,
so
at
its
core.
What
we
really
have
here
is
a
get
lab
ci
file
and
in
this
we're
specifying
the
image
to
be
ruby.
2.5
just
haven't
gotten
around
to
upgrading
it
yet,
and
we
kind
of
set
the
stages
of
gather
sandbox.
Compare
to
sync
now
macros
are
a
little
specific.
A
They
used
to
sync
to
the
sandbox.
We
have
that
disabled
for
the
time
being,
but
it
could
come
back
into
play.
We
have
the
cache
where
we
set
the
path
to
vendor
ruby.
This
is
just
so.
It
doesn't
take
as
much
time
installing
gems
between
runs
and
then
we
set
up
a
before
script,
where
we're
gonna
make
sure
that
call
the
ruby
version.
We
do
that
just
so.
We
can
check
to
make
sure.
Yes,
this
is
the
version
we
intended
to
use
it's
good
for
debugging.
A
We
then
called
jim
install
bundler,
so
we
installed
bundler
gym
and
then
from
there
we
run
bundle
which
will
install
all
the
gems
required.
We'll
go
over
that
as
we
go
through
the
script,
in
that
we
kind
of
have
four
jobs.
Currently
that
are
active,
we
have
the
from
zendesk,
which
is
part
of
this
gather
stage,
and
then
it's
going
to
run
the
zendesk
script
and
it's
going
to
create
an
artifact
called
desk.json
and
it
expires
in
two
hours.
This
is
so
we
don't
retain
it
for
too
long.
A
I've
set
this
to
have
a
needs
of
from
zendesk
from
repo,
which
means
these
past
two
jobs,
the
from
zendesk
here
and
the
front
repo
here
they
have
to
run
and
succeed
for
this
to
actually
run
that's
because
it
requires
this
zendesk.jsonrepo.json
file
for
files.
I
should
say
it's
going
to
run
the
compare
script
and
it'll
generate
two
artifacts,
the
creates.json
and
the
update.json,
which
will
also
expire
in
two
hours,
and
then
we
have
the
sync
script.
A
It's
part
of
the
sync
stage:
it
needs
this
comparison,
job
to
finish
and
succeed
from
there.
It's
gonna
run
the
sync
scripts,
and
it's
only
gonna
do
this,
for
when
the
ref
is
master,
that's
because
we
don't
want
it
sinking
to
production
for
anything
other
than
the
master
pipeline.
The
master
branch.
A
Now,
beyond
that,
we'll
take
a
quick
look
at
the
scripts
here.
So
the
zendesk
script,
not
very
specific.
It's
basically
just
saying
yeah
require
the
zendesk
macros
file
and
then
run
zendesk
macros
zendesk,
artifacts
you'll
find
the
other
ones
such
as
the
repo
are
very
similar,
so
desk,
macros
repo
artifacts,
the
compare
job
you'll,
see
it's
pretty
similar
too.
A
So
does
macros
compare
report
and
artifacts
because
this
we
want
a
report
of
what
it's
about
to
do,
but
we
also
need
the
artifacts
and
then
the
sync
script
is
the
other
one
to
go
over
and
that
one's
just
running
it
just
does
the
desk
macros
run
so
things
really
work
is
coming
from
lib.
We've
got
the
zendesk
macros
file
and
here
we're
declaring
the
modules
of
desk
macros.
A
We've
got
it
requiring
json,
ammos
and
desk.api
our
zendesk
underscore
api,
which
is
the
zendesk
api
gym
and
then
how
we're
going
to
require
the
client
file
and
that's
within
here
the
client
file
is
going
to
specify
some
pretty
mundane
stuff.
We're
going
to
set
the
class
to
client
we're
going
to
require
the
compare
repos,
sandbox,
zendesk
files,
we're
going
to
declare
the
clients
which
we're
going
to
use
this
right
here,
we're
going
to
call
the
zendesk
api
gym,
called
clients,
function
or
client
class.
A
I
should
say
we're
calling
a
new
one,
we're
passing
it
in
the
config
of
the
url.
Is
our
environment
url.
The
username
is
the
environment
username.
The
token
is
the
environment
token.
We
want
it
to
retry
if
it
fails,
fails
to
make
api
connections
and
we
want
the
logger
set
to
false,
because
otherwise,
it
floods.
The
thing
with
running
this
running
that
running,
that
did
this
update.
Did
this
create
it's
a
lot,
so
we
tend
to
just
not
want
that
present
when
the
sandbox
stuff
is
running.
We
also
declare
one
for
the
sandbox
clients.
A
A
And
then,
beyond
that,
we
create
a
function
called
gitlab
request
where
it
takes
an
http
method.
The
endpoint
and
any
parameters
that
we're
passing
in
from
there.
It's
going
to
do
a
public
send
to
the
http
method,
using
the
endpoint
and
the
params,
and
it's
going
to
use
the
ammo
to
safe
load
the
response
and
we're
going
to
pass
it
this
date
to
tell
it
parse
dates
as
well.
A
So
beyond
that
each
of
them
kind
of
vary
but
we'll
go
ahead
and
go
into
the
zendesk
one.
First
for
this
one,
I'm
just
we're
defining
the
client
we're
saying:
yeah,
pull
the
client
from
that
client
that
client
class
that
we
just
went
over
the
macros
are
going
to
be
map
macros,
which
is
a
function
up
here,
where
it's
going
to
call
the
client
get
every
macro
from
zendesk
and
then
push
them
to
an
array
using
the
macro
object
function.
And
then
it's
going
to
pass
this
macro
right
back.
A
So
what
it's
saying
is
the
macros
here
is
equal
to
all
the
macros
and
they're
passed
in
this
specific
object,
because
this
is
what
we
need
to
work
with
syncs
updates
and
so
on
so
forth.
We
need
the
id
and
the
title,
the
active
state,
description,
actions
and
restrictions
and
beyond
that
we
also
have
the
artifact,
where
it's
going
to
artifact
these
macros
into
a
json
file
using
json
style
formatting.
A
It's
going
to
call
for
active
and
inactive
to
get
active
files
and
inactive
files,
and
you
can
see
that
down
here
where
it's
basically
doing
a
blob
on
the
active
folder
to
local
yaml
files
on
each
file.
It's
going
to
attempt
to
safe
load
it
and
if
it
errors
out
because
it
can't
load
it.
It's
actually
going
to
send
this
error
using
the
error
function
which
we'll
go
over
in
a
bit,
but
if
it
doesn't,
it's
then
going
to
check
to
see
if
it's
active.
A
A
A
So
once
we
got
that
it's
going
to
parse
it's
going
to
send
out
all
the
errors
that
we
have
and
it's
going
to
notify
us
of
those
unless
there's
no
errors,
if
there's
no
errors,
it's
going
to
say,
map
macros
is
active,
plus
inactive.
It's
going
to
add
those
two
together
and
that's
how
we
get
the
macros
now
the
macro
objects
should
look
exactly
the
same
as
the
zendesk
object.
A
The
other
file,
the
error
function
literally
just
calls
an
abort
and
reads
out
what
the
error
is,
and
we
do
this
because
we
don't
want
to
proceed
if
it's
failed
to
parse
these,
it's
not
going
to
succeed
anywhere
else.
We
want
it
to
go
ahead
and
stop
now
the
checks
that
we
do.
The
tests
that
we
do
are
looking
for
bad
names,
duplicate,
ids,
duplicate
names
and
bad
names.
It's
basically
going
to
go
through
each
name
and
send
it
out
if
it's
got
a
bad
name.
A
A
There
we
go
yeah,
sorry,
bad
names,
but
yeah,
so
we're
basically
just
looking
for
each
of
these
and
we're
reporting
if
any
of
them
have
bad
names.
Now.
The
way
this
works
is
we're
basically
looking
for
any
that
use
dot
yml,
that's
because
the
script
specifically
is
looking
for.
If
you
remember
up
here,
dot
y
a
ml,
so
if
it
doesn't
have
it
there,
it's
going
to
let
you
know:
hey
you've
got
the
wrong
extension.
A
We're
looking
for
this
duplicate
ids
are
what
it
sounds
like
it's
going
to
look
through
all
of
them
and
look
and
see
if
any
two
have
the
same
id
function.
If
it
does
it's
going
to
report
that
hey
two
of
these
have
duplicate
ids,
we
can't
proceed.
We
can't
have
them
conflicting,
like
that,
and
duplicate
names
are
the
exact
same
one
if
it
finds
two
at
the
same
names,
it's
gonna
report,
while
zendesk
will
let
them
sync
with
the
same
name.
A
So
beyond
that,
we've
got
the
compare
script,
this
one's
a
little
less
complicated,
but
basically
we're
going
to
call
the
zendesk
macros
clients
from
zendesk
we're
going
to
parse
this
data
json
file
that
we
made
from
the
repos
we're
going
to
parse
this
repo
file
and
then
we're
going
to
set
some
some
global
variables
up
here.
Using
updates,
creates
and
deletes.
A
So
it's
going
to
report
an
artifact
report
is
basically
going
to
run
the
compare
script
which
is
going
to
go
through
everything
in
the
repo
folder,
a
repo
json
file
and
everything
in
the
zendesk
json
file
and
compare
them
if
it
finds
ones
that
exist
in
both,
but
there's
differences.
It's
going
to
say,
oh,
I
need
to
update
this.
The
repo
is
the
single
source.
True
from
this,
so
it'll
push
that
there
if
it
finds
one
where
hey
it
exists
in
the
repo,
but
not
in
zendesk.
A
It's
going
to
say
I
need
to
create
that
push
to
the
creates
file
we
kind
of
want
to
build
in
the
function
for
deletes.
We
don't
actively
do
it
right
now.
It
will
report
that
hey
this
exists
in
zendesk,
but
not
in
the
repo.
I
think
I
need
to
delete
it,
but
we
don't
actively
having
it
doing
these
deletes,
but
basically,
by
the
end
of
this,
what
we're
going
to
end
up
with
is
two
artifact
files
which
you
can
see
down
here
with
the
artifacts
we've
got,
updates
json
and
creates
json.
A
This
is
going
to
be
passed
to
the
sync
script,
which
will
help
it
figure
out
what
to
do,
which
brings
us
to
our
final
script,
the
sync
script
now
once
again,
this
is
going
to
call
these
zendesk
clients,
it's
going
to
parse
the
creates
file
and
the
updates
file,
and
it's
going
to
create
some
functions
here
of
created,
0,
updated,
0
and
errors
is
kind
of
this
hash
object.
We're
going
to
use
this
mainly
for
reporting.
A
So
the
pre-run
report
is
going
to
tell
us
hey.
I
need
to
create
this
many
macros
and
this
many.
I
need
to
update
this
many
macros
now
beyond
that,
it's
going
to
actually
run
the
creation
and
if
we
look
down
here
at
run,
we
see
create
happens.
First
then
update
then
post
run
and
then
the
error
report
so
for
created
it's
literally
going
to
go
through
all
the
created
the
creates
and
just
create
the
macro
which
is
going
to
call
the
zendesk
api,
create
passing
the
client
in
the
macro.
A
It's
going
to
add
one
to
it,
but
if
it
errors-
because
it's
invalid,
it's
going
to
store
that
in
our
errors
hash.
So
we
can
report
on
it
later
beyond.
Next
up,
it's
going
to
update,
which
is
going
to
look
very
similar.
It's
going
to
update
the
macros.
We
call
this
an
skpi
macro,
update,
function,
pass
client
macro,
add
one
to
update,
but
if
it
fails
because
the
record's
invalid,
we
want
it
to
lock
that
now
beyond
that,
it's
going
to
do
a
poster
report.
A
A
Then
we're
going
to
do
the
error
report,
which
is
basically
just
going
to
go
through
the
errors
and
print
out
what
the
error
actually
is,
and
you
can
see
up
here.
We
have
the
error
string
function,
which
is
going
to
be
unable
to
create
an
update
macro
title
due
to
error
and
then
the
actual
error
that
it
captured.