►
From YouTube: Reducing DevOps toolchain complexity with GitHub
Description
Development teams often lose valuable time switching between tools, working through admin tasks, and battling red tape. In this session, you’ll hear from Bassem Dghaidi, Senior Software Engineer at GitHub, on how to reduce context switching between teams and tools and eliminate costs in your organization. You’ll leave with a better understanding of what’s possible by evaluating your DevOps toolchain and narrowing your tools—giving teams better workflows and streamlined processes.
Stay up-to-date on all things GitHub by subscribing and following us at:
YouTube: http://bit.ly/subgithub
Blog: https://github.blog
Twitter: https://twitter.com/github
LinkedIn: https://linkedin.com/company/github
Instagram: https://www.instagram.com/github
TikTok: https://www.tiktok.com/@github
Facebook: http://fb.com/github
About GitHub
It’s where over 100 million developers create, share, and ship the best code possible. It’s a place for anyone, from anywhere, to build anything—it’s where the world builds software. https://github.com
B
A
So
possum,
please
don't
forget
this
and
yeah,
and
actually
I'm
based
in
Amsterdam,
so
I'm
in
the
Netherlands
I
saw
already
a
couple
people
joining
on
and
from
Amsterdam,
and
we
pass
them
together.
We're
talking
about
yeah,
reducing
devops
tool,
chain
complexity
with
GitHub
today
and
I
thought
I'd
share
a
little
fun
fact
on
the
side
to
get
a
bit
personal
and
I've
been
working
in
my
past.
Also
with
a
lot
of
complexity.
A
B
C
A
B
B
B
Will
do
that
amazing
Anna?
Thank
you
very
much
for
the
introduction.
My
name
is
Basin
I'm,
a
senior
software
engineer
at
GitHub
I'm,
also
celebrating
my
anniversary.
Quite
soon
it
will
be
three
years
for
me
and
now
I
am
part
of
the
GitHub
actions
team,
but
before
that
I
was
part
of
expert
services
at
GitHub,
working
on
solution,
architect,
working
with
a
lot
of
different
Enterprises
and
companies
advising
them
on.
B
You
know
their
engineering
strategy
and
how
they
can
leverage
the
best
out
of
GitHub,
but
right
now,
I'm
more
focused
on
building
the
next
generation
of
GitHub
actions
and
working
on
some
of
our
open
source
initiatives.
You
probably
see
my
name
on
some
of
them
if
you've
been
using
stuff
like
actions,
one
and
controller,
and
otherwise
we're
going
to
talk
a
little
bit
more
about
that
in
the
session
today.
B
Amazing
I,
don't
have
a
fun
fact
honestly,
like
I,
didn't
really
think
it
through.
I
was
just
thinking
about,
maybe
something
that
people
don't
know
that
I'm
very
passionate
about
pickling
and
making
pickles
and
I've
perfected
my
recipe.
So
if
there
are
folks
who
love
pickles,
maybe
you
could
share
that
stuff.
C
A
A
If
you
have
any
questions,
we
have
in
the
top
right
corner,
also
the
Q
a
tap.
Please
just
navigate
there
and
ask
your
questions
there,
but
also,
if
you
have
very
dedicated
technical
questions,
follow-up
questions
on
what
basem
has
been
talking
about
today
on
the
top
of
your
screen,
you
see
a
request:
the
demo
button.
A
Please
go
there
schedule
meeting
and
talk
to
us
about
your
questions
in
order
to
follow
us
here
and
have
an
optimal
viewing
experience.
We
recommend
you
to
use
Google
Chrome
if
you're
at
any
point
can't
see
us
anymore,
please
just
refresh
your
Google
or
your
your
tab
and
if
you
have
any
trouble
you
may
using
VPN,
maybe
just
go
ahead
and
just
disable
your
VPN
or
just
refresh
the
event
from
the
link
in
your
calendar
and
the
last
resource
would
be
incognito
window.
A
You
can
also
join
us
on
stage.
So
if
you
would
like
to
ask
your
question
directly
to
me
and
Bassam
and
just
go
ahead,
raise
your
hand
just
navigate
to
the
bottom
of
your
screen.
There's
this
little
race
hand
racer
hand,
button
just
click.
It
I
will
receive
a
request
to
join
the
stage
and
I'm
your
host
will
be
approved,
you're
coming
on
stage
and
basically
just
ensure
that
you
have
enabled
in
your
browser
that
you
can
use
the
camera
as
well
as
that,
your
microphone
will
be
enabled.
A
B
Definitely
don't
shy
away.
We
would
love
to
take
in
your
questions
and
maybe
you
know,
have
a
slight
conversation
and
bounce
back
some
ideas
all
right.
Let's
dig
into
our
topic
for
today
we're
gonna
start
by
talking
a
little
bit
about
the
research.
Why?
Because
we
want
to
motivate
this
conversation-
and
you
know
we
want
to
share
with
you
some
of
our
findings
but
as
well
hear
from
you.
What
are
your
opinions
and
thoughts
on?
B
But
that
means
that
half
of
your
Workforce
is
affected
by
switching
in
between
different
tools
and
utilities,
and
what
that
translates
in
terms
of
numbers
is
or
minutes
of
a
day
is
about
one
hour.
Almost
is
wasted
entirely
for
people
switching
in
between
different
apps,
trying
to
find
information
trying
to
look
up
information
somewhere
or
maybe
trying
to
do
something
that
spans
across
multiple
products
or
multiple
apps.
Let's
say
so
one
minute
one
hour
a
day.
B
That
might
not
seem
like
a
lot,
but
it
definitely
compounds
and
one
hour
doesn't
necessarily
mean
that
it's
the
maximum
or
the
minimum
right.
That
definitely
varies
depending
on
what
you
do
on
a
daily
basis.
As
a
software
engineer,
I
know
that
the
more
tools
I
have
in
my
tool
chain,
the
more
context,
switching
I
need
to
do,
the
more
distracted,
I
will
be,
and
the
less
focused
I
would
be
on
my
tasks
and
we're
going
to
talk
more
about
that.
B
From
my
perspective,
as
an
engineer
in
in
the
demo
a
little
bit,
research
also
shows
that
there
are
two
types
of
modes
we
could
be
in
when
we
doing
work-
and
this
is
particularly
true
for
us-
software
engineers
and
periods
of
lower
mental
workload,
they
will
be
better
moments
for
us
to
be
interrupted,
as
opposed
to
periods
of
higher
mental
workload.
And
every
engineer
here
probably
knows
this,
because
when
we're
writing
code,
it's
a
very
complicated
activity
and
I,
always
wonder
you
know
how
the
human
brain
works.
It's
fascinating.
B
How
actually
coding
is
quite
complex
in
our
minds,
but
it
just
feels
so
natural
whenever
we
get
accustomed
to
it.
So,
on
the
one
hand,
we're
trying
to
maintain
the
state
of
the
program
we're
trying
to
run
an
emulation,
mental
emulation
of
how
the
program
runs
and,
on
the
other
hand,
we're
trying
to
think
of
how
we
want
what
are
the
changes
we
want
to
introduce
to
the
code
base
and
the
impact
of
these
changes
on
the
emulation
that
we're
sort
of
running
in
our
minds
and
there
are
definitely
periods
where
we're
peaked.
B
We
have
a
peak
Focus.
We
have
this
emulation
running
at
full
speed.
We
are
fully
you
know,
productive,
we're
able
to
make
changes,
we're
able
to
reason
about
it
very
quickly
and
in
these
states.
If
someone
comes
in
if
Anna
comes
in,
for
example
and
Taps
on
my
shoulder
in
the
office
and
she's
like
hi,
that's
amazing
to
see
you
it's
been
a
while,
so
on
and
so
forth.
B
Heightened
state
of
focus
after
being
interrupted
and
developers
often
do
not
make
their
first
edit
of
the
session
until
several
minutes
have
passed,
Beyond,
The
Interruption
and
this
the
distribution
of
this
period
varies
greatly.
So
it's
between
5
to
30
minutes
in
the
worst
case
scenario,
if
it
goes
beyond
30
minutes,
that
means
that
person
has
completely
left
the
building
they're
completely
detached
now
from
their
activity
and
I'm
sure
Anna.
You
know
this
like
when
you
you're
working
some
on
something
that
you've
been
highly
focused
on
and
you
get
interrupted.
B
A
B
Been
there
so
many
times.
Definitely
it's
it's
kind
of
snowballs
right
like
something
drags,
the
other
and
by
the
time
you're
back
to
the
activity,
because
I
think
for
some
reason
we
sort
of
start
to
postpone
it
a
little
bit
because
it
takes
effort
for
us
to
go
back
to
that
state
of
Focus
right.
So
we
kind
of
start
procrastinating,
a
little
bit
Yeah,
okay,
fine,
I'll,
I
need
a
small
break.
I
need
to
go,
make
a
coffee
so
on
and
so
forth,
and
this
is
very
costly.
B
A
B
Yeah,
this
is
very
tricky
honestly,
like
I,
would
love
to
think
that
I'm
quite
disciplined
when
it
comes
to
these
things
and
I
can
come
back
to
it
after,
like
between
one
to
five
minutes.
But
it's
definitely
not
the
case.
I
often
feel
like
it
takes
me
way
longer
than
that,
and
it
depends
on
how
critical
that
activity
is
and
the
the
more
more
complicated
that
work
is
the
longer
it
will
take
me
to
go
back
to
it
honestly.
Yeah.
A
Definitely
and
I
I
think
here
it's
I
still
people
still
people
are
voting
but
I've
seen
between
five
to
ten
minutes,
10
to
20
minutes,
yeah
I
think
that's
also
I'm,
definitely
in
a
five
to
ten
minutes.
But
if
it's
a
very
like
yeah
extensive
task,
then
it
takes
me
much
longer
and
even
if
it's
tasks
that
I
don't
like
to
do,
I
think
that's
also
something
where
you
really
have
to
force
yourself
and
get.
B
B
E
B
B
B
A
B
All
right,
amazing,
so
moving
forward
interruptions
are
not
I'm,
not
just
an
I'm,
not
just
bad,
because
they
waste
our
Focus
their
back
and
they
waste
time.
Interruptions
are
bad
because
also
they
change
our
our
emotional
state
and,
as
evidenced
by
this
research,
annoyance
Rose
by
56,
when
we
interrupt
people
at
the
wrong
time
with
the
worst
possible
type
of
interruption
and
their
frustration
Rose
by
50.
A
D
D
B
A
E
You
you
guys
can
hear
me
right.
Yes,
so
we
can
hear
you
right,
yeah,
I,
I
do
agree.
It
definitely
depends
on
the
type
of
disruption
or
distraction
right.
Some
things
can
be
as
simple
as
run
a
query.
Something
can
be
as
get
up.
Try
to
figure
this
thing
and
prod,
right
and
but
yeah
I
think
it's
in
from
my
experience
is
it
can
go
up
to
20
minutes.
Some
things
will
require
you
actually
like
a
coffee
break
right,
you'll
be
like
you're
done
with
this
and
be
like
okay.
E
B
E
I
haven't
planned
that
far,
maybe
potentially
just
doing
the
putting
DND
afterwards,
like
he's,
definitely
like
to
say,
you're
busy
and
you
want
to
focus
like
it
depends
on
the
priority
right
and
one
little
trick.
I
actually
have
oh
I,
just
remember
one,
it's
basically
sometimes
depending
on
who
you
need
to
communicate
with,
and
you,
but
you
like.
E
Sometimes
you
need
this
time,
this
free
time
right
to
focus
on
something,
but
then
there's
some
other
important
people
you
need
to
communicate
with,
because
you
have
an
ongoing
thing
with
them
and
what
I
do
is
say,
prioritize
notifications,
so
some
some
applications
like
teams
have
that
so
in
teams
you
actually
can
say.
Okay,
those
couple
of
people
can
send
me
a
message
right
now
for
the
rest
or
okay.
Maybe
I
need
to
focus
that.
Oh,
it
is
hard
to
balance,
because
sometimes
you
need
to
help
someone
right.
A
A
Thank
you
for
sharing
this
and
I.
Think
with
that
and
I
will
send
you
off
stage
bye
with
that
I
will
open
up
a
new
Poll
for
everyone,
and
I
will
I'm
very
curious
to
hear
to
what
extent
everyone
feels
annoyed
or
frustrated
by
actually
being
interrupted
because
the
person
you
just
said
it
right,
some
people
just
like
it
and
they
don't
mind
too
much.
It's.
A
Yeah,
no
indeed,
and
but
I'm
I'm,
actually
doing
also
a
similar
activity.
I'm
I'm,
adding
Focus
time
to
my
agenda
and
it's
very
mean
because
it
already
clients
meetings
that
are
coming
in,
but
sometimes
it's
it's
so
useful.
It's
really
you're
getting
so
much
work
done
and
and
I'm
feeling
so
much
better.
Suddenly,
afterwards,
it's
almost
satisfying
100.
A
B
D
B
How
how
GitHub
can
help
with
a
lot
of
these
things
so
again,
GitHub
is
as
a
platform.
We've
come
a
long
way
like
GitHub
when
I
joined
was
way
different
than
what
GitHub
is
today.
We
have
so
many
different
tools
and
what
I
love
most
about
them
is
two
are
two
things.
One
I
use
GitHub
every
day
at
GitHub
to
build
GitHub,
and
the
second
thing
is
I
love.
How
integrated
everything
is
so
really
there's.
B
B
In
my
you
know,
development
chain
and
and
software
development
lifecycle,
I,
don't
have
to
move
in
between
apps
I
do
certain
things
in
the
morning
certain
things
in
the
evening
and
in
between
I'm,
just
in
my
editor,
trying
to
be
as
productive
as
I
can
be.
As
a
software
engineer,
which
is
the
purpose
of
you,
know
my
my
role
and
at
GitHub
we're
always,
we
have
always
been
and
we'll
always
be
focused
on
providing
a
developer,
an
excellent
developer
experience
that
enables
everyone
to
do
the
best
work.
Why?
B
C
B
Figuring
out
ways
to
make
it
better
because
it
will
make
our
lives,
even
you
know,
better
or
worse,
depending
on
how
good
we
we
perform
now.
Obviously,
manual
tasks
also
are
a
significant
inhibitor
to
your
productivity
as
developers
as
we
all
know,
nobody
wants
to
go
and
click
manually
certain
things
we
would
love
to
automate
as
much
as
possible
from
our
workflows
and
what
I
love
about
GitHub
as
well,
is
in
GitHub
actions
in
particular.
Is
the
ability
to
do
a
lot
of
that
automation
and
have
it
all
integrated
now.
B
It's
called
actions
running
controller,
which
is
a
kubernetes
controller
that
is
used
to
orchestrate
and
scale
self-hosted
Runners
we're
not
going
to
go
deep
into
what
this
does
obviously,
but
I'm
just
going
to
show
you
how
we
developed
this
kubernetes
controller,
which
we
adopted
from
the
community.
So
let's
jump
to
the
demo.
B
B
I
just
want
to
make
sure
that
the
text
is
legible,
all
right,
so
you
can
see
here
my
my
terminal
and
my
favorite
tool
to
be
honest
at
GitHub
that
I
start
with
always
is
GitHub.
Cli
allows
me
to
do
a
lot
of
awesome
stuff.
My
second
favorite
tool
is
GitHub
code
spaces,
but
before
I
jump
into
my
code,
space
I
want
to
show
you
a
little
bit
also
how
I
personally
plan
my
day.
So
let's
go
back
to
the
browser
just
for
one
minute
before
we
we
dive
deep
into
this.
B
What
I
want
to
show
you
is
my
personal
project
board,
so
a
few
people
mentioned
their
own
to-do
lists.
This
is
mine.
Obviously
this
is
not
my
actual
to-do
list,
because
I
don't
want
to
show
you.
You
know
some
of
the
stuff,
that's
not
supposed
to
be
public,
but
this
is
a
sort
of
the
same
structure
as
my
to-do
list
and
I
have
the
same
title
for
it.
It's
my
secret
stash
and
what
I
like
to
do
is
I
like
to
compose
my
to-do
list
into
three
different
views.
B
So
the
first
view
is
the
stabular
view
where
I
can
see
the
list
of
issues
categorized
by
different.
You
know
statuses,
like
my
to-do's,
my
follow-ups,
my
in
progress
and
what
I'm
doing
in
review,
and
this
could
be
tasks
that
I
need
to
pick
up
activities
that
I
need
to
do,
or
they
could
be
put
requests
that
need
my
attention
and
they
could
be
distributed
across
multiple
repositories.
For
example,
I
can
see
the
labels
I
can
also
what
I
love
to
do
is
assign
impact
to
my
work,
because
at
GitHub
will
very
much
impact
driven.
B
So
there
are
activities
that
we
need
to
do
that
are
chores
that
could
have
a
high
impact,
or
there
are
activities
that
are
quite
big,
but
they
have
a
low
impact
and
these
should
be
lower
priority
than
other
stuff.
So
this
is
a
great
mechanism
that
allows
me
to,
from
a
glance,
see
how
can
I
create
a
highly
impactful
day,
for
example,
and
pick
and
choose
the
things
that
are
high
impact
high
priority.
B
Maybe
high
impact
low
effort
depends
on
our
strategy
and
where
we
want
to
go
next
and
then
I
have
something
called
Next
action
and
which
is
something
I
love,
because
there
are
some
long
running
tasks
that
don't
require
my
attention
on
a
daily
basis.
So,
for
example,
these
two
issues
here
they
require
my
next
action,
maybe
in
a
week
from
now.
So
what
I
would
do
on
a
daily
basis
in
the
morning
is
I
would
refine
this
and
I.
B
B
You
know
like
the
scan
band
Board
of
all
of
my
items,
distributed
by
priority
I,
also
like
to
look
at
my
items,
distributed
by
buckets
you
know
or
like
Columns
of
their
different
status,
just
so
that
I
can
have
a
very
quick
glance
or
sorry
at
a
quick
glance.
What
are
how
much
am
I
overloaded
today
and
what
I
love
most
about?
B
This
is
I
share
this
every
single
morning
with
my
team
and
my
manager,
so
that
they
know
exactly
what
I'm
working
on
and
I
don't
have
to
report
on
status
for
anything,
because
I
can
just
tell
them
go.
Look
at
my
board.
It's
always
up
to
date
always
has
everything.
I
need
now
from
this
I
will
pick
up
my
activities
for
the
day.
So,
for
example,
let's
say
I
have
this
to
do
that:
I
need
to
figure
out,
which
is
it
requires
my
attention
less
than
one
day
and
it's
this
issue
so
again.
B
What
I
love
about
GitHub
is
how
everything
is
integrated.
I
can
even
change
the
status
of
my
EQ
right
here.
It
will
be
reflected
in
the
board.
I
have
a
summary
of
this
issue
and
tasks
that
I
need
to
work
on
and
I
have
a
description
and
also
I
can
link
to
the
code
immediately.
So
this
task
is
basically
it
says
that
the
current
that
the
current
step
in
our
workflow
is
not
readable
and
it's
not
really
testable
and
we
need
to
refactor
this
piece
of
code.
B
Obviously
there
could
be
more
in
the
summary,
but
I
just
wanted
to
give
you
like
an
example
and
if
we
go
back,
this
is
the
repository
where
all
the
code
is
and
I
can
have
a
permanent
link
for
every
single
line
in
the
code.
You
know,
and
I
can
come
here
and
see:
okay
yeah
this
it
looks
like
we
have
this
action
right.
This
step
right
here,
there's
some
JavaScript
code
over
here.
There
are
doing
some
Loop,
maybe
sleeping
a
little
bit,
and
it's
not
really
clear.
B
It
could
be
definitely
refactored
into
something
better
right.
I
mean
it's
obviously
doing
its
job,
because
the
workflows
are
not
failing,
but
we
can
definitely
improve
this
a
little
bit
and
make
it
slightly
better.
So
from
here
once
I
have
my
task:
I
would
jump
to
my
again
favorite
tool
and
what
I
love
about
code,
spaces
and
GitHub
CLI
is
that
I
can
get
a
list
of
all
of
my
code
spaces,
and
you
can
see
here,
I'm
going
to
be
using
this
one,
so
I've
created
also
some
aliases.
B
A
Or
anyone
wants
to
yeah
talking
about
their
start
in
their
day
or
how
they
maybe
have
been
using
already
projects
in
GitHub,
but
I
don't
know.
Does
anyone
have
experience
with
that
I'm
actually
using
it
as
well,
but
so
I
mean
I'm
I'm,
not
working
as
as
much
as
we
like
you
do
in
projects,
but
my
entire
work
day
is
basically
happening
in
GitHub
and
we're
all
communicating
through
GitHub
and
I
really
enjoy
that.
Definitely.
B
B
All
right,
amazing,
now
I
have
my
code
space
up
and
running
I
hope
the
text
is
clear.
Yes,
amazing,
so
also
from
here
with
my
code,
space
I
have
all
of
the
tooling
that
I
need.
I
can
also
configure
my
code
space
to
install
all
of
my
favorite
tools.
I
also
love
about
GitHub
CLI
is
the
fact
that
I
have
extensions
that
I
could
use
right.
So,
for
example,
now
I
really
don't
need
to
get
out
of
my
editor
anymore.
Why?
B
Because,
if
I
want
to
revisit
my
pull
requests,
for
example,
and
if
I
want
to
revisit
my
issues,
I
can
just
do
that
using
an
extension
called
Dash.
You
can
install
it
yourselves,
it's
open
source.
It's
amazing
I
can
just
check
the
put
request
that
need
my
review
and,
with
my
attention
from
my
terminal,
I
can
look
at
things
that
I,
maybe
I,
have
missed
from
my
board.
I
can
review
the
issue,
for
example,
and
this
is
the
issue
that
was
that
I
that
is
related
to
the
refactoring
task.
B
So,
for
example,
I
can
assign
it
to
myself
right
from
the
terminal
right
and
I
can
it
will
be
reflected
in
the
board
and
then
I
can
just
start
my
activities.
So
now
that
I've
assigned
this
issue
for
myself
I'm
going
to
start
the
actual
work
on
it,
and
let
me
see
make
sure
that
I'm
following
my
steps,
all
right
now,
I
have
this
repository
already
grown
locally.
B
I
don't
want
to
pollute
the
project
where
everybody
is
working
on
right
now,
just
for
this
demo,
so
I'm
going
to
be
pushing
stuff
to
the
fork
right,
amazing,
I
I
would
advise
you
also
to
have
your
fork
running
in
a
different
directory.
Just
so
that
you
don't
push
by
mistake
upstream,
and
you
always
push
to
your
fork.
That's
definitely
a
best
practice
and
I
want
to
make
sure
that
my
Fork
is
up
to
date.
So
I'm
gonna
pull
my
pull
any
changes.
There
are
in
the
main
branch.
B
Obviously
there
aren't
the
next
step
that
I
would
like
to
do
and
something
I
would
advise
everyone
if
you
have
a
project
whatever
that
project
is
make
sure
you
have
like
a
script
that
will
set
it
up
for
you
and
you
can
have
an
entirely
running
environment
on
the
get-go.
So,
for
example,
for
actions
running
controller,
my
team
and
I,
we
have
the
script
that
will
allow
us
to
use
the
local
copy
of
the
project
in
whichever
state
it
is.
You
know
to
completely
run
a
fully
working
environment
in
our
code
space.
B
B
Now
this
is
where
the
lazy
me
comes
into
place
and
GitHub
as
well
as
open,
Ai
and
Microsoft.
They
gave
me
the
best
gift
as
a
developer,
which
is
that
for
pilot
chat
instead
of
me
delving
into
this
and
trying
to
refactor
it
myself,
I'm
gonna,
ask
copilot
chat
to
actually
do
this
for
me,
so
I'm
gonna
select
all
of
this
text
and
I'm
gonna
try
to
create
a
prompt
that
will
try
to
refactor
this
into
a
more
legible
code
that
maybe
even
we
can
test
and
work
with.
B
B
B
Definitely
these
are
the
interruptions
I
definitely
enjoy
just
because
when
I
give
it
a
prompt
and
I
think
about
it,
it
will
yield
sometimes
very
surprising
things
that
would
make
my
life
so
much
easier.
Like
I
know
for
a
fact,
it's
going
to
take
me
between
half
an
hour
to
an
hour
to
you
know,
refactor
this
code
by
myself,
but
now,
let's
see
what
co-pilot
spits
out,
so
this
code
works
as
expected,
and
that's
what
it's
supposed
to
do.
B
I
need
you
to
make
it
more
readable,
focus
on
code,
readability
and
use
as
many
helper
functions
as
needed.
So
I
need
to
stand
in
two
hours:
no
I'm
not
going
to
pay
you
copilot,
sorry,
so
I'm,
just
gonna,
I'm,
just
gonna
go
with
the
front
right
now
and
we're
gonna
see
what
it
spits
out
and
again.
This
is
not
really
rehearsed,
so
I
have
no
clue
what
it's
gonna.
What's
gonna
come
out
of
this
and
as
a
reminder
to
everybody
right.
These
are
tools,
never
trust
the
tools.
B
B
B
B
B
E
B
It
does
make
sense,
however.
This
is
a
very
confined
context-specific
step,
so
it
will
either.
So
this
is
not
really
dependent
on
anything
else.
That's
happening
elsewhere
and
that's
why
I
didn't
really
try
to
get
it
to
get
more
contact,
but
that's
definitely
a
wonderful
tip.
I
will
definitely
leverage
that
in
the
future
for
sure.
B
B
So
let
me
make
sure
that
I
list,
the
workflows,
I,
think
they
correct
repository,
because
I
want
to
list
the
workflows
in
the
fork
and
not
necessarily
in
my
Upstream.
So
as
you
can
see
here,
I
have
two
workflows
that
are
currently
running.
One
of
them
is
the
end-to-end
tests,
which
is
exactly
what
I
need.
B
So
let
us
try
to
watch
one
of
these
workflows,
and
this
is
something
awesome
with
actions
that
I
always
love
to
do,
which
is
to
inspect
my
workflows
right
from
my
terminal,
and
what
this
will
do
is
it
will
show
me
basically
pretty
much
all
of
the
different
jobs
that
I
have
in
my
workflow
and
it
will
update
them
in
real
time.
So
again,
I
don't
have
to
switch
back
to
my
browser
in
any
way.
Shape
or
form.
B
I
can
continue
working
on
something
else,
while
maybe
even
my
workflows
are
running
in
the
background
and
I'm
getting
status
updates,
so
I
really
don't
have
to
switch
any
apps.
I,
don't
have
to
do
any
interruptions
for
my,
for
my
flow
I
can
continue
working
and
what
I
love
also
about
these
Integrations
is
copilot.
Chat
is
also
here
next
to
me
all
the
time.
B
So,
for
example,
if
I
want
to
inquire
about,
how
can
I
do
something
like,
for
example,
how
can
I
use
ghcli
to
workflow
updates,
for
example,
hopefully
GitHub
CLI,
sorry
copilot
will
spit
out
something
useful
and
it
has
made
the
recommendation
that
we
could
use
the
GitHub
API,
because
this
is
what
copilot
has
been
trained
on.
It's
actually
quite
good
in
figuring
out
how
you
can
leverage
our
API
for
for
doing
a
lot
of
things.
Maybe
it's
not
really
trained
on
the
commands
of
GitHub
CLI,
but
still
I.
B
Copilot
is
fantastic
for
these
things,
because
it
can
spit
out
really
nice
examples
and
it
can
add
a
lot
of
nice
context
around
them
which
again
as
developers,
you
really
have
to
vet
these
things
and
make
sure
that
they
are
correct.
But
they
are
just
a
major
productivity
booster
I.
Don't
have
to
go,
look
for
false
positives
on
Google
or
online
or
or
any
other
search.
I
can
just
get
the
results
right
in
my
editor
and
I.
Don't
have
to
go
anywhere.
A
C
Thank
you,
so
I'll
try
to
jump
into
my
question,
so
we
have
a
service
where
we
generate
workflows
for
our
users,
yeah,
GitHub,
workflows
and
we're
trying
to
figure
out
if
there
is
any
way
to
test
the
generated,
workflows
and
like
the
online
I
saw
something
called
app.
Yes
using
that,
but
I
found
it
was
lagging
some
features
like
recently.
We
didn't
try
using
that,
but
when
we
used
it
was
lagging.
It
cannot
find
reusable
workflows,
something
like
this
and
we
couldn't
really
use
that.
B
So
yeah
testing
workflows
are
tricky
because,
on
the
one
hand
you
want
your
workflows
to
be
running
and
as
close
of
of
their
final
environment
as
possible.
Right,
like
you,
have
a
lot
of
different
scenarios
that
you
cannot
really
emulate
elsewhere
locally,
it's
very
tricky
you
can
obviously
create
marks
for
anything,
but
also
that's
not
gonna.
Give
you
like
the
the
final
experience
that
you
want.
B
So
the
thing
the
way
we
work
with
workflows
is
personally
I
use
forks
as
much
as
I
can
and
I
try
to
recreate
the
environment
that
I'm,
you
know
creating
workflow
for
in
my
Fork
as
much
as
I
can
and
then
I
would
run
my
workflows
in
my
fork
and
if
they're
running
fine
there,
then
I
will
just
merge
them
back
to
my
other
environment,
I'm
afraid.
At
this
point
there
is
really
nothing
else
to
my
awareness.
G
Hi
everybody
greetings
from
Frankfurt
Germany
I
have
a
question.
Since
you
are
one
of
the
GitHub
action
developers.
Look
I
I.
Try
to
ask
my
questions.
The
chat
I'm
always
misunderstood
when
you
have
a
feature
branch
and
you
do
a
commit
and
you
have
a
pipeline
that
runs
on
this
feature.
Branch
which
runs,
builds
everything
and
you
only
want
things
to
be
merged.
If
everything
is
successful,
including
security
checks
and
stuff
like
this.
H
G
Is
a
small
racing
condition
when
I
commit
it's
like
I,
don't
know
five
seconds
until
the
pipeline
starts,
and
if
you
are
fast,
you
can
actually
push
and
instantly
merge
without
the
pipelines
to
be
run.
This
is
a
problem.
This
is
a
problem
because,
if
I
use
pipelines
security
stuff
in
order
to
ensure
that
the
developers
are
doing
things
properly,
everything
is
running
well.
I
only
want
to
merge
code
that
is
really
had
been
running
through
the
pipelines.
B
I'm
not
really
sure
so.
Okay,
let's,
let's
clarify
a
few
things.
Obviously
this
is
not
intended
Behavior,
so
I
would
love
if
you
could
report
this,
because
this
is
not
a
desired
desired
Behavior.
Obviously,
whenever
you
run
a
workflow
that
workflow
should
run
based
on
the
that
has
a
reference,
and
it
should
basically
check
out
that
ref
that
you
that
you
pushed
or
to
your
branch
or
whatever
else,
and
then
the
workflow
should
run
based
on
that.
B
It
should
not
run
based
on
anything
that
comes
in
between
you
doing
that,
triggering
that
workflow
and
the
workflow
running
right,
because
even
if
it
takes
us
time
to
assign
your
workflow
to
a
certain
Runner
and
it
takes
time
for
that
Runner
to
register
itself
and
pick
up
the
job.
That
doesn't
mean
that
you
can
inject
anything
in
between
or
into
that
process
right.
So,
let's,
maybe
if
you
erase
this
to
the
support
team,
maybe
they
can
advise
on
better
practices
for
how
you
can
prevent
this
from
happening
or,
if
there's
a
bug
you
would.
G
Not
interested
there,
there
is
no
it's
it's
just
an
implementation.
As
you
said,
it
usually
needs
like
five
seconds
until
you're
assigned
to
a
runner,
and
then
you
know,
I
commit
I,
see
my
my
pull
request.
The
merge
button
is
green
and
after
a
few
seconds
it
becomes
disabled
because
the
pipeline
is
running
and
then
like
it,
it
gets
green
again
after
the
pipeline
was
successful
or
it
stays.
B
Gray,
because
it
couldn't
be
happening
if
you
have
Branch
protection
and
you
have
checks
as
checks
that
are
mandatory
before
you
can
merge
a
request.
That
should
not
be
something
that
that
happens
and
again
I
would
love.
If
you
could
report
this,
maybe
with
a
video
that
showcases
a
scenario
and
let
us
have
the
support
team
address
this.
B
G
C
B
C
A
H
I
have
two
questions:
if
that's
okay,
the
first
being
our
team,
is
owning
around
78
repositories
and
it's
really
hard
to
have
an
overview
on
all
the
open
pull
requests
across
these
repositories.
Some
of
them
are
from
renovate
for
dependency
management.
Some
of
them
are
from
other
stream
aligned
teams
whatever,
and
the
notification
Bell
on
the
top
right
corner
is
not
really
intuitive
to
kind
of
get
an
overview
of
all.
B
On
the
roadmap,
yeah
I
understand
the
problem,
so
the
thing
is,
it
really
depends
on,
so
the
notifications
will
basically
show
you
pretty
much
everything
you're
watching
or
everything,
you're
subscribed
to
every
engagement
or
interaction
you
make
in
a
certain
repository,
then
you're
gonna
start
seeing
some
of
the
notifications
from
that
repo.
They
might
not
be
reposited
to
your
own,
but
they
they
are
the
positives
you
probably
engaged
with,
and
the
only
way
you
can
solve.
This
is
currently
by
unsubscribing
from
pretty
much
everything
you
don't
own.
Honestly
like
this
is
the
best.
B
This
is
the
best
way
and
honestly
for
for
pull
requests.
There's
also,
let
me
just
very
quickly
check.
We
have
the
pools
page,
which
is
showing
you
all
of
the
pull
requests
that
have
been
created
by
you,
the
ones
that
are
assigned
for
you,
the
ones
you're
mentioned
and
so
on,
and
so
forth.
I'm,
not
really
sure.
If
you
know
this
view
already
I
do
so.
There
is
a
revamp
also
for
all
of
this
UI
I
cannot
talk
much
about
it,
but
there's.
Definitely.
B
This
is
definitely
something
we're
thinking
about
and
we
are
working
on
and
there's.
This
is
going
to
be
more
grouping.
That
is
done
for
notifications
and
you're
going
to
have
more
context,
specific
notifications,
let's
say
so-
that
you
can
address
them
and
be
more
comfortable
with
also
with
the
apis
that
we
have
I
think
we
also
have
something
we're
working
on
that's
going
to
give
a
different
notification
experience
again.
I
cannot
share
much
about
it
because
it's
still
in
very
early
stages,
but
there's
definitely
stuff
coming
for
that
awesome.
E
F
Yeah
thanks
for
having
me
I
awesome.
I
have
one
thing
when
using
a
strategy
Matrix
in
actions.
Sometimes
we
have
like
a
lot
of
os's
and
sometimes
a
lot
of
browsers,
and
for
that
one
we
are
when
we
do
some
like
pull
requests
on
pull
request
events:
the
list
is
too
long
and
I
was
thinking.
Is
there
a
way
to
group
these
lists,
so
they
can
be
more
readable
in
the
VR.
B
B
Yeah
yeah
I
understand,
unfortunately,
I,
don't
think
we
have
something
right
now.
That
is
gonna
at
least
to
my
awareness,
because
again
GitHub
is
quite
big.
There
could
be
other
teams
that
are
working
on
a
lot
of
other
nice
stuff
right,
but
my
to
my
awareness,
we're
not
really
addressing
this
right
now,
just
because
there's
in
the
actions
view
you
can
go
and
you
can
see
you
know
the
workflow.
The
specifics
of
each
workflow
and
I
know
that
you
might.
B
B
B
H
A
H
Problem
where
we
we
are
leveraging
GitHub
templates
to
create
template
repositories
right
okay,
but
when
you
create
any
repository
out
of
this
template
beyond
the
initial
creation
it
and
then
doing
any
updates
to
the
template
are
not
synced
back
to
the
child.
Drip
was
so
to
say,
correct
and
I
was
wondering
if
there's
a
solution
for
that.
B
So
it's
a
tricky
problem
because
I
I
will
tell
you
this
like.
If
you
create
a
template
and
you
as
an
individual,
you
go
create
a
repository
out
of
this
template
right.
So
I'm
going
to
ask
you
put
yourself
in
in
our
shoes
and
someone
pushes
a
change
that
you
don't
want
in
your
template
in
your
in
your
copy
of
the
template
right.
How
can
you
control
that?
So
it's.
B
Problem,
there's
yeah,
there's
gonna
need
to
be
a
creation
of
a
new
environment
for
you
to
dismiss
this
change
when
it
comes
for
you
to
be
notified
about
it
and
then
for
you
to
accept
some
changes,
but
not
others,
and
then
also.
How
do
you
merge
these
changes
to
your
template
because
you
know
later
on,
because
your
your
repository
or
your
copy
has
obviously
changed
in
so
many
different
ways.
B
There's
really
no
way
for
us
as
a
platform
to
really
know
how
we
can
successfully
merge
these
new
changes,
otherwise,
you're
going
to
have
a
ton
of
Errors.
However,
you
can
create
pull
requests
on
your
copies
of
templates
and
then
you
need
to
create
a
mechanism
for
you
to
create
like
a
centralized
sort
of
a
template
enforcing,
let's
say,
workflows,
and
then
from
that
from
that,
whenever
you
make
changes
to
that
templated
repository,
there
are
workflows
that
are
triggered.
B
That
will
go,
create
pull
requests
on
all
of
these
copy
copied
repositories,
and
then
the
owners
of
these
repos
can
either
accept
these
pull
requests
or
not,
and
this
is
what
we
advise
pretty
much
everyone
to
do.
Put
requests.
Are
the
mechanisms
best
mechanisms
to
introduce
change
because
they
allow
for
a
you
know,
I
approve
I
want
to
change
this
I
want
I,
want
this
I
want
that,
and
you
can
safely
merge
changes
cool
thanks.
Thank
you.
B
A
A
B
A
Yeah
and
I
I
think
what
we
should
never
forget
for
us
at
GitHub,
the
developers
in
the
middle
is
he's
always
the
developers
are
always
in
the
center
and
I
think
this
is.
This
is
in
four
years,
definitely
not
changed,
and
that
is
also
how
we're
moving
forward
and
I
love.
I
love
that
that
is
the
way
we
are
developing
our
product
and
with
that
being
said,
we
just
have
shared
the
survey
in
the
chat.
So
please
we
like
and
love
to
hear
your
feedback.