►
From YouTube: GitHub Integrations - GitHub Universe 2016
Description
We have added a new way of building on top of GitHub: Integrations.
This session, hosted by Keavy McMinn, Engineer at GitHub, will take a look at how and why we took a fresh look at how third party services extend GitHub. We'll look at some common use cases for extending GitHub, and how they could be approached differently with the new Integrations.
Whether you've built OAuth applications, or are curious about how to, this session will help you get started building a new Integration. You'll learn about how to handle permissions, authentication and connecting the dots between GitHub and your service.
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
Imagine
you
run
a
company
that
wants
to
connect
your
web
service
to
get
hub,
so
you've
written
a
new
off
application.
Your
app
lists,
who's,
open
PRS
sounds
simple
right
to
access
the
endpoint
to
read
the
PR
data.
Your
OAuth
up
needs
repo
scope
and
repo
scope
gives
both
read
and
write
permissions
to
everything
within
a
repo
on
all
your
repositories
and
your
personal
account
and
any
organizations
that
you
have
access
to
kind
of
scary
right.
A
A
A
A
Imagine
you
work
in
a
company
that
uses
a
CI
service.
All
your
PRS
automatically
have
these
checks
run.
Everyone
in
the
company
happily
uses
this.
Everyone
knows
when
it's
safe
to
merge,
PRS
and
then
one
day,
that's
your
CI
service
suddenly
stops
working.
The
company
and
the
CI
integrator
have
to
communicate
to
figure
out
what
just
happened.
What
went
wrong
and
it
turns
like
that,
the
guy
who
installed
the
service
just
left
the
company.
So
when
his
credentials
are
expunged,
the
CI
service
stops
working
as
well.
A
A
The
flu
for
a
user
to
set
up
a
new
service
meant
they
had
to
initiate
that
process
on
the
integrator
site.
The
install
flow,
as
you
just
saw,
was
really
inefficient.
The
API
flows
for
fragrant
night,
what
a
user
had
access
to
you
could
get
very
chatty
and
because
the
new
orthop
is
authorized
by
and
uses
a
specific
users
credentials,
there's
no
direct
connection
between
an
organization
and
a
service.
A
There's
other
problems
as
well
like
permissions
on
around
multiple
kinds,
is
a
hard
problem
to
solve.
Most
SAS
providers
use
multiple
accounts,
for
example
in
Google
life.
My
personal
account
and
my
work.
It
kind
and
the
to
your
separate
on
github
I
have
one
a
kind
and
that's
a
hard
problem
to
deal
with
fairly
uniquely
for
us.
A
We
want
to
have
a
way
for
a
user
to
install
an
integration
in
whatever
repositories
they
want,
whether
that's
on
a
personal
or
an
organization,
a
kind
so
that
single,
a
kind,
the
whole
flow
of
installing
a
service,
the
lack
of
a
connection
between
an
organization
and
the
service.
We
maybe
could
have
fixed
some
of
these
as
isolated
problems,
but
we
knew
they
were
related.
A
So
we
took
a
step
back
and
ask
ourselves
if
we
were
building
this
thing
from
scratch,
knowing
what
we
knew
now,
what
would
we
do
differently
and
we
think
we've
got
that
now
with
integrations
they're
launching
as
a
early
access
and
shipped
today,
so
we
really
over
hold
this
whole
area
and
came
up
with
something
new.
This
is
a
new
and
additional
way
to
build
on
top
of
github.
So
let
me
show
you
a
bit
about
what
that
looks
like.
A
A
As
an
integrator
I
can
choose
whether
my
integration
is
available
publicly
for
everyone
to
install
or
limited
to
be
only
installed
and
within
repositories
in
my
organization,
and
you
can
start
with
a
peon
only
repositories
in
my
organization.
Obviously,
as
you
develop
an
integration
and
later
release
it
publicly.
A
A
A
But
then
we
we
made
these
granular
permissions
for
integrations,
which
introduced
a
whole
new
permission
system.
An
integration
needs
explicit
permission
on
each
resource
that
they
interact
with,
so
they
can
have
permission
to
read
code
in
a
repository
or
just
to
write
issues
within
a
repository,
and
they
don't
get
access
to
anything
that
they
don't
explicitly
have
that
permission
on
and
these
separate
ways
of
grant
and
permission
need
to
live
side
by
side.
A
So
the
old
way
of
check
checking
permissions
for
an
API
endpoint
that
say
rights
commit
service,
looks
something
like
this.
We
simply
need
to
check
if
the
user
can
write
to
the
repository
and
implicitly
everything
within
that
in
early
spikes,
we
did
multiple
checks
for
these
two
permission.
Systems
which
worked
for
a
while,
but
you
can
imagine,
would
get
very
messy
if
we
had
to
do
that
in
every
spot
within
the
API,
where
permissions
are
checked.
A
So
we
refine
that
to
a
cleaner
interface
and
this
physically
involved
adding
an
adapter
layer
in
the
middle
so
that
we
could
have
a
consistent
interviews
to
check
access,
whether
that
was
for
a
traditional
user
or
in
the
integration.
And
this
let
us
reduce
the
number
of
places.
We
check
the
various
possible
permissions
to
one
lower
level
location
which
makes
maintenance
and
security
a
whole
lot
easier.
A
The
second
big,
thorny
area
was
a
flow
for
identity
checks
for
the
end
user.
When
a
user
clicks
a
link
on
github
like
a
status
field,
we
want
them
to
see
the
bill
details
on
the
integrator
site
and
we
want
that
to
just
work
that
the
user
can
click
on
a
link
and
be
in
the
right
place
being
shown.
The
right
information
we
don't
want
an
interstitial
page,
might
accept
and
more
award
scopes.
A
We
were
driven
by
wanting
a
smooth
user
experience.
We
wanted
users
to
be
able
to
safely
install
and
use
the
best
development
tools
within
github
and
for
both
the
end
user
and
the
integrator.
We
wanted
a
smooth
authorization
flow
that
makes
using
these
third-party
services
within
github
a
smooth
and
experience,
as
is
securely
possible.
A
So
we
looked
at
a
few
possible
solutions
for
this
identity
flu
and
we
didn't
look
at
who
earth
and
confession.
This
is
what
we
did
in
the
early
development
cycles
when
we
were
trying
to
convert
internal
or
fabrications
to
integrations,
and
these
apps
already
had
an
OAuth
flow
and
place.
So
we
just
use
that,
and
while
this
might
seem
like
a
perfectly
reasonable
solution
in
the
short
term
and
the
longer
term,
it
would
be
terrible
for
several
reasons.
A
For
starters,
the
maintenance
headaches
of
managing
a
separate
orthop
and
for
identity
alongside
and
integration
for
doing
the
work
would
be
huge.
The
additional
authorization
flues
for
the
orthop
could
be
really
scary
if
an
org
admin
has
already
installed
this
integration,
that
I
interact
with
and
I
just
click
a
link
to
find
out
about
a
build
failure.
What
am
I
even
authorizing
also,
then
we're
back
to
dealing
with
OAuth
scopes,
which
just
don't
map
to
the
new
granular
permissions
or
a
/
repo
level
access.
A
After
several
spikes,
we
engineered
an
OAuth
like
solution
where
the
integrator
can
exchange
a
single
yeast
nonce
for
the
identity
of
the
current
github
user,
and
they
can
verify
that
they
are
like
that.
That
user
is
allowed
to
view
the
information
on
the
requested
installation
details
for
it
like
details
about
this
flow
are
available
in
the
developer.
Docs
that-
and
we
just
launched
today.
A
A
My
team
has
enjoyed
good
cooperative
relationships,
early
feedback,
an
ongoing
support
from
people
in
an
outside
of
engineering
from
product
design,
security,
business
development
and
support.
We've
really
valued
that
and
the
depth
and
quality
of
the
solutions
of
our
whole
work
has
been
really
ear
it
enriched
from
having
that
and
wide
and
diverse
support
network.
A
A
A
A
The
developer,
who
wants
to
install
an
integration
with
in
github
on
a
specific
repo,
an
integrator
had
to
do
this
complicated
back
and
forth
and
end
up
with
access
to
every
repo
that
she
has
access
to
nie.
The
flow
is
a
lot
more
efficient.
These
are
starts
to
flow
and
github
com
and
just
clicks
install
done.
A
A
A
A
A
We're
really
excited
to
share
this
feature
with
you
in
this
early
access
stage.
We'd
love
you
to
start
playing
with
this.
You
can
find
the
docks
at
developer,
Doggett
up
calm
and
have
a
have
a
look
around
that
explore
see
what
would
work
but
wouldn't
work
for
your
use.
Kiss
we'd
love
your
feedback
and
you
can
come
talk
to
us
I
at
this
new
forum,
at
platform
to
github,
community
and
we'd
love
to
hear
what
you
try
and
build
and
what
problems
you
come
across.