►
Description
Presented by Guðmundur Ólafsson, Software Engineer (GitHub)
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
hey,
my
name
is
Khan
Mandir.
You
can
find
me
on
all
those
social
medias
on
the
red,
sandal
I'm
here
gonna
talked
about
using
github
actions,
I'm
a
software
engineer
on
the
team.
That's
been
building
actions
and
that
we've
been
working
on
this
for
quite
a
few
months
now,
so
the
tank
is
gonna,
be
split
into
two
different
parts.
It's
the
using
actions,
part
which
is
how
you
as
a
customer,
use
it
and
then
secondly,
I'm
gonna
go
into
how
to
build
action.
A
So
if
you
want
to
contribute
to
the
community
of
actions,
then
I'll
get
into
that
to
showcase
some
of
this
stuff.
I'm
gonna
start
with
some
simple
demos.
The
first
one
is
starting
from
this
like
pretty
empty
repository
where
I'm
gonna
show
how,
if
you
push
the
commit
to
this
repository,
it
is
just
gonna,
say
hello,
so
it's
going
to
show
it
and
it
logs
behind
the
actions.
A
A
There
is
the
workflow
and
we
can
call
that
say
hello
on
push,
which
is
what
we
the
end
state
that
we
want
to
get
to,
and
then
we
can
drag
this
blue
dot
down
here
and
it'll
put
an
action
onto
the
canvas,
so
the
one
I'm
gonna
use
is
a
for
shell.
So
it's
basically
just
running
shell
commands
and
we
can
name
that
echo
hello
and
then
a
special
thing,
which
is
a
get
up
actor,
which
is
whoever
is
pushing
the
code
to
this
repository.
A
A
So
now
that
we
push
this,
we
just
want
to
go
ahead
and
create
a
pull
request
for
it,
and
you
can
see
now
that
it's
been
cute
and
then
in
a
tiny
bed,
it's
gonna
say
in
progress
which
means
that
it's
running
and
then
boom
there
you
go.
It's
run
the
thing
now
and
if
you
click
the
check
mark
there
we'll
see
the
logs
for
the
action
and
we'll
see
that
it
says
hello,
good,
lender
down
there.
So
this
action
here
is
in
this
file
here.
So
this
is
where
you
configure
actions.
A
This
is
where
you
put
your
workflows
and
actions
for
get
up
actions,
so
the
one
I
just
showed
you.
This
is
the
config
file
for
it.
So
it's
not
just
the
UI
that
you
can
use
to
do
this.
You
can
also
type
it
out
if
you
want
to,
and
the
two
concepts
here
are
workflows
and
actions.
When
we
take
a
little
step
back,
then
we
can
actually
say
see
that
these
have
special
things
in
them.
They
have
a
meaning-
and
we
also
added
this
thing
where
you
can
add
comments.
A
So
if
for
all
your
peoples,
that,
like
love
Jason
as
context,
we
have
comments
in
this
one,
so
let's
take
a
look
at
workflows
and
see
what
they're
all
about
and
how
to
use
them.
So
the
first
thing
there
is
that
they
have
an
identifier,
so
this
is
just
any
string
you
can
put
emojis
anything
you
want.
The
only
condition
is
that
it's
globally
unique
within
that
fare
file
that
you
have.
The
second
part
is
the
event
name,
so
that
is
any
event
that
we
showed
here
earlier.
A
A
We
would
say
hello,
but
we're
actually
adding
another
thing,
which
is
new
around
actions
which
is
repository
dispatch,
and
that
is
basically,
you
can
invoke
actions
and
workflows
with
API
calls,
and
the
way
that
works
is
that
we
have
a
new
endpoint
which
is
in
the
REST
API.
Currently,
you
post
to
this
end
point
on
API
github.com,
slash
all
of
this
repository
stuff
and
then
slash
dispatch
at
the
end,
and
you
can
give
it
this
JSON
payload,
which
is
going
to
show
up
in
the
event
when
the
actions
run.
A
A
The
visual
representation
here
is,
like
you,
have
the
workflow
on
top
and
then
actions
beneath
it,
and
this
is
what
we're
also
recommending
for
the
workflow
files
that
you
create
so
leave
all
the
workflows
at
the
top
and
then
the
actions
beneath
it
and
group
them
based
on
what
workflow
they're
part
of
so
the
action
I
showed
before.
Is
this
one
here
so
similarly
like
if
we
table
take
a
bit
of
a
step
back,
we
see
that
this
is
basically
the
simplest
form.
A
Often
the
uses
is
the
only
thing
that's
required
and
it
has
an
identifier
like
the
workflows
and
it's
the
same
namespace,
so
you
can
call
them
whatever
you
want,
but
they
just
have
to
be
unique,
and
this
is
when
you
referred
to
actions.
This
is
the
identifier
for
that.
So
here
we
I'm
gonna,
take
a
bit
of
a
step
back
and
show
you
all
of
the
optional
arguments
or
the
optional
keywords
for
actions.
A
So
let's
go
ahead
and
click
the
Edit
link
here
on
the
action
and
you
can
see
there
is
actually
a
handful
of
them,
so
I'm
gonna
scroll
down
here
and
what
we
can
do
now
is.
We
can
see
that
these
are
all
the
attributes
that
are
available
in
the
action
to
kind
of
give
you
an
idea
what
you
use
all
of
these
for
I'm
gonna,
set
up
a
small
example
repository,
so
I'm
gonna
illustrate
like
what
you
actually
use
all
these
force
right,
rather
than
trying
to
explain
it.
I
think.
A
It
also
has
a
tests
directory
where
it
has
a
single
test
for
this
particular
repository
and
then
a
nice
lint
file
to
lint
the
code
in
the
repository
and
finally
like
what
we
want
to
do
is
to
npm
install
on
this
repository
using
actions
and
then
to
npm
test
and
run
lint
in
parallel
and
then.
Finally,
as
like
a
cherry
on
top,
we
want
to
deploy
it
to
sites.
A
So
let's
go
ahead
and
setup
this
workflow,
we
create
the
main
that
workflow
like
we
did
before,
and
there
is
a
nice
visual
tweak
that
we
did
as
well
that
there's
a
full-screen
pattern
up
here.
So
it
looks
even
nicer
like
before
we're
gonna
go
ahead
and
name
this
workflow.
So
let's
call
it
deploy
on
push.
So
it's
gonna
pick
up
purchases
to
like
any
branch
and
I'll
get
back
to
how
you
can
actually
configure
it
to
do
like
on
different
branches.
A
First
thing
was
npm
install,
so
let's
go
ahead
and
label
that
build,
because
that's
kind
of
the
general
concept
that
we're
doing
here
and
click
done
and
then
let's
track
this
further
on
and
add
another
npm
action
here
from
the
featured
list
to
lab
tests
and
that's
gonna
run
npm
tests.
So
the
things
in
the
featured
thing:
that's
what
we're
talking
about
our
earlier
path
like
open
source
actions,
so
we
ever
have
a
handful
of
them
now,
but
we'll
be
adding
more
and
hopefully
the
community
as
well.
A
There
you
go
and
then
finally
we're
gonna
enable
the
site's
token
here,
so
that
is
going
to
be
injected
for
this
action,
and
the
last
thing
I
mentioned
was
running
a
linter
in
parallel
with
a
test
action
there.
So
it's
still
using
NPM,
but
instead
of
doing
tests
we
just
say
run
length
and
the
last
thing.
We
only
want
the
deployment
to
happen.
If
both
of
these
succeeds.
A
There
you
go
and
open
up
a
pull
request,
and
since
this
is
a
pre-recorded
demo,
I've
sped
it
up
a
bit,
but
the
first
step
here
is
doing
the
build
and
that
takes
about
a
minute
in
real
life,
but
in
this
demo
it's
just
a
few
seconds,
so
you
don't
have
to
wait
for
that
to
happen.
You
can
see
that
lint
and
test
they're
gonna
show
up
a
screen
about
the
same
time.
There
we
go
and
then
the
deployment
is
the
last
thing.
That's
gonna
happen
there
we
go
what's
interesting
about
this.
A
A
That's
the
thing
that
the
clears
dependencies
between
these
so
the
deploy
step.
The
last
thing
that
is
gonna,
say
that
it
needs
tests
and
lint
and
then
tests
and
lint
they
are
gonna
say
that
they
need
build
and
the
build
doesn't
have
any
dependencies.
So
that
is
the
first
thing
that
we're
gonna
kick
off
and
we
have
this
like
dependency
graph
of
what
is
going
to
happen
and
then
that's
the
thing
we
actually
do
so.
A
The
config
file
behind
all
of
this
is
this
thing
here
and,
as
I
just
explained
about
the
need
statement,
you
can
also
see
at
the
top
that
it
says
resolves
deploy.
So
it
starts
by
going
all
the
way
down
to
the
action,
deploy
and
figuring
out
that
this
that's
the
thing
that
we
want
to
converge
at
and
then
it
can
like
build
up
the
tree
in
from
there,
and
another
thing
that
you
probably
want
don't
want
to
do
is
to
actually
deploy
every
push
that
you
do
to
your
production
system.
A
So
you
could
basically
set
up
another
workflow
block
like
the
one
that
you
have
at
the
top,
and
that
would
just
say
test
and
lint
and
the
resolve
statement,
and
this
one
would
still
be
just
deploy,
but
there's
a
concept
that
we've
been
building
in,
which
is
called
filters.
So
you
could
say
that
only
pushes
to
master
or
going
to
deploy,
but
anything
else
is
just
gonna
run
tests
and
lint.
A
nice
side
effect
of
that
is
that
it
allows
us
to
do
all
sorts
of
optimizations.
A
So,
for
example,
when
you
push
something
to
a
branch
and
then
deploy
and
then
merge
it,
we
don't
need
to
do
all
of
the
intermediate
steps.
We
can
actually
do
optimizations
where
we
like
grab
the
results
from
those
and
then
push
them
forward.
So
that
was
the
need
statement
and
similar
to
some
of
the
other
ones.
If
it's
only
a
single
thing
that
you
have,
you
can
actually
drop
the
brackets
for
that.
So
this
is
how
you
do
like
the
dependency
rulers
resolution
and
specify
dependencies
between
everything.
A
So
now
we're
gonna
get
a
bit
into
like
detail.
So
what
is
what
is
the
thing
that
actually
runs
an
action?
This
short
answer
is
darker,
but
it's
a
bit
more
convoluted
than
just
that.
The
first
thing
here
is
that
we
can
pull
images
from
a
docker
registry.
The
second
one.
You
can
point
it
at
any
repository
on
github,
that's
public
and
the
last
form
is
anything
that's
in
the
current
repository.
A
So
let's
go
through
each
one
of
these
and
talk
a
bit
about
that.
So
in
this
case
we
will
just
be
pulling
down
debian
from
docker
hub
and
by
itself.
It
needs
an
entry
point,
it
doesn't
specify
one,
so
you
have
to
tell
it
what
to
run
and
I'll
show
a
demo
of
how
to
do
that
in
a
bit.
If
you
want
to
be
pulling
an
image
from
a
private
repository,
you
would
need
a
preceding
action
to
that
which
does
a
darker
login
to
that
particular
registry
and
yeah.
A
The
second
form
is
this
one
here
pointing
at
a
public
repo
on
github,
and
this
is
the
one
I
showed
you
earlier
with
a
shell,
but
we've
actually
opened
up
an
organization
on
github
called
github,
calm,
slash
actions
and
we've
posted
a
few
repositories
there
with
actions,
we're
gonna
be
adding
more
so
the
ones
we
have
now
are
these
here.
This
is
when
I
checked
it
last
night.
The
action
builder
is
an
action
that
helps
you
build
other
actions.
So
it's
a
thing
that
will
lint
your
actions.
A
It
will
run
tests
on
them
if
you
have
them
the
bin.
One
just
has
a
handful
of
command
line
tools
that
you
are
likely
to
use
with
actions.
Then
we've
got
the
three
big
clouds
which
we
showed
early
in
the
demo.
That's
Google
cloud
ash,
shihr'
and
AWS,
and
you
can
use
that
for
anything
from
deploying
to
kubernetes
uploading
static
assets
to
a
bucket,
whatever
you
can
think
of,
then
we
have
darker
and
NPM.
A
A
The
bin
directory
has
a
few
things
and
I'll
take
a
bit
of
a
deeper
dive
into
one
of
them
later
on.
But
if
we
look
at
the
filter,
one,
which
is
the
one
that
will
look
closer
and
I'm
just
gonna,
take
like
a
tiny
look
into
that,
and
we
can
see
that
I
hope
you
can
see
it.
There
is
a
docker
file
up
there.
So
that
is
the
thing
like.
A
If
we're
not
pulling
images
from
a
docker
registry,
we
are
actually
looking
for
a
docker
file
and
if
you
find
one,
we
will
build
that
and
run
that
as
the
action,
the
last
form
is
kind
of
similar,
so
it'll,
basically
just
look
in
the
current
repository
and
if
there's
a
docker
file
it'll
build
on.
So
this
is
where
we
are
thinking
that
there
are
some
actions
which
don't
necessarily
make
sense
to
publish
publicly.
A
So
these
are
like
one
of
things
that
are
only
like
relate
to
this
particular
repository
and
don't
really
have
a
broader
purpose
other
than
that
and
and
this
example.
This
is
just
a
demo.
We
have
and
there's
a
docker
file
and
there's
also
a
ruby
file
there.
So
that
is
kind
of
to
illustrate
that
you
can
write
your
actions
in
any
language
that
you
can
think
of.
The
filter.
Demo
is
just
shell
script.
This
one
is
Ruby.
A
A
Similarly,
there
are
arguments,
so
if
a
darkroom,
it
specifies
an
entry
point,
which
is
something
that
we
highly
recommend
one
building
actions.
You
can
just
pass
the
arguments
directly,
and
so
this
is
again
you
can
specify
it
in
this
form
and
the
example
I've
been
giving
a
few
times.
Is
this
where
you
can
have
an
NPM
action,
and
the
argument
is
just
to
install
you:
don't
need
to
write
NPM
install
every
time.
A
This
particular
example
I
gave
you
here,
it
uses
the
array
notation,
but
it's
for
the
shell
action
and
that
expects
that
every
argument
that
you
pass
in
is
a
standalone
command.
So
if
you
want
to
run
like
10
different
shell
commands
in
a
sequence,
you
can
just
add
them
to
this
array
and
it
will
run
them
and
if
one
of
them
fails,
it'll
fail
the
entire
flow.
A
Cool
so
we
mentioned
the
secrets
vault
earlier
and
so,
rather
than
persisting
tokens
in
a
repository
and
possibly
encrypting
them
in
there
we're
adding
this
thing
called
the
secret
vault
and
the
way
that
works
is
in
the
demo.
I
gave
earlier
I
passed
an
aside
token.
So
from
the
get
up
UI
you
can
actually
specify
a
token,
and
that
is
going
to
be
available
only
for
the
action
that
has
it
specified
as
a
secret.
So
any
other
action,
that's
running,
won't
be
able
to
see
this
in
the
demo
that
I
gave
you
earlier.
A
It
was
already
persisted
in
the
repository,
but
right
here
on
the
right
hand,
side
you
can
see
that
there's
a
secret
section
and
there
is
a
get
up
token
thing
there.
So
if
you
check
that
box,
then
an
action
will
actually
get
a
github
token
that
it
can
use
to
make
calls
back
to
github.
There
are
some
other
cool
use
cases
and
I'll
get
back
to
one
of
them
in
a
bit,
but
let's
click
the
Create,
a
new
secret
button
here
and
type
in
cites
token-
and
the
token
is
nice.
A
There
is
also
this
other
thing
where
you
can
specify
environment
variables,
so
this
is
useful
for
cases,
for
example
with
a
AWS
you
want
to
specify
which
region
it's
supposed
to
use.
Then
you
can
do
that
by
doing
this
and
the
environment
variables
they're
going
to
be
passed
to
the
process,
that's
running
and
we
actually
add
a
few
more
and
I'll
get
again
to
that
in
a
bit.
So
this
was
the
the
last
thing
with
actually
running
actions
and
using
them
so
building
actions.
A
That's
the
second
half
of
the
talk
and
the
way
that
works
is
basically
dockerfile.
That's
like
what
I've
alluded
to
a
few
times
now.
So
when
we
run
actions,
it's
actually
docker
containers
that
we
run,
we
just
orchestrate
how
they
get
run
and
the
filters
act.
The
action
that
I
mentioned
earlier.
That
has
a
few
things
in
its
docker
file
and
those
are
things
that
we
are
recommending
that
people
put
in
there.
A
The
first
thing
to
notice
is
the
first
line,
which
is
from
debian,
and
that
is
the
thing
that
we're
recommending
that
people
do
for
actions.
So
we
don't
have
like
something
from
a
boom
to
something
from
there
beyond
something
from
all
sorts
of
places
which
is
gonna,
make
things
slower.
So
we
basically
say
if
you
can.
A
Please
use
that
yet
because
then,
like
things,
will
pull
down
faster
and
use
slim
images
if
possible
and
then
give
them
a
name,
give
them
a
maintainer
and
then
portly
give
them
a
version
which
is
just
the
semantic
versioning
and
and
then
we
also
have
these
four
labels
for
actions
and
when
we
show
the
card
in
the
UI.
That
is
the
thing
that
actually
gives
it
the
description
and
the
icon
and
the
color,
and
the
entry
point
here
is
also
quite
important.
A
A
A
There's
both
the
filesystem
and
then
there's
also
the
environment
variables
that
the
processor
is
gonna
see
and
for
both
of
those
we
are
specifying
the
get
up
preface
as
reserved
so
we're
gonna
be
injecting
things
there
that
are
going
to
affect
the
lifetime
of
your
action
and
furthermore,
we
can
split
this
into
the
immutable
environment
and
an
immutable
one.
So
the
immutable
one
is
going
to
be
scoped
to
this
particular
action
and
anything
you
do
there
like.
It
won't
bubble
up
anywhere
else
and
the
mutable
one
is
like
where
we
persist
things
across
actions.
A
So
the
environments
that
we
pass
to
the
action
is
this.
You
can
see
here
at
the
top
that
we
give
you
the
repository
that
the
action
is
running
for
and
then
we
also
give
you
a
ref,
so
that
is
gonna
be
the
branch
that
it's
running
on.
If
it's
an
event
based
on
a
tag,
we'll
have
the
tag
name
there,
if
it's
something
that
neither
has
attacker
or
a
branch
like
this
Gator
breath
is
gonna
be
absent.
A
But
then
you
also
have
the
give
this
sha
of
the
command
now
for
events
that
don't
have
anything
to
do
with
code.
For
example,
issues
an
issue
comments,
we're
just
going
to
use
the
default
branch
and
the
event
name.
That's
what
is
the
event?
That's
actually
triggering
the
workflow
and
you
can
see
the
actor.
That's
just
my
name
and
that's
my
github
login
and
workflow.
That's
the
name
of
the
workflow
action,
the
name
of
the
current
action.
A
One
thing
to
note
here
is
you
don't
really
get
access
to
the
workflow
file
itself,
because
we
are
basically
thinking
that
the
action
shouldn't
have
to
parse
the
file
itself
and
figure
out.
What's
going
on
in
there
like
that's
on
us,
we'll
take
care
of
that
and
you
just
take
what
input
you
need
and
produce
the
outputs
that
you
want
to
pass
on.
A
So
this
is
super
useful
for
actions
that
you
maybe
want
to
look
into
something
about
the
event
that
triggered
the
thing.
So,
if
you're,
looking
for
something
specific,
for
example,
was
this
a
push
that
deleted
a
branch?
Then
you
would
be
looking
into
the
event
payload
for
that
the
mutable
environment.
That
is
basically
everything
you
write
to
these
particular
places,
they're
going
to
be
persisted
across
actions
and
the
first
one
is
the
workspace.
So
that
is
going
to
be
this
directory
and
that's
going
to
be
the
working
directory
for
actions.
A
But
there's
a
use
case
that
I
think
is
gonna,
be
super
cool
when
people
start
to
use
it,
and
that
is
with
the
get
up
token,
that
I
showed
us
a
secret
earlier.
We
can
actually
use
that
to
push
code
back
to
get
up.
So,
for
example,
if
you
could
have
a
workflow
where
you
say
if
I
need
to
do
code
generation
and
if
I
as
a
developer,
forget
to
do
that
locally
and
then
I
push
changes
to
github.
A
A
So
that's
the
next
part
of
the
immutable
environment,
and
that
is
just
a
classical
home
directory
in
Unix,
except
that
it's
in
slash,
github,
slash
home
and
that's
because
we're
gonna
be
doing
a
few
things
with
it,
which
are
like
technical
details.
But
you
can
ask
me
later
what
that's
all
about
and
the
intent
there
is
that's
where
you're
going
to
be
putting
credentials
and
configuration.
So
when
you
use
command
line
tools,
some
of
them
need
to
write
credentials
to
a
file,
so
the
default
with,
for
example,
Heroku
to
leave
and
be
an
NPM.
A
Does
it
as
well
and
darker?
There
right
credentials
to
a
file
on
the
file
system.
You
don't
want
to
put
that
alongside
your
source
code,
because,
if
you're
building
a
container
and
then
deploying
that
summary,
you
don't
actually
accidentally
want
to
be
putting
tokens
in
there.
So
that's
what
the
home
directory
is
for,
but
we
also
have
a
git
config
in
there
and
the
credential
helper.
So
that's
the
thing
I
mentioned.
A
So
then
everything
else
on
the
file
system
inside
the
container
it
is
mutable.
You
can
modify
it,
but
once
the
action
is
actually
finished,
running
like
it's
just
gonna
be
thrown
away.
So
if
you
need
to
write
temporary
data
anywhere,
you
can
just
do
that.
If
you
want
to
delete
everything
inside
the
container,
you
can
also
do
that.
But
as
soon
as
you
touch
anything
in
the
home
or
the
workspace,
then
it's
gonna
be
gone.
So
please
don't
do
that.
A
The
last
thing
around
building
actions
is
exit
codes.
That's
how
we
detect,
whether
it's
a
successful
action
run
or
whether
it's
a
failure.
So
as
with
any
unix
program,
if
you
exit
with
zero,
it's
considered
successful
anything
else,
a
failure.
So
this
is
like
the
check
mark
that
you'll
see
in
the
github
UI
after
the
action
runs
or
the
X,
which
is
not
happy
about
things
so
filters
I've
mentioned
them
a
bunch,
so
I'm,
just
gonna
show
you
a
tiny
bit
of
how
they're
actually
implemented.
A
So
we
have
this
repository
here
and
which
is
a
path
inside
this
bin
repository
and
I
mentioned.
Also
that
you
can
say
we
can
have
an
action
that
filters
based
on
a
branch.
I'm
gonna
go
a
bit
like
a
long
winded
way
around
it,
because
it's
simpler
to
show
the
code
for
it,
but
instead
of
saying
in
the
arcs
here,
I'm
saying
ref,
but
you
could
actually
say
branch
and
just
give
it
master.
There
is
also
one
for
tag.
A
There's
a
few
of
them,
but
here
I'm,
just
saying
ref
and
then
refs
hats
master,
which
is
the
get
notation
for
a
branch
called
master.
If
you
look
at
the
repository
again,
we
can
see
there's
a
docker
file
which
I
showed
you
already.
If
you
look
at
that,
it's
basically
the
same
contents
as
I
showed
you
before,
but
there's
a
few
extra
things
in
here.
It's
copying
in
some
licenses
and
some
documentation
into
the
root
of
the
file
system.
It's
also
installing
a
few
packages.
A
If
you
squint,
you
can
maybe
say
that
it's
installing
JQ,
which
is
a
tool
for
parsing
JSON
files
and
figure,
doing
running
queries
against
them.
So
there
are
a
few
filters
that
will
do
that.
So
it's
a
filter,
for
example,
to
inspect.
If
you
have
an
issue
you
can
see,
was
it
opening
an
issue,
closing
an
issue
and
then,
similarly
with
polar
quests?
Was
it
being
opened
or
closed?
And
then,
lastly,
it
also
copies
some
bin
files
into
user
local
bin
and
then
adds
that
to
the
path.
A
And
the
last
thing
is
that
it
runs
a
shell
and
that
was
for
the
expansions
that
I
mentioned
earlier.
So
let's
have
a
look
inside
the
bin
directory
and
there
are
a
few
scripts
in
here.
I
mentioned
branch
and
wrap
attack
and
they
basically
called
the
ref
one,
which
is
kind
of
why
I
went
to
long
waited
round.
So
let's
look
at
the
ref
one,
it's
just
a
simple
shell
script.
It's
looking
at
the
get
up
graph,
which
is
going
to
contain
the
branch
name
or
tag
name.
A
So
the
first
thing
it's
checking
is:
is
it
actually
set?
If
it
isn't,
it
does
an
exit
one
which
is
a
failure.
So
that's
gonna
stop
the
workflow
if
it
actually
matches
the
pattern
you're
looking
for
so
that's
like
refs
headmaster,
then
it'll
exit
with
a
zero
which
is
success
and
then
it'll
continue
with
workflow
and
then
last
thing
is
like
it
doesn't
match
the
pattern
and
then
it
just
exits
with
a
failure
as
well.