►
From YouTube: How GitHub uses Infrastructure as Code to deploy
Description
2:08 - Program Start
3:34 - Overview of IaC and important distinctions
12:13 - What makes Infrastructure as Code work?
17:34 - The core components of IaC
20:16 - Demo stack: https://github.com/jefeish/demo-days-21_IaC-in-github
22:35 - GitHub Enterprise on a Multicloud
24:37 - Hands-on Demo
27:40 - Hubot & Chatops and connecting them to Slack
30:05 - API Token handling
34:20 - Preparing the Infrastructure as Code and state files
35:43 - Running IaC
40:33 - What did we get?
43:28 - Looking at the State files
47:10 - Closing thoughts
Jürgen Efeish explains Infrastructure as Code by looking at how we at GitHub use IaC to deploy GitHub Enterprise and make it easily available in the marketplace.
For the next session in this series: https://www.linkedin.com/events/demodays-howmitreusesgithubacti6803786085974589440/
A
A
A
A
Hello,
hello,
how's.
It
going
chat.
Welcome
to
demo
days,
namaste,
hello
to
our
friends
from
azerbaijan,
hello,
hello,
git
commit
hi
everyone
nice.
I
like
I
like
good
to
see
you
all
welcome
good
morning,
good
evening,
good
afternoon,
good
night,
always
nice
to
see
everyone
from
all
over
the
world
tuning
in
to
demo
days.
B
All
right,
thanks
for
the
nice
introduction,
so
guys
yeah
today
we're
here
to
talk
about
the
second
part
of
the
infrastructure,
s
code,
I'm
gonna
start
out
with
a
little
bit
before
we
get
to
the
demo
a
little
bit
with
some
overview.
Some
topics
that
I
like
to
address
some
parts
of
infrastructure
as
code
that
are
important
to
me,
based
on
yeah
my
past
experience
in
kind
of
enterprises
where
it's
actually
applied.
B
B
Why
do
I
bring
all
that
up?
It's
because
when
you
start
building
your
infrastructure
for
a
specific
application
or
service,
you
start
out
with
just
the
basic
infrastructure
that
then
you
drift,
I
would
almost
say
into
more
and
more
the
application
configuration
code,
and
even
so
that
is
sometimes
necessary.
Try
to
separate
these
things,
try
to
kind
of
yeah
decouple
these
two
items,
because
you
can
deploy
many
times
the
same
infrastructure
for
maybe
multiple
different
applications.
B
But
if
you
bundle
these
things
together
into
the
same
infrastructure
as
code,
then
you
create
dependencies
that
in
the
long
run
yeah
they
might
hurt
you
or
might
make
it
harder
for
you
to
reuse
that
infrastructure
as
code
or
even
to
grow
it.
So
keep
that
in
mind,
but
one
last
thing
many
tools
they
have
this
where
they
say
you
know
I'm
made
for
provisioning.
But
if
you
want
to
configure
things,
you
can
do
that
too,
in
the
same
way
or
the
other
way
around
I'm
made
for
configuration.
B
B
B
So
back
in
the
days
when
you
built
something
it
took
you
a
long
time
to
build
it
so
now
you're
very,
very
attached
to
it
almost
emotionally,
because
if
it
gets
destroyed,
it
will
take
a
long
time
to
rebuild
this,
but
infrastructure
as
code
will
change
that
or
has
to
change
that
nowadays,
yes,
you
spend
some
time
building
it
as
a
code
part
or
as
a
plan,
but
from
that
point
on
it
has
to
be
able
to
be
thrown
away
right
in
a
heartbeat.
If
something
breaks,
something
is
not
right.
B
B
If
I
run
this
terraform
plan
again,
terraform
will
know
how
many
notes
are
out
there.
It
will
not
create
more
than
five.
If
one
node
got
destroyed,
it
will
add
one
to
have
the
total
number
of
five
again
ansible.
On
the
other
hand,
if
I
tell
it
to
create
five
notes,
it
will
create
five
notes
again
and
again
and
again
and
again
again,
I'm
not
trying
to
throw
any
of
these
tools
under
the
bus,
because
even
ansible
clever
programmers
program
around
that
they
make
playbooks
that
are
smart,
but
by
playing
definition.
B
So
all
that
gives
you
in
the
end
the
managed
infrastructure
yeah.
That's,
of
course,
that's.
Why
we're
here?
That's
why
we
want
is.
We
have
a
consistent
system
now
we
can
rely
on
it.
We
can
hopefully
trust
it
because
it
has
been
approved
before
it
gets
pushed
out.
All
these
things
are
now
standardized.
B
B
It
was
a
funny
statement
in
one
way
and
it's
scary
in
another
way.
It
is
true
when
you
have
infrastructure
as
code,
you
have
change
control.
You
now
have
a
control
system
that
you
deploy.
You
know
what
went
out
there
into
a
into
the
cloud
and
if
you
don't
have
that
and
things
break
you
end
up
with
change
forensics.
You
know
you
try
to
figure
out
three
o'clock
in
the
morning.
Oh
my
god.
What
went
wrong?
What
did
change
and
who
made
that
change
to
the
infrastructure
live
basically
think
about
your
production
system.
B
Yeah
putting
it
in
perspective
with
infrastructures,
code
and
devops
when
I
have
to
deal
with
infrastructure
as
code,
I'm
sometimes
in
two
different
positions,
sometimes
I'm
the
receiving
end.
The
ops
end
right
where
the
automation,
the
self-service
lets
me
benefit
from
infrastructure
as
code,
and
especially
that's
what
we
do
in
github
with
our
demolator
and
then
there's
sometimes
the
part
where
I'm
asked
to
create
that
infrastructure
right,
provide
that
initial
optimized
tuned
infrastructure
platform
for
our
service.
B
So
when
it
comes
to
that
github
has
our
platform
provides
us
with
the
branch
protection
so
that
nobody
just
pushes
in
code.
That
is
not
approved
right.
We
do
this
with
branch
protection,
like
I
just
said,
pull
requests
and
our
repositories
have
code
owners
and
we
turned
the
branch
protection
on
to
request
the
code
owners
to
approve
things.
So
from
that
perspective
we
have
a
change
control
process
in
place.
B
B
B
Look
at
the
code
and
say
you
know
what
I
found
the
block,
or
I
found
a
better
way
to
do
this
open
the
branch
submit
the
pull
request
and
the
team
that
maintains
this
is
actually
the
only
the
only
role
they
play
at
this
point
is:
is
the
approval,
so
you
extended
your
workforce
virtually.
So
I
like
that
part
when
it
comes
to
our
industrial
inner
sourcing.
B
B
These
things
you
have
to
suppress,
I
mean
it
happens.
I
know.
Sometimes,
when
you
figure
out.
Oh
my
god,
we
have
to
do
a
real,
quick,
hot
fix
here.
We
have
to
log
on
to
the
machine.
We
have
to
change
these
things,
fine,
but
they
have
to
immediately
go
back
into
your
infrastructures
code
because
it
has
to
be
in
sync
think
about
what
I
said
before
immutable.
B
I'm
jumping
on
the
same
thing
again,
like
I
said
before
the
inner
sourcing,
the
collaboration
right.
We
enable
global
collaboration.
That's
the
little
story
that
I
just
gave
you
with
some
users
now
being
able
to,
or
anybody
in
the
company
being
able
to
participate,
I
would
say
across
departments
into
other
people's
code,
which
is
very
useful,
helpful
and
what
it
helps
us
to
do
is.
I
said
it
here
right
the
reduced
importance
of
location
and
time
zones
it
in
many
cases.
You
know
I
live
in
new
york.
B
B
Next
thing
is
trust
your
infrastructures
code.
That
is
something
you
have
to
very
much
keep
in
mind.
It's
not
you
write.
It
once
apply
it
once
and
then
forget
about
it
for
the
next
two
years.
I've
seen
that
happening
and
I've
seen
people
looking
at
machines
and
saying
hey
wow.
The
uptime
is
three
years
and
there
were
two
reactions.
B
First
reaction
was
like:
oh
my
god,
two
years,
this
thing
is
really
stable,
awesome
and
the
second
reaction,
like
oh,
my
god,
three
years,
that's
scary!
Because
what
happens?
If
we
shut
these
things
down,
can
we
really
recreate
it?
I
said
before
github
has
to
be
the
source
of
truth,
and
that
is
still
my
statement,
but
you
still
have
to
exercise
that
what
you
just
committed
to
your
infrastructure
as
code
is
still
working
and
valid.
So
for
that
reason
many
companies
actually
do
this
cattle
versus
cats
scenario
and
tear
their
infrastructure
down
even
production.
B
We
have
companies
that
do
it
monthly
and
that's
kind
of
a
scary
thought
that
you're
actually
tearing
down
your
production
system
on
a
monthly
basis,
but
when
you
do
it
right
with
infrastructure
as
code,
it
becomes
much
much
less
scary,
and
I
prefer
that
you
do
it
often,
because
if
you
see
something
you
can
do
something
right.
If
there
is
a
bug-
and
you
have
your
unit
tests
and
your
qa
testing
going
on,
you
can
at
least
fix
it
fix
it
in
time.
If
you
do
it
in
a
managed
way,
that
is
fine.
B
Everybody
knows
it's
happening
at
the
end
of
the
month,
but
the
critical
part
is
you
need
your
infrastructure
as
code
the
moment
things
go
wrong.
Like
I
said
three
o'clock
in
the
morning:
your
system
crashes.
Now
you
need
infrastructure
as
code
to
recover
and
it
needs
to
work.
Nobody
wants
to
trouble
infrastructure
as
code
as
this
time.
B
The
last
thing
I
said,
follow
the
github
workflow
again
half
a
dozen
times.
I
mentioned
it
now.
For
me,
the
infrastructure
as
code
workflow,
is
literally
the
github
workflow
right
and
with
the
previous
stuff,
where
I
said
that
you
exercise
your
infrastructure
rebuilds
frequently,
you
definitely
prevent
the
drifts
that
can
occur.
They
shouldn't
occur,
but
alphabet
they
do.
You
can
prevent
these
things.
You
can
have
in
terraform's
case,
run
it
against
your
plan
and
check
that
terraform
tells
you
hey.
You
know
what
there's
five
resources
out
of
sync.
B
Now,
when
it
comes
to
the
infrastructure
as
code
in
github,
there
are
a
couple
of
parts
of
iac,
I'm
using
a
shorter
version.
Now
it
makes
it
easier
for
me
so
iac
under
the
covers.
You
have
definitely
in
the
middle.
That's
the
definition,
your
declaration
right
in
terraform,
it's
a
plan,
inansible,
it's
a
playbook.
B
You
have
your
parameters
when
the
parameters
go
into
your
declaration,
they,
together
in
the
combination
they
define
what
you're
building
out
on,
let's
say
the
cloud
and
that
results
in
a
state
the
declaration
we
store
it.
Of
course,
in
our
own
repository,
it's
no
big
deal.
Everybody
can
reuse.
That
repository
refer
to
it.
If
you
use
it
with
your
own
parameters,
then
you
can
make
it
specific.
The
same
declaration
with
different
parameters
can
either
be
used
for
standing
up,
production,
infrastructure
or
qa
or
whatever
any
infrastructure.
You
want
development
infrastructure.
B
What's
important
is
maintaining
that
state
and
managing
that
state
I
go
back
to
terraform.
Terraform
creates
state
files.
These
state
files
are
very
important
because
they
are
the
memory
for
your
for
your
terraform
tool
right
next
time
you
run
it.
Terraform
looks
at
that
state
file.
You
have
to
reference,
of
course,
that
state
call-
and
it
says,
okay
based
on
the
state
file.
This
is
the
stuff
I
stood
up
last
time
and
now
you
want
me
to
run
it
again
now,
let's
compare
what
actually
needs
to
be
updated
with
that
state
file.
B
You
get
this
item
potency
right.
It
will
look
at
the
same
stuff
it
did
before
and
it
will
address
the
same
resources.
It
will
not
create
new
ones
without
a
state
file,
it
will
always
just
create
one
state
file.
Important
thing
is
the
terraform.
It
has
sensitive
data
in
there
so
for
dummy
purposes
or
development.
B
You
can
literally
put
that
state
file
in
an
extra
repository,
make
it
private
make
sure
that
nobody
can
see
it,
and
only
your
cicd
process
can
refer
to
it,
which
yeah
it's
a
poor
man's
protection
plan.
I
would
say
in
reality
you
can
do
remote
state.
You
can
use
three
buckets
whatever
you
like.
You
have
to
look
at
what
terraform
specifically
provides
there.
B
B
We
have
in-house
something
that
we
call
the
demo
stack
and
github
professional
services
uses
infrastructure
as
code
for
standing
up
a
demo
stack.
What
does
it
really
mean?
The
demo
stack
for
us.
It's
standing
up
our
github
enterprise
server
in
multiple
configurations.
You
could
have
it
as
a
standalone
one.
You
could
have
it
as
an
hda
setup
with
multiple
instances.
B
If
you
need
to
test
something
you
need
to
simulate
the
customer's
environment,
we
just
go
into
our
infrastructure
as
code
use
that
and
pick
the
specific
plan
or
infrastructure
plan
that
we
want
to
use
and
within
roughly
like
15
minutes,
depending
on
how
busy
the
cloud
is,
we
have
a
full
infrastructure
that
we
can
log
into
that
we
can
play
around
with
and
yeah
exercise
the
way
we
like
it.
We
don't
have
to
ask
anybody
for
approval.
B
We
don't
have
to
wait
for
other
people
to
we
don't
have
to
submit
a
ticket
and
say:
oh,
can
you
do
this?
For
me,
this
is
all
self-service
so,
like
I
said,
15
minutes
we're
pretty
much
in
business
with
any
kind
of
infrastructure
that
we
need
internally
to
do
our
work
at
the
bottom.
Here
you
see
the
demo
location
that
little
link
has
a
repository
in
that
repository.
B
So
when
you
clone
that
and
follow
the
readme
instructions,
you
should
be
able
to
replicate
everything
that
I'm
going
to
show
you
in
a
bit
what
our
demo
days
now
use
as
a
demo
demo
stack
literally
it's
I
told
you
about
our
internal
stack
and
how
big
this
thing
is.
It
is
really
large
over
time
it
has
grown
and
it
does
some
really
impressive
things.
B
B
You
will
see
it
when
you
look
at
the
repository
there's
a
link
to
youbot.
We
walk
through
this
in
a
short
while
so
ubot
is
our
little
helper
and
a
while
back.
There
was
an
article
where
somebody,
I
think,
if
I
can
remember
it
correctly,
it
was
saying
the
busiest
person
in
github
is
not
a
human
being
and
that's
actually
true
ubot
is
doing
ex
extremely
high.
It's
a
lot
of
things
that
it
does
not
just
infrastructure
it's
code,
but
for
today
we
focus
on
that.
B
B
It
is
public,
but
it
has
branch
protection,
so
at
least
I
have
control
over
it
and
I
just
jumped
right
into
the
readme
file
for
a
moment.
Just
ignore
my
little
console
windows
here,
I'm
going
to
go
into
that
in
a
in
a
second,
but
I
want
to
go
over
this
little
readme,
so
we
have
our
demo
days
the
overview,
it's
the
same
stuff
that
I
just
mentioned
to
you,
these
four
components
that
we're
going
to
build
right.
The
infrastructure
is
code.
Our
declaration.
B
B
I
said
it
before
I'm
using
for
our
demo
here,
terraform,
so
just
to
verify
that
I
have
everything
I
need:
let's
go
where
there
we
go,
I'm
having
version
15..
It
complains
because
they
just
released
version,
one,
that's
a
big
milestone,
but
we
can
live
without
that.
So
looking
at
npm,
okay
typing
is
difficult.
Here
we
go,
we
got
this.
We
got.
B
B
B
B
B
B
That
is
relatively
easy.
I
give
you
a
link
here
and
here
it
is
install
a
slack
bot.
If
you
click
on
that
guy
open
that
you
will
notice
one
thing
it
takes
you
directly
to
a
page
from
slack
that
allows
you
obsession
to
add
the
spot,
to
your
slack
account.
Of
course
you
have
to
have
one
and
if
you
are
logged
in
like
I
am,
if
you
see
this
up
here
on
the
top
right,
then
it
will
allow
you
to
right
away.
B
Click,
add
it
to
slack,
and
it
will
add
this
ubot
app
to
your
slack
account
what
it
will
end
up
doing.
Is
you
see
it
down
here
in
the
app
section
you
will
have
a
little
you
bought.
This
is
the
right
connectivity
you
bought.
This
is
not
youbot
being
in
a
channel
right.
This
is
you
talking
directly
till
you
want,
because
with
that
you
are
basically
in
business.
A
B
And
see
what
else
we
have
to
do?
Oh
yeah,
most
important
thing.
The
way
it
works
is
the
moment
you
install
a
bot,
you
create
an
api
token
right.
Slack
creates
an
api
token
for
you.
You
can
regenerate
that
token
anytime,
you
like,
but
that
api
token
needs
to
be
passed
on
to
ubot.
Ebook
needs
to
know
that
you
bought
with
the
slack
adapter
and
the
token
in
combination
is
now
able
to
talk
to
your
slack
account
and
with
that
we
are
able
to
start
yeah
executing
some
smart
code.
B
B
B
Here's
my
different
plans
for
different
clouds,
underneath
you
will
see
a
little
bit
more.
We
go
in
there
in
a
bit
and
also
in
that
same
repository.
There
is
my
fully
installed
u-bot,
so
normally
you
would
have
to
go
out
there
and
install
your
ubot,
create
a
little
project,
run
ubot
configure
it.
I've
done
all
that
stuff
for
you
and
that's
what
I
just
did.
I
went
into
that
ubot
folder
and
underneath
there's
a
ubot
executable
and
I'm
running
that
you
want
executable.
B
B
B
B
B
B
I
didn't
do
the
ping
and
pong
I
just
used
the
help
and
the
help
came
back,
so
you
bought
is
active
and
running.
So
from
that
perspective,
we
are
connected
so
step.
Two
prepare
the
infrastructure's
code.
When
you
run
this
demo
on
your
own,
make
sure
that
there
is
clean
start.
I
would
say,
if
you
don't
have
anything
that
was
deployed
in
the
cloud,
make
sure
that
this
state
file,
a
state
folder,
is
empty.
B
I
mentioned
to
you
before
you
have
to
maintain
your
state
somewhere.
You
can
do
it
remotely.
You
can
do
it
locally
for
demo
purposes
or
development.
Mostly
people
run
it
and
let
it
let
it
sit
there.
Local
and
they're
on
the
machine,
not
a
big
deal.
If
you
talk
production
and
security,
you
have
to
put
it
somewhere
else
in
a
safe
place.
Right
now
we
are
putting
it
in
this
specific
folder.
We
say:
terraform,
ghjs
aws,
so
one
state
file,
a
state
folder
specific
for
aws
and
one
state
folder
specific
for
azure.
B
Under
this
state
folder,
you
will
see
that
we're
executing
things
per
user.
I
will
explain
in
a
moment
what
that
really
means
credentials.
I
use
the
basic
stuff
I
have
logged
into
an
azure
login,
so
I'm
authenticated
with
azure
azure
lets
me
go
in
and
execute
my
terraform
plan
similar
thing
with
aws.
I
have
my
credentials
on
my
system,
so
I
can
test
away.
B
B
B
B
B
B
B
B
Actually,
I
might
have
had
a
change
in
the
code
that
could
have
happened,
seems
like
it,
so
it's
destroying
something.
Unfortunately,
that
will
take
a
little
bit
longer.
What
happens?
Is
you
bought
here's?
The
details
you
want
receives
the
call
you
bought
fires
off
a
little
rapper
strip
that
handles
all
the
terraform
interaction.
Ubot
has
a
stream
connection
into
that
tarot
into
that
little
script,
so
you
are
now
can
still
interact
on
other
commands
right.
We
can
type
whatever
we
want.
B
B
It
returns
to
ubot
and
you
will
tell
you
hey
this:
is
your
infrastructure,
here's
your
ip
address
to
connect
to
it
and
you
can
just
log
into
the
system
that
is
unfortunate
that
it
had
to
make
these
changes.
I
thought
I
didn't
have
that
because
now
we
can
talk
about
you
see
40
seconds.
In
reality,
this
will
probably
take
five
to
ten
minutes,
destroys
a
whole
resource
group
and
it
will
create
that
resource
group.
B
B
B
The
key
element
for
me
is
our
product
team
or
the
developers
of
the
product.
They
can
create
spin
up
another
release
anytime.
They
want
as
soon
as
they
feel
like.
This
release
is
ready
for
ga
they
create
an
appliance
and
that
appliance
ends
up
in
the
cloud
in
the
marketplace
and
from
that
moment
on
anybody
in
our
services
team
can
connect
to
it
and
yeah
play
with
it,
download
it
do
whatever
they
want.
So
it's
a
very
how
kind
of
a
decoupled
operation
from
both
ends
right?
B
Everybody
can
work
without
having
the
other
one
being
a
bottleneck
and
we're
doing
it
like.
I
just
tried
to
show
you.
Hopefully,
it's
still
doing
its
job,
we're
doing
it
on
both
clouds
and
cloud
environments,
and
that
is
we
see
what
the
next
thing
is
on
my
list
yeah,
I
gave
a
couple
of
images
so
that
you
would
not.
B
B
B
B
We
want
to
tear
down
our
environment
when
we
are
done
in
our
real
demo
stack.
We
use
something
like
a
lifespan
tag
that
we
attach
to
every
stack
that
we're
putting
out
there
that
lifespan
tag
is
eight
hours
after
eight
hours.
We
automatically
tear
down
your
infrastructure,
again:
cats
versus
cattle
right.
You
can
always
recreate
it,
but
it
doesn't
have
to
sit
around
for
more
than
eight
hours.
If
you
do
need
more
than
eight
hours,
you
can
provide
it
as
a
parameter
and
can
tell
you
know
what
I
need
it
for
12..
B
I
need
it
for
16..
We
have
a
maximum
of
48
hours
when
you
say:
okay,
48
hours,
that
stuff
can
really
really
cost
money.
Specifically,
when
you
talk
about
hundreds
or
thousands
of
people
that
use
that
self-service.
So
that
is
why
we
have
these
grouped
per
user.
You
can
then
tear
down
something
for
yourself
and
only
you
can
tear
your
own
stuff
down.
Nobody
can
go
in
there
and
say
hey.
I
want
to
tear
down
stuff
for
your.
It's
not
going
to
happen.
B
You
own
it
you're
safe,
but
we
also
the
last
kind
of
statement
here.
Is
I
brought
it
up
before
the
immutable
and
potent
we
now
have
that
with
that
kind
of
statement
and
management
like
I
said
we
can
destroy
it,
we
can
rebuild
it
any
time
we
want.
We
force
an
eight
hour,
destroy
on
you,
which
is
just
for,
I
would
say,
resource
consumption
reasons
right
and
we
can
have
multiple
instances
running
for
multiple
people.
B
But
when
you
run
your
stack
again
like
you
saw
actually
it's
a
good
example.
What
had
happened
on
azure?
I
ran
the
same
command
again,
but
I'm
not
sure
if
the
previous
version
was
different.
Maybe
it
wasn't
3.1.0,
maybe
it
was
3.0.1
and
with
that
in
mind,
it
has
to
tear
everything
down,
but
it
doesn't
create
a
secondary
stack.
It
just
updates
the
stack
that
is
owned
by
you
whoa.
I
was
a
lot
of
talking
on
my
end.
B
B
I
have
to
say
the
longer
you
use
this,
the
less
you
become
aware
of
actually
what
you
do,
meaning
it
becomes
a
very
convenient
tool
and
after
a
while,
we
don't
even
ask
ourselves
anymore.
What's
going
on
behind
the
scenes,
you
see
it
takes
like
10-15
minutes
to
build
this
and
all
these
components
are
involved,
but
the
user
yeah
since
we're
using
it
with
slack.
You
can
operate
it
from
anywhere.
B
B
See
what
happened
you
told
me,
hey
here's,
a
response
from
your
terraform
run
right.
I
have
a
couple
of
output
information
here
pieces
here.
You
see,
I
have
an
output
of
a
private
key
that
I
generated
for
our
resources
here
and,
as
you
can
see
there,
it
says
sensitive,
which
is
good
when
you
refer
to
terraform
and
tell
terror
form,
please,
output,
certain
information,
terraform
knows
what
is
sensitive
information
and
it
will
redact
it,
but
it
is
still
in
plain
text
in
your
state
file
right.
This
is
not
a
binary
version
or
anything
encoded.
B
It
is
there
in
plain
text.
So
therefore,
like
I
said
before
security
reason,
wise,
please
protect
your
state
from
make
sure
it's
in
a
safe
space.
Same
thing
goes
for
slack
ubot
is
you
can
look
at
it
as
another
user
in
your
in
your
slack
channel
right
and
instead
of
talking
to
bob
now
you're
addressing
ubot?
And
you
say
you
bought.
Please
do
something
for
me
and
you
bought
with
the
slack
adapter
and
our
ubot
code
might
have
access
to
resources
github
as
an
example
right
or
any
other
third-party
tool.
B
So
you
have
to
keep
that
in
mind
when
you
tell
you
about
to
do
something
and
you
what
has
the
permission
you,
what
will
go
out
there
and
do
it
so
you
have
to
limit
that
access.
You
have
to
make
sure
that
you
wasn't
on
the
right
channels.
We
do
that
we
have
checks
and
balances
in
our
ubot.
That
actually
says
you
know
you
want
to
see
a
private
key.
You
can't
do
it
or
not
in
this
channel.
You
have
to
go
somewhere
else,
so
we
have
these
things,
but
keep
that
in
mind
security.
B
A
B
It's
in
terms
of
security
I
mentioned
before,
but
just
to
remind
people.
That's
why
I
kept
saying
this
is
open
source
right.
There
is
nothing
hidden
if
you
have
security
teams
in
your
company
there
and
you
want
to
use
ubot,
you
want
to
use
these
slack
adapters.
It
is
in
many
ways.
Yes,
it's
hard
to
convince
people
hey!
I
want
to
use
this.
Can
you
approve
this?