►
From YouTube: Professional Services: Workshop 1 - Automate your workflow using GitHub Actions and GitHub Packages
Description
This Workshop is focused on helping you move from idea to production using GitHub Actions and GitHub Packages. We'll look at how to build, test, release, and deploy code to the cloud; secrets management; and automating administrative tasks. After this Workshop, you'll be able to leverage these features to improve your own workflows. Difficulty level = Intermediate (200)
For more from GitHub Universe 2020, visit https://githubuniverse.com
As always, feel free to leave us a comment below and don't forget to subscribe: http://bit.ly/subgithub
Thanks!
Connect with us.
Facebook: http://fb.com/github
Twitter: http://twitter.com/github
LinkedIn: http://linkedin.com/company/github
About GitHub
GitHub is the best place to share code with friends, co-workers, classmates, and complete strangers. Millions of people use GitHub to build amazing things together. For more info, go to http://github.com
A
So
a
little
bit
about
myself,
my
name
is
rowena
and
I'm
an
implementation
engineer
on
the
professional
services
team.
So,
on
my
day-to-day
basis,
I
talk
to
github
enterprise
customers
from
all
around
the
world
to
help
them
how
to
use
and
maintain
their
github
enterprise
instance.
So
today
I
hope
I
can
bring
some
of
my
experience
and
expertise
to
help.
You
learn
something
new
today.
So
with
my
co-presenter
stefan
I'll
hand
it
over
to
him
and
let
him
introduce
himself.
B
Thank
you,
ravenna
hi,
everyone.
From
my
side,
my
name
is
stephen
belkinos.
I
am
a
solution
architect
on
the
professional
services
team
and
in
my
daily
work
I
help
customers
develop
software
using
github
and
common
ask
is
how
to
improve
their
software
development
lifecycle
by
automating
common
tasks
using
actions.
B
A
All
right
awesome,
so
from
today's
workshop
we
hope
to
achieve
a
few
outcomes,
the
first
one
being
we
hope
to
help.
You
understand
how
github
actions
and
packages
can
fit
into
your
software
development
life
cycle,
how
we
can
add
value
to
it,
and
we
also
hope
they
can
come
away
with
a
better
understanding
of
the
components
that
make
up
github
actions
and
github
packages.
So
I
understand
that
maybe
many
of
you
on
this
call
today
have
very
rich
experience
and
expertise
and
actions,
given
that
it
came
out
a
year
ago.
A
However,
if
you're
on
a
101
level,
I
got
you
covered,
we
have
a
one-on-one
level
overview
of
github
actions
and
even
if
you're
an
expert,
we
hope
that
you
would
go
into
the
workshop
with
the
same
level.
You
know
same
understanding,
same
use
of
terminology
so
regardless.
I
hope
that
this
kind
of
level
set
everyone
going
into
it.
A
Finally,
we're
going
to
get
our
hands
dirty,
of
course,
and
we're
going
to
learn
how
to
build
our
own
workflow
so
that
by
the
end
of
this
workshop,
you
should
be
able
to
walk
away
with
knowledge
and
confidence
to
learn
how
to
automate
your
pipelines.
So,
let's
jump
right
in
first
of
all,
why
even
care?
Why
even
learn
about
github
actions
and
packages?
How
does
it
fit
into
your
day-to-day
work?
A
Well,
maybe
during
if
you
are
here
during
your
universe
on
day
two,
our
ceo
erica
talked
about
how
it
takes
about
23
minutes
to
get
into
that.
Zen
flow
that
that
zone
that
you're
you're
really
into
your
work,
you're
just
cranking
work
away
and
nothing
else,
matters
you're
not
distracted
by
anything.
So
it
takes
about
23
minutes
to
get
into
it
and
if
you're
distracted
by
something
else
or
if
you
need
to
switch
contacts,
it
takes
another
23
minutes
to
enter
it
again.
A
So
it's
important
to
think
about
how
it
can
help
reduce
the
noise
and
reduce
the
test
that
forces
developers
to
kind
of
context
switch
throughout
the
day.
So
this
diagram-
maybe
a
lot
of
you-
are
familiar
with
it.
This
is
the
diagram
that
shows
your
entire
software
development
life
cycle.
I'm
just
gonna
call
it
sdlc
from
here
on,
just
because
it's
a
very
long
phrase
to
talk
about
so
sdlc.
For
short,
so
along
this
life
cycle,
developers
may
have
to
switch
from
different
tools.
You
know
to
to
carry
on
different
tasks.
A
Most
of
it
might
not
even
be
directly
related
to
your
code.
You
know
maybe
they're
in
jira,
maybe
they're
doing
administrative
tasks.
So
there's
a
lot
of
contest
switching
going
on
and
we
wanna
think
about
how
we
can
implement
automation
in
every
face
and
let
the
bots
do
the
work
so
that
you
can
focus
on
developing
code
and
just
generally
make
life
easier.
A
So
from
each
phase
you
know
at
the
planning
phase,
there's
issues,
github
issues
and
github
project
boards
that
can
help
you
out
with
that
planning
phase.
I
recently
talked
to
one
of
my
customers
and
I
was
really
impressed
with
how
they
were
thinking
outside
of
the
box.
You
know
not
just
using
github
actions
for
ci
cd,
but
they
had
this
idea
of
using
github
actions
to
create
issues
automatically,
so
they
built
they
have
this
web
application
and
they
also
have
this
feedback
form
what
they
had
built.
A
Was
you
know,
whenever
a
customer,
their
customer
have
any
feedback,
they
can
create
a
form
they
can,
you
know,
send
their
suggestion
in
and
when
they
click
send.
It
automatically
hits
our
github
api
and
creates
an
issue
for
them
directly
in
their
repositories,
so
that
developers
can
just
start
cranking
work
away.
So
I
thought
it
was
pretty
genius
for
them
to
even
think
about.
You
know
how
to
use
actions
outside
the
box.
You
know
even
before
the
planning
event
begins
when
it
comes
to
code.
A
There's
a
lot
of
features
in
place
already,
such
as
code
review,
and
if
you
were
here
on
the
first
day
of
universe,
it
was
announced
that
we
have
a
new
feature
called
auto
merge
where,
as
long
as
your
call
request
has
met
all
the
criterias,
the
pull
requests
will
automatically
merge
for
you
and
some
ways
where
you
might
want
to
use
github
actions
to
help
automate
that
you
might
think
about.
Maybe
auto
labeling
your
pr's
or
issues
things
like
that.
A
A
So
when
you're
thinking
about
compiling
buildings,
storing
artifacts,
you
can
do
that
with
get
up
actions
and
packages
when
it
comes
to
the
testing
phase,
using
github
actions
to
automate
your
test,
suites
from
unit
tests
all
the
way
to
regression
testing
using
linters
for
code
quality,
using
our
code
ql
for
finding
security
vulnerabilities
downloading
installing
packages
as
part
of
a
workflow
using
github
packages
all
can
be
very
powerful
when
it
comes
to
accelerating
their
process
and
kind
of
increase
velocity
along
your
sdlc
release
and
deploy.
This
is
also
pretty
straightforward.
A
You
know
publishing
your
release,
uploading
artifacts
to
your
release
and
then
finally
deploying
your
application
either
on
premise
or
to
any
of
your
cloud
providers
using
github
actions.
These
are
all
ways
that
you
can
use
actions
and
packages
to
automate
your
process
along
the
way.
So
maybe
you
might
be
thinking
about
hey.
A
I
have
all
these
tools
in
place
already,
I'm
already
using
jenkins,
I'm
already
using
jira.
So
what
is
the
point?
Even
if
I
want,
if
like?
Why
do
I
need
to
migrate
to
github
actions?
If
I
already
have
all
these
tools?
Well,
one
thing
is
github
actions
in
short,
allow
you
to
build
ci
cd
capabilities
directly
in
your
repository
instead
of
using
ci
cd
integrations.
So
this
gives
you
the
freedom
to
automate
and
accelerate
your
process
all
along
your
software
development
cycle.
A
A
They
are
stored
as
code,
which
is
really
nice.
It
means
that
you
can
version
control.
It
you
can
share,
reuse
it
for
easy
collaboration.
It
comes
with
live
logs
and
again
new
feature
that
came
out
that
was
announced
during
universe.
Actions
now
come
with
a
visualized,
workflow
execution,
so
maybe
you're
using
jenkins.
A
This
is
very
similar
to
like
blue
ocean,
where
you
can
kind
of
see
it's
each
stage
going
on,
but
this
time
it's
directly
in
the
repository,
I
really
like
the
live
logs
feature
because
in
the
past
you
know
I
I
personally
use
jenkins.
I
don't
mean
to
hate
on
jenkins
or
anything,
but
it's
just
an
example.
A
That
is
very
salient,
but
you
know
I
have
to
push
my
code
go
to
jenkins
and
see
the
logs
and
if
something
breaks,
I
have
to
come
back
push
code
and
then,
when
I
go
back
sometimes
I
get
logged
out,
there's
something
wrong
with
my
server
and
all
that
kind
of
stuff
that
I
think
about
now
with
live
logs.
Everything
is
in
my
repository.
I
get
instant
feedback
and
I
don't
have
that
kind
of
silo
going
on.
So,
if
anything
breaks,
I
can
immediately
just
change
it
in
my
repository.
A
So,
let's
take
a
another
step
deeper
into
github
actions
and
understand
the
components
that
make
up
github
actions
from
the
start.
You
start
with
an
event
the
event.
It
will
be
the
fire
that
sparks
this
chain
reaction.
It
will
be
triggering
the
workflow,
so
events
is
a
specific
activity
and
it
triggers
the
workflow.
The
workflow
is
going
to
be
made
up
of
one
or
more
jobs.
Each
job
contains
a
set
of
steps,
and
each
step
is
an
individual
task
that
can
run
commands
in
a
job.
A
A
step
can
either
be
an
action
or
a
shell
command.
Actions
are
then
referenced
in
the
step.
This
is
going
to
be
your
smallest
building
block
of
the
workflow,
the
action
that
you
reference
is
also
portable,
meaning
that
you
can
reuse
it
somewhere
else.
You
can
put
it
in
the
repository
put
it
on
the
workflow.
Whatever
you
want
to
do,
that's
what
I
mean
by
portable
and
then
the
last
component
of
github
actions
is
the
runner
itself.
A
The
runner
is
the
environment
where
the
job
is
executed,
each
step
in
the
job
executes
on
the
same
runner,
allowing
the
actions
in
that
job
to
share
data
with
each
other.
You
can
use
a
runner
again
either
from
us
or
you
have
your
own.
Arena
listens
for
available.
Jobs
runs
one
job
at
a
time
and
then
reports
the
progress
logs
and
results
back
into
github.
A
So
how
does
this
work
in
practice?
Well,
first,
you
start
with
a
yaml
file
called
you
know,
whatever
you
want
to
call
your
workflow,
but
it's
going
to
be
an
email,
syntax
and
then
you're
going
to
put
this
file
in
a
folder
called
dot.
Github
forward,
slash
workflows.
This
is
going
to
be
in
your
repository.
You
create
a
folder,
create
this
file.
Put
it
in
there,
it
will
come
with
the
following
syntax.
A
A
So,
let's
look
into
each
individual
component
a
bit
deeper,
we're
going
to
start
with
events,
things
that
you
can
use
as
part
of
the
events.
One
is
going
to
be
web
hook.
Events-
these
are
your
traditional
github
events
like
when
someone
opens
a
poll
request
when
someone
approves
a
pull
request
opens
an
issue
close
issue
or
whenever
someone
pushes
through
the
repository.
A
So
in
this
example
that
I've
highlighted,
I
use
an
event
where,
whenever
an
issue
has
been
closed,
reopen
or
labeled,
please
trigger
this
workflow
file.
The
second
type
of
event
is
called
schedule.
Events.
This
is
where
you
use
a
cron
job
and
in
this
example,
it's
going
to
be
run
every
15
minutes,
the
last
type
of
event.
If
none
of
this
worked
for
you,
you
can
think
about
manual
events
as
well.
One
of
the
manual
events
that
you
can
use
is
called
workflow
dispatch.
A
A
Next,
we
have
the
runners
if
I
want
to
go
with
the
github,
hosted
runner
it's
going
to
have
the
following
hardware
configuration
it's
going
to
have
the
following
operating
systems
as
well,
such
as
windows,
linux
and
mac
os,
and
it
has
tons
of
software
installed
already
so
on
the
right
side.
Wow,
where
my
syntax
is.
This
is
how
I
would
reference
a
runner
that
I
would
like
to
use
in
my
workflow
the
if
you
don't
want
to
use
any
of
that.
There
are
good
reasons
why
you
might
want
to
consider
a
self-hosted
runner.
A
Some
reasons
are
like.
Maybe
you
have
a
job,
a
larger
job
that
you
need
to
run,
or
maybe
you
need
your
job
to
run
in
a
specific
specific
environment
where
you
require
a
specific
version,
certain
type
of
software
that
is
not
offered
by
github
or
you
know,
if
you
want
to
run
your
actions
in
a
private
network.
Self-Hosted
runners
are
a
good
reason
to
go
with
that.
So,
when
you
install
a
runner
onto
your
repository,
github
automatically
creates
labels
for
them,
or
you
can
create
your
own
labels
to
associate
with
these
runners.
A
There
are
three
types
of
actions
you
can
reference,
the
first
one
being
you
can
reference
an
action
coming
from
a
public
repository.
So
an
example:
I
have
on
the
right
side
in
the
syntax,
I'm
using
an
action,
that's
coming
from
an
organization
called
actions
and
the
repository
is
called
checkout
and
it's
you
know
at
version
two.
So
this
is
an
example
where
I'm
using
someone
else's
action.
It
could
be
your
own,
but
you
know
if
you
put
your
action
in
a
public
repository.
This
is
how
it
referenced
it.
A
A
A
So
we
have
gone
to
understanding,
github
actions
from
a
very
high
level,
understanding
the
components
and
then
we
move
on
to
talk
about
the
syntax
of
workflow
file
and
what
are
the
elements
you
need
in
your
workflow
file?
So,
let's
just
zoom
out
a
little
bit
and
kind
of
have
a
more
abstract
idea
of
github
actions.
Essentially
github,
essentially,
events
trigger
workflows
and
your
workflows
would
reference
an
action
altogether
is
what
typically
you
know.
A
People
refer
github
actions,
as
when
people
talk
about
github
actions,
they
usually
refer
to
all
three
components:
they
talk
about
the
workflow
file
and
how
to
build
your
jobs
and
your
steps
not
very
often
do
people
actually
mean
the
last
component
of
actions,
meaning
that,
if
you
are
thinking
about
writing
your
own
action,
that's
not
what
the
focus
of
this
workshop
is
about.
Writing
your
own
action
is
a
kind
of
a
separate
conversation,
we'll
we'll
get
into
it
a
little
bit,
but
it's
kind
of
a
little
separate
conversation.
A
A
A
So
a
container
allows
you
to
have
very
specific
environments.
Right
like
it,
you
can
have
specific
versions
of
dependencies
tools,
software
all
that
kind
of
stuff.
So
if
you're
thinking
about
writing
an
action
that
requires
it
to
run
in
this
specific
environment,
configuration,
then
docker
container
would
be
an
ideal
situation
for
you
to
write
an
action
in
so
so
that,
if
you're
thinking
about
having
someone
else
consume
your
action,
they
don't
have
to
worry
about
the
dependencies
which
is
awesome.
A
A
The
next
thing
to
think
about
is
that
your
action
needs
to
be
defined
with
a
file
called
action.yml.
The
action
the
action.yaml
file
is
a
metadata
file
in
this
metadata
file.
It
defines
the
inputs,
outputs
and
the
main
entry
point
for
reaction.
So
in
this
example
that
I've
highlighted
in
this
specific
action
requires
an
input
parameter.
So
an
input
parameter
allows
you
to
specify
data
that
the
action
expects
to
use
during
runtime.
A
You
want
to
use
chainable
actions
as
opposed
to
monolithic
actions,
so
that's
easier
to
debug
stuff,
like
that,
we
recommend
using
release
management
to
control
how
you
distribute
updates
so
that
whoever
is
consuming
your
action
they're,
not
using
your
action
from
the
default
branch.
They
have
the
specific
version
that
they're
looking
at.
A
So
when
you
are
writing
your
own
actions,
it's
going
to
be
the
same
deal
like
any
open
source
projects
out
there.
It
needs
to
have
really
good
documentation
like
rainy
dot,
md
and
contribute
on
md.
So
people
understand
how
to
install
your
action,
how
to
contribute
to
it
proper
action.yaml
metadata.
That's
goes
without
saying,
and
finally,
you
want
to
add
your
action
to
the
marketplace
so
that
other
people
can
benefit
from
the
work
that
you
have
done.
So
I
talked
about
marketplace
a
little
bit
here
and
there.
A
So
let's
talk
about
that
some
more.
Let's,
let's
look
into
what
a
marketplace
actions
are.
Sometimes
these
actions
are
being
referred
to
as
third-party
actions
and
they
live
on
the
marketplace.
So
let
me
show
you
what
that
looks
like
okay,
so
this
is
you
guys
can
see
my
screen
awesome.
So
with
github
marketplace,
I
can
look
for
actions
from
companies
that
you
know
I
might
be
using.
If
you
see
a
little
blue
check
mark,
you
know
that's
kind
of
the
vip
symbol
on
the
internet.
That's
when
you
know
it's
legit.
A
A
Let
me
look
up
azure,
because
maybe
I
need
to
deploy
to
azure,
and
here
I
can
find
things
that
have
already
been
written
by
azure,
so
instead
of
magically
knowing
how
to
deploy
to
azure
container,
I
can
just
come
in
here
and
look
for
stuff
that
was
is
already
written
by
azure
themselves,
and
you
know
they
already
did
the
legwork
for
you.
All
I
need
to
do
is
just
use
this
action
and
reference
that
in
your
workflow,
so
in
their
readme
file.
They
kind
of
show
you
how
to
do
that.
A
A
I
can
see
a
lot
of
jira
actions
here
as
well.
So
maybe,
if
you
are
using
jira
as
part
of
your
project
management
tool,
this
could
help
you
maybe
reduce
that
that
context
switch
that
we're
talking
about
maybe
bring
some
of
that
information
into
github.
Instead
of
you
know
forcing
developer
to
go
to
another
place.
Do
some
jira
stuff
come
back
to
github?
A
Again,
let's
see
what
else
I
I
think
it's
really
important
to
plug
in
the
work
that
your
co-workers
are
doing,
so
I'm
going
to
talk
about
super
linter
because
it
was
built
by
a
bunch
of
my
co-workers.
They're
really
awesome-
and
this
is
super
popular
because
it
has
6
000
stars.
Basically,
the
super
linter
it
lints
for
code-
and
this
is
all
the
languages
that
it
supports.
A
It
gives
you
a
really
quick,
high
level
overview
about
how
to
use
it,
how
to
reference
it
in
your
workflow-
and
I
can
see
here.
This
is
how
I
would
use
it
okay
and
if
you're
curious
about
the
source
code
of
this
action,
I
can
go
into
the
links
here.
Click
into
super
superlinter
look
into
the
actual
source
code
repository.
A
I
can
see
it
comes
with
the
action.yaml
file.
This
is
what
I
mean
by
writing
your
own
action.
If
you're
someone
that
writes
your
own
action,
it
needs
to
come
with
an
action.yaml
metadata
file
and
another
good
practice
that
you
see
here
in
this
repository
is
that
it
has
good
versioning
going
on.
So
you
can
see
in
a
release.
It
was
tagged.
Seven
days
ago,
that
that
shows
you,
you
know
it's
pretty
active,
so
it
does
use
some
of
the
best
practices
that
I
was
talking
about.
A
A
A
I
can
also
click
on
set
up
a
workflow
yourself
right
here
and
then
I
can
then
see
the
marketplace
from
here
as
well,
so
I
don't
need
to
always
go
to
the
github
marketplace
to
grab
something
I
can
search
the
marketplace
directly
in
my
repository,
so
let's
say:
if
I
go
into
superlinter,
I
found
it
and
I
click
into
it.
I
get
some
information
here,
and
so
I
can
think
about
bringing
that
in
to
my
workflow
file.
Okay,
so
again
it
comes
with
two
perspectives.
A
If
you're
someone
who
wants
to
leverage
the
community
the
community
work
for
github
actions
and
use
third-party
actions
from
the
marketplace,
I
would
definitely
encourage
you
to
go
over
the
workflow
syntax
for
github
actions,
kind
of
learn.
What
are
some
parameters
you
need
to
declare
in
your
workflow.
On
the
other
hand,
if
you're
creating
an
action,
if
you're
someone
who
wants
to
contribute
to
the
marketplace,
then
I
would
encourage
you
to
focus
on
the
help
documentation
on
how
to
create
your
own
action.
A
Okay.
So
that
being
said,
let's
go
back
to
our
keynote
all
right,
so
I
showed
you
the
marketplace
action.
Some
of
you
here
may
be
repository
admins
and
you
might
be
wondering
hold
on
a
second,
so
you're
saying
that
we're
gonna
go
out
and
grab
all
this
different
actions
coming
from
different
places
like
I
don't
like
that,
I
want
to
at
least
audit
or
make
sure
that
all
the
actions
coming
in
are
secure
and
they're
in
good
hands.
A
So
what
you
can
do
in
your
repository
settings
is
that
you
can
go
in
and
say
what
type
of
actions
you
want
to
allow.
In
your
repository,
you
can
say
that
you
want
to
allow
local
actions
only
meaning
that
you
are
only
allowing
actions
coming
directly
from
the
repository
or,
you
can
say,
allow
select
actions,
either
they're
actions
created
by
github
actions
by
verified
creators.
You
know
the
one
with
the
blue
tick
or
you
can
say
you
want
specified
actions
at
a
specific
version.
A
A
A
So
you
can
manage
secrets
through
the
api.
That
means
you
can
create,
update
or
retrieve
any
information
about
encrypted
secrets.
So
again
you
can
have
secrets
at
the
organization
level
or
you
can
have
it
at
the
repository
level.
At
the
organization
level
you
can
define
where
you
want
the
secrets
to
be
used,
so
you
can
say
the
secret's
only
for
this
one
repository,
only
no
other
repositories
can
use
it.
But
what's
nice
is
what's
nice
about
having
secret
at
the
organization
level?
Is
that
it's
just
one
place?
A
You
know
one
place
that
rules
them
all.
So
if
you
need
to
update
a
and
a
secret,
you
can
just
go
into
this
higher
level
place
update
and
then
all
the
repositories
will
get
the
updated
secret.
On
the
other
hand,
you
can
also
have
secrets
at
the
repository
level,
which
obviously
is
scoped
to
the
repository
itself.
A
So
how
do
you
use
secrets
in
a
workflow
I'm
back
again
into
my
workflow
file?
This
is
the
yaml
syntax
that
you
were
looking
at
previously,
so
to
use
a
secret
in
a
workflow.
You
would
access
them
using
the
same.
The
syntax
that
I
have
here
so,
whatever
secret
name
you
have,
you
will
just
access
it
with
the
syntax.
A
On
the
other
hand,
github
also
creates
a
token
automatically
for
you,
so
that
you
can
use
that
in
your
workflow.
The
way
github
does
this
is
that
it
installs
a
github
app
on
your
repository,
and
this
token
is
used
to
authenticate
on
behalf
of
the
github
app
installed
on
your
repository.
So
this
means
that
the
token's
permission
is
limited
to
the
repository
that
contains
your
workflow
again
in
in
the
highlighted
syntax
that
I
have
on
the
right.
If
I'm
using
this
token
that's
automatically
created.
A
So
when
you
run
your
workflow
github
would
fetch
this
token
for
the
job
and
the
token
would
expire
when
the
job
is
finished
and
what,
if
you
already
have
some
type
of
secret
store
that
you
you're
already
using
maybe
from
hashicorp
or
azure
key
vault?
Well,
you
can
use
their
github
actions
to
still
continue
using
the
faults
that
you
already
have,
instead
of
using
the
built-in
secret
store
so
again
leveraging
the
power
of
community
actions
to
help
you
out
in
your
automation.
B
C
B
All
right,
if
one
of
my
fellow
moderators
could
give
me
a
thumbs
up
if
you
see
the
gita
packages
front,
page,
awesome,
okay,
that
was
that
was
really
interesting
stuff.
Thank
you
for
that
ravenna.
I
just
wanted
to
highlight
before
we
move
on
to
the
next
topic
that
there
were
a
few
questions
in
the
slack
channel.
Thank
you
very
much
for
that.
Keep
them
coming.
B
There
was
one
specific
questions
about
github
actions
and
how
you
would
kind
of
design
principles
about
how
to
modularize
these
actions
and
so
on,
and
I
just
wanted
to
verbally
as
well
like.
Second,
the
input
from
from
thomas
and
stowe
and
evgeny
about
you
know
still
respecting
the
software
design,
principles
of
separation
of
concerns
and
all
these
kind
of
things.
B
It's
basically
about
you
know,
thinking
about
like
which
parts
do
I
want
to
reuse
and
which
parts
do
I
want
others
to
make
use
of
and
so
forth.
So
it's
not
that
much
different
than
developing
software,
as
you
used
to
already
so
speaking
of
separation
of
concerns.
Now
that
we
have
talked
about
automation
with
github
actions.
B
So
you
don't
need
multiple
accounts,
a
lot
of
software
projects.
They
don't
use
just
one
language
right,
you
maybe
have
different
components,
microservices
or
something
of
that
sort
that
are
developed
in
different
languages,
and
that
also
means,
if
you
want
to
package
this
code
and
distribute
it,
you
also
need
to
have
accounts
and
manage
credentials
and
that
kind
of
stuff
for
all
of
these
different
package
managers.
B
B
So
you
can
build
and
publish
your
package
using
either
a
community
action
which
ravenna
already
showed
you
on
the
marketplace
or
you
can
build
your
own
and
if
you
go
to
that
actions
tab,
you
will
see
a
lot
of
these
started.
Workflows
right
and
one
of
the
solid
workflows
that
popped
up
in
rovanna's
demo
was,
for
example,
the
publish
node.js
package.
B
By
using
this
package
event
as
well-
and
the
next
part
is
api
support
a
lot
of
our
features
in
github,
you
can
do
vr
api
in
the
same
manner
as
you
would
do
it
in
the
user
interface
and
that
also
counts
for
packages.
There
are
some
constraints,
but
essentially
you
have
existing
api
endpoints
that
you
can
invoke
for
our
graphql
api.
You
might
be
familiar
with
github
apis
and
we
have
two
versions.
We
have
version
3,
which
is
our
rest
api
and
we
have
version
4,
which
is
our
graphql
api
and
using
our
graphql
api.
B
You
can
both
retrieve
info
about
a
package
and
you
can
even
delete
specific
package
versions
using
that
same
endpoint
in
terms
of
url.
If
you
use
one
of
these
package
managers
already,
then
you
already
have
a
target
url
right
that
you
that
you
push
your
packages
to
for
github
packages.
It's
very
simple:
it's
simply
the
packageregistry.pkgithub.com
followed
by
the
owner,
which
might
be
either
your
user
handle
or
your
organization
name
depending
on
whether
you
have
your
repository
in
an
organization
or
behind
your
personal
account.
B
B
And
then
the
last
point
on
this
slide
before
we'll
have
a
quick
look
at
the
gui
is
that
it
inherits
the
permissions
and
the
visibility
from
your
repository.
So,
for
example,
if
I
have
a
private
repository
and
I
build
and
publish
my
source
code
from
that
same
repo,
then
the
package
will
also
be
private
and
vice
versa.
For
if
I
have
a
public
repository,
if
I
publish
a
package
from
that
repo,
then
that
will
be
a
public
package.
B
You
might
notice
that
you
know
we
are
missing
a
few
things
on
the
right-hand
side,
such
as
python
php
and
maybe
even
generic
packages,
but
we'll
loop
back
to
that
at
the
end
of
the
workshop
and
for
docker.
We'll
also
have
our
own
little
slide
on
that
coming
up
later
before
we
go
there.
I
just
wanted
to
show
you
what
this
looks
like
in
the
gui.
We'll
also
have
a
bit
of
demoing
on
this
part
as
well
coming
up,
but
just
a
few
key
points.
B
B
On
second
thing,
a
few
more
data
points
here
you
see
who
the
owner
is
you
see
when
it
was
published?
You
can
also
see
the
shark
commit
that
this
package
points
to
the
version
number
and
the
tarball
file,
which
you
can
download
as
an
asset
download
activity
as
well.
If
you,
you
know,
would
like
to
monitor
how
popular
is
my
package
and
so
forth.
This
is
where
you
you
would
do
that
and
of
course,
you're
probably
going
to
end
up
having
multiple
versions
of
the
same
package.
B
So
you
can
both
view
and
manage
these
versions
directly
in
the
in
the
ui
all
right.
So
now
we
had
some
basics
about
packages
so
how
to
actually
use
this
in
your
workflow.
It
is
pretty
easy,
and
if
you're
coming
from
an
existing
package
manager
like
npm,
then
you
could
essentially
switch
over
to
using
gita
packages
by
changing
the
target
url,
because
we
have
starter
workflows
for
different
ecosystems,
not
only
npm,
also
for
ruby
for
mado,
sorry,
maven
and
gradle
and
so
forth.
B
B
You
can
also
reuse
existing
workflows
that
you
might
have
in
github
actions
by
updating
the
target
url,
which
we
showed
on
the
on
the
earlier
slides,
and
one
of
my
favorites
actually
is
that
it's
so
easy
to
get
started,
because
you
don't
even
have
to
create
a
new
personal
access
token.
You
can
just
use
the
github
token,
which
was
briefly
mentioned
during
the
secrets
session,
which
has
the
appropriate
scope
to
publish
a
package
in
that
repository.
B
So
you
don't
even
have
to
you
know,
set
up
your
organization
or
repository
secrets
or
something
like
that.
You
can
just
use
the
use
the
github
token,
and
that
is
what
we
see
on
the
right
hand
side
here.
So
this
is
a
workflow
file
that
listens
to
a
push
event
and
it
listens
to
push
events
on
the
branch
main.
There
was
a
question
slack
earlier
whether
you
can
actually
have
some
more
granular
control,
over
which
events
we
want
to
trigger
the
workflow
on
one
of
the
questions
was:
can
we
specify
this
to
a
specific
branch?
B
And
the
answer
is
yes,
as
you
see
here,
and
this
workflow
has
one
job
which
is
essentially
to
publish
to
the
github
package
registry,
we
see
that
it
runs
on
the
github
hoster
runner
on
the
ubuntu
latest,
and
it
contains
three
steps.
The
first
one
is
just
to
check
out
the
repository
and
the
next
two
are
to
actually
publish
the
package.
B
We
do
something
that
I
also
do
a
lot,
which
is
really
convenient
with
workflows
you
can,
since
the
github
hosted
runner
comes
with
a
lot
of
pre-configured
and
installed
software,
you
can
just
run
terminal
commands
directly
in
your
workflow
file.
So
in
this
case,
because
of
the
github
hoster
runner
coming
pre-installed
with
npm,
I
think
on
ubuntu
latest
is
npm
version
6.14,
or
something
like
that.
B
I
can
just
say
in
this
step
here:
run
npm,
publish
and
that's
it,
and
I
just
need
to
specify
which
token
I
want
to
use
to
authenticate
and
I
can
use
the
github
token,
and
this
will
successfully
publish
a
package
as
part
of
my
workflow
file.
So
it's
pretty
cool
stuff
and
it's
fairly
lightweight
and
it's
really
easy
to
to
get
started.
B
B
So
it's
not
necessarily
an
action,
but
if
your
source
code,
you
want
to
press
a
container
image,
how
do
you
do
that?
Well,
you
can
do
that
with
github
container
registry,
and
some
of
you
might
have
already
used
this
before
because
before
we
also
had
docker
support
in
github
packages,
but
this
has
now
been
separated
into
two
different
features.
Let's
say
so:
we
now
have
gita
packages
and
we
have
github
container
registry,
and
but
the
conception
is
the
same.
B
B
B
And
another
difference
with
github
packages
is
that
it
has
fine
grained
permissions
and
visibility.
That
means
that
you
can
actually
define
for
a
specific
container
who
should
get
access,
what
sort
of
access
should
they
have
just
read
or
write
access,
or
maybe
even
admin,
and
I
can
also
decide,
even
if
I
create
an
image
from
a
private
repository,
I
can
still
make
that
image
public.
B
Another
difference
it
does
require
a
personal
access
token.
You
cannot
use
the
github
token
to
to
build
and
publish
a
container
image,
unfortunately,
at
least
for
as
long
as
this
feature
is
in
public
beta,
but
there
might
be
changes
there
as
well,
so
so
we'll
see
once
it
gets
to
general
availability
and
before
we
move
on.
I
just
wanted
to
highlight
a
few
really
great
marketplace:
actions
you
can
use
to
build
and
publish
your
image
here.
B
We
use
two
actions
they're,
both
both
built
by
the
docker
organization
actually
and
the
first
one
is
just
for
logging
in
to
to
the
container
registry,
and
here
we
specify
the
url
and
our
username,
which
we
pull
from
the
workflow
context.
So
in
this
case,
when
we
trigger
the
workflow
that
workflow
has
access
to
certain
data
about
its
context
and
one
of
those
contexts
is
okay,
so
which
repository?
Am
I
running
this
workflow
in?
And
I
have
access
to
this
payload.
B
So
I
can
just
pull
using
this
syntax
here
with
the
dollar
sign
the
repository
owner.
So
I
want
to
log
into
ghdr
using
whoever
is
the
repository
owner,
which
in
this
case
would
be
myself
right
and
as
the
password
as
I
mentioned
before,
you
cannot
use
the
github
token.
So
I
have
set
up
a
repository
secret
called
cr
underscore
pat,
and
this
will
then
authenticate
me
to
gher,
and
the
next
thing
is
then
to
push
the
the
image,
and
here
I
use
another.
B
It's
quite
similar
to
the
packages
that
I
showed
before
just
a
few
few
of
the
same
metadata
here,
for
example,
the
code
snippet
about
how
to
to
pull
your
image,
the
name
of
the
image
and
also
the
list
of
the
different
versions
and,
on
the
right
hand,
side.
You
have
a
button
that
you
don't
have
for
gita
packages,
which
is
the
package
settings,
and
this
is
where
you
can
specify.
B
Okay,
so
that
was,
I
think,
a
lot
of
talking
on
my
side.
I
think
it's
time
to
maybe
show
some
of
these
features
that
we've
been
talking
about
for
github
packages.
So
what
I'm
going
to
do?
Next,
I'm
going
to
show
a
workflow
that
published
an
npm
package
and
same
for
a
container
image
and
we'll
talk
a
little
bit
more
about
that
all
right.
So
then,
I'm
gonna
change
my
screen
here
and
I
will
pull
up
oops.
B
I
think
I
think
that
would
also
depend
on
which
package
manager
you're
already
using
because
with
github,
for
example,
you
can
pull
a
package
so
there's
nothing
preventing
you
from
pushing
that
same
package
up
to
a
different
package
manager
in
this
case,
but
for,
for
example,
for
npm.
I'm
not
sure
about
that.
To
be
honest,
maybe
we're
gonna
have
to
look
back
on
that.
I
haven't
encountered
that
use
case
before
so
maybe
we'll
have
to
come
back
to
it
at
the
end
of
the
workshop.
Okay.
B
Yeah
I
I
will
mention
that
in
the
same
workflow
you
can
push
to
multiple
registries
right.
So
in
the
previous
workflow
that
I
showed
there
is
nothing
preventing
me
from
pushing
to
both
npm
js
and
to
github
packages
and
the
same
for
container
images.
I
can
put
push
to
both
github
and
to
docker
hub,
for
example.
B
B
All
right
so
with
that,
let's
have
a
quick
demo,
we'll
do
this
demo
and
then
we
will
move
on
to
the
hands-on
exercise.
I
guess
a
lot
of
you
want
to
kind
of
try
this
out
yourselves
as
well,
so
we
are
getting
there
hang
on
and
we'll
be
there
in
a
moment.
I
just
wanted
to
kind
of
show
a
yeah
kind
of
a
live
live
session
here
where
we
demonstrate
some
of
these
features,
and
I
just
want
to
get
a
thumbs
up.
First
from
one
of
my
moderators
that
you
see
in
my
chrome.
B
Looking
at
a
workflow
that
I
want
to
use
to
publish
an
npm
package,
the
way
I'm
going
to
do
that
is
to
first
I'm
just
going
to
click
on
this
action
tab
here.
Actually,
actually,
so
I
have
first
of
all
my
repository,
it's
behind
an
organization
that
I
call
step
actions,
packages
right,
but
feature-wise.
This
is
exactly
the
same,
whether
you
have
it
behind
your
organization
or
your
personal
account,
and
what
I
see
here
is
that
I
have
four
workflows.
B
Two
of
them
has
this
strange
symbol,
and
I
just
wanted
to
address
that
in
case.
Some
of
you
are
wondering
what
does
this
mean?
This
means
that
the
workflow
is
disabled
and
it's
maybe
just
something
to
point
out
that
if
you
have
a
lot
of
workflows-
and
you
see
like
one
day-
okay,
we
want
to
get
rid
of
this
workflow,
but
we're
not
really
sure
we
just
want
to
kind
of
pause
it
for
a
moment.
B
You
can
do
that
by
simply
disabling
this
workflow
and
that
will
essentially
suspend
it,
so
it
will
no
longer
trigger
it,
and
you
can
also
re-enable
that
workflow
at
any
time
right.
So
that's
what
you
see
here
for
this
suspended
workflow,
that
I
can
just
enable
this
one
again,
once
I
decide
that
I
need
to
use
it,
so
we
have
one
workflow
called
publish
to
gpr.
B
B
So,
let's
have
a
quick
look.
First
of
all,
it
has
a
name
publish
to
gpr
and
it
reacts
on
push
events
to
my
main
branch
and,
additionally,
you
can
add
some
more
granularity
to
the
trigger.
So
in
this
case
I
just
want
to
trigger
this
workflow
if
there
is
a
push
to
or
a
change
to
a
file
package.json
right.
So
this
essentially
means
hey.
B
I
just
wanna,
I
don't
wanna
publish
a
new
package
unless
there
are
actually
any
changes
to
my
node
project
file,
which
is
my
package.json
and
then
I
have
one
job
which
is
to
publish,
runs
on
a
github
poster
runner.
It
checks
out
the
repository
sets
up
my
environment
with
node
version
12,
and
it
specifies
to
our
url
that
I
want
to
publish
to.
B
Then
it
runs
a
few
commands
right.
So
we
talked
about
earlier,
you
can
run
commands
directly
in
your
workflow
file.
This
runner
comes
pre-installed
with
npm,
so
I
can
just
run.
Npmci
npm
run
build
which
will
run
a
build
script,
which
I
define
in
my
package.json
file.
If
I
have
a
script
present
and
then
lastly
publish-
and
I
authenticate
using
my
github
token.
B
So
if
I
now
go
back
to
my
code
and
just
have
a
quick
look
at
my
package.json
file,
I
just
wanted
to
show
a
few
metadata
points
that
are
important
to
highlight
so
in
package.json.
That
is,
I
mean
if
you
do
java,
for
example,
you
might
use.
This
would
be
your
maybe
your
palm
xml
file
or
if
you
use
ruby
with
the
ruby,
gems
and
so
on.
I
know
that
now
then
npm
is
getting
all
the
love
today,
but
but
javascript
is
the
most
popular
language
on
github,
at
least
according
to
the
latest
report.
B
So
chances
are
a
lot
of
you
have
already
seen
this
before,
but
anyways
in
package.json.
We
see
our
name,
and
here
we
need
to
specify
who
is
the
owner
of
this
package
and
which
repository
do
I
want
to
publish
this
package
to
and,
of
course
we
have
a
version,
and
these
two
metadata
points
are
used
by
gita
packages
to
actually
publish
it
right
and
we
see
have
one
dependency
already
and
some
other
data
like
the
repository,
url
and
so
forth,
all
right.
B
B
This
is
a
fairly
simple,
simple
code
snippet
in
javascript
granted,
but
so
it
might
not
make
it
to
the
to
the
top
spot
of
gita
packages
in
terms
of
downloads,
but
let's
go
ahead
and
make
a
change
anyways,
because
I
just
wanna,
I
just
wanna
trigger
a
new
package.
So
what
I'm
going
to
do?
I
think
this
the
exclamation
mark
is
a
bit
too
aggressive.
So
I
add
some
points
there
instead,
which
then
highlights
that
I
have
a
change
here
and
I
will
stage
and
commit
that
change.
B
B
I
will
sign
it
I'll,
give
it
a
message-
and
I
will
just
say:
improve
code
comment
right,
okay,
so
that
is
committed,
and
then
I
also
need
to
update
my
package.json
file.
So
here
I
just
want
to
use
an
npm
command
as
well,
which
is
called
npm
version,
because
it
will
update
the
version
and
it
will
also
commit
that
change
by
default.
B
B
A
B
I
have
a
a
new
workflow
that
was
pretty
good.
Rovano
mentioned
this
by
the
way,
with
the
visualization
of
the
workflow.
Now
I
just
have
one
job,
so
you
only
see
one
box,
so
it
might
not
be
super
interesting,
but
if
you
had
a
more
complex
workflow,
you
would
see
those
tied
up
in
a
chain
here
all
right.
So
that's
that
succeeded.
B
As
you
can
see
here,
it
ran
all
of
the
scripts
and
it
published
my
package.
So
that
means,
if
I
go
back
to
my
call
tab
here,
I
can
see
that
I
have
a
package
link
in
my
on
my
right
hand,
side
and
if
I
click
on
that,
I
already
had
previous
versions
of
this
package.
But
now
I
publish
a
new
version,
so
I
won't
see
a
new
package,
but
I
would
just
see
okay.
B
I
can
look
at
all
of
the
metadata
here,
which
I
showed
you
in
the
slide
as
well.
I
can
see
the
the
readme,
which
has
automatically
been
added
as
a
description,
but
I
don't
really
like
that
description.
For
example,
it
has
some
relative
links
to
images
and
so
on
that
are
not
really
good.
So
I'm
just
going
to
delete
that
and
I
also
don't
need
to
include
the
the
badges
right.
So
I
just
preview
that
and
okay
good
enough.
B
B
B
I
want
to
actually
install
my
package
and
make
use
of
it,
so
I'm
going
to
do
in
this
folder
here,
I'm
just
going
to
initiate
a
new
node
project
with
all
of
the
defaults,
which
makes
a
package.json
file
pop
up
here,
good
stuff,
and
then
I'm
going
to
install
that
package
as
a
dependency
right.
So
now
this
one
is
is
basically
empty,
but
I
go
back
here.
I
go
to
my
package.
B
Wait
for
a
moment
all
right
cool.
So
now
we
see
in
the
dependencies
field.
Here
we
added
our
package
as
a
dependency,
so
I
now
have
access
to
reuse
the
codes
that
I
have
available
there
all
right.
So
the
next
thing
we're
going
to
do
is
to
just
create
a
very
simple
javascript
file
that
we
call
index.js.
B
B
Me
equals
require
and
which
okay
thank
you
intellisense.
It
added
that
for
me
right,
so
I
added
that
now
in
my
code
base
and
then
I
want
to
check
if
it
actually
works
right.
So
if
I
went
back
here
to
this
code,
it's
basically
just
like
outputting,
something
to
be
my
console
and
I
need
to
feed
it
one
variable
which
is
just
a
text,
a
string.
Basically,
so
let's
do
this.
Let's
just
do
print
me
and
I
want
to
ask:
does
this
work
cool
then
I
will
run
that
code.
B
B
If
I
go
back
to
my
repository
here,
I
also
had
a
second
workflow,
which
was
called
publish
to
github
container
registry,
and
this
one
is
a
little
bit
different.
This
won't
take
as
much
time.
I
will
just
show
you
the
workflow
file
and
we
will
trigger
this
workflow
as
well.
To
show
you
how
easy
it
is
to
to
publish
a
new
image
the
trigger
for
this
one
is
a
bit
different.
It
listens
for
a
release,
event
of
type
publish
means.
B
In
order
to
trigger
this
workflow,
I
need
to
create
the
release
and
publish
that
release,
and
then
it
will
trigger
one
job
and
they
also
run
some
github
hosted
runner
check
out
my
repo.
I
run
a
few
scripts
here
as
well.
This
is
basically
to
determine
which
tags
to
add
version
and
these
sort
of
things,
and
then
I
run
a
few
other
actions
by
docker
like
keemu,
for
setting
up
like
machine
emulators.
B
If
you,
if
you're,
already
familiar
with
that
build
x
as
well,
which
is
another
tool
that
can
be
added
on
top
of
docker,
and
then
we
use
the
same
two
actions
that
we
had
in
the
slides.
First,
one
is
to
login
using
a
personal
access
token,
which
I
already
have
available
and
we
build
and
push
that
same
action
right.
So
if
I
trigger
this
one
now,
which
should
be
as
simple
as
just
creating
a
release,
I
should
be
able
to
find
my
new
image.
B
I
will
create
the
tag
and
which
one
was
the
latest
one
that
we
created
was
one
for
one
right,
so
I
will
just
say
an
awesome
release
and
then
describe
this
release.
This
also
takes
you
know
you
can
add
images
in
here
as
well.
I
think
I
have
an
image
in
this
repository
actually,
which
is
called
demo
gods.
Does
that
work?
Okay?
B
Okay,
that's
not
that
it!
So
then
I
would
just
add
a
rocket
here
for
now
and
yeah
that's
publish!
Let
me
check
if
that
workflow
is
kicking
off
all
right,
so
something
is
running.
This
will
probably
take
a
bit
longer,
but
it's
fairly
quick.
In
the
meantime,
we
can
look
at
the
logs
and
just
briefly
summarize
as
well
what
we
have
what
we
have
done
during
this
demo,
so
basically,
what
you
will
notice
by
the
way,
stop
this
from
jumping
around.
B
What
we
have
noticed
is
that
I've
done
all
of
these
things
without
leaving
the
github
my
github
environment
right.
So
speaking
of
context,
switching
that
was
mentioned
earlier.
I
can
do
all
of
these
things
without
you
know
invoking
external
cool
tools
or
when
you're
logging
in
with
other
credentials,
doing
any
manual
sort
of
labor
so
to
speak.
B
B
If
I
go
back
to
my
code,
I
won't
see
this
one
in
my
repository
now,
because
I
defined
the
organization
as
the
owner
of
this
image.
So
that
means
that,
in
order
to
access
this
image,
I
go
back
to
my
organization
and
then
we
also
have
a
packages
tab
here,
which
is
called
universe
docker
right.
So
this
is
the
latest
version
of
of
my
image
and
we
saw
that
we
created
a
release
from
a
existing
tag
that
we
created
when
we
created
a
node
package.
B
B
Now
I
have
this
screen
might
be
familiar
to
you
if
you
already
use
repositories
and
you
used
to
like
managing
users
who
get
access
and
which
kind
of
access
I
can
just
do
the
same
for
images.
So
if
I
wanted
to-
and
my
colleague
here
ravenna
I
can
do
that.
So
I
add
her
now
she
has
access
to
this
image
and
I
don't
want
to
do
just
that.
Read
access.
She
should
have
write
access.
I
can.
I
can
also
do
the
same
for
teams
right,
so
I
think
I
have
a
team
called
devs.
B
B
You
can
also
make
it
public,
even
if
this
was
published
from
a
private
repository.
So
I
can
just
click
on
make
public
here
and
it
works
the
same
way
as
with
a
repository,
basically
right
and
as
with
packages,
you
can
manage
your
versions,
so
I
can
go
in
here.
I
can
delete
the
specific
version
and
so
forth.
B
All
right
cool
stuff,
I'm
just
thinking
about
whether
I've
missed
anything
here,
but
I
think
I
covered
most
of
it.
So
what
I'm
going
to
do
now
is
to
just
finalize
the
packages
section
with
this
last
slide,
and
I
just
want
to
highlight
a
few
things
about
the
packages.
Why
would
you
use
it
if
you
already
have
a
package
manager,
it
works
for
you,
you
don't
have
a
reason
to
switch
well.
B
There
are
certain
benefits
that
at
least
I
have
experienced
by
having
everything
behind
the
same
account
and
a
lot
of
our
customers
as
well
have
also
experienced
the
same
benefit.
It's
just
less
overhead
and
less
like
management
in
terms
of
you
know,
spending
time
on
managing
different
credentials
and
so
forth,
and
it
also
eases
the
sharing
of
the
code
you're
already
used
to
sharing
your
code
in
in
internally
and
externally.
B
If
you,
whether
you
do
like
an
inner
source
project
or
an
open
source
project-
and
this
is
you
know-
you
can
use
the
same-
github
features
as
you're
already
used
to
you're,
just
kind
of
extending
it
to
also
include
your
your
packaged
software
and,
lastly,
the
integration
with
github
actions.
Of
course,
it's
very
easy
to
get
started.
You
can
use
one
of
the
startup
workflows,
so
just
build
your
own
and
you
can
get
going
in
a
very
short
amount
of
time.
B
Okay,
so
that's
a
quite
a
big
chunk
of
info.
I
think
I
think
to
tie
it
all
together.
We
would
want
to
get
our
hands
dirty
and
build
something
right.
We
like
to
build
stuff
and
for
this
workshop,
we're
also
going
to
build
our
own
workflow
and
what
we're
going
to
do
is
to
build
a
ci
workflow
and
we
are
going
to
build
a
second
workflow
that
package
and
release
our
code
we'll
be
guiding
you
through
this
I'll,
be
going
through
each
step
and
we'll
at
the
end
of
it.
B
B
On
that
event,
it's
going
to
run
some
ci
tests
across
multiple
node
versions.
Ruben
I
mentioned
you
can
use
build
matrices
in
your
workflow
file.
So
that
is
what
we're
going
to
do.
It's
also
going
to
auto
label
your
pull
request,
and
it's
going
to
give
some.
You
know
some
commenting,
some
output
to
the
user
as
well
like
hey.
B
Maybe
you
want
to
merge
this
pull
request,
then
we're
going
to
merge
it,
which
is
going
to
trigger
our
second
workflow,
which
would
say
take
that
code
that
we
that
we
put
in
our
repository
package,
it
publish
it
with
npm,
and
then
it
will
also
create
a
release
where
we're
going
to
add
a
configuration
file.
That
kind
of
you
know
automatically
drafts
your
release,
notes,
which
is
one
of
my
favorites
as
well.
When
it
comes
to
actions
you
know
we
mentioned
earlier.
B
B
B
A
B
B
B
If
you
have
any
issues
during
this
hands-on
exercise,
please
you
know
give
us
a
shout
out
in
slack
or
something
like
that
and
we'll
try
to
get
you
as
fast
as
you
can.
We
also
have
our
moderators
here
being
able
to
jump
in
and
so
on.
So
if
you,
you
know,
if
you
see
something
is
going
too
fast
or
you
know,
you
have
some
issues
just
just
drop
that
in
the
chat
and
it
we'll
help
you
out
okay.
So
this
is
the
same
image
as
I've
showed
before
so.
B
The
first
thing
we're
gonna
do
now
is
to
create
our
ci
workflow.
So
I
have
already
logged
into
my
github
account,
which
you
can
see
here
and
what
we're
gonna
do.
First
is
to
simply
create
a
new
repository,
so
you
can
go
to
your
profile
here
your
repositories
and
then
you
will
have
this
new
button.
So,
let's
do
that
you
can
use
the
you
know,
suggested
name
or
you
can
give
it
your
own
name,
just
call
it
yeah
universe,
automation,
just
nice
and
simple,
give
it
a
description.
B
B
All
righty,
so
we
have
a
repo.
So,
let's,
let's
start
digging
in
before,
we
do
that.
Just
I
wanna
I
wanna
just
mention
that
we
will
be
doing
a
few
naughty
tricks
like
committing
directly
to
our
main
branches.
So
forth,
don't
worry
about
that!
You
know
if
you
later
on.
Of
course
you
you
might
want
to
set
up
different
branches
and
so
on
to
to
collaborate
on
your
code,
but
for
this
demo
to
keep
it
as
simple
as
possible
and
make
sure
that
everything
is
working,
fine
and
so
on.
B
We're
just
gonna
be
committing
some
things
to
our
main
branch.
If
your
main
branch
or
your
default
branch
is
not
called
main,
then
you
know
you
don't
have
to
change
it.
You
would
just
have
to
keep
that
in
mind
for
later
on.
Whenever
you
have
to
specify
a
branch
name,
you
would
just
need
to
make
sure
that
you,
you
specify
the
name
of
your
default
branch.
B
All
right
so
we're
just
gonna:
do
everything
in
a
gui
right,
I'm
not
gonna,
do
any
terminal
commands
or
something
if
you
feel
super
comfortable,
doing
everything
in
the
terminal
using
git
operations
and
npm,
and
these
sort
of
things
feel
free
to
do
that,
but
we're
not
going
to
jump
back
and
forth
between
the
terminal
during
the
demo.
So
just
make
sure
that
you
yeah
that
you
have
a
good
handle
on.
You
know
how
to
pull
and
push
and
create
new
branches
and
so
on.
But
you
don't
need
to
use
the
terminal.
B
You
can
do
everything
in
the
gui
here,
so
that
is
actually
the
the
first
point
there
in
the
instructions.
If
you
want
to,
if
you
have
node
installed,
you
can
run
these
commands
to
do
this
locally
on
your
machine,
but
for
the
purpose
of
this
demo
I
would
just
follow
the
gui
instructions
here.
So
we'll
jump
right
to
this
point.
B
B
And
then
we
have
also
added
some
content
here
for
you
to
copy
and
we're
going
to
make
some
changes
to
it
afterwards.
But
please
make
sure
you
you
copy
this
entire
text
over
to
your
new
package.json
file
and
after
you
copy
in
case
you,
you
know,
touch
something
on
keyboard
or
something
and
wondering
if
you
have
a
syntax
error,
you
can
click
on
preview
because
it
will
highlight
in
case
you
have
a
syntax
error.
B
You
should
get
like
a
little
or
something
like
that,
but
it
should
look
like
this
and
we
have
to
make
a
few
changes.
So
the
first
thing
is
to
replace
the
owner
placeholder
with
our
github
handle
or
your
organization
name.
You
might
have
created
a
repository
in
an
organization
and
not
behind
your
user
account.
So
in
that
case
you
will
have
to
insert
the
organization
name
and
the
repository
name
here.
The
easiest
way
to
do
this
is
probably
to
use
whatever
is
in
your
url
here.
So
I
will
take.
B
I
will
update
that.
Make
sure
that
you
keep
the
admission.
This
name
attribute
this:
how
github
determines
where
to
push
the
package?
So
if
you
don't
have
the
ad
mention
your
published
job
later
on
will
probably
fail
all
right
I'll
do
the
same
for
the
others
here
as
well.
We
have
three
more
placeholders,
so
I
would
just
replace
this
yeah
a
url
for
for
bugs
and
then
the
home
page
as
well,
so
I'll
just
use
that
same
same
string
and
just
to
make
sure
that
I
don't
have
any
errors.
B
B
B
A
B
Great
good
stuff,
so
the
next
thing
we're
gonna
do
is
to
create
our
source
code.
This
is
going
to
be.
You
know,
if
possible,
an
even
simpler
example
of
a
javascript
code,
but
let's
do
it.
We
create
that
on
the
root
of
our
repository,
we
call
it
index.js,
and
you
know
if
you're
comfortable
with
javascript,
you
can
put
whatever
you
want
in
here.
Just
make
sure
that
you
don't
have
any
syntax
errors
since
we're
doing
this
in
the
in
the
gui.
B
So
for
now
I'm
just
gonna
add
a
console.log,
and
I
will
commit
this
again
to
the
main
branch,
all
right.
So
at
this
point
you
should
have
two
files
right.
You
should
have
index.js
and
package.json,
and
once
we've
done
that
now
we
get
to
you
know
the
the
fun
part
so
to
speak,
because
we
are
going
to
add
some
workflows
more
specifically.
In
the
first
instance
now
we
will
add
one
workflow,
which
is
our
ci
and
we
will
start
off
by
creating
an
empty
file
called
ci.yamo.
B
So
I
will
click
again
add
file,
and
if
you
haven't
used
the
gui
before
to
create
files
in
github,
you
can
add
new
directories
by
simply
using
the
forward.
Slash
so
like
that
right.
So
the
the
final
path
should
be
dot.
Github,
don't
forget
the
dot.
By
the
way
it
has
to
be
dot.
Github,
workflows,
forward,
slash.
B
A
B
B
And
now
we're
going
to
add
the
actual
workflow
syntax
right
and
we
have
done
you
a
bit
of
a
favor
and
added
the
content
here
right.
So
if
you're
in
this
repository,
you
expand
this
part
here,
you
should
be
able
to
see
what
I'm
seeing
now
and
we
are
simply
going
to
copy
this
over.
For
now,
we
will
make
some
changes
as
well,
but
this
is
the
this.
B
Is
the
base
base
workflow,
so
I
copy
I
make
sure
I
select
everything
and
I
add
that
to
my
ci
dot,
yammer
file
right
and
one
thing
to
mention
that
I
added
to
the
instructions
as
well
is
that
if
you
know
yama
syntax,
it
relies
on
indentation
right.
So
you
have
to
make
sure
that
you
copy
it
over,
as
is
and
that
you
don't
change
the
indentation,
for
example
like
this,
because
then
it
will
not
work
and
you
will
even
get
a
syntax
highlighting
like
an
android
like
you
see
on
my
screen
here.
B
If
you
do
that,
so
I'll
put
that
back
all
right,
so
we
will
update
the
name
and
I
would
just
call
it
ci
actually,
and
then
we
have
a
look
at
what
else
is
here.
We
have
a
few
jobs.
The
first
job
is
the
build
job
which
runs
on
the
github
hoster
runner,
and
this
is
how
we
define
a
build
matrix
in
github
actions.
We
can
say
strategy
matrix
node
version,
and
in
this
case
I
want
to
build
my
code
for
two
different
node
versions,
12
and
14..
B
I
could
also
build
for
different
operating
systems
as
well,
that
I
combine
with
different
node
versions
and
if
you
look
at
the
workflow
syntax,
the
help
documentation,
you
will
see
how
this
fits
together
and
how
you
know
you
can
use
this
in
your
own
workflow
as
well.
There's
quite
a
lot
of
options
in
there
too.
B
That
offer
this
flexibility
all
right.
So
this
job
has
a
few
steps
checks
out
the
codes.
It
builds
the
my
node
environment,
using
the
matrix
that
I
defined
above
here
then
it
runs
a
few
commands.
Npm
install.
It
runs,
build
and
mtm
test
right
and,
if
you
use
node,
you
might
be
familiar
with
this
already.
B
So
now
that
we
have
built
our
code,
we
want
to
label
a
pull
request
and
if
you
look
here,
one
of
the
parameters
is
needs
build,
and
this
is
quite
nice
because
you
can
actually
define
relationships
and
dependencies
between
jobs
in
your
workflow.
So
in
this
case,
what
this
means
is
that
I
don't
want
to
run
the
label
job
unless
the
build
job,
which
is
this
one.
B
This
one
also
has
a
few
steps,
checks
out
the
code,
and
then
it
uses
a
very
nice
community
action
which
is
called
github
script,
and
what
github
script
does
is
that
it
essentially
allows
you
to
interact
with
the
github
api
directly
in
your
workflow
file.
So
I
don't
have
to
create.
You
know
like
a
separate
piece
of
code
that
runs
a
curl
command,
or
something
like
that
I
can
just.
I
can
just
do
a
lot
of
the
things
that
I
need
to
do
directly
in
the
workflow
file.
B
B
If
this
label
doesn't
already
exist
by
the
way
it
will
be
created
automatically
and
then
the
last
job
is
to
actually
comment.
So
we
want
to
say
something
to
the
user
right.
So
a
lot
of
this
is
the
same.
We
also
define
a
relationship
here,
so
this
one
will
only
trigger
if
build
and
label
succeeds,
and
it
also
has
a
few
steps.
It
uses
the
same
action
authenticates
for
the
github
token
and
it
doesn't
add
a
label,
but
it
creates
a
comment.
B
So
here
I
can
just
say
like
yeah,
I
passed
the
issue
number
owner
and
the
repo,
and
what
is
the
body
of
my
message?
So
in
this
case
I
say
great
job,
whoever
this
is.
This
will
be
me
right
because
I
am
the
logged
in
user
and
I
define
some
static
text
here
and
you're
you're.
You
know
welcome
to
edit
this.
If
you
want
just
make
sure
that
you
persist
the
backticks
here
right.
B
B
And
that's
done
so
afterwards
we're
going
to
test
it,
but
first,
let's
just
do
a
few.
You
know
quiz
like
questions
here.
First
of
all,
how
many
jobs
are
there?
In
the
workflow
we
saw
that
we
had
three
jobs
right,
that
we
added
we
had
the
build
label
and
comment
job
and
the
event
that
triggers
this
workflow
is
a
pull
request.
Right,
like
we
see
here
and
the
last
one,
does
this
work
for
user
build
matrix?
Yes,
it
does.
B
We
define
that
in
in
this
area
right
here,
all
right,
so,
let's,
let's
try
and
test
it.
I
hope
that
everyone
on
the
call
are
following
along
and
so
forth.
I
don't
see
a
lot
of
activity,
at
least
not
in
slack,
but
it
looks
like
people
are
following
along
so
great
job
on
that,
because
now
we're
going
to
test
it
right
and
we
need
to
trigger
it
and
by
to
do.
C
B
So
let's
do
that.
We'll
also
create
the
pull
request
directly
from
the
gui,
and
I
would
just
create
the
simple
one
because
it
doesn't
matter
you
know
which
file
I
changed
or
something.
So
I'm
just
going
to
change
the
readme
file.
Here,
I'm
going
to
click
edit
and
I
will
say
this
trigger
my
ci
and
then
I
will
not
commit
to
main.
But
I
will
commit
to
a
new
branch
that
I
call
update,
readme
right.
B
B
All
righty,
so
now
we
have
our
pull
request
and
in
a
moment
I
should
see
this
gui
being
updated.
Yes,
okay,
there
we
go,
and
you
should
see
the
same
in
your
pull
request.
You
should
see
these
two
build
jobs
popping
up.
Why
are
there
two,
of
course,
because
we
defined
a
build
matrix
for
two
separate
node
versions?
B
A
B
A
Cool
visual
right
now,
it's
it's
really
nice
to
look
at
yeah
feel
free
to
keep
the
questions
coming.
Maybe
it
might
be
hard
for
you
to
type
a
question
and
also
look
at
stefan,
so
we're
going
to
pause
here
a
little
bit
just
to
give
you
an
opportunity
to
ask
questions,
feel
free
to
give
feedback
too
we're
open
to
that
all
the
time.
A
B
B
B
So
if
your
workflow
failed
for
some
reason,
so
if
you
have
any
red
crosses
showing
up
here,
anything
that
indicates
that
something
is
wrong.
You
know
drop
something
in
the
chat.
Please
add
a
screenshot
or
something
as
well,
so
that
we're
able
to
help
you
out,
but
for
now
we'll
we'll
continue
as
well,
and
our
moderators
will
support
you
in
case.
You
have
any
issues
all
right,
so
we
will
not
merge
this
pull
request
yet
all
right.
B
B
B
B
B
So
here
we
have
our
second
workflow
right.
So
this
is
the
main
workflow
file,
and
what
this
workflow
will
do
is
to
publish
and
release
a
package.
It
listens
to
one
event
which
is
push,
but
only
if
the
push
event
happens
on
a
branch
called
main.
So
this
is
why
I
mentioned
earlier.
If
your
default
branch
is
called
something
else
than
main,
then
you
need
to
update
that
name
here
to
if
it's
still
called
master,
for
example,
by
default
in
github.
B
Now
all
new
default
branches
are
set
to
main
default
branch
names
are
set
to
main,
but
if
you
have
something
else,
make
sure
you
reuse
that
name
here.
So
this
one
also
has
a
couple
of
jobs.
First,
one
is
the
update
they
release
draft
and
this
one
will
essentially
reuse
an
action
called
release.
Drafter.
B
We
have
a
link
here
as
well
in
the
instructions
where
you
can
have
a
look
at
the
description,
how
this
actually
works.
We
use
this
as
well
in
github.
I
have
used
it
before
as
well
with
customers
and
so
forth.
It's
it's
very
powerful
actually
in
terms
of
its
configuration
options,
and
it
saves
you
a
lot
of
work
when
it
comes
to
like
setting
up
new
draft
releases
and
these
sort
of
things.
B
B
B
And
then
the
demo
before
sets
up
our
node
environment
and
then
publish
the
package
so
great,
and
then
I
have
actually
selected
the
wrong
branch.
I
see
so
what
I
can
do,
if
you're
in
the
same
position
as
me,
where
you
can
no
longer
choose
which
branch
to
commit
to,
because
I
want
to
commit
to
the
same
branch
that
I
created
earlier,
the
update
readme
branch
right.
So
I
would
just
copy
this
for
now,
without
confusing
everybody,
I
will
go
back
to
my
codes.
B
B
B
B
There
all
righty,
so
we
now
have
a
compli
file.
You
don't
actually
have
to
change
anything.
I
mean
if
you
know,
markdown
syntax.
You
can
add
some
subtitles
and
stuff
like
that,
but
I
would
recommend,
for
the
purposes
of
this,
just
quick
demo
to
to
leave
it
as
it
is,
and
I
will
also
commit
this
to
the
update
readme
branch.
So
I
commit
that.
A
B
Yeah
yeah,
thank
you
yeah,
that's
a
that's
a
good
point
as
well.
They
can
you
can
make
it
more
minimalistic.
Let's
say
if
you
want
to
write
all
right,
so
we
have
now
actually
set
up
our
workflows.
I
also
see
that,
because
I
I
pushed
here
to
this
to
this
pull
request,
I'm
running
my
ci
again,
which
is
you
know,
probably
what
should
happen
right
if
you
have
a
ci
workflow,
but
I
will
wait
until
this
has
completed
and
then
I
will
merge
it
back
on
to
my
main
branch.
B
So
now
I'm
going
to
update
readme
branch,
I'm
in
my
pull
request
and
let's
merge
this,
and
this
should
trigger
the
release
drafter
and
after
this
action
is
done,
you
don't
have
to
delete
the
branch,
but
I
think
it's
good
practice,
so
let's
delete
it
just
for
some
house
cleaning
and
now,
if
I
go
to
my
actions
tab
here,
I
should
see
another
workflow.
That's
my
publish
and
release
workflow
right
now.
Go
to
that.
B
You
can
now
see,
since
we
have
more
jobs
here,
you
can,
you
know,
see
how
this
visualization
works
as
well,
and
once
this
is
done,
I
should
see
a
few
things
happen
in
my
repository.
The
first
thing
is
that
I
should
have
a
package
that
is
released,
and
the
second
thing
is
that
I
should
see
the
release
draft
and
this
release
draft
should
be
formatted
according
to
my
config
file.
B
B
B
All
right,
so
this
one
should
be
fairly
quick.
It's
not
a
lot
of
source
code
to
publish
so
there
we
go
completed
in
in
a
few
seconds:
okay,
great
stuff,
all
green
again,
I
think
we're
on
a
roll.
So
we
go
back
to
our
repository
right
and
then
we
see
on
the
right
hand,
side
hey.
We
have
a
package
there
you
go
and
then
you
can
see
exactly
the
same.
As
I
showed
you
earlier
in
the
demo,
you
can
navigate
here.
You
can
manage
the
versions.
B
Now
you
just
have
one
version,
but
but
yeah
it
looks
like
that
went
really
well
and
when
it
comes
to
the
releases,
you
also
have
that
on
the
right
hand,
side
right
but
don't
be
worried.
Since
it's
only
a
draft
release,
it
doesn't
show
up.
In
this
overview,
you
have
to
click
on
the
release
link
and
then
I
can
see
here
a
few
things.
I
have
a
draft
which
has
a
headline.
B
You
did
it
great
stuff
and
I
can
also
list
all
of
the
changes
included
in
that
release,
which
essentially
means
all
of
the
pull
requests.
So
if
I,
this
one
is
automatically
adding
a
list
of
bullets
with
a
link
to
my
pull
request
right,
so
this
is
really
useful,
especially
in
larger
projects
in
open
source
projects
or
whatever
it
might
be.
To
always
have
that
coherent
release,
notes
right
and
you
can
do
all
kinds
of
stuff
with
this
as
well
like.
B
If
you
have
very
well
formatted,
commit
messages
and
pull
request
names,
you
can
essentially
just
have
a
full-fledged
release
with
the
notes
without
doing
almost
any
of
the
overhead.
You
don't
have
to
do
any
manual
typing
and
stuff
like
that,
so
this
is
really
something
that
saves
time
for
the
team
yeah.
That
was
just
the
link
to
the
pull
request,
which
I
merged
awesome
all
right.
That
was
actually
the
end
of
it.
B
I
am
conscious
of
the
time
as
well,
and
we
do
just
have
a
couple
more
things
that
we
want
to
mention
before
we
wrap
up
and
address
any
questions
that
might
be
left
later
on.
You
can
have
a
look
at
this
additional
exercise
by
the
way.
There
are
a
few
configuration
options
in
the
config
file
to
you
know,
define
your
release.
Drafts
any
way
you
want
so
have
a
look
at
that
later
as
well.
If
you,
if
you
would
like
to
work
more
with
it,.
B
B
A
So
let
me
show
you
screen
again
yeah,
so
just
a
quick
summary
of
what
we
have
to
achieve
today.
We
saved
some
time
and
talked
about
how
automating
can
help
reduce
the
risk
of
human
error
and,
just
generally
just
make
your
life
a
lot
easier.
We
talked
about
how
workflows
are
triggered
by
events.
We
walked
through
the
all
the
components
of
github
actions
and
don't
forget
to
leverage
the
work.
That's
already
been
done
by
the
community.
Again,
github
is
known
for
its
open
source.
Community.
Definitely
use
that
to
your
advantage.
A
Why
build
something?
That's
already
been
built
by
someone
else?
We
talked
about
using
secrets,
and
finally,
we
talked
about
github
packages
and
how
you
can
publish
your
code
with
github
packages,
and
so,
if
you're
curious
about
what's
up
and
coming
for
the
next
steps
for
all
these
features,
we
have
the
public
roadmap
that
you
can
definitely
go
and
check
it
out.
The
link
is
in
here
and
don't
worry,
the
slides
will
be
shared
with
you
after
the
call
as
well
and
so
you'll
be
able
to
click
in
onto
other
slides.
A
We
also
have
a
change
log
that
we
keep
track
of
all
the
changes
that
has
happened.
So,
if
you're
curious
about
what
kind
of
changes
have
arrived
to
github,
you
can
go
and
check
out
the
blog
as
well.
So
with
that
we'll
wrap
this
up,
I
definitely
want
to
thank
all
the
moderators
we
have
on
the
call
they
are
also
our
mentors.
So
thank
you
so
much
thomas
thiago,
evgeny
and
stowe.
Thank
you
so
much
for
your
help.
A
C
Yeah
there
are
a
couple
questions
in
slack
right
now
that
I
guess
we
can
answer
live.
Maybe
instead
here,
so
one
came
from
tio.
It
says.
First
of
all,
this
was
a
great
session,
so
thanks
and
then
I'm
wondering
about
the
privacy
of
packages
within
an
organization
that
has
teams.
So
if
a
team
wants
to
have
a
secret
npm
package,
are
they
able
to
do
that?
If
so,
how.
B
C
B
B
Yeah,
it
depends
on
the
organization
setup
because
what
you
do
essentially,
if
you
have
read
access
to
a
repository,
you
can
also
pull
the
package
right.
So
if
you
have
an
organization,
then
definitely
it
ties
back
into
your
permission
structure
within
the
organization
itself.
So
if
you
want
the
secret
secrets
package
that
nobody
knows
about,
then
yeah
you
would
have
to
kind
of
marry
that
up
to
your
permission,
structure
in
your
organization,
it
is
possible
for
sure
but
yeah.
There
are
just
multiple
things
to
take
into.
C
C
Okay,
edward
asked
I'm
curious
about
the
management
of
non-regression
tests
and
their
results
looks
like
I'm
gonna
be
starting
to
ask
some
clarifying
questions
there.
But
if
we're
talking
about
like
unit
testing,
maybe
performance
testing
like
things
that
aren't
just
checking
your
your
sanity
checks
for
regression
or
your
smoke
test
for
that.
B
B
Things
like
that,
and
essentially
you
can
do
a
lot
of
these
things
with
github
actions,
but
it
is
a
little
bit
dependent
on
the
context,
because
if
you
have
done
performance,
testing,
load,
load
and
performance
testing,
for
example,
in
enterprise
grade
software,
is
not
a
trivial
task
right.
So
if
you
want
to
kind
of
migrate
from
whatever
you're
having
today
into
action
actions,
then
it
does
require
some
architecting
and
some
fault.
But
if
your
tool
has
an
api
that
can
interact
with
actions,
then
yeah
you,
you
could
do
it.
B
I
haven't
seen
too
many
publicly
available
actions
that
are
kind
of,
like
you
know,
specific
for
non-regression
or
performance
testing
or
stuff
like
that,
but
I
think
there
will
be
more
and
more
of
it
coming
up
in
the
future.
At
the
moment
we
have
like
six
thousand
six
thousand
actions
on
the
marketplace
and
it's
only
growing
so
keep
an
eye
on
it.
C
Awesome,
thank
you.
I
think
another
good
one.
It
was
answered
in
the
chat,
but
I
think
it's
important
to
call
it
out.
So
if
a
workflow
fails
in
the
middle
of
a
run
and
has
already
tagged
the
repo
in
previous
steps,
for
example,
is
it
going
to
converge
when
I
rerun
the
workflow
and
how
does
that
work?
C
B
That's
correct
yeah,
it
is.
It
is
a
good
point,
though,
to
bring
up
because
exception
handling
in
actions
is
actually
I
mean
it's
a
real
thing
right.
So
if
you
it's
one
of
the
one
of
the
the
aspects
that
should
be
taken
into
account
when
you
are
building
your
workflow
files,
I
have
had
this
experience
with
some
customers
as
well,
that
you
start
to
build
an
action
and
just
for
the
convenience
of
it
to
kind
of
you
know,
start
doing
everything
in
your
javascript
action
and
suddenly
you
have
kind
of
like
this
bloated
action.
B
That
does
a
lot
of
different
things,
but
it
makes
the
exception
handling
and
the
debugging
more
complex
in
the
end.
So
in
terms
of
exception,
handling
is
a
lot
cleaner
to
have
these
different
actions
that
have
that
can
exit
with
different
states
right
and
you
can
react
on
these
states
as
well,
so
that
you
don't
have
like
the
whole
thing
triggering
performing.
A
lot
of
you
know
operations
on
your
repository,
adding
teams
all
the
things
that
you
can
do
with
actions
without
having
like
an
exit
point.
So
it's
it's
all.
C
Yeah
definitely
agree,
I
think
rowena
touched
on
it
with
the
the
chainable
versus
monolithic
actions
and
just
kind
of
that
separation
of
concern
and
really
having
like
one
action.
That
does
one
thing
very,
very
well
and
that
way,
if
that
one
individual
step
fails,
you
know
that
that's
the
pain
point
and
you
don't
have
maybe
a
giant
action
that
does
your
entire
release
process
sends
out
a
tweet
to
twitter,
saying
that
I
release
something
and
orders
a
pizza
from
domino's.
So
you
know
you
want
to
have
those
individual
steps
like
that
cool.
C
So
another
question
I
think,
would
be
important
to
call
out
is
around
billing
for
github
actions.
So
what
happens?
If
I
finish
my
included
minutes
either
as
an
organization
or
a
user?
How
does
that
portion?
Work
and
show's
already
been
answering
that
for
us
here,
but
just
to
kind
of
publicly
say
it
here
on
the
call
or
on
the
webinar.
Excuse
me
as
an
organization.
A
Is
there
a
place
where
feedback
can
be
given?
I
actually
don't
know,
is
there
gonna
be
something
that
gets
sent
out
or
we'll
still
be
looking
at
the
slack
channels?
So
if
you
want
to
say
something
feedback,
anything
at
all,
I
mean
we're
reading
it.
Now
I
don't
know
if
there's
anything
official
going
on.
B
Yeah
yeah
we
love
feedback
and,
of
course
we
love
your
input
on
how
to
improve
some
aspects
of
our
presentation
on
the
workshop.
Whatever
it
might
be,
right,
maybe
we'll
have
to
just
we'll
make
sure
that
you
know
you'll
have
a
channel
to
provide
feedback
and
so
on
and
we'll
look
back
after
the
session
tool
to
see
how
that
works.
B
C
Yeah-
and
I
just
thought
of
one
other
note
regarding
the
like
monolithic
versus
attainable
action-
is
another
interesting
process,
or
maybe
a
good
process
for
for
maintaining
these
workflows
would
be.
You
can
export
your
logs
as
well
from
actions.
So
there
is
that
live
streaming
that
we
saw
on
the
ui,
but
you
can
also
export
those
and
save
them
off
separately
if
need
be
and
then
load
them
into
something
like
splunk
or
something
like
that
for
long-term
storage.
If
you,
if
you
want
to
do
that.
B
Yeah,
that's
an
excellent
point
exactly
so
that
we
kind
of
scratched
the
surface
today.
But
if
you
look
into
the
documentation
a
lot
of
those
resources
are
in
the
workshop
repo.
If
you
click
through
those,
you
will
get
a
better
sense
of
you
know
all
of
the
different
like
the
corners
or
github
actions
and
packages,
and
it's
very
flexible
and
just
one
use
case
like
thomas
mentioned,
exporting
the
logs
and
so
on.
B
C
A
couple
quick
questions
coming
in
the
last
couple
of
minutes
here,
so
maybe
just
to
kind
of
rapidly
answer
those
ones
ivan
or
yvonne.
I'm
sorry,
I'm
not
sure
which
way
you
would
pronounce
it.
Are
there
any
visualizations
coming
to
yaml
changes
similar
to
azure
build
service,
so
I
know
I
think
three
days
ago
we
just
announced
the
beta
on
day,
one
of
universe
of
visualizations
to
see
like
your
visual
pipeline,
like
rowena,
had
mentioned
blue
ocean
and
jenkins.
For
example,
you
can
see
kind
of
your
branching
pipeline
across
the
screen.
C
That
is
a
beta
you
need
to
opt
in
for,
and
then
let's
see
for
yaml
itself
right
now.
There
actually
is
some
smart
syntax
in
there.
That
will
highlight
if
you
have
errors
and
things
or
it'll
help
you
kind
of
auto
populate
and
the
docs
are
built
into
the
the
web
ui
editor,
so
you
can
actually
just
copy
paste
things
over
and
find
references
that
way.
So
hopefully
that
answers
that,
let's
see,
there's
one
more
I
saw
in
here
the
recording
for
the
session.
Do
we
know
where
that's
going
to
be
posted.
B
C
Okay,
there's
another
question
from
todd
that
was
talking
about
jenkins
earlier
and
just
kind
of
our
opinion
on
actions
replacing
jenkins
circle.
Ci
travis
things
like
that.
I
think
in
a
general
sense,
we
see
actions
as
being
a
competitor,
and
we
do
have
people
that
are
migrating
off
of
jenkins
into
github
actions
or
team
city
or
circle
or
travis.
We
have
some
public
docs,
actually
on
migrating
from
those
as
well
and
kind
of
comparing
and
contrasting
the
the
difference
between
those.
C
You
know
it's,
it's
not
a
full
feature
parody
yet,
but
I
think
that
that
is
kind
of
the
idea
is
that
we're
going
to
have
this
full
ci
cd
pipeline
and
then,
in
addition,
actions
is
going
to
github
enterprise
server,
which
is
our
on-premises
model
as
well.
So
as
that
comes
more
generally
available,
I
think
more
people
are
going
to
adopt
it
and
we,
we
might
see
a
shift
from
jenkins,
so
we'll
see
we're
still
happy
with
jenkins
2,
though
so.
C
A
I
I
just
saw
one
someone
asked.
I
even
asked
a
question
about
azure
to
github
action
from
what
I
can
gather
coming
from
azure
is
that
microsoft
is
going
to
essentially
the
features
are
going
to
be.
How
should
I
say
this
without,
like?
I
have
a
graph
that
I
usually
talk
about
this,
but
essentially
microsoft
is
going
to
continue
to
invest
more
in
github
actions
and
it's
not
about
whether
you
should
go
with
azure
or
github
actions.