►
Description
Presented by Chris Hulton, Senior Software Engineer (Code Climate) & Josh Kalderimis, Co-founder and VP (Travis CI).
GitHub Apps provides a new powerful and flexible way to integrate with GitHub. Both Code Climate and Travis CI have gone through the migration processes respectively, and are here to share their learnings. We will be covering the benefits of GitHub apps, the challenges we encountered during the migrations, and some stories and learnings direct from the teams involved.
About GitHub Universe:
GitHub Universe is a two-day conference dedicated to the creativity and curiosity of the largest software community in the world. Sessions cover topics from team culture to open source software across industries and technologies.
For more information on GitHub Universe, check the website:
https://githubuniverse.com
A
So
our
talk
is
from
millions
of
OAuth
tokens
to
github
apps.
Thank
you
thanks.
So,
first
off
happy
end
of
day
one
it's
been
a
long
day.
A
lot
of
cool
stuff
hope
everyone's
had
a
great
day
to
introduce
both
of
us
I'll
start
on
traduced
myself,
I'm
Chris,
Holton
I,
don't
like
Comic
Sans
Josh
made
me
use
that
font,
because
he
didn't
really
like
this
picture.
I.
A
A
A
B
B
Travis
is
a
Berlin
company
I.
Will
you
know
from
what
we
know
of
Berlin?
It's
filled
with
a
lot
of
history,
a
lot
of
dance
clubs,
a
fair
amount
of
let's
just
say,
walls
and
I-
will
thank
Germany
for
David
Hasselhoff.
If
it
wasn't
for
the
wall
coming
down,
David
wouldn't
be
the
star
he
was
today.
So
thank
you.
Germany
for
David
Hasselhoff.
A
All
right
now
stand
back
over
here,
so
the
three
main
takeaways.
We
want
people
to
learn
from
this
talk
today.
The
first
is
github.
Apps
is
the
best
way
to
integrate
with
github
we're
gonna
start
reviewing
the
OAuth
app
integration,
explain
some
of
its
limitations
and
move
on
to
summary
of
github
apps
and
how
we
implemented
it
for
both
code,
climate
and
Travis.
We
want
you
to
take
away
that
migrations,
have
some
complexities.
So,
if
you're,
starting
from
an
Olaf
app
moving
to
a
github
app
there's
a
lot
of
things
to
keep
in
mind.
A
A
So
first,
let's
talk
off
o
auth
people
have
probably
heard
of
are
familiar
with
it's
a
spec
related
to
authorization.
There's
been
a
couple
of
versions
and
the
way
github
is
implemented.
It
is
you
can
create
an
OAuth
application
and
you
can
have
a
user
authorize
that
application
you'll
get
a
token
back
and
that
token
can
be
used
to
access
github
data
on
behalf
of
that
particular
user.
A
The
access
level
is
determined
by
the
user
token
scope,
so
scopes
can
be
something
like
user,
email
or
organizations
or
repository
and
those
really
limit
what
that
token
can
do,
and
what
authorization
is
we're
just
getting
the
we're
good
all
right,
it's
awesome.
Thank
you
very
much
and
authorization
is
based
on
the
user's
accessible
resources.
So,
if
I
authorize
the
repo
scope
for
an
OAuth
app,
it's
pretty
much
with
excluding
third-party
OAuth
X
restrictions,
it's
going
to
have
access
to
what
I
can
access
all
of
my
repositories.
A
So,
given
that
there
are
some
limitations
with
it's,
this
ooofff
app
framework,
so
one
is
that
tokens
can
be
revoked
or
suspended
at
any
time
by
a
user.
They
can
go
into
their
profile
settings.
They
can
revoke
a
token,
and
your
application
generally
won't
know
about
that
until
it
goes
to
use
the
token
and
get
some
sort
of
exception,
the
management
of
which
user
token
to
use
is
complex
and
unreliable.
A
So
if
you
have
an
integration,
that's
really
application
focused
and
you
have
a
bunch
of
user
tokens
knowing
which
one
to
use
who
has
authorization
for
what
which
ones
are
revoked
can
be
very
challenging
to
work
with,
and
many
scopes
include
both
read
and
write
access.
The
repo
scope
is
a
big
one.
Many
integrations
need
access
to
some
aspect
of
your
repository
data
and
the
scope
provided.
Repo
scope
is
both
read
and
write,
so
you
can
end
up
over
requesting
permissions
every
what
authorization
is
individually
configured.
So
each
person's
OAuth
token
is
separate.
A
You
might
change
your
own
scope.
Everyone
has
to
go
in
and
reauthorize.
You
can
end
up
in
a
situation
where
some
users
have
given
more
scope
or
less
scopes
and
others
and
ooofff
doesn't
include
the
concept
of
event
hook.
So
that'd
be
something
like
wanting
to
take
an
action
when
a
user
commits
to
set
that
up,
you
have
to
use
someone's
ooofff
access
token
to
make
an
API
request
to
the
hooks
endpoint
and
it's
really
tied
to
a
specific
user
rather
than
your
application
itself.
A
So
I
will
now
tell
you
more
about
github,
apps,
so
github
apps
for
people
who
aren't
familiar
with
it.
It
really
shifts
the
focus
from
the
user
to
an
installation,
so
it
provides
a
way
to
access
github
data
on
behalf
of
an
application
or
installation
itself
and
the
way
it
does.
This
is
through
short-lived
refreshable
access
tokens.
Your
installation
will
first
it's
a
two-step
process.
A
To
get
these
tokens,
it
will
authenticate
as
itself
using
its
private
key
and
a
JWT
token,
and
then
it
will
as
itself
request
a
token
for
particular
installation
and
then
that
installation
token
comes
back
it's
valid
for
a
period
of
time.
You
get
a
token
expiration
date
associated
with
that.
You
can
cache
it
until
then,
and
that's
the
way
that
you
really
interact
with
github
as
your
service
rather
than
a
particular
user.
The
access
level
is
determined
by
the
app
permission
so
rather
than
this
idea
of
scopes.
A
When
you
set
up
your
github
app,
you
specify
exactly
what
permissions
you
want
it
to
have.
They
can
be
much
more
granular,
they're,
read
or
write,
and
they
break
down
repository
to
things
like
pull
request.
So
if
your
vacation
needs
to
read,
pull
requests
and
right
to
commit
statuses,
you
have
the
ability
to
do
that.
You
don't
need
to
worry
about
these
tokens
being
in
different
states.
An
authorization
is
based
on
what
repositories
the
app
have
been
installed
for.
So
this
is
another
big
difference
where
the
users
specifically
choose
what
repositories.
A
They
want
your
app
to
be
able
to
access,
rather
than
the
very
broad
access
and
with
github
apps.
You
can
interact
with
github
as
a
bot,
which
is
what
I've
been
talking
about,
and
primarily
that's
what
you'll
be
doing,
but
there's
also
a
way
to
interact
as
a
user.
So
if
you
have
an
application
that
has
user
management
aspects
as
well
as
something
that's
doing
at
a
data
crunching
as
the
application,
you
can
do
both
and
that's
what
I'm
going
to
talk
about.
A
In
my
section
on
how
we
use
this
act
code,
climate,
so
code,
climate
for
people
who
don't
know
there's
two
main
products
at
code-
climate
people,
who've
heard
of
code,
climate-
would
probably
think
of
our
quality
product.
This
one's
been
around
for
about
seven
years
and
its
main
goal
is
to
help
developers
write
better
code.
So
it
integrates
with
winters
and
test
coverage
tools
and
it
helps
integrate
with
polar
quest,
workflow
to
make
sure
developers
are
merging.
A
So
we
were
pretty
deep
in
territory
and
we
saw
a
lot
of
those
limitations
that
I
mentioned
earlier
about
integration,
sometimes
breaking
or
not,
really
feeling
like
they're,
integrating
the
correct
way
so
moving
on
our
newest
product
velocity,
it's
got
launched
this
year
and
what
we
really
wanted
to
do
with
velocity
is
take
a
lot
of
our
learnings
from
quality
and
github
apps
and
really
started
off
as
a
github
app.
So
to
give
a
summary
of
how
velocity
works
or
what
it
does.
A
Its
objective
is
to
take
a
step
back
from
sort
of
the
repository
level
metrics
and
look
at
your
entire
engineering
organization
and
the
health
of
your
engineering
team.
So
how
often
our
developers
merging
pull
requests?
How
often
are
they
reverting
poll
requests?
How
long
are
they
waiting
for
review
things
like
that?
And
it
interacts
heavily
with
github?
It
queries
a
lot
of
repository
data
using
graph
QL
to
build
out
all
of
these
metrics,
and
it
pulls
often
for
a
feature
that
we
call
real-time
risk
alerts.
A
So
if
you
open
a
pull
request
and
it
starts
to
generate
a
lot
of
activity-
that's
something
that
we
want
to
notify
your
team
of,
so
it
can
potentially
take
action
as
quickly
as
possible,
and
so
we
need
to
pull
often
and
keep
this
in
mind
when
we
tell
some
tales
later
on.
This
is
this
sort
of
interaction
pattern
who's
gonna
come
up
for
us.
It
was
originally
implemented
as
an
OAuth
app.
A
So
right
around
the
time
we
started
it
early
this
year
was
when
we
were
learning
of
github
apps
and,
as
you
can
see
here,
the
Scopes
that
we
are
requiring
here.
It's
repository,
read
and
write
access
organization.
Admin
access
is
a
lot
of
things
that
we
needed
just
to
be
able
to
do
this
reading
of
github
data,
but
there
wasn't
really
a
way
to
say
we
only
need
read-only.
So
this
is
what
it
looked
like
before
we
decided
to
migrate
to
the
github.
A
A
So
the
way
that
worked,
we
added
all
the
code
for
being
able
to
refresh
the
access
tokens
for
listening
to
installation
web
hooks
things
like
that,
and
when
we
were
ready,
we
just
replaced
our
ooofff
client
ID
in
secret,
with
the
github
app
client
ID
in
secret,
and
so
the
next
time
users
logged
into
velocity.
They
saw
a
screen
like
this,
and
only
the
only
user
thing
that
we're
asking
for
here
is
email
access.
A
So
it's
a
huge
difference
from
before
when
the
first
thing
you
hit
is
basically
granting
all
your
positive
reax
is
here:
it's
just
your
email
and
this
the
installation
is
really
what
talking
about
earlier.
It
has
very
targeted,
read-only
permissions.
The
users
can
specify
exactly
what
repositories
they
want
velocity
installed
for.
Maybe
they
don't
want
to
use
it
on
their
personal
repositories,
but
they
do
for
their
work
repositories
and
the
permissions
lists
down
at
the
bottom.
It's
only
read
access
and
on
the
specific
resources
that
make
sense
with
what
velocities
trying
to
do
so.
A
That
was
a
big
win
and
advantage
for
us,
and
one
thing
to
keep
in
mind.
If
you
are
doing
a
migration,
is
you
need
a
plan
for
maybe
lazy's
a
bit
harsh
but
users?
You
know
there's
this
step
where
now
that
they've
authorized
with
the
github
app,
they
also
need
to
go
and
install
the
github
app
for
all
the
repositories
that
they
had
authorized
previously.
B
B
So
a
lot
of
Travis
is
built
on
events
that
are
coming
from
github.
So
you
push
a
commit
to
your
repository.
They'll
tell
us
we'll,
run
the
build
and
then
we'll
do
various
actions
afterwards,
like
we'll
deploy
to
Heroku
or
we'll
send
a
slack
message
in
the
pull
request
flow.
It's
very
similar,
pull
requests.
It's
opened
we're
gonna
test
it.
We're
gonna,
say
that
everything's,
okay
to
merge,
we're
gonna,
say
it's
passed.
B
So
Travis
is
enabled
across
about
1.2
million
repositories.
This
was
a
couple
of
months
old
we've
got
or
we
run.
Six
million
builds
a
month,
which
is
15
million
tests
or
jobs
per
month,
and
that
at
at
peak
time,
will
run
about
four
and
a
half
thousand
VMs
when
we're
running
people's
jobs,
and
you
know
concurrently
at
the
same
time,
essentially
what
Travis
is
about
is
reliability
and
why
I
stress
and
this
reliability
is
any
change
that
we
make
to
our
system.
B
If
we
stop
your
tests
from
running,
that's
breaking
a
contract,
you
expect
CI
to
be
reliable,
so
you
can
be
confident
in
what
your
merging
in
so.
What
you
may
not
know
is
that
there
are
two
websites:
we've
got
Trevor,
CI,
dot,
org
and
Travis
CI
comm
dot
org
is
for
our
open
source
and
dot-com
is
for
our
private.
So
we
didn't
really
want
that
long
term.
This
is
a
bit
of
a
history
thing.
This
is
a
whole
nother
talk
in
itself.
B
What
we
really
want
is
Travis
CI
comm
for
your
open
source
in
private,
but
to
get
there
we
have
a
bit
of
a
journey.
Now,
a
bit
of
this
started
with
a
phone
call.
It
started
with
a
phone
call
from
github
and
they
said:
hey
we've
got
this
new
chicks,
API
we'd,
love
you
to
get
on
board
and
use
it,
and
we
saw
this
as
a
great
opportunity.
Well,
chicks
API!
B
As
you
may
know,
this
new
tab
in
your
pull
request
and
it
can
show
you
rich
information
about
a
job
that
or
builders
passed
or
failed
or
about
what's
happening
with
your
code
coverage
and
your
complexity,
and
it
looks
a
little
bit
different
in
that
UI
in
the
poor
request.
You
know
UI
as
well
so
you're
instead
of
having
the
slashed
approach,
you've
actually
got
the
github
app
name
and
what
we're
running.
B
So
we
saw
this
as
an
opportunity
to
marry
together
our
private
and
our
public
to
have
this
one
platform,
but
to
get
there,
there's
really
the
UI
UX
flow,
and
this
is
what
I'd
like
to
talk
about
specifically
before
I
mention
the
UI
UX
fo.
Any
github
is
here
in
the
audience:
oh
I
do
love
you
just
please
be
aware
of
that.
Also
everyone
here
just
remember
those
hands
that
are
going
up
because
they're
the
people
to
talk
to
when
you've
got
a
problem.
B
Yeah
Brent
is
a
perfect
person
to
talk
to
so
in
the
ui/ux
flow.
We'll
look
at
what
it
looks
like
on
Travis
fear,
so
on
the
old
system,
which
is
what
we've
kept
with
Travis
CI
dot-org.
Now
this
is
a
way
of
pushing
people
to
calm
and
in
part,
because
in
get
up
apps
we
don't
have
a
way
of
saying
in
that
select
your
repositories
list.
You
can
only
select
public
or
you
can
only
select
private.
It
is
just
you
can
select
anything.
B
So
what
we
wanted
to
do
is
we
saw
this
as
a
perfect
opportunity
to
say:
let's
move
towards
the
one
platform
now
on.org
you've
got
these
switches
and
we
would
use
the
API
and
you're
all
token,
and
we
would
enable
a
service
hook
now
in
the
new
way.
We
have
to
actually
do
a
redirection
to
github
for
authorization,
so
you'll
click
on
the
activate
button.
That's
that
you'll
be
on
the
Travis
organization
and
you'll
come
to
github
and
then
github
you've
got
two
options.
You
can
select
all
repositories
or
select.
B
This
is
both
a
blessing
and
a
curse.
The
blessing
is
on
a
security
standpoint.
It's
great,
because
organizations
can
decide
what
repositories
you
can
see
whenever
you're
talking
to
get
up,
you
could
have
a
super
secret.
I've
got
a
mega
space
program.
That's
going
to
take
over
the
moon,
repo
that
you
don't
want
your
integration
to
see,
and
you
can
just
not
give
it
access
to
it.
That's
perfect!
B
The
trouble
is
that
a
lot
of
people
just
select
or
repositories
because
they
think
this
is
about
giving
access
to
the
repo,
instead
of
actually
authorizing
that
repository
to
use
the
service.
It's
this
bit
of
this
mind,
shift
of
great
for
security,
but
it's
a
little
bit
misunderstood
and
that's
a
problem
we
fell
into.
So
a
lot
of
people
will
first
have
to
decide,
am
I
doing
this
for
all
of
my
repositories
or
just
a
couple.
B
Next
they'll
come
back
to
Travis,
but
we
have
to
process
a
web
hook
in
between
so
have
we
processed
it
in
time
what
repositories
were
activated
during
list
some
to
enlist
all
and
then,
if
you
click
that
manage
button
and
the
top
right
that
you'll
see
there
and
we'll
go
to
one
of
two
places.
If
you're
a
member
of
the
organization
you'll
go
to
the
screen,
where
you
can
suggest
changes,
so
I
can
suggest
that
I
want
to
enable
this,
for
all
I
can
suggest
another
one
or
two
repositories
or
if
you
are
a
manager.
B
You
are
owner
of
the
organization.
You'll
come
to
this
manage
page
and
it
looks
a
little
bit
different.
But
what
we
found
is
whenever
you
have
that
manage
button,
it
will
always
select
all
repositories
by
default
and
in
part
because
of
the
joy
of
URLs,
because
there
is
no
URL
that
you
can
send
a
member
to
and
then
have
them
go
and
have
a
suggestion
and
then
have
another
one
for
it.
B
Well,
technically,
there
are
two
URLs
you
could
use,
but
then
you
have
to
keep
track
of
all
of
the
members
that
are
owners
of
the
org
and
it
gets
complex
and
it
gets
harder
to
actually
make
sure
it's
a
reliable
way
of
going
through
the
flow.
So
what
we
did
is
we
hijacked
the
URLs
and
we
found
that
if
you
always
suggest
use
the
suggested
target
ID,
which
is
the
github
owner
ID,
so
either
the
user
or
the
org,
and
you
use
installations
new
permissions.
B
If
you're,
a
member
of
the
org
you'll,
get
the
suggested
screen.
If
you're
an
owner
of
the
org
you'll,
be
redirected
to
the
installation
manage
page,
but
you
will
always
be
showing
the
selected
all
by
default,
which
people
get
confused
by
click
Save,
then
it
changes
everything
and
everything
blows
up,
and
then
they
email
you
that
something's
wrong.
Essentially
the
redirects
and
the
UX
is
a
bit
janky
at
the
moment
to
handle
so
Brent.
If
you
could
get
this
fixed,
it
would
be
really
great.
Thank
you.
B
Another
thing
is
that
you
have
to
keep
track
or
there
is
no
way
actually
to
keep
track
of
an
event
has
been
processed
yet
so
when
that
redirect
happens,
you
just
have
to
wait
a
period
of
time
and
hope
that
everything
has
been
processed
by
your
system
that
the
event
came
quickly.
It
was
processed
quickly.
There
were
no
delays,
there
are
no
errors,
great,
it
just
works
and
there's
no
event.
B
Id
that's
passed
to
you
for
you
to
then
track
if
an
event
came
for
you
to
process,
but
all
in
all
get
BAPS
has
actually
helped
us
move
towards
a
single
platform
when
we
first
launched
our
integration.
Now
these
two
lines,
the
green
and
the
blue
green-
is
our
old
service
hooks.
This
is
coming
into
our
application.
That
is,
processing
all
our
hooks
and
the
blue
is
the
get
up,
apps
listener
and
what
you'll
see
in
the
very
beginning
or
end
of
August,
beginning
of
May.
B
We
announced
this
to
everyone
that
you
can
use,
get
up
apps
and
have
one
just
Travis,
CI
comm,
and
we
had
a
few
flowing
in
a
few
people
started
migrating
and
then
on
the
7th
of
May
github
announced
checks,
API
and
it
exploded.
So
within
about
a
week,
we
were
processing
about
the
same
amount
as
people
started,
transferring
and
integrating
over
and
then
at
the
end
of
the
month,
they're
into
four
weeks,
we're
already
at
double
what
the
service
hooks
was
doing,
and
this
is
the
last
week
in
the
last
week
now.
B
Service
hooks
is
about
five
percent
of
what
we're
doing
so.
It's
actually
helped
us
move
towards
much
more
reliable
system
because
of
how
tokens
work,
how
we
can
listen
to
the
events
and
how
we
don't
have
to
find
a
random
user
or
token
for
talking
to
the
API
to
date
and
I
just
checked
this
about
20
minutes
ago
we
have
over
50,000
active
installations
between
organisations
and
users
on
Travis,
CI,
comma
loan.
B
Of
the
events
that
we're
processing,
83%
of
them,
84%
I'll,
say
83.5%
are
coming
from
a
github,
apps
installation,
while
still
16%
are
coming
from
web
hooks
and
that's
the
problem
there's
a
long
tail
that
you'll
need
to
address,
especially
when
you're
dealing
with
large
migrations,
and
this
is
what
happened.
What
we
saw
in
about
April
April
May
was
the
actual
dip.
You
can
see
that
activity
on
org
dipped
while
on.com
is
increased
and
that's
the
eventual
goal
of
this.
B
We
want
to
transfer
the
load
over,
but
we
want
this
to
be
mostly
invisible
to
users.
We
don't
want
them
to
have
to
have
the
rug
pulled
out
and
just
have
to
be
weird
and
complex
to
not
work
and
as
well
organization
usage
is
increased
and
dipped
and
increased
in
depth
for
users.
What
we
wanted
to
focus
on
needs
to
be
opt
in
so
moving
from
Roth
to
get
up.
Apps
does
require
people
to
accept
and
opt
into
it.
You
do,
though,
have
to
force
the
new
way.
B
You
have
to
help,
you
know,
lead
them,
guide
them
hold
their
hand
through
the
process,
and
we've
still
got
a
much
bigger
issue
to
tackle,
which
is
github,
apps
or
now
that's
how
you
can
have
people
authenticate
to
your
github
app
and
it's
kind
of
like
that
mixture
of
orth
and
get
up
apps,
but
we
haven't
got
there
yet
so
we've
got
through
a
part
of
the
problem.
I
think
we're
probably
about
20%
of
the
way
through
there
with
80%
of
the
work
done.
B
A
That's
about
25,000
graph,
dwell
points
you
get
per
hour,
so
compare
that
to
with
github
apps.
The
installation
itself
has
its
own
rate
limit.
So,
while
that
makes
sense
to
jump
from
switching
over
immediately
our
rate
limit
when
from
what
it
was
before,
and
we
really
felt
like
we
weren't
even
sure
if
we
could
switch
over
and
not
run
into
all
kinds
of
issues
with
the
statuses,
not
posting.
You
know
up-to-date
and
things
like
that.
A
So
the
first
thing
we
really
needed
to
do
was
understand
our
graph
QL
usage
and
that
maybe
sounds
easier
than
it
is
when
your
queries
really
get
complicated,
and
this
snippet
here
is
only
5%
of
one
of
our
more
complicated
queries.
It's
really
hard
to
look
at
it
and
figure
out.
There
are
formulas
based
on
like
how
many
n
plus
1
queries.
There
are
like
roughly
how
many
graphical
points
you're
using,
but
we
really
couldn't
do
it.
We
tried
to
look
at
ours
and
we
just
couldn't
figure
it
out.
A
So
what
we
actually
ended
up
doing
was
we
used
the
rate
limit
object
in
graph
QL,
so
that
will
return
the
cost
of
each
query,
which
is
particularly
useful
for
us
as
well
as
things
like
when
you
can
retry
the
query,
the
rate
limit
arraigning,
but
we
really
use
the
cost
and
we
log
for
every
organization.
You
know
what
queries
we
were
making,
how
expensive
they
were.
A
How
often
we
were
making
them
and
we
ended
up
with
a
very
rough
equation
for
how
many
graphs
ul
points
we
were
using
per
hour
as
a
function
of
the
number
of
repositories
in
that
organization.
So
we
looked
at
what
we
would
get
with
github
apps
and
we
thought
well.
We
found
there
would
be
some
difficulties
remaining
on
our
limit
if
we
just
immediately
switched
over
one
cool
thing,
the
github
apps
does
have
is
a
sliding
rate
limit.
A
A
Conditional
request
is
also
a
great
way
to
limit
how
many
requests
you're
making.
So
that
would
be
things
like
using
etags
or
last
modified.
Unfortunately,
that's
not
really
an
option
for
graph
QL,
it's
not
supported,
but
if
you're
using
the
REST
API,
that's
a
great
way
to
do
that.
However,
that
also
has
the
complexities
of
you
need
to
keep
track
of
the
response
you
to
keep
track
of
those
tags,
etc.
So
those
were
options
for
us.
What
we
ultimately
ended
up
doing
was
taking
advantage
of
a
few
other
strategies.
A
One
was
relatively
simple,
but
once
we
had
that
equation
for
how
many
graph
12
points
we
needed,
we
knew
what
sort
of
rate
limit
adjustments
we
would
get
based
on
how
many
repositories
were
installed.
We
just
adjusted
our
frequency
so
that
it
would
fit
within
those
bounds
for
an
average
organization
size.
A
So
that
would
be
something
where
we
were
still
running
quickly
enough,
where
the
notifications
would
be
useful,
but
maybe,
instead
of
coming
ten
seconds
after
the
poll
request,
is
opened,
it's
one
or
two
minutes,
but
that
allows
us
to
not
hit
these
rate
limits
every
hour.
Another
was
to
just
expect
rate
limits
to
happen
and
handle
those
exceptions.
A
If
you
don't
need
to
do
any
kind
of
querying
and
you
can
get
all
the
data
take
an
action
based
on
a
web
hook,
something
that
we
I
don't
know
if
we
mentioned
we
may
have
glossed
over,
is
that
github
apps
they
come
with
the
web.
Hooks
are
really
built-in.
So
when
you
setup
your
app,
you
can
specify
particular
events
that
you
want
that
app
to
listen
to,
so
that
can
be
pushing
to
github
opening
and
pull
requests.
B
All
right,
actually,
it's
perfect
timing
that
chris
said
that,
because
one
of
the
important
parts
that
was
a
little
bit
glossed
over
as
you're
right
is
that
there
are
there's
a
kind
of
a
breakdown
in
a
github
and
you've
got
events
and
permissions.
So
specifically,
on
the
permission
side,
you've
got
repository
permissions.
These
encompass
probably
about
20
different
permissions
which
are
read/write
and,
of
course,
no
access.
B
B
You
can
sign
up
for
a
little
and
then
you
can
sign
up
for
a
lot
and
then
you
can
tweak
it
down
and
remove
it,
and
if
users
won't
care
or
know
about
it,
but
any
changes
to
permissions
and,
more
specifically,
any
additional
permissions,
not
removal,
but
additional
permissions
require
user
acceptance.
So
this
means
that
if
I
then
decide
I
need
an
organization
hook,
I
need
read/write
access
to.
Therefore
my
application
you
get
up
will
send
an
email
to
all
org,
admins
and
then
say:
hey
or
org
owners
and
say
hey.
B
This
has
changed,
you
need
to
go
review
and
it
accept
it
now.
This
is
usually
fine
for
small
team
small
companies.
It's
not
really
that
great
for
large
teams,
large
companies,
because
imagine
your
IBM
and
you
have
got
you
know.
You
know
several
hundred.
Several
thousand
people
on
the
your
account
and
then
an
email
are
sent
out
to
the
org
admin.
Are
they
gonna
know
who
changed
it?
Why
it's
changed
who's
using
it?
What
needs
to
happen
so
a
lot
of
the
time
those
emails
can
get
glossed
over
when
they
click
on
the
link.
B
What
happens
when
users
ignore
those
emails?
What
happens
if
a
new
feature
acquires
a
new
permission
and
you
don't
have
access
to
that
permission?
Yet
so
we
recommend
store
locally
within
your
own
system,
store
what
permissions
each
installation
has
it's
true
and
gracefully
degrade,
because
when
you
change
and
a
user
takes
a
long
time
to
accept
that
change,
you're,
not
gonna,
have
that
new
permission
for
a
while,
additionally
remind
remind
remind
users
put
that
in
every
UI
that
is
needed
to
you
know.
Whenever
the
user
uses
your
application,
so
they
know
to
upgrade.
B
Don't
let
them
take
months.
Have
them
take
days,
I
think
it's
the
difference
between
iOS
and
Android
iOS.
When
you
get
a
new
version,
you
get
like
most
80%
of
phones
have
that
new
version
stalled
within
like
a
week,
Android
it
takes
years.
But
that
means
a
lot
of
the
time
your
application
is
going
to
have
to
know
when
it
can
or
can't
use
a
permission
or
a
feature
or
a
new
improvement.
B
So
we're
at
time.
I
I've
heard
every
other
room,
I
think
just
finished,
so
I
think
it's
time
for
us
as
well.
To
recap:
get
up.
Eps
is
the
best
way
to
integrate
your
service
with
github
right.
We
recommend
it
it's
much
better
than
OAuth
I
love
all
the
security
but
migrations
when
you're
a
large
application
are
more
complex
than
starting
fresh
with.
You
know
the
it's
a
big
difference
between
having
1.2
million
worth
tokens
and
having
a
couple
hundred
right
and
the
only
way
that
we
can
improve,
get
up.
B
Apps
is
by
talking
to
Brent
and
getting
what
hi
Brent.
So
the
only
way
that
we
can
improve
good
up
apps
is
together.
If
you're
running
into
a
problem,
you're
running
into
an
issue
talked
github,
raise
it
on
the
forums.
If
you've
got
someone
that
you
can
speak
to
email
support,
because
the
only
way
that
we
can
make
them
change
or-
and
you
know
help
make
it
better-
is
from
them
hearing
from
us
cool
well,
thank
you
very
much
everyone
that
was
that
was
us
enjoy.