►
Description
Webhooks are valuable tools for powering real-time integrations and workflows in your project’s existing tools. This session will walk through an approach of building a webhook-powered application that acts on events as they take place on GitHub. You will also learn how to use the GitHub REST API through the Octokit SDK to call for additional resources after receiving an event.
GitHub Satellite: A community connected by code
On May 6th, we threw a free virtual event featuring developers working together on the world’s software, announcements from the GitHub team, and inspiring performances by artists who code.
More information: https://githubsatellite.com
Schedule: https://githubsatellite.com/schedule/
A
A
Today's
workshop
we're
gonna
break
into
two
sections:
first,
an
introduction
to
rest
api's
web
hooks
and
the
best
practices
when
using
them
and
in
the
second
half
will
be
live
coding.
An
integration
that
uses
web
hooks
and
our
REST
API
to
build
a
live,
updating,
changelog,
hosted
on
github
pages
anytime,
that
a
pull
request
is
merged
into
our
repository.
It'll
update
the
changelog
based
on
a
set
of
criteria.
It's
super
neat
and
I'm
really
excited
for
Jane
and
John
to
share
this
with
you
all.
A
So
to
start,
let's
kick
it
off
with
a
brief
introduction
or
perhaps
reintroduction
to
the
idea
of
rest.
Api's
rest
api
is
are
a
way
of
programmatically
getting
data.
They
allow
us,
as
developers
to
fetch
information
from
a
server.
Now
there
are
many
different
flavors
of
REST
API
in
the
world,
but
today
I'll
be
talking
specifically
about
HTTP
API.
So,
let's
take
a
moment
and
dig
into
the
concept
of
HTTP,
specifically
what
we
call
the
request
response
lifecycle
in
HTTP.
Everything
starts
with
a
request,
and
it's
composed
of
two
main
parts.
A
First
is
a
verb
and
it
specifies
the
operation
that
we'd
like
to
take
against
the
API.
It
signals
whether
we'd
like
to
fetch
information,
update
something
or
maybe
even
destroy
it,
and
the
second
is
an
endpoint.
It's
an
identifier
that
allows
us
to
specify
which
part
of
the
API
that
we'd
like
to
interact
with,
in
this
case
we're
making
a
request
to
github
the
REST
API
asking
for
information
about
the
currently
authenticated
user.
A
Now,
when
we
make
our
HTTP
requests
to
the
server
using
that
get
and
going
to
the
slash
user
endpoint,
the
request
makes
its
way
across
the
internet
to
one
of
github
servers
and
then
it
starts
to
fulfill
our
request.
It
does
this
by
pulling
information
that
it
has
about
the
currently
authenticated
user.
A
A
A
Then
we
call
the
user
method
and
we
get
the
information
about
the
currently
authenticated
user,
just
like
we
were
doing
with
curl,
or
perhaps
your
language
of
choice
is
JavaScript.
In
this
case
we
include
the
library
and
then
we
use
the
users
and
get
authentication
functions
to
make
the
API
request
behind
the
scenes.
Client,
libraries
abstract
away
the
interactions
that
we
make
with
an
API
and
the
language
of
our
choice.
A
Now
rest
api,
czar,
fundamentally
based
on
a
poll
model,
meaning
that
we,
the
consumers
of
these
api's,
need
to
pull
the
data
from
the
server
we
have
to
go
out
and
we
have
to
ask
for
it
because
of
this
it's
hard
to
achieve
a
real-time
experience
in
this
model.
We
need
to
constantly
request
from
the
server
whether
or
not
there
were
any
updates.
If
we
wanted
to
every
few
seconds,
we
could
have
pull
the
API.
Have
there
been
any
updates
to
this
pull
request
and
the
server
responds
nope?
A
No
new
updates,
go-fish,
maybe
a
few
seconds
later
we
pull
again
again.
The
server
says
that
there
haven't
been
any
updates
to
the
pull
request
and
maybe,
on
the
third
time
around,
there
was
an
update
to
our
pull
request.
So
the
server
responds
with
the
new
HTTP
status
code,
signifying
the
response
was
successful,
along
with
the
data
when
taking
a
polling
approach,
it's
not
only
a
waste
of
resources
but
you'll
quickly
run
into
rate
limits
rate
limits
are
in
place
to
ensure
the
stability
of
the
overall
API
platform.
A
So
this
all
sort
of
begs
the
question:
what
would
the
inverse
model
look
like
and
that's
where
web
hooks
come
in
web
hooks
flip
the
idea
of
a
REST
API
around
we
go
from
a
flow
that
looked
like
this
with
the
REST
API,
where
we
were
the
ones
making
the
request
to
the
server
so
now
having
github
sent
requests
to
us
anytime.
That
an
event
happens
on
github
that
we've
previously
expressed
interest
in
it'll.
A
Send
us
the
request:
you'll
notice,
that
there's
a
new
HTTP
verb
a
post
and
it
carries
along
a
JSON
payload
with
the
information
about
the
event
that
happened
on
github.
Now
we
as
the
server
need
to
do
our
part
and
respond
to
github
the
same
way
that
it
was
doing
for
us
in
the
REST
API
example.
We
have
to
return
a
sensible
HTTP
status
code.
A
So,
let's
dig
into
the
anatomy
of
a
web
hook
the
first
part
of
a
web
hook
our
HTTP
headers,
and
these
are
a
way
to
specify
metadata
about
the
request.
For
example,
the
user
agent
header
identifies
the
github
server,
that's
sending
the
request
to
us,
followed
by
the
version
of
code
running
on
the
server.
This
is
a
helpful
tool
to
include
in
support
requests
that
you
have
with
github
related
to
web
posts.
A
Next
is
the
X
github
delivery
header
and
it's
a
unique
identifier
of
the
event
that
took
place
on
github
there's
also
an
X
github
event
header,
and
it
signifies
the
type
of
event
that
we're
receiving.
We
can
see
that
for
this
web
hook.
The
event
that
took
place
is
really
related
to
an
issue
comment
now,
just
like
in
our
REST
API
example,
we
have
a
JSON
payload
and
it
includes
a
variety
of
information
about
the
event.
A
In
this
case,
we
can
see
that
a
new
issue
comment
was
created
who
the
author
was
and
the
contents
of
that
comment.
Now
it's
worth
pointing
out
that
I
emitted
a
significant
portion
of
the
payload
just
to
save
space
for
slides
and
reality.
You
get
a
ton
of
information
about
the
event
in
all
of
its
relationships.
You
can
always
expect
a
similar
convention
to
github
webhook
payloads,
including
the
resource.
A
The
event
took
place
on
the
sender
and
the
target,
so
I
mentioned
before
that
web
hooks
are
only
sent
if
you
previously
subscribe
to
events
on
github
when
subscribing
to
events,
there
are
a
large
number
of
options
to
choose
from,
for
example,
if
you
want
to
build
a
CI
server,
you
might
only
be
interested
in
events
like
push
status
and
check
run
events.
These
are
things
that
are
related
to
code
and
the
lifecycle
around
them.
For
example,
the
push
event
is
triggered
anytime,
that
someone
pushes
code
to
a
repository
say.
A
For
example,
you
wanted
to
build
a
real-time
project
management
integration.
You
might
be
more
interested
in
events
like
issues,
pull
requests
and
project
events
and
for
when
you're
uncertain
about
what
you
may
need.
Github
provides
what
we
call
a
wild-card
event
which
will
send
you
a
web
book
for
all
supported
event
types
and
any
additional
events
that
we
add
in
the
future.
A
Now
there
is
one
caveat
in
that
web
book
subscriptions
need
to
be
installed
on
a
target
that
you
have.
Access
to.
One
target
type
is
an
organization
which
means
that
any
organization,
specific
events
will
generate
web
hooks,
along
with
any
repositories
that
belong
to
that
organization,
or
you
can
install
web
hooks
on
a
repository
target,
and
it
will
only
send
events
that
take
take
place
in
that
repo.
There
are
a
variety
of
other
targets
that
web
hooks
can
be
installed
on,
including
github
apps.
A
So
how
do
we
actually
create
these
subscriptions?
Well,
the
easiest
way
is
using
the
UI,
but
this
also
can
be
done
programmatically
via
the
API
in
the
settings.
Page
of
any
organization,
a
repository
you'll
see
an
option
to
create
new
web
book
subscriptions
here,
I'm
creating
a
new
repository
web
hook
for
the
evil,
beast
Winterton
user.
It
will
receive
a
web
book
anytime
that
an
issue
or
issue
comment
event
happens.
A
There's
also
a
few
requirements
for
receiving
web
focus.
First,
you
need
a
web
server.
That's
always
listening
for
these
requests
from
github.
If
you're,
not
listening,
github
will
attempt
to
contact
your
server
but
it'll,
eventually
timeout.
A
second
you'll
need
an
address
on
the
internet.
That
getup
can
actually
reach
things
like
localhost
won't
work
because
from
a
computer's
perspective,
localhost
is
to
always
a
reference
to
itself
and
not
something
that
other
computers
can
resolve.
A
That's
where
tools
like
n
crock
come
in
and
make
it
much
easier
to
test
web
hooks
on
your
own
machine
and
rock
works
by
creating
a
public
address
that
you
can
send
web
hooks
to,
and
then
it
forwards
those
requests
directly
to
your
machine.
It
also
adds
a
ton
of
Handy
features
around
what
seeing
what
requests
are
coming
in,
as
well
as
the
ability
to
redeliver
those
requests
all
right
on
to
our
last
section,
the
best
practices
when
receiving
web
hooks.
A
These
can
be
broken
up
into
three
main
themes,
and
the
first
is
the
theme
of
resiliency
it's
in
important
to
respond
to
webhooks
as
quickly
as
you
can
in
your
applications,
and
what
I
mean
by
this
is
to
make
sure
that
you
avoid
any
blocking
calls
and
areas
of
your
code
that
receive
webhooks.
Now,
there's
a
few
reasons
why
this
is
important.
The
first
is
the
get
up,
has
a
10
second
timeout.
A
When
a
web
hook
is
sent
to
you,
you
must
give
a
response
within
10
seconds,
or
else
github
assumes
that
you're
not
listening
and
it'll
just
give
up.
The
second
reason
you
should
respond
on
the
web
hooks
as
quickly
as
you
can
is,
because
you
want
to
be
able
to
grow
with
an
increasing
number
of
events
that
you
might
receive.
If
your
application
takes
a
long
time
to
respond
and
you're
getting
an
influx
of
events,
it
can
result
in
a
request,
backlog
and
you
might
end
up
dropping
valuable
web
hooks.
A
The
next
best
practice
is
in
the
theme
of
resiliency
and
it's
to
be
defensive
about
the
order
of
events.
Almost
all
events
that
are
set
by
github
are
in
order,
but
you
may
find
that
a
very
small
percentage
of
the
time
you
receive
events
out
of
order
do
your
best
to
be
tolerant
of
these
out
of
order
events.
A
The
next
theme
of
best
practices
is
security
because
we're
running
a
server
on
the
internet
that's
publicly
accessible.
We
need
to
make
sure
to
keep
security
in
mind
when
receiving
these
Web
books.
The
first
tool
in
our
toolbox
to
make
our
application
secure,
is
to
verify
that
requests
are
authentic
and
actually
from
github.
We
can
do
this
using
a
technology
called
H
Mac
and
a
little
bit
of
pre
configuration,
but
before
I
show
you
how
to
configure
this.
A
Let
me
talk
about
what
this
protects
against,
because
our
servers
running
on
the
internet
there's
nothing
really
preventing
someone
malicious
from
pretending
that
their
github,
if
someone's
able
to
determine
the
address
of
your
application,
they
may
try
and
send
requests
to
it
or
worse,
impersonate
github.
This
could
cause
you
to
assume
that
an
event
happened
on
github,
but
when,
in
reality
it
didn't.
There
are
a
few
ways
to
defend
against
this,
but
one
of
the
most
popular
ways
is
using
h
max
signatures
with
h
mac.
A
You
create
a
secret
that
only
you
and
github
know
about
I've
used
a
simple
ABC
password
in
this
diagram,
but
it's
important
to
use
a
secret.
That's
not
easily
guessed
and
something
that
you
don't
share
with
anyone
other
than
github
right
before
get
up
sends
a
request.
It
looks
at
the
payload
and
it
computes
a
signature
based
on
the
secret
that
you
provided
that
only
you
and
github
know
about.
It
then
takes
that
signature
and
it
place
and
the
X
hub
signature
header.
A
When
you
receive
the
web
book,
you
can
check
the
headers
and
cryptographically
verify
that
the
signature
is
correct
and
was
created
using
the
secret
that
you
provided
ahead
of
time.
This
verifies
that
the
payload
hasn't
been
tampered
with,
and
it's
authentic
from
github.
In
order
to
configure
this,
you
can
simply
add
the
shared
secret
to
the
secret
field
when
creating
a
web
book.
A
Another
popular
way
to
verify
that
Web
books
are
only
coming
from
github
is
to
allow
requests
from
certain
IP
addresses
at
github.
We
publish
all
of
the
IP
address
ranges
that
we
send
web
hooks
from
in
the
meta
endpoint
of
our
REST
API.
If
you
decide
to
whitelist,
IP
addresses
make
sure
to
regularly
update
them,
based
on
the
results
of
this
API
endpoint.
We
try
to
avoid
modifying
this
list,
but
it
does
happen
from
time
to
time.
A
The
last
section
of
best
practices
are
related
to
HTTP.
First,
when
you
respond
to
a
web
book,
always
use
a
sensible
HTTP
status
code.
Anything
starting
with
a
200
is
denoted
as
successful.
Anything
starting
with
400
is
a
client
error
and
anything
starting
with
a
500
is
a
server
error.
By
using
sensible,
HTTP
status
codes,
it
will
make
it
easier
to
see
which
web
books
were
successful
and
which
failed
in
your
delivery
logs
next
try
to
get
in
the
habit
of
sending
github
helpful
error
messages
when
something
goes
wrong.
A
This
will
make
it
much
easier
to
debug
errors
in
the
deliveries
page
here
I
can
see
that
for
this
web
book,
the
application
was
expecting
it
to
be
delivered
to
a
specific
endpoint
that
doesn't
exist
as
a
result,
it
returned
an
HTTP,
404
and,
lastly,
keep
track
of
the
goods
that
github
sends
you
and
the
X
github
delivery
header.
These
are
a
unique
identifier
of
the
event
that
took
place
on
github
and
they're
very
helpful
when
debugging
web
hooks
with
the
get-ups
support
team.
A
There
are
a
few
tools
that
will
make
help.
You
help
make
your
life
a
little
bit
easier
when
working
with
REST
API
s
and
web
Polk's
first
is
a
tool
called
postman,
and
this
is
a
graphical
user
interface
that
allows
you
to
test
out
API
calls
and
development.
You
can
save
these
calls,
add
variables
and
replay
them
any
time
that
you'd
like,
but
if
they
find
postman
a
little
bit
heavy-handed,
you
can
always
fall
back
to
command-line
tools
like
curl
and
JQ.
A
Jq
is
a
way
of
querying
JSON
data.
In
this
example,
I'm
fetching
the
meta
endpoint
from
Kidd
hubs,
REST
API
and
then
I'm
selecting
the
first
results
of
the
hooks
array
of
that
response
in
terms
of
web
hooks,
we
saw
and
grok
earlier,
but
one
of
the
coolest
parts
about
it
is
the
user
interface
that
shows
you
a
list
of
all
the
requests
that
you've
received,
as
well
as
a
button
to
redeliver
them.
There's
also
some
other
great
tools
for
receiving
web
hooks
without
forwarding
support
likes
me,
request
bin
and
hook
bin.
A
B
Thanks
Brooks
yeah,
so
today,
Brooks
kind
of
already
teased
this,
but
today
we're
gonna
be
building
a
changelog
application.
Together,
it's
going
to
listen
to
web
hooks
and
then
use
API
requests
to
actually
update
this
change
log
and
the
application
is
actually
going
to
be
hosted
on
github
pages.
So
that's
even
another
bonus
feature
yeah.
So
the
point
of
today
is
less
about
the
actual
changelog
application
itself
and
more
about
how
to
develop
and
test
with
web
hooks.
How
to
debug
web
hooks,
how
to
make
REST
API
calls
via
client
libraries.
B
The
one
we're
going
to
use
today
is
octocat
and
we're
also
gonna
go
over
some
of
the
best
practices
that
brooks
already
mentioned
great.
These
are
some
of
the
things
you're
gonna
need
today.
The
one
that
I
want
to
point
out,
first
and
foremost,
is
docker.
Please
have
docker
running
on
your
computer.
If
you
plan
on
following
along
I
should
mention
that,
like
this
is
gonna
be
recorded
and
the
slack
channel
is
gonna
be
open
after
even
after
we
finished
the
demo.
B
But
if
you
do
want
to
do
it
with
us,
you
are
gonna
need
docker
running
so
I
would,
if
it's
not
running
right
now,
start
it
up
right
now.
The
other
little
I'll
help
int
I
guess
I'll,
give
is
that
you
should
maybe
have
your
terminal
and
editor
side-by-side.
We're
gonna
be
switching
back
and
forth
between
the
two
of
them
quite
a
bit
so
yeah.
B
Yeah,
oh
also
I,
think
I'll
just
mention
that
everything
that
we're
doing
here
is
written
down
inside
the
repository
the
web
books
with
rest
repository
in
the
workshop
MD
file.
So
if
you
do
want
to
do
this
later,
and
you
just
want
to
follow
along
while
we're
doing
it
right
now,
that's
totally
fine.
You
should
be
able
to
refer
back
to
that
and
get
the
steps
there.
All
right,
I
guess!
Well,
we'll
kick
it
off.
John
is
gonna
share.
B
Okay,
so
yeah.
The
first
thing
everybody
should
do
is
open
this
repository,
but
before
we
even
get
started
on
the
workshop
itself,
let's
take
a
look
at
the
final
product
that
we're
gonna
be
aiming
for.
So
we
already
have
a
github,
a
github
page
hosted
for
this
repository
John's
gonna
switch
over
to
it
for
us
beautiful.
This
is
this:
is
a
static
site
hosted
by
github
pages?
There's
one
entry
in
this
changelog
already
and
the
way
that
we're
gonna
add
entry,
stats.
B
Changelog
is
every
time
a
pull
request
with
certain
criteria
that
has
certain
criteria
is
merged.
We
will
update
the
change
log
with
those
changes,
so
we
also
have
a
demo
PR
open
already.
Here's
our
demo
PR
so
I'm
just
gonna
point
out
some
things
on
this
PR.
So
the
first
thing
is
the
label.
You
can
notice
that
there's
a
documentation
label
on
here.
We
basically
set
up
the
application
to
check
for
that
label
and
if
a
pull
request
doesn't
have
that
label,
we
will
just
ignore
it.
B
We
don't
care
about
pull
requests
that
don't
have
this
label.
The
other
thing
that
I'll.
That
I'll
note
is
that
this
pull
request
is
the
base.
Branch
of
this
pull
request
is
in
two
master,
so,
for
example,
if
the
pull
requests
were
a
pull
request
into
another
branch
that
wasn't
master
and
it
got
merged,
we
wouldn't
care
about
that
event.
We
would
only
care
about
pull
requests
to
get
merged
into
master,
and
the
last
thing
I
point
out
is
these
changes
HTML
tags
that
we've
added
to
the
pr
body?
B
What
we've
decided
is
that
everything
that
goes
in
between
those
two
tags
is
gonna,
be
the
entry
for
the
change
log
itself,
so
yeah.
All
that
marked
down
in
between
those
two
tags
is
what's
going
to
be
added.
If
we
don't,
if
we
didn't
have
these
changes
tags,
we
would
just
fall
back
to
the
PR
title,
but
yeah
so
I
have
the
app
running
locally.
I
already
have
the
web
hook
configured
so
fingers
crossed.
Let's
merge
this
PR
and
we
should
see
the
the
change
log
update.
D
B
Head
over
to
the
docs
slash
index
MD
file
in
this
repository,
so
this
is
the
page.
This
is
the
file
that
github
pages
is
actually
hosting
for
us
and
we'll
notice
that
there
was
a
new
commit
to
it
21
seconds
ago,
which
is
what
we
expected.
We
made
that
committee
met
eclis
via
the
API,
so
let's
take
a
look
at
it.
B
We're
doing
this
mostly
just
to
waste
time,
because
github
pages
builds
are
not
instantaneous.
Okay,
great.
We
see
that
new
entry
there.
That
is,
that
is
the
markdown
that
we
had
in
between
those
two
changes
tags.
Hopefully,
we've
wasted
enough
time
already
and
the
github
pages
build
has
happened.
So,
let's
also
fingers
crossed
and
refresh
the
page
yeah.
C
C
B
B
So
that
is
what
we're
gonna
be
building
together
today,
I
think
we're
pretty
much
ready
to
get
started
so
yeah.
Everyone
should
have
that
repo
open
and
we
also
John.
Do
you
mind
navigating
to
the
workshop
MD
in
here
yeah.
This
file
has
everything
that
we're
gonna
do
together
today.
So
if
you
are
following
along
and
you
fall
behind,
there
are
steps,
there
are
actually
branches
that
we
already
created.
B
A
B
B
C
For
for
everybody
that
is
on
Windows,
please
follow
the
git
clone
snippet
that
we
have
being
the
documentation,
because
you
need
to
basically
put
that
flag
in
in
order
to
basically
get
some
files
that
we
have
from
from
Unix.
This
one
will
basically
help
running
the
project
inside
docker,
so
instead
of
learning
like
a
bear,
git
clone
just
from
the
whole
thing.
B
B
C
The
equivalent
scripts
that
we
have
everything
is
in
readme,
so
you
can
basically
go
to
that
works
of
dot
MD
and
just
follow
their
the
guidelines
there,
but
all
the
equivalent
scripts
that
are
for
Windows
users
are
inside
the
folder
called
exec,
so
I'm
just
gonna
so
case
here
the
contents
of
the
folder.
So
basically
you
need
to
execute
these
scripts
right.
B
And
these
scripts
are
all
named
the
same
things
as
what
we're
gonna
be
running.
So
when
we
do
a
script,
slash
whatever
you
guys
do
the
equivalent
okay
great.
So
now
what
we're
gonna
do
is
we're
gonna,
create
we're
gonna
generate
a
personal
access
token,
together
personal
access
tokens,
so
we're
gonna
head
back
to
github.com.
B
Yeah,
it's
that
settings
token
new
link,
yeah,
so
personal
access
tokens
or
what
we're
going
to
use
today
to
authenticate
with
the
API
they're
very
nice
they're,
very
easy
way
to
authenticate
with
the
REST
API.
So
yeah
we're
gonna,
give
it
a
name.
It
doesn't
really
matter
what
name
you
give
it.
The
thing
that
does
matter
here
is
which
scopes
you
select.
So
this
this
token
can
have
limited
access
to
everything
that
your
actual
user
has
access
to.
B
So
today,
the
only
scope
we're
going
to
need
is
the
repo
scope,
so
just
select
that
checkbox
awesome,
so
yeah
I'll
just
mention
that,
like
the
fewer
the
scopes
that
you
use
the
better
because
if
your
token
does
become
compromised,
that
means
that
that
token
doesn't
have
access
to,
as
as
to
everything
that
your
user
has
access
to.
Okay,
great,
so,
let's
generate
the
token
in
general.
B
Personal
access
token
should
never
be
shared
by
a
judge,
but
in
general
never
share
them,
never
show
them
to
anyone
else,
so
yeah
when
it's
generated
just
copy
it
and
we'll
head
back
over
to
our
local
machine
and
actually
that
script
bootstrap
that
we
ran
should
have
copied
a
dot
n
file
for
you,
so
it
should
be
in
change,
logger,
/n
and
yeah,
and
so
we're
just
gonna
open
that
file.
Right
now
there
are
two
placeholder
environment
variables
that
we're
gonna
need
to
set
in
there.
B
Great,
so
we're
just
gonna
paste
our
personal
access
token
that
we
got
in
the
purse,
get
have
personal
access,
token
section,
and
then
the
next
one
is
a
github
webhook
secret,
as
brooks
already
mentioned.
These
generally
should
be
very
unique
and
very
random
and
long
and
more
secure,
but
for
today
we're
just
going
to
use
any
string
that
we
want
that
we
can
easily
remember
because
we're
gonna
configure
a
web
hook
with
this.
In
a
few
seconds,
awesome
John
chose
the
name
of
his
adorable
dog
Bruno,
our
team
mascot,
very
rememberable,
okay.
B
B
C
B
Great,
so
once
we're
here,
the
only
thing
we're
gonna
select
is
that
source
drop-down.
It
should
say
none
and
we're.
Gonna
click
that
little
button
and
then
we're
gonna
choose
the
option
that
says
master
branch,
slash
Doc's
folder.
We
already
have
a
Doc's
folder
with
an
index
empty
in
this
repository.
So
this
is
what
the
pages
is
gonna
host
for
us.
You
should
see
a
notice
that
says
github
pages
source
is
saved
and
John.
Do
you
mind
scrolling
back
down
yep.
C
D
B
B
A
B
Is
a
very
good
point?
Yes,
the
personal
access
token
will
only
be
used
for
the
REST
API
great
I'm
gonna
I'm
gonna
move
on.
So,
if
you
are
following
along
on
this
workshop
MD
file,
we
are
about
to
start
step
zero.
I
know
it
feels
like
we've
done
a
lot
of
steps
already,
but
this
is
what
we've
named
step
zero.
B
And
so
this
should
start
two
things
for
you.
This
will
start
an
end
crop
container
and
this
will
start
a
webserver
container
so
yeah
it
should
output
a
URL
for
you
to
use,
and
then
we
should
also
get
the
output
saying
that
the
web
server
is
listening
on
port
3000,
while
we're
waiting
for
the
web
server
to
start
up
here,
John,
let's,
maybe
give
a
little
tour
of
what
the
code
looks
like
right
now.
So,
let's
check
out
the
routes
RB
file.
First.
B
Awesome:
okay,
so
we
can
see
that
this
application
already
has
two
routes.
One
of
them
is
to
get
route.
If
your
server
is
already
started,
and
you
just
go
to
localhost
3000,
that's
the
route
you're
gonna
hit
and
then
the
second
one
is
a
post
route
brooks
already
mentioned
that
all
web
hooks
make
post
requests.
B
B
That
rails
gives
us
that
just
it
basically
returns
a
hash
of
all
of
the
params
that
get
sent
through
the
request,
and
we
know
that
the
only
key
that
we
care
about
in
those
programs
is
the
webhook
key
rails,
puts
everything
for
the
web
hook.
Controller
inside
the
web
hook
key,
so
the
entire
payload
will
be
in
the
web
hook
key,
and
then
we
have
this
error
method.
That's
just
gonna.
B
Okay,
great.
So
it
seems
like
our
server
is
running
great.
So,
let's
head
back
to
the
repository
and
I
think
most
of
us
should
probably
still
be
on
the
repo
settings
page.
But
if
you're
not
on
the
repo
settings
page,
please
navigate
back
to
the
repo
settings
page
so
yeah
that
would
be
John.
Do
you
mind
scrolling
up,
maybe
at
the
top
of
the
repo
that
settings
tab
great
and
then
once
you
get
there
on
the
sidebar
side,
menu
bar
there's
a
webhooks
option,
so
you
should
click
into
there.
B
B
And
so
the
next
option
is
the
content
type
for
today.
We're
gonna,
actually
click
this
box
and
select
application.
Slash,
JSON
JSON
is
definitely
the
most
popular
type
and
the
easiest
to
work
with.
So
that's
what
we're
gonna
use
today
and
then
the
next
field
is
the
secret.
So
this
is
where
we
type
in
whatever
we
put
in
as
our
secret
in
that
damn
file,
so
John
chose
Bruno,
so
he's
gonna
use
Bruno
again
great.
So
the
next
section
is
where
we
decide
which
events
we
want
to
subscribe
to.
B
So
the
default
option
here
is
just
the
push
event.
So
if
all
you
cared
about
was
knowing
when
pushes
happen
to
this
repository,
you
could
just
leave
it
like
it
is.
The
next
option
is
send
me
everything
which
Brooks
mentioned
already.
That's
that
wildcard
event
and
that
will
send
every
every
event
that
ever
happens
on
this
repository
will
be
to
you,
and
also
I
should
mention
every
new
event
that
gets
added
to
to
the
list
of
events
that
we
subscribe,
that
we
offer
will
be
included
in
this
as
well.
B
B
Yep
and
so
underneath
each
of
these
event
types
we
can
also
see
which
actions
are
supported
for
these
events,
so
for
pull,
request,
there's
quite
a
lot
of
them:
there's
open
closed
reopened,
edited
assign,
etc,
etc.
Today,
we're
only
going
to
really
care
about
that
closed
event,
but
when
we
select
this
check
box
will
be
automatically
be
subscribed
to
all
of
them.
B
B
Great-
and
you
sure
this
great
when
you,
when
you
add
this-
you
should
see
that
little
green
checkmark
next
to
your
web
book
URL,
so
we're
just
gonna,
actually
click
back
into
yeah,
so
just
click
that
link
we're
gonna
click
back
into
the
web
hook
settings
and
we're
gonna
scroll
down
all
the
way
down
and
we'll
be
able
to
see
our
recent
deliveries.
Here
and
again,
there
should
be
a
little
green
check
box,
but
if
you
click
on
it,
you
should
be
able
to
get
more
information
about
this
event.
B
Great,
we
can
see
that
we
got
a
response
to
a
four.
We
got
all
those
headers
that
Brooks
mentioned
so
the
user
agent
and
the
delivery
header
and
the
event
header,
something
that
I
will
note
it
I'll
point
out
here
is
that
we
got
this.
The
event
type
here
is
Pig
and
you're,
probably
wondering
I
only
subscribe
to
pull
request
events.
Why
did
I
get
this
pig
event,
and
the
answer
is
that
there
are
actually
some
events
that
are
auto
subscribed
for
everyone.
B
So,
no
matter
what
type
of
hook
you
have
you'll
automatically
be
subscribed
to
a
pig
event.
This
just
happens
one
time
after
the
hook
is
created,
and
it's
actually
just
an
easy
way
to
help.
You
test
your
configuration
and
because
you'll
see
there
is
a
redeliver
button
up
there.
So
let's
say
you
pasted
your
URL
incorrectly.
You
can
update
your
configuration
and
then
redeliver
this
pig
event
and
test
until
it
turns
green.
D
B
Think,
okay,
so
the
first
thing
we
did
is
that
we
pasted
that
end
rock
URL
that
we
got
when
we
started
our
server
into
the
payload
URL
field
and
then
the
second
step
we
took
was
for
content
type.
We
actually
switched
it
from
forum
encoded
to
application,
JSON
right
so
yeah
as
we
did,
and
then
in
the
secret
field.
B
Until
we
got
to
the
pull
requests
event,
they
should
be
in
alphabetical
order,
I
think
so
it
should
be
slightly
easy
to
find
full
request,
and
then
we
just
marked
that
checkbox
simple
request
and
then
we
just
said
add
webhook.
We
want
to
make
sure
that
that
active
checkbox
is
remains
checked.
It
should
be
checked
by
default,
but
it
should
remain
checked.
We're
not
changing
that
one
and
when
you
do
that
it
should
auto
create
a
ping
event
for
you.
D
B
So,
okay,
great
okay,
I,
think
I
was
in
the
middle
of
explaining
auto,
subscribed
events.
So
yeah
ping
is
one
of
the
events
it's
auto
subscribed,
so
it
will
never
appear
in
that
list
of
events.
It'll
just
automatically
happen
for
you
and
yeah.
That's
pretty
Oh
John.
Let's!
Actually,
since
we
see
it
in
this
recent
deliveries,
let's
actually
check
the
server
and
make
sure
that
we
see
it
in
our
server
logs
as
well.
B
D
B
C
B
B
Okay,
it
doesn't
seem
like
we
have
any
questions
so
yeah
if
you
are
following
along
on
the
workshop
empty,
we're
about
to
start
step
one
and
something
that
I
will
note
before
we
start
step.
One
is
that,
while
we
do
provide
the
code
for
for
all
of
these
steps,
we
are
gonna,
be
doing
some
things
in
github
itself,
like
opening
full
requests
and
triggering
events
that
you're
gonna
need
to
follow
along
for
because
you
won't
have
those
automatically.
B
Great
so
yeah,
let's
go
back
to
our
web
hooks
controller,
that's
where
we're
gonna
be
doing
all
of
our
code
today.
So
the
first
thing
that
we
want
to
point
out
is
that
we
don't
actually
care
about
any
events
other
than
the
pull
request
event.
So
what
we're
gonna
do
is
we're
gonna
filter.
Anything
that
comes
in
is
not
a
as
not
a
pull
request
event.
B
So
yeah
there
should
be
a
before
action
on
line
5
that
is
truly
line:
5
right,
John,
okay,
great
on
line
5,
there's
a
before
action
called
that
calls
the
verify
event,
type
method
before
actions,
I
guess,
yeah
Before
we
jump
into
this.
This
is
a
rails
application.
This
is
this
is
Ruby
I
know
not
that
Ruby
and
rails
is
not
everybody's
first
choice.
We
generally
try
to
avoid
using
too
many
Ruby
isms
and
rails
isms.
B
B
So,
let's
check
out
that
verify
event
type
method
which
starts
on
line
32
and
we're
just
going
to
uncomment
that
great.
So,
let's
take
a
look
at
what
code
we
have
in
here
already
so
first,
what
we're
gonna
do
is
we're
gonna,
take
that
X,
github
event,
header
and
assign
it
to
a
variable,
and
then
the
next
thing
we're
gonna
do
is
we're
gonna
check
if
that
there?
If
what
we
got
from
that
header,
is
the
string
pull
request
and
if
it
is,
the
string,
pull
request
rate
will
return
early?
That's
what
we
want.
B
If
it's
not,
then
we're
gonna
return,
an
error
in
both
the
server
logs
and
via
the
API
that
we're
building
together.
Okay,
so
now
that
this
is
saved,
uncommented
and
saved,
we
actually
shouldn't
need
to
restart
our
server
rails
should
just
automatically
get
these
updates.
So
you
should
just
leave
your
server
running
this
whole
time.
Never
you
don't
have
to
restart
it
ever
and
so
yeah
we've
saved
this.
B
Great,
we
got
a
422,
let's
check
out,
that
response,
tab
yeah.
So
this
this
tab
shows
us
everything
that
we
returned.
These
are
all
the
headers
that
we
returned
and
the
body
that
we
returned,
and
so
we
have
that
string
on
a
LAN
event,
type
ping
great,
and
if
we
head
back
to
our
server
logs,
we
should
see
basically
the
same
thing
great
on
allowed
event
type
ping.
B
B
So
you
just
click
into
that
one
or
you
can
click
that
edit
button
all
the
way
to
the
right
and
then
on
this
page
you
should
be
able
to
scroll
all
the
way
down
to
the
bottom,
and
you
should
see
a
list
of
recent
deliveries,
of
which
there
should
only
be
one
one
entry
and
then,
if
you
just
click
on
the
gooood
or
you
click
on
those
three
dots
all
the
way
to
the
right.
You'll
get
that
expanded
view.
B
You
should
click
it
and
you
can
name
the
file
anything
you
want
and
put
any
contents
in
the
file
that
you
want
that
doesn't
matter.
The
only
thing
that
matters
is
when
you
scroll
all
the
way
down.
There
are
options
for
how
you
want
to
commit
this,
so
the
default
is
commit
directly
to
the
master
branch,
but
actually
what
we
want
is
to
create
a
new
branch
for
this
commit.
B
So
please
make
sure
that
you
select
the
create
a
new
branch
for
the
commit,
if
you
did
accidentally
already
hit,
commit
to
rocket
master
you're
gonna
have
to
create
another
new
file,
because
the
point
of
is
that
we
need
to
open
a
full
request.
So
yeah
you
can
name
the
branch
whatever
you
want,
we'll
just
leave
it
as
the
default
for
now
and
then
we're
gonna
propose
a
new
file,
we're
gonna
click
that
propose
new
file
button,
and
so
this
should
take
us
to
the
like
open
a
pull
request.
Page.
B
Something
that
I
do
want
to
note
here
is
that
the
base
branch
of
this
pull
request
should
be
the
master
branch
of
your
fork.
If,
for
some
reason
it
is
it's
selected,
the
master
branch
of
the
original
repo,
please
change
it
to
just
a
master
branch
of
your
fork,
and
so
now
we
have.
We
have
this
draft
full
request.
It
doesn't
really
matter
right
now
what
we
title
it
or
what
we
have
a
put
of
the
body.
B
B
B
Yeah
will
refresh
that
page
and
we
should
see
a
new
delivery
and
we
should
see
a
green
check
box
next
to
it
because
it
is
John
G,
my
clicking
into
it
and
we'll
be
able
to
see
that
this
is
a
pull
request
event.
So
we
were
able
to
match
that
string,
and
so
we
passed
that
filter
that
we
already
added
great
I
am
going
to
take
another
pause
here.
I
know
we
just
did
a
bunch
of
stuff,
so
I.
B
And
so
on
line
eight,
the
first
line
of
that
create
method,
we're
gonna
uncomment
that
line,
and
so
that
line
says
return
error
unless
labeled.
So
the
idea
here
is
that
we
don't
we
only
care
about
pull
requests
that
have
that
documentation
label
that
I've
pointed
out
before.
If
it
doesn't
have
that
documentation
label,
we
don't
care
about
it.
B
So
once
we
uncomment
that
line
line,
eight
we
can
scroll
down
and
on
line
38,
we
should
see
the
method
itself
and
will
come
out
the
whole
method,
so
thirty-eight
through
42,
great
and
John
before
we
actually
go
through
this
method
line
by
line,
let's
actually
just
put
in
a
binding
dot.
Pry
really
quick
here.
B
C
B
And
when
we
do
this,
we
should
head
back
to
our
server
and
we
should
be
caught
in
a
bind
it
up
right,
amazing.
So
let's
take
a
look
at
the
payload.
Let's
do
payload
keys
right
here,
so
these
are
the
keys
that
come
back
from
the
web
book
payload
itself,
so
the
first
one
is
action.
We
kind
of
already
went
over
that
this.
The
action
for
this
event
is
opened.
B
The
number
is
like
the
idea
of
the
pull
request,
the
pull
request,
which
is
the
resource
that
was
changed,
the
repository,
which
is
the
target
and
the
sender
which
is
the
user
who
actually
triggered
the
event.
I
guess
just
one
note
about
sender
is
that
it's?
It
is
the
person
who
triggered
the
event
so
for
for
something
like
pull
request
opened
the
pull
request,
user
and
the
sender
will
always
be
the
same
user
but,
for
example,
for
the
closed
event.
B
B
Great,
we
got
a
lot
of
keys
back
in
here,
but
the
one
that
we
care
about
right
now
is
the
labels
key,
because
that's
what
we're
trying
to
filter
right
now.
So,
let's
take
a
look
at
what
labels
returns
so
we're
just
doing.
Payload
pull
request
labels
right
now,
and
this
should
be
an
empty
array
because
there
aren't
any
actual
labels
on
here,
but
it's
good
for
us
to
notice
that
this
is
actually
a
list
and
not
just
a
single
a
single
item.
So
great,
let's
exit
this
finding
that
fry
you
can
exit
it.
B
B
Let's
get
rid
of
that
binding
dot
pry
and
take
a
look
at
what
this
labeled
method
is
doing
so
we're
gonna
work
in
a
search
in
the
pull
request:
labels
which
returns
a
list,
we're
gonna
ask
if
there
are
any
pull
up.
There
are
any
labels
with
the
name
documentation
that
dot
any
method
is
going
to
return
true
or
false,
whether
or
not
the
condition
was
met.
So
the
condition
that
we're
using
is
if
there
is
a
label
with
the
name
documentation
here
so
yeah
John.
B
If
we
head
back
to
our
recent
deliveries,
will
notice
that
this
one
did
timeout.
That
is
to
be
expected
because
we
had
that
binding
dot
pry
in
and
we
didn't
respond
quickly.
Enough
I
think
Brooks
already
mentioned
that
github
has
a
ten
second
timeout.
So
if
we
don't
respond
within
ten
seconds
wilkesy,
this
service,
timeout
error,
and
so,
let's
just
redeliver
this
event.
Now
that
we
have
the
label
filtering.
So
what
we
should
expect
here
is
a
422,
because
there
is
not
a
label
that
matches
documentation
great.
B
Let's
check
out
that
response
tab
and
make
sure
we
get
the
right
error,
great
webhook
and
valid,
not
labeled
great.
So
now,
let's
head
back
over
to
that
pull
request
that
we
made
yeah,
which
would
be
in
another
tab
and
then,
on
the
right
hand,
side.
There
should
be
an
option
for
labels
and
if
you
click
it,
you
should
be
able
to
add
the
documentation
label.
B
B
B
B
A
B
B
So
if
you
head
back
over
to
your
web
hooks
controller
and
scroll
back
up
to
the
top
on
line
9,
which
is
right
after
that
check
for
the
label,
we're
gonna
uncomment
the
check
for
whether
or
not
the
pull
request
is
closed.
So
this
line
just
says,
return
error.
Unless
it's
closed,
so
let's
take
a
look
at
that
closed
method,
which
is
on
line
44
44
through
46,
so
yeah
we
can
take
a
look
at
this
one.
This
one
is
pretty
self-explanatory.
B
C
C
B
Great
so
great
we
haven't,
we
have
a
new
empty
server
log
over
here.
So
let's
head
back
over
to
our
recent
deliveries
and
let's
redeliver
that
latest
event,
which
is
the
action,
is
labeled,
and
so
what
we
should
see
now
is
that
this
actually
422
is
because
we
don't
care
about
labelled
events.
We
only
care
about
closed
events.
B
Great,
we
got
a
422.
Let's
look
at
that
response.
Tab
great.
We
got
a
little
message
saying
that
the
web,
that
the
event
is
not
closed.
Okay,
so
now
what
we
can
do
is
we
can
head
back
over
to
that
floor,
request
that
we
opened
and
before
we
before
we
actually
do
close
it.
Let's
just
edit
the
body
and
we're
gonna,
add
those
changes
tags
that
we
talked
about
before
so
yeah.
B
B
So
we're
just
gonna
update
the
PR
body
here.
It's
very
quick
update
comment,
let's
just
head
back
to
our
recent
deliveries
and
just
notice
that
that
actually
also
triggered
a
web
pop
event,
so
yeah,
let's
refresh,
and
we
should
see
a
new
event
at
the
top
and
if
we
click
into
that
it
should
be
red,
because
this
also
does
not
have
an
action
of
close.
It
has
an
action
of
edited.
B
So
that's
fine.
This
is
expected
so
but
John,
maybe
let's
clear
our
server
logs
again,
just
so
that
it's
clean
for
when
we
do
actually
a
very
good,
great
okay,
so
we're
gonna
head
back
over
to
github
and
we're
gonna
head
back
over
to
our
pull
request
and
we
get
to
merge
it
now.
Click
that
button
click
that
button
click
that
button.
C
B
B
A
B
So
what
we
had
comments
it
just
now
is
that
line
9,
but
the
line
above
it
line
8
should
also
be
uncommented
and
also
two
lines
above
that
line.
Five
should
also
be
uncommented,
and
then,
if
we
scroll
down
every
line
between
line,
32
and
46
should
be
uncommented
yeah,
even
above
even
above
that
John
from
the
bare
room.
The
top
of
verify,
okay,
too
close
so
32
to
46,
should
be
uncommented.
A
B
This
line
says
return
error
unless
merged
into
master,
so
there
is
the
ability
to
close
a
PR
that
isn't
merged.
So
once
we've
checked
that
the
action
is
murd
is
closed,
we
need
to
check
that
it
was
actually
merged
into
master.
So,
let's
scroll
down
once
we
my
commented
line
10,
we
need
to
scroll
down
to
the
line
48
and
uncomment
everything
between
48
and
53,
and
so
once
it's
uncommented
we'll
just
go
through
what
what
the
the
innards
of
this
method
are.
B
So
the
first
line
here
we
need
to
check
whether
or
not
the
PR
was
merged.
So
inside
the
pull
inside
the
payload
that
pull
requests
resource
has
a
key
called
merged
and
it'll
either
be
true
or
false.
Based
on
whether
or
not
the
pull
request
was
merged,
we
only
care
about
the
true
state.
The
true
side
of
that.
So
we're
saying
is
this
full
request
merged?
B
Is
this,
or
is
this
key
equal
to
true,
and
so
the
next
line
is
not
only
do
we
want
to
know
if
it's
merged,
we
want
to
know
if
it's
merged
into
master,
as
I
mentioned
before,
there
is
a
scenario
in
which
a
pull
request
could
the
base
branch
could
be
something
other
than
mastered.
So
if
a
pull
request
is
merged
into
a
different
base
branch,
we
don't
we
don't
really
care
about
that.
We
only
care
about
things
that
go
into
master
so
inside
the
payload.
B
C
B
B
We
need
to
check
whether
or
not
this
space
branch
was
into
the
space
branch
was
masters,
so
we
have
that
ref
key,
which
should
be
the
branch,
the
branch
name
and
so
we're
just
checking
that
it's
master
and
so
the
next
line
line
52
we're
just
checking
that
both
of
those
conditions
are
true
and
yeah
and
if
they're
not
true,
we'll
return
early
and
return
them
return
an
error
so
because
we
did
merge
into
master.
When
now
that
we've
been
commented,
this
we
should
be
able
to
go
back
to
our
recent
deliveries.
B
B
So
if
you
are
following
along
on
the
web,
the
workshop
MD
file,
we
are
done
with
step
one
and
if
you
have
fallen
behind
or
you
have
some
errors
in
your
code
or
something
what
you
can
do
is
you
can
just
check
out
the
branch
for
step.
One
and
you'll
be
caught
up
to
exactly
where
we
are
because
we're
about
to
start
step,
two
I
will
just
pause
and
see
if
there
are
any
questions
or
anything,
we
should
go
over
before
we
start
step
two.
B
Okay,
sorry,
we're
gonna
jump
into
step.
Two
now
step.
Two
is
very
short,
so
so
yeah
step,
two
is
gonna,
be
enabling
octo
kit.
I
will
just
mention
that
today,
we're
gonna
be
using
the
octo
kit
gem,
the
gem,
which
is
like
the
Ruby
way
of
saying
library,
dependency,
and
so
it's
already
installed
in
this
application.
So
we
don't
have
to
worry
about
that.
We
know
we
have
access
to
it.
B
So
all
we're
gonna
do
right
now
is
on
line
55,
we're
going
to
uncomment
line
55
through
57,
and
we're
gonna
see
here
that
all
this
does
is
create
a
new
octo
kit
client,
with
our
personal
access
token
that
we
set
before
as
I
mentioned
before
personal
access
tokens
are
what
allows
us
to
authenticate
with
the
REST
API.
There
are
a
few
endpoints
that
I
think
you
don't
actually
need
authentication
for,
but
for
the
most
part
you
do
need
to
authenticate,
and
so
this
is
just
the
way
that
we're
gonna
do
it.
B
B
So
John
is
gonna,
do
puts
that
and
then
quote
the
current
user
is
and
then
string,
interpolation
and
he's
gonna
call
inside
the
string,
interpolation
octal
kit,
dot
user
dot
login.
So
this
should
be
our
user
login,
because
we
are
authenticating
as
ourselves
with
this
personal
access.
Token
great!
So
let's
save
this
and
we'll
clear
the
server
logs
and
we
will
redeliver.
B
So
we're
just
it
doesn't
at
this
point:
it
doesn't
really
matter
which
event
we
redeliver,
because
we
put
it
at
the
top
of
that
method,
but
we
are
just
going
to
redeliver
the
one
that
passes,
which
is
that
pull
request
closed
one
because
it
was
the
most
recent
one
great.
We
should
still
see
a
success.
Let's
go
over
to
our
server
logs
and
see
if
we
got
great
so
it
looks
like
we
printed
out.
B
B
B
B
So
now
that
we
have
the
ability
to
make
API
calls
and
we
verified
that
we
actually
need
to
know
which
API
calls
we're
gonna
be
making,
and
there
are
a
lot
of
API
endpoints.
So
who
knows
who
could
possibly
know
which
API
endpoints
we
would
need?
The
way
to
know
is
to
look
at
our
developer,
documentation,
yeh,
documentation.
B
So
we
actually
something
I
was
just
note.
Is
that
you
could
you
guys
do
not
need
to
do
this
yourselves?
Let's
all
just
watch
what
we're
gonna
be
doing,
so
you
can
give
yourself
a
little
break
here,
we're
just
just
following
along
with
what
we're
gonna
do.
So
we
already
have
the
REST
API
documentation
open,
and
we
actually
know
that
the
API
that
we
care
about
is
the
contents
API.
This
actually
lets
us
fetch
and
update
content
like
file
contents
inside
of
repositories.
So
let's
just
go
through
the
API
endpoints
that
are
provided
here.
B
So
it
looks
like
the
first
one
is
the
get
readme
endpoint,
which
is
an
HTTP
GET
and
the
path
is
readme,
and
so,
if
all
you
care
about
is
viewing
the
conscious
of
a
readme.
This
is
the
endpoint
for
you.
The
next
one
is
just
a
get
contents,
one
which
is
a
get
request,
but
you
actually
are
able
to
use
any
path
that
you
want
and
you
can
pass
it
in
as
a
parameter
and
you
can
get
the
content
of
any
file
in
the
repository
and
yeah.
B
I
should
mention
that
these
Doc's
are
actually
really
helpful.
They
show
you
all
the
parameters
that
you
can
pass
in
and
all
of
the
like
example
requests
and
example
responses,
and
so
the
next
endpoint
is
a
put
endpoint.
That
also
takes
a
path,
parameter
and
yep
that
that
will
update
or
create
a
file
in
the
repository,
and
then
the
last
one
here
is
a
delete
endpoint
that
so
takes
that
argument
of
a
path
and
will
delete
any
file
in
that
path.
B
Great.
So
today
we
know
that
what
we're
gonna
need
to
be
doing
is
we're.
Gonna
need
to
be
fetching
the
file
content,
so
we're
gonna
need
to
fetch
what's
already
existing
in
the
changelog
and
then
we're
gonna
need
to
update
the
changelog
contents
with
what
was
existing
plus
our
new
entry.
So
the
endpoints
that
we're
going
to
use
just
to
go
over
them
again.
Is
that
get
endpoint
where
you
can
put
in
a
path,
and
this
create?
B
Great
okay,
so
now
that
we
know
which
endpoints
we
care
about,
we
could
like
s
Brooks
mentioned.
If
we
weren't
doing
this
in
application,
we
could
just
curl
these
endpoints
and
be
done,
but
because
we
are
doing
this
in
an
application
and
we
want
to
do
it.
Programmatically
we're
gonna,
use
the
octo
kit,
client,
and
so
let's
take
a
look
at
the
octo
kit
source
code,
great
John
uhrin
has
it
open,
and
so
we
at
we
already
know
that
the
only
API
that
we
care
about
for
today
is
the
content
API.
B
So
John
is
already
in
the
contents,
our
B
file,
and
so
the
way
that
I
soak
it
works
is
that
it
actually
creates
methods
for
each
individual
endpoint.
So
you
can
see
that
this
readme
method
maps
to
that
readme
endpoint
that
we
already
looked
at
and
the
next
method
is
the
contents
method
which
maps
to
that
get
endpoint
and
I.
Think
I'll
just
point
out
as
we're
looking
at
these
that
the
there
are
comments
above
each
of
these
methods
that
tell
us
which
humans,
the
methods
take
which
what
the
return
value
is
of
the
method.
B
It
gives
you
a
link
to
the
documentation
and
it
gives
you
an
example
of
how
to
actually
called
method
so
pretty
useful
stuff,
and
so
there's
that
method.
And
then,
if
we
keep
scrolling,
we'll
see
a
create
content.
So
this
would
create
a
file
for
us
and
the
next
one
is
the
update
contents,
which
will
update
a
file
using
that
put
endpoint
and.
B
And
yeah
and
the
arguments
that
this
one
takes
are.
This
is
an
example
of
what
this
one
of
how
to
call
this.
But
the
arguments
are
you
need
a
repository.
You
need
a
path
to
the
file.
You
need
a
commit
message.
You
need
the
SHA,
which
is
the
head,
get
sha
of
the
file
and
the
actual
contents
that
you're
trying
to
update
and
I
think
there
should
be
one
more
method
in
here.
B
So
now
that
we
know
which
methods
we
want,
let's
head
back
over
to
our
web
hooks
controller-
and
this
is
where
you
guys
should
start
following
a
lot
again.
If
you
were
just
watching
we're
first
gonna
uncomment
line
12,
which
calls
that
create
change,
log
entry
method
and
then
once
that's
uncommented,
we
can
scroll
down
and
so
we're
gonna
uncomment
line
59
through
68.
B
And
John,
actually
just
for
right
now.
Do
you
mind
re
commenting
lines,
63,
okay,
yeah,
so
we're
just
going
to
uncomment
lines,
59
and
through
61
and
then
68.
So
the
only
things
that
should
be
uncommon.
Sorry,
that
was
maybe
a
little
bit
confusing.
The
only
thing
that
should
be
uncommented
in
this
method
are
the
first
two
lines
and
the
end,
which
is
on
line
68
great,
and
so
let's
take
a
look
at
these
first
two
lines,
so
it
looks
like
that
first
line
is
calling
a
method
called
get
file.
B
So
if
we
scroll
down,
we
can
see
on
line
70.
We
have
a
method
called
get
file
and
so
we're
gonna
uncomment
that
method
line
70
through
75,
and
so
this
method
is
using
that
octave
key
client
that
we
created,
and
it's
calling
that
contents
method
that
we
already
looked
at,
which
will
return
the
contents
of
a
file.
So
if
the
arguments
it
takes
are
a
repository,
and
so
this
is
actually
a
string,
that
is
the
repository
name,
what
we
call
name
with
owner.
B
So,
for
example,
this
one
is
because
our
user
name
is
Bruno
the
Pug.
It
would
be
Bruno
the
Pug
slash
web
hooks
with
rest,
but
neither
repository
name
but
yeah.
We're
actually
just
using
a
method
here,
and
we
have
the
repository
as
part
of
the
web
book
payload,
so
we're
just
gonna
pull
that
string
out
of
the
web
book
payload,
so
yeah.
What
we
just
did
right
now
is
we
uncommented
the
repo
method
which
is
line
77
through
79
and
so
yeah.
It
just
looked
into
that
repository
key
and
finds
the
full
name
of
it.
B
Great,
so
now
that
that
is
now
that
we
have
this
much
uncommented,
we're
gonna,
add
another
binding
dot,
pry
and
we're
gonna
put
it
right
after
line
71.
So
basically
we're
gonna
call
the
method
which
is
gonna,
make
the
API
call
for
us
and
then
we're
gonna
hit
this
binding
dot.
Pry
and
we're
gonna
examine
the
response
together.
B
So
we
should
save
this
and
let's
head
back
over
the
server
logs
and
clear
them,
and
we're
gonna
go
back
to
our
recent
deliveries
and
this
time
we
do
want
to
make
sure
that
we're
gonna
redeliver
the
most
recent
event,
which
is
the
pull
request
closed
event,
because
we
needed
to
pass
all
of
those
filters
that
we
already
added
great.
So
we're
gonna
hit
that
redelivery
button.
B
B
Yeah
great,
so
these
are
the
things
that
we
get
back
from
the
API,
so
we
got
the
name
of
the
files
we
get
the
path
of
the
file.
We
get
that
sha
that
we
need.
This
is
the
size
or
the
content
length
of
the
file,
some
URLs
to
view
the
file
and
the
actual
contents
of
the
file
I
yeah.
So
because
we
already
know
about
this
API,
it
turns
out
that
the
contents
are
base64
encoded.
B
So
what
we're
gonna
need
to
do
right
now
is
decode
them,
and
so
ruby
gives
us
this
nice
method
called
decode,
64,
John's,
favorite
method,
and
when
we
do
this,
we
get
the
actual
like
human,
readable
file.
Context
final
contents-
and
this
is
exactly
what
we
expect.
This
is
the
actual
raw
markdown
of
that
markdown
file.
B
Great.
So
now
that
we
know
we
can
get
the
content
and
we
can
get
the
shop
from
this
from
this
response,
we
should
be
all
good.
We
can
exit
this
pry
by
typing
exit
and
we're
gonna
head
back
over
to
the
web
hooks
controller,
and
we
can
remove
that
by
need
a
pry
that
we
added
yeah.
So
we
just
removed
it,
and
so
what
we're
gonna
do
now
that
we
have
called
the
method
on
line
71
and
we
assign
the
response
to
that
response.
B
B
The
contents
as
a
string
and
disha,
something
that
I
was
just
note
for
Ruby
for
Rubeus,
who
will
continue
to
use
the
ahsoka
client
in
the
future.
Is
that
the
way
that
the
Advocate
client
works
is
that
if
you
get
a
response
from
the
API,
that
is
not
a
success.
Response
it'll
actually
raise
an
exception,
a
custom
exception,
and
so
the
best
practice
here
would
be
to
actually
rescue
those
custom
exceptions
and
handle
those
cases
here.
We're
yeah
something
like
octo
kit
not
found
or
something
yeah,
something
like
that.
B
B
Okay,
great
so
now
that
we
have
this
get
file
method,
all
uncommented
and
working
as
expected.
Let's
actually
go
back
up
to
the
create
change
log
file
and
we're
gonna
uncomment
lines
63
through
67,
so
this
entire
file,
this
entire
method
should
be
uncommented
now
and
so
we'll
be
just
uncommented.
Is
this
other
API
call
that
we're
gonna
make?
Thank
you?
John
John
just
expanded
it
so
that
it
doesn't
do
the
word
wrapping.
B
So
yes,
so
it's
more
easy
to
view
that
it's
line
63
through
67,
so
this
is
going
to
do
another
API
call
for
us
this.
Does
this
uses
that
octal
kick
client
that
we
created
and
it's
going
to
update
the
file
contents
for
us,
and
so
the
arguments
that
we
need
are
that
same
repo
that
we
already
used
to
get
the
contents?
We
need
the
file
path
again,
which
is
the
same
file
path
that
we
used
before.
We
need
the
commit
message
which
could
be
any
string.
This
is
the
string
we
decided
on.
B
We
need
the
sha,
which
is
that
head
get
for
the
file,
and
then
we
actually
need
the
contents
of
the
file.
So
every
whatever
we
put
in
here
is
going
to
be
updated.
Everything
will
be
replaced
by
whatever
we
put
in
right
here.
So
what
we're?
What
we
want
to
do
is
we
want
to
take
what
was
already
existing,
which
is
that
contents
and
we
want
to
append
that
new
entry
to
what's
already
existing,
so
we're
just
going
to
add
them
together,
but
we
haven't
actually
looked
at
that
format.
Changes
method.
B
So
what
we're
gonna
do
is
we're
gonna,
uncomment
format,
changes
which
is
line
81
through
99
great,
and
so
let's
take
a
look
at
what's
in
here.
So
first
is
we're
gonna
dig
into
the
payload
and
get
some
information
about
the
pull
request
and
the
user
who
opened
the
pull
request
so
that
we
can
add
that
as
information
on
the
changelog.
So
the
first
thing
is
the
author
avatar.
This
allows
us
to
display
that
avatar
on
the
name,
so
we
can
put
their
name
next
to
their
avatar.
B
The
URL,
so
that'll
just
be
a
link
to
their
github
profile
and
I.
Guess
I'll
just
mention
since
we're
in
here.
All
of
these
are
accessing
the
pull
request
user,
which
again
is
different
than
the
sender,
which
is
different
than
the
sender
key.
So
I'll
just
go
back
to
the
same
example
again.
If
John
opened
this
PR
and
I
was
the
one
that
closed
it.
This
user
would
still
be
John,
whereas
the
event
sender
would
be
me.
B
Yeah.
So
that's
just
a
note
on
that,
and
so
the
next
thing
is
the
diff
URL.
So
this
is
actually.
This
will
display
the
entire
diff
of
the
pull
request
if
they
click
it
and
then
the
next
one
is
actually
just
a
link
to
the
pull
request
itself,
and
so,
if
we
scroll
down
a
little
bit
more,
this
is
just
a
Ruby
multi-line
string,
that
is
in
marked
the
insides
of
this
string
or
markdown,
so
that
first
line
line
19
you
can
see.
B
We
have
that
pound
sign,
so
that'll
make
it
an
h1
and
we'll
just
put
in
a
timestamp
right
there.
So
it'll
be
a
bigger
timestamp
and
then
the
next
line,
we're
gonna,
add
all
the
information
about
the
author
that
we
have.
So
this
will
just
be
the
author,
avatar
URL
I
mean
the
author
avatar
image
and
then
the
name
with
a
link
to
their
profile
and
then
at
the
bottom.
B
We're
gonna
display
a
link
to
the
diff
and
a
link
to
the
pull
request,
and
the
one
thing
that
we
skipped
in
here
is
this
change
description
method.
So
this
is
where
we're
actually
gonna
pull
that
information
from
in
between
those
two
changes
tags.
So
let's
take
a
look
at
that
method
which
starts
on
line
101
101
through
108
great.
B
So
yes,
this
is
the
method.
So,
let's
just
deep
dive
into
what
this
method
is
doing.
So
the
first
thing
it's
doing
is
it's
getting
the
pull
request
body,
which
is
that
you
know
main
box
on
the
pull
request
page
and
then
we're
doing
a
regex
match
to
capture
every
character,
whitespace
or
not
in
between
the
two
changes,
tags
and
so
Ruby
will.
B
The
way
this
works
in
Ruby
is
that
if
it
finds
a
match,
it
will
return
a
match
object
and
then
we
can
call
captures
which
will
give
us
what
was
captured
in
between
those
two
tags
and
then
we're
just
gonna
strip
any
trailing
whitespace
on
that
string
and
then,
if
there
wasn't
a
match.
So
if
those
changes
tags
didn't
exist
there,
we
would
just
fall
back
to
the
pull
request
title
great.
So
now,
that's
that
now
that's
uncommented
I
think
we
won
commented
basically
everything
that
we
need
so
format.
B
C
B
And
change
log
entry
so
that
last
line
line
67
we're
gonna
take
what
was
originally
there
and
we're
gonna
append
that
new
string
with
that
new
information
and
that's
gonna
be
replaced
as
the
file
contents.
Okay,
oh,
that
was
a
lot
of
talking.
I,
think
we're
ready.
We've
saved
these
changes.
We
have
a
clear
server
log.
We
have
an
event
that
should
pass
all
of
our
filters,
so
we're
gonna
head
back
over
to
the
recent
deliveries
and
redeliver
that
event.
D
B
D
B
B
B
A
B
Last
step
this
should
be
pretty
fast,
yeah,
okay,
so,
let's
just
mention
again
that
was
the
end
of
step
three.
So
if
you
are
following
along
on
the
workshop
MD
and
you
have
fallen
behind,
you
can
just
check
out
the
branch
for
step.
Three
and
you'll
be
caught
up
to
exactly
where
we
are
right
now
and
we're
about
to
start
step.
Four.
So
great.
Let's.
B
Do
it?
This
is
the
last
step
you
guys,
so
we
just
wanted,
since
we
just
wanted
to
like
leave
you
with
some
webhooks
best
practices.
We're
only
gonna
go
over
one
right
now,
which
is
the
H
max
signature,
verification
that
Brooks
already
talked
about,
but
we're
gonna
implement
it
together.
So
on
line
four
there's
another
before
action,
you
should
be
able
to
uncomment,
and
it
says
before
action
verify
signature.
B
Just
a
note
about
rails
is
that
rails
does
actually
run
these
before
actions
in
order
and
since
since
it's
possible
that
the
request
could
be
malicious
before
we
check
this,
we
don't
want
to
actually
do
anything
before
we
check
whether
or
not
it's
from
github
just
for
security
reasons.
So
that's
why
we
put
this
one
above
the
other
one,
and
if
you
scroll
all
the
way
back
down
to
line
110,
you
should
be
able
to
uncomment
lines
110
through
120
and
we'll
just
do
a
deep
dive
into
the
body
of
this
method.
B
So
the
first
thing
we're
going
to
need
we're
gonna
need
that
github
webhook
secret,
which
we
set
at
the
very
beginning
and
just
reminder:
John,
says:
Bruno.
The
adorable
pug,
and
so
what
we're
gonna
do
is
we're
gonna,
take
that
secret
and
we're
gonna
create
an
H
Mac
digest
of
the
secret
and
the
request
body.
Just
as
a
string,
we're
just
gonna
read
the
body
as
a
string.
We
don't
actually
want
to
interact
with
any
of
the
request
body
until
we
have
verified
that
it
has
come
from
github.
B
We
don't
want
to
access
any
of
the
data
in
there.
We
just
want
the
full
string,
and
so,
if
there's
even
one
byte
of
difference
from
what
we
sent
you
on
the
github
side,
this
signature
will
be
completely
different
and
will
not
match
what
you
get
from
the
header.
So
the
next
line
you
can
see
that
we
do
this
secure.
Compare.
So
we
take
that
signature
that
we
generated,
and
we
take
the
signature
that
we
got
in
that
X
hub
signature
header
and
we
compare
them
with
each
other.
B
This
secure
compare
method,
basically
will
compare
every
single
byte
and
actually
prevents
timing
attacks,
so
it
won't
ever
return.
Early
it'll
always
compare
all
of
the
bytes,
and
so
if
it
doesn't
pass
this
comparison,
what
we're
gonna
do
is
we're
gonna
return,
we're
gonna,
get
that
X,
github
delivery,
header
and
we're
just
gonna
return
an
error
with
that.
Gooood
that'll
just
be
helpful
for
debugging
later,
and
we
don't
actually,
as
I
mentioned,
we
don't
want
to
access
anything
in
the
request
body,
because
this
has
already
been
verified
as
a
malicious
request.
B
So
we
only,
we
only
will
access
something
of
the
headers
at
this
point
great.
So
now
that
this
is
uncommented
and
staged,
we
can
clear
our
blogs
and
we'll
head
back
over
to
the
recent
deliveries
and
we
are
going
to
redeliver
it
that
most
recent
event,
which
is
the
pull
request,
close
one.
We
will.
We
want
it
to
be
able
to
pass
I
guess
it
actually
doesn't
for
this
example,
doesn't
really
matter,
but
we
will
just
do
that
in
this
most
recent
one
great
lets
redeliver
it
just
a
note.
B
This
will
also
add
another
entry,
another
duplicate
entry
to
your
change,
lock,
that's
totally
fine
great.
We
still
got
a
successful
response,
that's
because
we,
when
we
configure
this
webhook,
we
use
that
same
secret.
So
what
we're
gonna
do
now
is
we're
gonna
scroll
up
on
this
page
and
John's
gonna
change
the
secret
to
anything
else
and
we'll
see
that
it
doesn't
match.
Oh
he's
using
Jane
as
his
new
secret,
which
is
my
favorite
string
and
so
yeah.
B
He
just
changed
that
field
and
then
he's
gonna
click
update
webhook
great,
and
he
should
you
should
see
at
the
top.
The
hook
was
successfully
updated
and
then
we
can
scroll
back
down
and
something
about
redeliver
e's
is
that
it
will
honor
that
new
configuration
on
the
redelivery.
So
if
we
hit
that
redeliver
button,
it
will
it'll
compute
a
signature
with
that
new
secret,
so
let's
hit
redeliver
and
what
we
should
expect.
This
time
is
a
422
because
it
doesn't
match
the
secret
that
we
have
set
in
our
application.
So
we
got
the
422.
B
B
B
A
Thank
you.
Everyone,
Thank
You
Jane
for
telling
me
that
I
was
muted
by
the
way
this
is
Bruno.
The
Pug
that
we've
been
working
with
throughout
this
workshop
feel
free
to
continue
any
sort
of
debugging
or
questions
that
you
have
in
the
slack
we're
going
to
keep
this
open
until
Friday,
but
thanks
everyone.
It's
been
a
pleasure.