►
Description
Adopting GitHub Actions at scale in the enterprise (Part 2 / 2)
For the full series: https://youtube.com/playlist?list=PL0lo9MOBetEEk9gIFox8EbCf1Co_4ppIO
0:00 - Start
2:11 - Intros and recap of the series
5:16 - Reference Architecture
8:01 - DNS name and domain setup
10:13 - Configuring the cert manager
15:19 - Deploying the cluster issuer
25:10 - Configuring the GitHub App (Oauth Apps vs GitHub Apps)
32:36 - Installing the GitHub App
42:42 - Installing the Actions on the controller
54:23 - Creating a deployment, and horizontally scaling
1:05:30 - Additional resources
Demo repo: https://github.com/link-/actions-at-scale-ghoh
Contact Us: https://resources.github.com/devops-learning-journey/
A
A
B
One
such
problem
is
adopting
actions
or
github
actions
at
scale
within
your
organizations.
This
series
of
offers
hours
is
split
into
four
episodes
or
four
events
that
are
going
to
be
released
on
a
weekly
basis
and
during
these
events
or
episodes
we're
going
to
be
tackling
the
following
questions:
how
can
I
deploy
and
auto-scale
self-hosted
runners?
B
Can
I
use
kubernetes
to
deploy
self-hosted
runners?
How
can
I
manage
access
to
these
runners?
Can
I
create
custom
images
for
for
my
runners
and
how
can
I
create
my
own
scaling
solution
for
self-hosted
runners?
There's
gonna
be
so
much
more
content
beyond
these
questions,
but
these
are
just
to
highlight
the
highlights
of
the
different
episodes.
Today
we
are
running
episode.
Two
episode
one
aired
last
week.
If
you
did
not
get
the
chance
to
catch
it,
you
can
still
view
it
on
the
github
youtube
channel.
B
In
today's
episode,
we're
gonna
be
continuing
where
we
left
off
in
episode
one
next
week,
episode
three
is
gonna:
go
live
where
we're
gonna
be
customizing,
our
self-hosted
runners
and
in
episode,
four
we're
gonna,
be
creating
our
own
custom
solution
for
scaling
our
infrastructure
to
discuss
a
little
bit.
What's
gonna
happen
today,
we're
gonna
be
configuring,
our
search
manager
for
tls
termination.
I
promise
you
that
we're
gonna
do
that
in
episode
one,
but
we
did
not
get
the
chance
or
the
time
to
do
so.
So
we're
gonna
do
this.
B
First
then,
we're
gonna
be
creating
our
github
app
and
I'm
to
show
you
what
a
github
app
is
and
how
you
can
use
it
for
dispatching
web
hooks
and
for
authenticating,
so
that
you
can
use
our
rest
for
graphql
apis
we're
going
to
need
the
apis
to
register
our
self-hosted
runners,
then
we're
going
to
install
and
configure
action
runner
controller,
which
is
the
kubernetes
controller,
we're
going
to
be
using.
That
will
have
the
logic
for
adding
and
removing
self-hosted
runners
based
on
the
web
book
events.
B
And,
finally,
I'm
going
to
give
you
a
quick
demo
of
how
auto
scaling
works
and
I'm
going
to
show
you
how
this
whole
setup
works
all
together.
We
have
not
seen
that
yet.
Lastly,
we're
going
to
do
a
live
q,
a
I'm
going
to
go
back
on
stage
and
I'm
going
to
be
answering
your
questions
live.
So
please
make
sure
you
drop
these
questions
in
the
comments
right
now.
I
will
try
my
best
to
answer
them
async
and
then,
towards
the
end
of
the
episode
I
will
be
answering
them
live.
B
If
you
have
more
details
to
inquire
about
again,
these
sessions
will
be
available
on
demand
later
on
on
youtube
on
the
github
channel.
So
just
sit
back,
relax,
don't
worry
about
notes,
I'm
gonna
be
making
all
the
commands
and
instructions
available
for
you,
so
that
you
can
implement
these
at
your
own
time,
explore
them
and
even
deploy
them
in
production
at
a
later
stage,
as
usual,
we're
going
to
be
starting
with
the
reference
architecture.
This
is
the
starting
point
of
everything.
It's
very
important
for
you
to
understand.
B
What's
going
to
happen
and
have
a
a
big
picture,
you
know
have
a
perspective
of
the
whole
setup
end-to-end.
So
let
us
do
this
before
we
go
back
to
the
terminal
and
continue
with
the
setup.
Last
week
we
we
we
talked
about
the
enterprise.
On
the
github
side,
we
talked
that
this
solution
works
well
for
github.com
and
github
enterprise
server.
We
talked
about
the
organization
and
the
repository
structure.
There's
not
really
much
going
on
here.
We
just
simply,
I
simply
narrated.
B
What
would
how
you
would
most
commonly
use
github
and
we
discussed
the
need
for
github
apps
for
both
web
hook.
Registration
and
authentication
purposes,
we
talked
about
the
api
in
the
web,
hooks
layer
and
we
discussed
also
what's
going
to
be
happening
in
the
asia
region,
and
what
are
the
services
that
we're
going
to
be
deploying
to
it
reiterate
very
quickly?
We
had
a
resource
group
called
github
actions
runner
in
this
resource
group.
B
We
are
basically
deploying
everything
we
will
be
having
two
v-nets
which
we
created
and
we
created
appearing
in
between
these
v-nets
so
that
they
are
able
to
so
that
the
resources
within
them
are
able
to
communicate.
We
have
created
the
application
gateway
which
we
are
going
to
be
using
as
our
english
controller.
We
have
initialized
or
created
our
aks
cluster.
B
We
had
the
default
namespace.
We
deployed
a
very
simple
application
to
our
default
namespace,
so
just
so
that
we
can
test
our
controller
that
is
working
properly.
We
deployed
a
public
ip
address
which
we
assigned
to
the
application
gateway.
We
created
a
container
registry
which
we
attached
to
our
kubernetes
cluster
and,
of
course,
I
mentioned
the
node
resource
group,
which
is
the
associated
or
the
attached
resource
group
that
gets
automatically
created
whenever
you
spin
up
an
aks
cluster.
B
What
would
we
be
using
it
for
and
how
we
can
configure
it
and
how
we
can
use
it
for
authentication
purposes
and
we're
going
to
be
talking
about
the
setup
of
the
actions
runner
controller
on
our
cluster
and
how
we
can
configure
it
so
that
it
can
listen
to
webhook
events
and
respond
to
them
by
spinning
up
or
shutting
down
self-hosted
runners
also
part
of
episode,
one
which
we
did
not
have
time
to
tackle,
was
the
setup
and
installation
of
cert
manager
for
dls
termination
purposes.
We're
gonna
start
with
this
in
this
episode.
B
Now
that
you
have
a
good
idea
of
what's
going
to
happen,
let
us
begin,
let's
first
jump
to
our
microsoft,
azure
portal
and
in
this
portal
the
first
thing
we're
going
to
do
is
we're
going
to
provide
a
dns
name
for
our
public
ip
address.
This
is
necessary
before
we
proceed
with
the
next
steps,
because
we
cannot
generate
tls
certificates
without
having
a
domain
name
right.
We
cannot
generate
one
for
an
ip
address.
B
B
I
don't
have
a
custom
domain
that
I'm
going
to
be
using,
so
I'm
going
to
be
just
relying
on
the
subdomain
that
can
be
provided
by
azure
by
default,
and
if
you
click
on
configuration
over
here,
you
can
see
that
you
can
assign
a
dns
label
which
is
optional.
That's
fine
to
your
ip
address
and
I'm
going
to
do
that
right
now
and
I'm
going
to
call
this
one
github
actions
at
scale.
Let's
say
office
hours,
it
has
to
be
unique.
B
B
And
if
I
press
enter,
of
course
it's
not
https,
it
should
be
http.
I
should
be
getting
this
page
over
here
right,
because
our
application
is
still
there.
It's
still
being
served
by
our
english
controller,
which
is
our
application
gateway,
and
the
change
should
be
reflected
right
away.
It
doesn't
take
a
lot
of
time
for
the
dns
entry
to
be
propagated,
so
you
should
be
seeing
it
almost
instantaneously.
B
Now
let
us
close
this
window
and
proceed
to
configuring,
our
cert
manager,
and
in
order
for
us
to
do
so,
we
need
to
go
back
to
our
terminal.
Again.
I
am
inside
my
docker
container
and,
as
I
mentioned
in
the
first
episode,
I
wanted
to
use
a
docker
container,
because
I
wanted
to
use
ubuntu
as
a
distribution
to
make
things
more
or
less
standardized
and
not
having
to
worry
about.
You
know
operating
system,
compatibility
and
whatnot.
B
B
So
the
variables
are
as
follows:
the
first
first
one
is
setting
up
the
acr
url
or
fetching
the
acr
url,
and
we
use
this
command
over
here,
using
the
azure
cli
as
usual
to
fetch
the
login
server
or
the
dns
entry
for
our
container
registry,
and
once
we
do
that,
we
store
it
in
this
variable
called
acr
url,
and
we
also
echo
it
here
just
for
validation
purposes,
so
our
acr
url
is
github
actions,
oh
or
office
hours
acr.
That
cr
perfect
next
step
is
having
the
registry
name
stored
in
a
variable.
B
Next,
we
are
going
to
specify
the
cert
manager
information.
Why
do
we
need
this
information?
Because
I
want
to
import
these
images
of
cert
manager
into
my
container
registry?
I
don't
want
to
use
the
quay.io
public
registry
to
fetch
these
images,
why?
It's
always
a
good
practice,
because
normally,
when
you
want
to
do
this,
you
would
scan
these
images
for
vulnerabilities
or
for
issues
before
utilizing
them
in
a
production
environment
right.
So
you
can
enable
these
on
acr
and
you
can
scan
the
images
that
you
import.
We're
not
going
to
do
the
scan
today.
B
I'm
just
sharing
with
you
a
best
practice,
so
also
you
might
want
to
keep
these
images
in
case
they
get
pulled
out
from
the
public
registry.
This
makes
sure
that
your
future
deployments
are
consistent
and
they
are
not
prone
to
problems
if
these
images
disappear
from
you
know,
the
public
registries,
so
first
thing
is
defining
the
quay.io
registry.
B
Next
is
specifying
which
version
of
search
manager
we're
going
to
be
using
and
we're
going
to
be
using
version
1.6.1.
This
is
the
latest
version.
Next
we're
going
to
be
specifying
the
image
name
as
well
as
the
image
webhook
name,
sorry
as
as
well
as
the
webhook
image
name
and
the
ca
injector
image
as
well.
So
these
are
three
images
that
we're
gonna
be
using.
B
Basically,
azure
cli
will
just
pull
these
images
and
store
them
in
our
container
registry
for
us,
and
we're
going
to
do
this
three
times
over
and
in
a
sequence,
so
the
and
towards
the
end
of
each
command
will
basically
not
launch
the
next
command
until
the
first
one
has
succeeded.
If
the
first
one
fails,
the
chain
will
fail
as
well,
and
this
will
allow
us
to
troubleshoot
and
not
have
to
do
a
lot
of
cleanup
if
these
commands
fail.
For
whatever
reason
perfect,
the
images
have
been
imported
into
our
container
registry
without
any
issues.
B
The
next
step,
we're
going
to
do
is
we're
going
to
be
installing
a
cert
manager
using
helm.
However,
first
we
need
to
create
the
namespace
where
we're
gonna
be
installing
search
insert
manager
in
and
we
can
do
that
with
cube,
color
create
namespace
search
manager
and
then
we
need
to
label
this
namespace
with
disable
validation.
And,
lastly,
we
need
to
add
the
repo
to
helm.
B
Once
that
is
done,
I
am
going
to
run
the
installation
and
again
all
of
these
environment
variables
have
been
set
or
defined
in
the
first
step
we
did
in
our
terminal
right,
you
can
also
revisit
them,
replace
them
manage
them.
Whichever
way
you'd,
like
I
think,
environment
variables
make
it
a
little
bit
easier
because
they
can
come
in
a
block,
you
can
edit
them
all
at
once
and
you
just
simply
do
the
installation.
B
Now
the
assert
manager
installation
has
happened
successfully.
We
can
verify
this
by
running
cube
cattle,
get
pods,
dash
and
meaning
namespace
cert
manager,
and
we
can
see
here
that
we
have
the
three
pods
and
their
containers
up
and
running,
which
is
good
news,
because
that
means
that
our
installation
has
been
successful.
B
Next,
we
need
to
deploy
the
cluster
issuer.
The
cluster
issuer
is
responsible
for
doing
the
challenge,
checks
as
well
as
making
sure
that
the
domain
belongs
to
you
and
injecting
the
certificate
into
the
appropriate
containers
so
that
we
can
properly
use
them.
I'm
gonna
show
you
a
little
bit
how
or
what
this
configuration
is
made
of,
and
it
is
available
insert
manager,
cluster
issuer
prod,
yaml,
and
you
can
see
here.
This
is
a
simple
configuration.
B
So,
first
of
all,
the
kind
is
cluster
issuer.
Next
we're
going
to
be
providing
a
name,
we're
going
to
call
it
test
encrypt
and
we're
going
to
be
using,
let's
encrypt
for
issuing
the
certificates.
In
this
case
it's
just
easy
to
use
and
quite
convenient,
and
these
certificates
are
very
well
known
and
they
are
safe
to
use.
So
if
you
have
your
own
certificates,
you
can
definitely
take
a
different
approach
to
this.
You
can
store
them
in
vault
and
you
can
use
cert
manager
to
fetch
these
certificates
from
azure
vault.
B
Otherwise,
let's
enclip
is
a
definitely
easy
to
use
and
viable
option.
What
matters
is
that
you
don't
use
your
own
certificate
authorities,
because
these
are
not
accepted
by
you
know
by
github.
So
whenever
we
push
the
web
hooks
towards
you,
these
certificates
will
not
be
recognized
and
you
might
have
some
problems
with
tls
verification
when
we
push
these
webhooks
to
your
server.
B
The
root
ca
there
and
running
a
one
of
the
command
line,
scripts
that
we
already
make
available
for
you
over
there
to
install
the
root,
ca
or
ca
bundles
inside
your
server,
and
then
the
services
will
be
rebooted
so
that
they
recognize
the
new
ca
and
whenever
a
web
hook
is
issued
towards
your
kubernetes
cluster.
In
this
case,
you
will
not
have
tls
verification
problems.
So
let
us
proceed
with
let's
encrypt
next,
we
need
to
specify
which
server
we
are
using,
for
you
know
the
generation
of
the
certificates
and
the
challenges.
B
If
you
don't
know
what
these
solvers
are
they're,
basically
ways
for
search
manager
to
or
for
the
script,
to
verify
sorry
for
insert
manager
to
verify
that
you
actually
own
the
domain
before
generating
a
certificate
for
and-
and
you
know,
verifying
that
the
way
that
can
be
done
is
via
http
or
dns.
Or
there
are
many
multiple
other
mechanisms
you
can
go
to.
The
search
manager
configuration
to
check
out
what
these
are
for.
B
B
We
created
an
english
controller,
called
ingress
main,
it's
very
important
for
you
to
specify
the
name
of
the
english
controller
that
cert
manager
can
use
for
these
purposes
and
what
cert
manager
is
going
to
do
is
whenever
you
want
a
certificate,
it's
going
to
create
a
new
ingress
rule,
and
this
english
rule
will
point
to
a
service
that
cert
manager
is
gonna
use
to
host
a
challenge.
Key
and
search
manager
is
gonna
use.
B
This
challenge
key
to
verify
that
you
actually
own
the
domain,
and
then
the
issuance
of
the
certificates
will
happen
quite
smoothly.
So
let
us
deploy
this
configuration
and
we
can
do
that
very
easily.
With
cube,
color
apply,
dash,
f,
and
then
we
provide
the
file
name,
cert
manager,
cluster
issuer
frog.yaml,
and
then
it
doesn't
really
matter
which
namespace
you
deploy
this
in.
It's
going
to
be
this.
B
This
search
manager
can
function
across
namespaces,
so
we're
gonna,
deploy
it
right
now
and
next
we
need
to,
of
course,
update
our
english
controller
now
with
what
with
the
tls
routes
right.
So
we
can
do
this
with
I'm
going
to
show
you
first
what
we're
updating
it
for,
so
we
can
undo
cat
ingress
and
then
the
name
of
the
new
configuration
english
tls.com
and
the
change
that
we
are
applying
is
basically
the
following.
We
are
specifying
the
host
right,
I'm
going
to
update
this,
because
I
think
I
changed
the
the
hostname.
B
As
our
english
controller,
the
name
of
our
controller
is
called
english
main,
and
then
we
are
saying
that
for
tls
termination
and
generation
you
need
to
use
let's
encrypt
dash
prod,
which
is
the
name
of
the
issuer
right,
but
the
issuer
we
just
created-
and
here
we
are
saying
that
we
want
to
redirect
all
requests
coming
in
from
http
to
https.
The
next
step
is
again,
as
I
mentioned,
specifying
the
host
and
the
secret
name.
This
could
be
anything
it
doesn't
really
matter.
This
is
whenever
a
secret
is
generated
that
contains
a
certificate.
B
This
is
basically
the
prefix
that
is
given
to
that
name
so
that
you
can
recognize
it.
It's
good
to
have
a
name
that
maybe
matches
your
domain
just
so
that
you
can
easily
recognize
it
in
case
you
need
to
next.
We
are
going
to
specify
the
host
to
also
be
the
domain
that
we
specify
over
here
and
then
we're
going
to
keep
everything
else
to
be
the
same.
B
B
B
And
now,
if
we
run
kubeco
get
ingress
one
more
time,
we
should
see
the
appropriate
host
and
the
correct
ip
address,
and
you
should
now
see
the
port
443
added
to
your
configuration.
Next
we
can
say
cube
cattle
describe
ingress,
ingress
dash
main,
and
we
should
get
more
information
about.
What's
going
on
here,
you
can
see
that
search
manager
has
created
a
path
right,
which
is
the
challenge
for
our
tls
configuration,
and
we
also
have
the
regular
path
for
our
test
app
already
available
for
us
to
use.
B
Now.
You
can
also
see
here
that
we
have
successfully
created
the
certificate
pls
ingress
and
now,
if
we
navigate
to
this
endpoint
or
url.
Let's
do
that
in
a
new
browser
and
in
this
case
it's
through
https
this
time.
Right,
if
I
do
that,
I
should
be
getting
this
message
over
here,
which
means
that
our
configuration
is
successful.
Let
us,
let
me
show
you
that
the
certificate
is
is
appropriate.
B
We
can
also
see
the
certificate
over
here
and
we
can
see
that
the
issue
is
let's
encrypt
and
we
see
we
see
here
that
the
certificate
verification
has
is
okay,
so
our
configuration
is
proper,
and
here
we
have
the
ls
termination
done
properly
on
our
application
gateway
from
this.
We
can
now
proceed
to
installing
or
configuring
our
github
app
and
we
need
the
github
app
before
we
install
the
actions
runner
controller,
because
we're
going
to
need
some
of
the
secrets
created
with
the
github
app
in
our
actions.
B
Runner
controller
configuration,
so
I'm
gonna
switch
to
my
browser
one
more
time
and
we're
gonna
go
to
inner
sanctum,
which
is
an
organization
that
I
have
set
up
in
my
enterprise
account
it's
very
normal.
This
is
what
your
organization
page
should
look
like.
There's
nothing
really
out
of
the
ordinary
here:
we're
going
to
click
on
settings,
we're
going
to
scroll
down
to
the
developer
settings
tab,
and
then
we
are
going
to
scroll
down
also
to
github
apps.
B
There
are
different
ways
where
you
can
integrate
or
authenticate
with
github
to
use
the
apis.
You
can
create
oauth
apps
with
if,
if
your
purpose
is
to
impersonate
other
users
on
github.com
or
github
enterprise
server,
so
if
you
want
to
do
actions
on
behalf
of
the
user,
oauth
apps
are
the
way
to
go.
If
you
need
like
sort
of
an
independent
identity
that
is
not
associated
with
users,
that
is
able
to
do
actions
on
the
apis
on
the
organizations
on
the
repos
as
github
apps,
you
know
it's
like
an
independent
from
user
accounts.
B
This
is
the
way
to
go
so
for,
for
example,
server
to
server
integrations.
They
should
be
done
with
github
apps,
as
opposed
to,
if
you
build
an
app
to,
for
example,
update
the
avatar
of
the
user.
This
is
an
action
on
behalf
of
the
user.
You
would
go
for
an
oauth
app
and
we
are
building
the
oauth
app
to
be
owned
by
the
organization,
because
there's
also
another
approach,
you
can
build
the
github
app
using
a
user's
account,
but
that
makes
it
problematic
for
you
to
install
the
application
on
the
organization.
B
If
you
create
the
app
on
the
organization
level,
it
should
be
easy
to
install
it.
You
don't
have
to
make
it
public
and
you
have
to
you,
can
make
it
restricted
just
for
this
organization,
and
this
is
my
recommendation.
So
if
you
are
basically
going
to
do
this
for
multiple
organizations,
you
need
to
create
a
github
app
per
organization
or
you
can
create
a
github
app
on
one
account
and
then
install
it
on
multiple
organizations.
That
is
also
another
option
or
another
route
to
go
for
now.
B
B
B
This
is
whenever
you
want
to
make
your
app
public,
it's
basically
when
you,
the
page
or
the
url,
that
the
users
can
read
more
about
what
your
app
does,
but
because
we're
not
publishing
this
app
to
the
marketplace
or
anywhere
we're
not
going
to
make
it
public.
So
it
doesn't
really
matter
what
you
have
here,
I'm
just
gonna
add
the
page
or
the
url
for
my
organization.
B
B
We're
not
going
to
use
this
feature
right
now
we're
going
to
skip
this
post
installation
setup
url
also
going
to
skip
this
because
we're
not
going
to
authenticate
to
the
app
via
an
oauth
path.
I'm
going
to
show
you
a
little
bit,
I'm
going
to
show
you
how
we
can
use
this
app
for
authentication
in
a
bit
now
the
webhook
url.
This
is
very
important.
B
The
webhook
url
is
basically
the
url
that
is
going
to
be
receiving
the
webhook
events,
which
in
this
case,
is
going
to
be
the
webhook
server
that
is
installed
by
runner
controller
in
our
cluster,
but
because
this
webhook
server
is
not
currently
set
up
and
we
don't
have
a
path
that
we
can
enter
here.
We're
going
to
skip
this
for
the
moment,
we're
going
to
configure
the
privileges,
the
accesses
so
on
and
so
forth,
and
then
we're
gonna
come
back
to
this
to
configure
the
webhook
url.
B
So
again,
just
remember
this
is
the
where
we
configure
the
server.
That's
gonna
receive
our
webhook
events.
We're
gonna
skip
it
for
now,
and
next
we're
gonna
start
providing
permissions.
So
for
actions,
I'm
going
to
give
it
a
read-only
permission
for
contents,
I'm
going
to
give
it
a
read-only
permission
and
for
method
data.
It's
going
to
be
read
only
by
default.
That's
good,
then,
for
self-hosted
runners.
B
B
So
these
are
the
only
permissions
required,
and
we
can
say
here
only
on
this
account,
because
we're
only
going
to
use
this
app
on
this
organization.
If
we
want
to
use
this
app
for
other
users
or
other
organizations,
you
can
specify
any
account,
but
for
now
we're
going
to
create
it
with
these
settings
only
and
as
you
can
see
here,
the
setup
is
successful.
B
Now
we
need
to
note
a
few
things.
So,
first
of
all,
we
need
to
keep
track
of
the
app
id.
This
is
very
important
for
authentication
purposes,
so
I'm
going
to
copy
that
and
put
it
on
the
side,
and
then
I
am
going
to
generate
a
private
key,
because
using
this
private
key,
I'm
gonna
be
able
to
authenticate
and
get
what
we
call
an
access
token,
an
installation
access
token.
This
access
token
will
allow
me
to
do
actions
up
to
the
scope
that
we
just
defined
right,
like,
for
example,
registering
self-hosted
runners.
B
We
selected
the
scope
and
in
the
previous
page,
so
up
to
that
scope
on
the
organization,
so
I'm
gonna
click
on
generate
private
key,
and
you
can
see
here
in
my
browser,
a
private
key
was
downloaded
onto
my
machine,
and
this
is
the
signature
of
the
private
key.
So
basically,
the
public
key,
which
is
the
second
half
of
it
will
be,
will
remain
with
github,
and
I'm
going
to
be
using
my
private
key
to
authenticate
and
receive
generate
an
installation
access
token.
B
That
will
allow
me
to
call
the
apis
and
basically
do
stuff
we're
not
done
yet
because
we
just
generated
the
app.
We
did
not
install
it
right.
So
again,
I
want
you
this
might
be
confusing
for,
for,
if
you
have
not
done
so
before,
but
just
think
about
it.
In
this
way
you
create
a
github
app
that
is
owned
by
someone
it
could
be
a
user
or
an
organization.
B
So
a
github
app
can
be
owned
by
a
user,
a
regular
user,
a
regular
account
like
mine
or
an
organization
and
ownership
of
the
app
does
not
mean
automatic
setup
on
this
account
or
organization
right
there's,
a
next
step,
which
is
to
install
the
app
on
a
given
organization.
It
could
be
that
the
owning
organization
installs
it
on
itself,
but
it
could
be
that
that's
not
the
case
that
you
install
the
app
on
another
organization
that
you
created
in
one
organization,
but
you
install
it
on
another
organization
right.
B
This
is
think
about
it
again
from
a
marketplace
perspective
from
making
apps
public
and
not
necessarily
just
restricted
to
your
own
small
environment.
So
now
we
need
to
install
the
app
I'm
going
to
click
on
the
install
tab
and,
as
you
can
see
here
already,
it's
asking
me
whether
I
want
to
install
it
on
inner
sanctum,
I'm
going
to
click
on
install,
and
it's
going
to
redirect
me
to
this
page,
where
I
am
going
to
approve
or
authorize
this
app
for
the
following
scope.
B
So
it's
going
to
be
able
to
read,
have
read
access
to
actions
the
code
in
my
repositories
and
metadata
be
careful
because
we
gave
it
access
to
the
code.
That
means
it's
going
to
be
able
this
app
and
whoever
has
the
private
key
for
this
app
is
going
to
be
able
to
read
the
repositories,
even
if
there
are
private
repositories,
because
now
you
have
read
access
to
everything
inside
the
organization
right
and
then
we
have
read
and
write
on
the
self-hosted
runners
so
also
be
careful
because
the
there's
a
malicious
actor.
B
They
can
basically
now
register
self-hosted
runners
on
your
on
your
organization
and
of
course
you
don't
want
that,
because
then
you
can
sniff
secrets
and
do
a
lot
of
very
nasty
stuff
point
being
now.
We
have
installed
the
app
that
is
called
self-hosted
runners
scaler
on
the
inner
sanctum
organization.
You
can
see
it
over
here
and
now
we
are
ready
for
the
next
step
and
for
the
next
step
you
have
to
be
a
little
bit
patient
with
me,
because
I
need
to
introduce
a
small
tool
here
that
will
help
us
in
our
work.
B
So
we
have
generated.
We
have
created
the
github
app.
We
have
installed
the
github
app
on
our
organization.
We
have
copied
the
app
id
right.
I
show
you
we're
going
to
copy
this
because
we're
going
to
need
it,
so
we
have
copied
the
app
id
somewhere
else
and
we
have
generated
a
private
key
now
we're
going
to
be
using
the
app
id
as
well
as
the
private
key
we
generated
in
order
for
us
to
touch
the
installation
id.
This
is
very
important.
What
is
the
installation
id
the
installation?
B
Id
is
basically
because
a
github
app
can
be
installed
on
multiple
organizations
right.
We
need
an
identifier
for
where
we
installed
the
github
app.
This
is
also
very
important
and
critical
to
the
authentication
process
in
order
for
us
to
generate
the
access
key
so
for
us
to
generate
the
access
key,
we're
going
to
be
needing
the
app
id,
the
private
key
and
the
installation
identifier,
and
using
those
we
will
be
able
to
authenticate
to
github
and
execute
actions
using
the
apis.
B
B
Otherwise,
I
have
created
a
very
handy,
github,
cli
extension,
that
is
basically
a
credentials
helper
in
some
sort,
which
is
called
gh
token,
and
you
can
install
it
as
an
extension
to
to
github
cli,
and
you
can
use
this
to
do
multiple
things.
So,
for
example,
you
can
use
it
to
fetch
to
generate
an
access
key
using
the
using
the
private
key
we
generated
as
well
as
the
app
id
and
the
installation
id.
B
You
can
also
use
it
to
fetch
the
list
of
installations
for
a
given
application
and
one
more
thing
you
can
also
do
with
this
helper
or
this
extension
is
to
revoke
a
generated
access
token.
So
if
you
generate
an
access
token
that
you
use
for
whatever
purpose,
you
can
also
revoke
it,
we're
not
going
to
need
the
revoke
command,
we're
not
going
to
need
the
generate
command,
because
the
kubernetes
controller
is
going
to
be
doing
this.
B
B
It
also
requires
bash
version,
five
point,
whatever
five
point
x
and
above
it
requires
jq,
and
it
requires
sha
sum
you
need
to
install
these
prerequisites
as
well
as
the
github
cli
before
you
can
proceed
with
this
now
very
quickly.
I'm
gonna
install
the
github
cli,
you
can
go
to
cli.github.com
and
then
you
can
go
to
view
installation
instructions.
If
you
have
conda,
if
you
have
any
of
the
package
managers,
it's
very
easy.
B
I
don't
have
any
of
them
in
my
container,
so
I'm
just
gonna
jump
to
the
release
page
and
I'm
gonna,
probably
I'm
gonna
just
download
the
binaries
for
the
latest
release,
which
is
cli
2.4
in
this
case,
and
I'm
gonna
scroll
down
all
right
copy,
the
url
and
then
we're
going
to
go
here,
we're
going
to
say,
wget.
Sorry,
I
don't
have
wget
installed,
let's
try,
curl
dash,
l,
ghcli
z,
and
then
we
specify
the
url.
B
This
should
allow
us
to
download
the
utility
and
there
we
have
it
it's
great
and
then
we're
going
to
extract
it.
Xpf
ghcli
and
there
we
go.
Then
we
can
go
inside
this
directory
and
inside
the
bin
folder,
where
we
have
the
executable
and
we
can
run
gh
just
for
verification
purposes,
perfect,
and
then
we
can
move
to
our
user
bin,
of
course,
with
the
sudo.
B
B
Gh2
and
now
we
have
ghcli
installed
perfect
next
thing
we
need
to
do
is
to
install
our
credentials
helper,
and
we
can
do
that
with
let's
go
here.
You
can
see
it's
in
my
profile.
It's
the
repository
name
is
called
gh
dash
token
and
the
installation
instructions.
I've
already
added
them
over
here.
So
the
setup
is
quite
simple:
you
just
copy
this.
B
If
you
want
to
install
it
as
a
github
cli
or
you
can
also
use
it
as
standalone,
but
I
just
wanted
to
show
you
how
you
can
use
the
github
cli,
because
I
think
it's
very
handy
and
I
might
need
it
down
the
line.
So
I'm
gonna
run
this
and,
oh
sorry,
I
need
to
authenticate
first.
So
let's
do
that
gh
off
log
in
and
github.com
yes
logged
in
with
the
web
browser,
and
let's
do
this
authentication
very
quickly.
B
All
right
we
are
now
authenticated
next
is
to
install
the
extension
one
more
time
perfect.
Now
the
extension
is
installed.
All
we
need
to
do
is
to
run
our
commands
all
right.
Let's
run
the
gh
token
version
command
to
check
that
the
installation
has
been
correct
and
we
see
the
correct
version
over
here.
That's
great
next
step.
We
need
to
install
also
one
more
dependency
for
this
token
to
work,
which
is
a
jwt
helper
binary,
and
we
can
do
this
by
going
to
this
repository
over
here
mike
angle,
jwtcli.
B
This
is
a
very
nice
jwt,
helper
utility
and
I'm
gonna
install.
I
I'm
gonna
install
it
very
quickly
on
my
machine.
You
can
do
that
by
going
to
releases
and
by
the
way
release
number
five
version.
Number
five
is
not
supported
yet
so
you
need
to
get
version
number
four
and
just
like
we
did
last
time.
We
just
need
to
copy
the
url
for
the
linux
version,
linux
compatible
version
and
we're
gonna
download
it
girl
dash
l
dash
o,
and
we
specify
the
file
name
jwtcar.gz
and
we
provide
url.
B
B
I
162
110
dash
k
here
we
need
to
provide
the
path
for
the
key
route
to
work,
the
ir
self-hosted
runners,
that's
great,
and
then
we
can
run
this.
You
should
see
an
output
like
this
and
this
basically
will
give
us
an
array
of
all
of
the
installations
of
the
github
app.
The
first
item
is
the
one
we
need,
because
this
is
the
organization
where
the
installation
has
happened
on,
and
we
just
need
to
copy
this
installation
id
number.
B
I'm
gonna
put
it
next
to
my
app
id
because
I'm
going
to
need
both
of
them
and
if
you
want
to
try
things
out
also
and
generate
an
access
token,
you
can
freely
do
so
and
easily
do
so
with
the
extension,
you
can
do
it
as
such
gh
token
generate
and
then
dash.
I
one
more
time
the
application
id
number
and
then
dash
k.
We
provide
the
path
to
the
key
and
then
also
the
installation
id
with
dash
l
and
let
me
copy
it.
B
This
is
a
big
number,
let's
put
it
here
and
when
I
click
enter,
I
should
see
a
access
token
generated.
Don't
worry,
I'm
going
to
revoke
it
right
now.
So
with
this
access
token,
you
can
pretty
much
pass
it
to
your
as
a
header
parameter,
and
then
you
can.
You
can
use
this
for
authentication
and
call
any
rest
api
on
your
organization,
of
course,
within
the
scope
that
is
defined.
B
B
That's
all
we
need
for
us
to
move
forward,
so
we
have
the
github
app
installed.
We
have
the
installation
id
now.
We
need
to
install
the
actions
runner
controller
before
we
do
that.
Let
us
go
to
the
repository
of
the
project
and
let
us
have
a
quick
look
around
again.
As
I
mentioned,
the
actions.
Runner
controller
is
a
kubernetes
controller.
It
is
built
by
the
community,
specifically
by
this
this
guy.
Over
here
amazing
amazing
work
by
mushroom
on
this
and,
of
course,
with
all
the
112
contributors
to
this
project.
B
B
The
documentation
is
pretty
extensive.
It's
not
always
clear!
You
don't
have
really.
You
know,
step-by-step
instructions,
so
there
are
some
pitfalls.
That's
why
we
are
making
this
video
today
to
discuss
all
of
these
things.
So
without
reading
all
of
this,
these
documentation,
I'm
going
to
show
you
right
now
exactly
what
you
need
to
do.
The
installation
work,
let's
jump
back
to
the
terminal
and
let
us
first
of
all
add
the
repository
at
the
chart
or
the
helm
repo
for
the
actions,
runner
controller-
and
you
can
do
this
with
helm.
B
Repo
ad,
then
actions,
runner
controller
and
then
provide
this
url
over
here,
and
it's
going
to
say
that
it's
been
added
to
my
list
of
repositories.
That's
great,
then
we're
going
to
do
a
helm,
repo
update,
fantastic.
There
we
go
and
then
we
are
going
to
do
the
installation.
However,
before
we
do
the
installation,
we
need
to
revise
and
update
our
values.yaml
file,
why?
This
is
the
the
file
that
contains
the
parameters
or
the
parameter
values
for
our
helm
track.
B
So
you
can
find
a
sample
values.yaml
file
inside
the
folder
actions,
runner
controller,
and
I'm
going
to
show
that
to
you
right
now.
Actually,
I'm
going
to
open
it
for
editing
so
now
we're
gonna
jump
to
the
parts
that
are
important
and
relevant,
and
the
first
part
is
the
authentication
secret,
so
we're
gonna
specify
that
we're
gonna
allow
the
action
runner
controller,
to
create
a
secret
on
our
behalf,
and
the
next
thing
we're
going
to
do
is
we're
going
to
update
these
values
over
here.
B
B
21870103
and
this
part
is
for
the
private
key.
The
private
key
is
basically
coming
from
for
the
content
of
the
private
key
come
from
the
file.
We
downloaded
and
I'm
gonna
paste
the
private
key
over
here.
Just
give
me
a
second:
let
me
copy
it
and
yeah.
I
should
not
be
exposing
this
private
key,
but
that's
okay,
because
I'm
going
to
delete
all
of
this
stuff
later
anyway,
I'm
gonna
go
here
and
I'm
gonna
delete
this
stuff,
and
then
I
am
going
to
paste
the
private
key.
B
B
B
I'm
going
to
show
you
that
in
a
little
bit-
and
then
one
thing
you
need
to
update
here
is
the
service
type.
You
need
to
change
that
to
cluster
ip.
We
change
it
because
we're
gonna
need
to
point
towards
this
service
from
our
english
controller
and
then
the
metrics
you
can
pretty
much
configure
them
to
whatever
you
want
the
resources
here.
You
can
specify
the
limits
in
my
opinion,
you
should
not
specify
those.
Let's
leave
it
to
the
teams
to
define
their
own
requirements.
B
B
Also,
the
service,
I'm
gonna
make
it
cluster
ip
and
english.
You
can
just
keep
it
disabled.
We
don't
want
there.
This
controller's
ingress
configuration
we're
gonna,
add
hours,
I'm
gonna
show
you
I'm
gonna
we're
gonna
do
that
in
a
bit
and
that's
it.
Basically,
you
can
just
if
you
want
to
just
try
things
out
just
copy
this
file,
as
it
is
make
sure
you
edit
the
section
where
you
add
the
github
app
private
key
app
id
and
installation
id,
and
you
should
pretty
much
be
good
to
go
from
here.
B
I
don't
want
to
create
another
namespace
for
this,
so
I'm
going
to
do
that
right
now,
with
helm,
upgrade
dash,
dash,
install
and
then
we're
going
to
specify
the
values.yaml
file
we're
going
to
specify
the
namespace.
We
don't
need
the
create
namespace
because
obviously
it's
already
there
and
we're
going
to
wait
for
the
installation
to
happen.
B
So,
let's
run
this
and
now,
with
the
controller
deployed,
we
can
have
a
quick
look
with
cube,
cuddle,
get
pods
dash
n
default
and
we
should
be
able
to
see
the
action
runner
controller
as
well
as
the
web
hook
server
both
of
them
running
just
fine.
That
is
great
to
see.
The
next
thing
we're
going
to
do
is
we're
going
to
update
our
english
controller
so
that
we
expose
the
webhook
server
to
the
internet
so
that
we
can
reconfigure
our
github
app
to
push
the
webhook
events
towards
our
actionrunnercontroller
github
webhook
server.
B
B
Ingress,
tls
runners.yamo,
as
you
can
see
here,
nothing
has
changed.
So
we
are
updating
our
ingress
main
controller
right.
Nothing
on
the
annotations
has
changed
the
hosts.
I
need
to
update
them
now
because,
as
you
remember,
we
provided
another
name
for
this.
So
let
me
we're
gonna
update
this
before
we
forget
it.
Nothing
has
changed
on
the
rules
side.
We
are
still
pointing
towards
our
test
app.
We
just
added
a
new
path
which
is
called
forward,
slash
runners,
scaler,
and
then
we
are
pointing
this
path
towards
the
service
actions.
B
Runner
controller
github,
hook
server.
This
service
is
already
created
when
you
installed
the
actions,
runner
controller,
so
there's
nothing
much.
We
can
you
need
to
do
here.
You
can
have
a
quick
look
at
it
with
cube,
cuddle,
get
service
and
then
provide
the
namespace,
and
you
can
have
a
look
here
that
the
service
is
deployed,
the
cluster
ip
is
provided
and
it
is
running
on
port
80,
which
is
looking
fantastic.
B
Now.
Let
us
update
quickly
the
english
configuration
file
and
let
us
apply
it
once
we
are
done
so.
The
update
here
is
just
to
add,
oh
at
the
end
of
this,
because
that's
what
our
dns
entry
is
and
now
we
can
do
cube,
cuddle,
apply,
dash,
f,
ingress
and
then
english
tls
dash
runners,
ammo,
and
if
we
do
cube,
cuddle,
describe
sorry
ingress
and
then
ingress
dash
main.
B
We
should
be
able
to
see
the
runners
scaler
deployed
successfully
and
let
us
do
a
quick
test,
so
curl
dash
g
on
this
path,
of
course,
with
https
we
should
be
getting
this,
that's
fantastic
and
then,
if
we
add
the
path
runners
scaler,
we
should
be
get
this
message
over
here
that
the
webhook
server
is
running.
This
is
a
fantastic
validation
that
our
configuration
is
correct,
and
now
that
we
have
this
url
configured,
we
need
to
go
towards.
B
Basically,
you
do
you
get
there
with
by
going
to
the
organization
settings
page
and
then
this
time,
instead
of
going
to
the
developer
tools,
you
go
to
the
installed
github
apps
and
then
you
go
to
the
self-hosted
runner,
scaler
and
then
configure
you
click
on
app
settings
over
here
and
then
you
go
to
words
in
the
general
tab.
You
go
to
the
web
hook
and
this
is
where
you
click
it
to
be
active
and
my
recommendation
is
to
keep
ssl
verification
enabled
now
webhook
secret.
This
is
very
important.
It's
it's.
B
The
only
way
that
we
can
do
authentication
is
that
github
when
it
pushes
a
web
book
event
right
can
authenticate
your
webhook
server.
We
have
not
configured
a
webhook
secret
because
we
did
not
have
one
when
we
created
this
app
right
and
we
have
one
that
is
in
the
default
values.yaml
file
which
we're
gonna
add
over
here.
So
let
me
go
to
my
file.
Please
modify
it
before
you
deploy
the
values
that
you
ml
file.
This
is
my
mistake.
B
I
should
have
told
you
about
it
before
we
com
moved
on
with
this,
so
this
secret
is
available
over
here
in
this
section.
So
if
you
look
at
the
github
book
server,
you
will
see
the
secret.
So
this
is
the
secret
that
is
created
in
the
kubernetes
cluster,
but
this
is
the
github
web
hook
secret
secret
for
the
for
the
for
the
github
app,
and
I
have
it
here
specified
as
some
very
random
secret.
B
This
means
that
our
actions-
runner
controller,
is
configured.
We
only
need
to
now
create
a
deployment,
as
well
as
the
horizontal
runners
scalar
resource
on
our
kubernetes
cluster,
for
us
to
be
able
to
start
scaling
our
resources.
How
do
you
do
this?
I'm
gonna
go
back
to
my
terminal
one
more
time
and
I
have
provided
you
with
a
sample
deployment
file.
This
sample
deployment
file
is
also
available
in
our
actions.
Runner
controller.
It's
called
autoscale
underscore
webhook.yaml.
B
If
we
go
into
here,
you
will
see
the
crd
for
the
actions
runner
controller.
We
have
a
custom
resource
called
runner
deployment.
We
have
another
custom
resource
called
horizontal
runner,
auto
scaler,
and
this
is
just
a
regular
deployment,
but
it's
you
know
a
deployment
specific
with
certain
parameters
for
the
actions
runner
controller.
Here
we
are
giving
some
metadata.
B
So,
first
of
all,
we
are
naming
this
deployment,
I'm
going
to
call
it
azure
runners,
you
can
call
it
whatever
you'd
like
and
I'm
specifying
that
namespace
where
this
deployment
is
going
to
reside
in
and
I'm
going
to
put
it
in
the
default
namespace.
Next,
you
specify
the
number
of
replicas
you
want
to
have
for
this
deployment.
This
number
this
value
here
is
irrelevant
because
we
already
have
the
horizontal
runner,
auto
scaler.
This
replicas
here
doesn't
really
do
anything.
Next,
we
are
going
to
specify
inside
the
template
the
organization
where
we
want
to
these.
B
We
want
these
runners
to
be
registered
in
and,
of
course,
the
organization
name
is
inner
sanctum.
The
next
thing
is,
we
are
specifying
the
labels
we
want
to
give
these
runners
right.
Our
self-hosted
runners
can
have
one
or
multiple
labels,
and
in
order
for
us
to
address
these
runners
for
us
to
use
these
runners,
we
need
to
reference
them
using
labels.
So
here
I'm
just
giving
them.
B
You
know
that
doesn't
exist
in
other
runners,
so
this
is
how
you
can
categorize
your
runners
to
different
needs,
and
then
we
are
providing
the
environment
variable
here,
which
is
the
runner
feature
flag,
ephemeral.
This
is
very
important.
This
environment
variable
instructs
the
self-hosted
runner
image
to
configure
itself
as
an
ephemeral
runner,
which
means
it
will
only
run
once
and
then
it
will
destroy
itself.
B
This
is
perfect
because
that's
from
a
security
standpoint,
exactly
what
we
need,
we
need
these
runners
to
execute
their
job
once
and
then
completely
destroy
themselves,
so
that
each
job
is
run
in
a
fresh,
clean
runner.
This
will
prevent
pollution.
This
will
prevent
people
sniffing
secrets.
This
will
prevent
secret
leaking
and
so
many
other
security
problems.
B
Next
in
the
same
file,
we
are
also
deploying
another
custom
resource,
which
is
the
horizontal
runner,
auto
scaler.
This
is
necessary.
This
is
the
resource.
That's
going
to
make
the
decision
about
how
to
scale
up
and
down
the
runners
and
we're
gonna
do
this
by
just
giving
it
a
name
whatever
name
that
works
well
for
you
and
then
the
target
ref
is
basically
the
deployment
right.
You
just
need
to
give
it
the
name
of
the
deployment
we
specified
over
here
and
then
this
is
where
you
specify
the
size
of
your
scale
set
right.
B
The
minimum
number
is
zero.
The
maximum
number
I
want
to
have
is
five,
because
my
node
or
the
node
that
I
have
supplied
this
cluster
with-
I
only
have
one
cannot
probably
handle
more
than
this,
but
if
you
add
more
nodes,
this
autoscaler
will
or
basically
kubernetes
will
spread
your
self-hosted
runner
across
the
nodes
that
you
register
with
your
cluster
and
then
scale
up
trigger
is
the
github
event.
You
can
keep
it
empty
over
here.
This
will
basically
listen
for
the
workflow
job
webhook
event,
and
it
will.
B
Basically,
respond
to
that
by
adding
more
resources,
and
then
the
duration
here
is
basically
for
how
long
you
want
your
runners
to
live
after
they
complete
their
job,
we're
going
to
say
it's
five
minutes
before
they
get
destroyed.
This
should
be
a
good
starting
point.
One
more
thing
we
did
not
do
before
we
can
jump
to
a
quick
demo,
which
is
to
configure
the
webhook
events
right.
So
we
installed
the
app
we
configured
it.
B
We
configured
the
webhook
url,
but
we
did
not,
which
we
did
not
specify,
which
webhook
events
we
want
to
send
to
our
controller
or
to
our
webhook
server
right.
So
we're
going
to
do
that
one
more
time
by
jumping
into
the
browser
and
then
we're
going
to
go
to
permissions
and
events
and
we're
going
to
scroll
to
the
bottom
of
this
page
to
the
subscribe
to
events-
and
we
are
just
gonna
subscribe
to
one
event,
which
is
the
workflow
job
and
workflow
dispatch.
B
Nothing
else
needs
to
be
done
over
here.
We
can
jump
to
the
advanced
section
to
monitor
the
delivery.
Let's
jump
over
here
and
let
us
deploy
the
autoscale
webhook
configuration
file
and
we
can
do
that
with
obviously
kubernetes
cubecattleapply.f,
and
then
we
provide
the
configuration
file
and
then
the
default
namespace.
B
Once
we
do
this,
if
we
do
cubecarl
getpods,
you
should
be
able
to
see
here
that
we
have
a
azure
runners
right.
This
is
the
registration
runner.
It's
currently
still
configuring.
So
let
me
show
you
how
this
auto
scaler
works.
First
thing
we're
going
to
do
is
we're
going
to
do
a
watch,
n
2
and
we're
going
to
specify
cube
color
get
pods
dash
n
default.
This
will
allow
us
to
see
what
is
happening.
I'm
going
to
put
this
over
here
on
this
side,
and
then
I
am
going
to
bring
in
my
browser.
B
We
can
have
them
side
by
side.
I
want
to
show
you
what's
going
on
now,
I'm
going
to
jump
to
inner
sanctum
the
organization
I'm
going
to
go
to
my
to
the
list
of
repositories.
I
already
have
a
depository
for
testing,
so
I'm
going
to
click
on
it.
I
have
a
couple
of
workflows
in
this
repository.
The
workflows
are
a
single
job,
multi-job
or
matrix
jobs,
with
very,
very
simple
workflows.
They
are
triggered
by.
You,
know,
workflow
dispatch.
B
B
You
see
them
right
here,
so
three
runners
were
created
right
now,
because
we
have
three
jobs
that
need
to
be
fulfilled
in
this
workflow
and
once
these
runners
are
up
and
registered,
they
will
be
assigned
or
the
jobs
will
be
dispatched
for
them.
Of
course,
the
jobs
will
not
run
in
any
specific
order,
because
jobs
run
in
parallel
and
that's
how
they
are
designed
designed
to
run.
B
And,
yes,
you
can
see
here
already
jobs
are
being
fulfilled,
so
job
one
has
been
completed,
and
one
thing
to
note
is
that,
once
the
containers
are
completed
with
their
work,
they
start
terminating.
This
is
the
whole
point
of
ephemeral,
runners
right
and
now
that
the
three
jobs
have
been
completed
successfully.
B
The
containers
or
the
pods
have
been
destroyed
and
they
are,
they
have
been
recreated.
Why?
Because
now
they
have
to
wait
for
the
five
minute
mark
before
they
get
completely
removed
or
eliminated
as
resources
right.
You
can
specify
the
duration
to
be
lower,
and
that
means
also
that
your
runners
will
be
de-provisioned
at
a
much
faster
rate
than
than
five
minutes.
Let's
see
this
one
more
time,
but
this
time
with
matrix
workflows,
so
the
matrix
jobs
are
the
ones
where
let
me
go
to
the
workforce
and
show
you
the
matrix.
B
Jobs
are
the
ones
where
you
have
one
job,
but
you
are
adopting
a
matrix
strategy
whereby
you
can
have
multiple
versions
of
node
or
some
language
where
you
want
to
test
different
versions,
for
example
right
or
different
opera.
You
want
to
test
on
different
operating
systems.
You
might
want
to
leverage
the
matrix
strategy,
and
here
I
am
going
to
do
a
test
with
seven
matrix
values
right,
but
we
already
specified
that
we
can
scale
up
to
five
max.
So
this
is
a
scenario
that's
important
for
you
to
be
aware
of.
B
We
will
only
we
are
only
gonna
provision
up
to
five
right
and
then
we're
gonna
queue.
The
remaining
jobs
until
one
of
the
five
runners
that
have
been
that
are
working,
completes
its
work
and
then
it
goes
back
to
the
queue
to
pick
up.
Another
drop
so
we're
gonna
click
on
this
and
we're
gonna
run
the
workflow
and
we're
gonna
see
what's
gonna
happen
over
here.
B
As
you
can
see,
five
runners
now
are
trying
to
do
work.
You
can
see
them
over
here.
So
that's
the
total
number
we're
not
gonna
have
more
than
five.
You
can
see
that
we
have
zero
of
seven
jobs
is
completing.
Obviously
this
number
is
gonna
be
going
up
bit
by
bit
until
the
seven
jobs
have
been
completely
fulfilled,
we're
going
to
give
it
some
time.
B
You
need
to
be
aware
also
that,
even
though
it
says
here
running
that
doesn't
mean
that
the
runner
has
been
registered
yet
right,
so
the
container
is
spun
up
and
then
it
needs
to
register
with
github
by
making
an
api
call.
That's
why
it?
You
might
see
a
little
bit
of
delay
between
running
and
the
jobs
being
fulfilled
right,
so
you
can
see
here.
Five
out
of
seven
jobs
have
been
completed,
and
now
we're
going
to
wait
for
a
couple
of
runners
to
complete
the
two
remaining
ones.
B
So
you
can
see
here
now
two
more
runners
have
been
created
right
from
the
five
of
course
have
been
recreated
so
that
they
can
fulfill
the
remaining
two
jobs
after
the
first
five
have
been
completely
exhausted.
Right.
You
will
see
here
that
these
jobs
might
take
a
little
bit
will
take
a
little
bit
more
time
to
be
completed.
B
Obviously
you
can
scale
up
more
than
five.
You
can
put
in
any
number
that
your
nodes
can
handle,
but
for
now
my
node
is
quite
small,
so
this
is
the
maximum
number
I
have
configured
and
with
this
we
conclude
our
demo
for
the
actions,
runner
controller
and
that's
a
wrap.
That's
all
I
had
for
you
in
this
episode.
I
know
that's
really
dense
in
terms
of
information.
B
Configuration
lots
to
absorb
lots
to
think
about,
keep
in
mind
that
if
you
want
a
demo
for
all
of
this,
we
at
the
expert
services
are
available
to
support
you
with
your
github
actions
journey,
especially
if
you
are
you
know,
dealing
with
github
enterprise
server
or
any
other
environments
that
are
less
liberal.
Let's
say
than
the
environments
that
the
demo
I
just
I
just
gave.
B
Thank
you
very
much
everyone
for
watching
so
far,
I
see
a
lot
of
familiar
names
in
the
chat
coming
in
from
episode,
one
I'm
so
happy
to
see
this.
Thank
you
very
much
for
your
dedication
and
I
hope
the
content
was
up
to
your.
You
know
liking
and
satisfaction.
I
hope
you're
getting
something
out
of
this,
and
I
I
see
here
that
you,
someone
is
you're
gonna
all
right.
That's
awesome!
You're
gonna!
Try
this
during
the
weekend.
That's
fantastic!
B
Please
do
and
please
reach
out
to
us
if
you
need
some
help
with
this
and
the
repository
over
there
that
we
just
shared
with
you,
where
we
have
all
of
the
instructions
feel
free
to
create
issues.
If
you
have
questions
you
can
do
so
over
there.
I
already
see
facundo,
who
has
created
a
couple
of
awesome
suggestions
and
a
couple
of
awesome.
You
know
enhancements
to
the
instructions.
Thank
you
very
much
for
that,
and
thank
you
very
much
for
supporting
this
this.
B
This
effort,
the
qr
code-
oh
actually
it's
over
here,
so
you
think
your
code
at
the
in
this
section
of
the
screen
will
allow
you
to
schedule
a
session
with
us.
If
you
feel
that
this
is
necessary,
if
you
have
some
specific
edge
cases
or
specific
scenarios
that
you'd
like
us
to
be
involved
with,
give
you
some
consultation,
some
feedback
answer
some
more
specific
questions
regarding
your
environment,
or
maybe
even
you
don't
have
a
full-blown
service
engagement
where
we
can
do
more
advanced
stuff.
B
This
is
the
this
is
the
way
to
go,
and
this
is
the
way
to
reach
us.
Definitely,
I'm
gonna
take
in
questions.
If
you
have
any.
I
already
saw
a
question
from
simon
whether
we
can
deploy
multiple
action,
runner
controllers
and
different
namespaces.
Yes,
this
is
definitely
gonna,
be
the
big
part
of
our
conversation
next
week.
The
third
episode
is
gonna.
Be
really
awesome,
because
now,
after
this
basic
setup
is
done
now
we
can
talk
about.
B
B
Endpoint,
you
know
from
from
different
types
of
attacks
and
from
ddosing,
and
also
all
of
that,
that
type
of
stuff,
because
we're
exposing
that
endpoint
to
the
internet,
we're
gonna
be
talking
about
the
benefit
of
setting
up
multiple
action,
running
control
in
different
name
spaces,
for
isolation
purposes
and
so
on
and
so
forth.
Obviously,
there
are
many
many
best,
I'm
not
going
to
call
them
best
practices,
because
this
is
everything
here
is
still
in
the
very
early
stages.
We
are
still
learning
as
we
go.
B
We
are
still
learning
as
we
deploy
this
in
different
environments
with
different
customers
at
different
scales.
So
obviously
this
the
recommendations
are
going
to
evolve
and
we
would
love
your
feedback
if
you
have
any
also,
and
if
you
discover
certain
scenarios
where
you
need
some
answers
for
you
need
our
support
with,
we
would
love
to
help
on
these
fronts.
B
Thank
you
very
much
for
the
feedback
that
we
received
on
the
first
session.
It
has
been
brilliant.
Please
do
make
sure
that
you
provide
us
with
your
feedback
for
this
episode
as
well.
I
would
love
to
hear
from
you
and
if
there
are
any
enhancements
we
could
do
for
future
episodes.
We
would
love
to
know
about
them
so
that
we
can
make
sure
that
we
always
create
content.
That
is,
you
know
up
to
your
standards
or
up
to
your
liking.
B
B
I
don't
see
any
new
questions
in
the
chat.
I'm
gonna
assume
that
you
probably
don't
have
any.
I
hope
you
enjoyed
this
episode
and
I'm
really
looking
forward
to
chatting
with
you
next
week
feel
free
to
hit
me
up
on
the
social
media
accounts
on
linkedin
or
anything
like
that.
If
you
have
any,
you
know
questions,
I
will
also
redirect
you
to
the
appropriate
people
within
github
to
support
you
with
those.
B
You
can
also
talk
to
your
account
managers
solution
engineers
about
you,
know
this,
the
specific
topic,
and
we
can
definitely
facilitate
and
support
you
with
any
work
that
you
are
currently
doing.
Thank
you
very
much
everyone
for
watching.
I
want
to
wish
you
a
great
rest
of
the
day
and
a
great
weekend,
and
I
will
see
you
next
friday.