►
From YouTube: June CI/CD Engineering Demonstrations
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
A
Recently,
thanks
to
some
really
awesome
work
by
a
bunch
of
our
back
end
engineers,
we
now
have
the
ability
to
create
dag
pipelines
which
are
directed
acyclic
graphs,
and
what
that
means
is
that,
instead
of
the
pipeline
executing
stage
by
stage,
you
can
use
the
needs
keyword
and
indicate
that
a
job
can
start
operating
as
soon
as
as
soon
as
it's
depend,
the
things
that
it
depends
on
which
aren't
the
same
thing
as
the
dependencies
keyword.
But
as
soon
as
the
thing
that
it
depends
on
is
finished
running.
A
It
can
also
run-
and
you
see
that
in
our
pipelines,
right
like
if
you
look
you'll
be
like
oh
test
is
still
running
while
compile
is
still
running,
so
that's
really
cool,
but
the
way
that
our
pipeline
page
looks
as
you
can
see
here.
It's
really
hard
to
see
what
the
dependencies
of
a
job
are.
What
the
graph
looks
like
you
just
have
like
all
of
these
different
rows
and,
like
everything
is
connected
to
everything.
A
So
what
we've
been
working
on
is
creating
a
visualization
of
pipelines
that
are
directed
acyclic
grasp
so
that
when
you
write
your
file,
especially
if
you're
making
a
very
complex
file,
you
know
you
might
not
know
all
the
paths
that
you're,
including
when
you're
like
oh
yeah.
This
needs
this.
You
know
you
can
sort
of
lose
track
of
where
everything
is.
So
the
idea
is:
how
do
we
visualize
that?
The
first
way
that
we
talked
about
visualizing?
It
was
using
this
tangled
tree
visualization.
A
This
is
just
an
example
from
the
d3
from
a
d3
notebook,
and
you
can
see
right,
it's
sort
of
like
it.
Has
these
nice
little
nodes
and
they
all
come
together,
and
this
is
a
really
cool
graph.
Unfortunately,
it's
not
a
default
d3
layout,
so
basically,
it's
very
hard.
A
The
way
d3
works,
the
way
that
dataviz
works
in,
like
a
short
sense
right
is,
you
have
a
bunch
of
data
and
then
you
have
to
tell
a
browser
how
to
draw
a
picture
with
all
of
that
data
and
the
apis
for
drawing
pictures
and
browsers
are
really
low
level.
It's
like
put
this
thing
literally
at
this
place,
so
our
problem
is
okay.
A
How
do
we
draw
this
without
taking
a
year
to
draw
this,
and
I
want
to
call
out
that
peyton
and
fred
spent
a
lot
of
time
looking
at
our
data
and
trying
to
figure
out
how
to
draw
it
this
way,
and
it
was
hard,
it
was
really
really
hard,
there's
all
sorts
of
edge
cases
and
things,
and
when
I
joined
the
project,
I've
done
a
little
bit
of
d3
before,
and
I
said
okay
instead
of
trying
to
make
this
right
away
what,
if,
instead
classic
zoom
in
the
way
of
my
tabs
there
we
go
what,
if
instead
we
made
a
sankey
now
when
you
first
look
at
this,
it
might
not
be
like.
A
Oh
yes.
Obviously
I
can
see
how
this
graph
is
exactly
like
the
graph
you
showed
me
before
sarah,
but
the
way
that
it
works
in
d3.
A
lot
of
the
data
it
uses
to
lay
these
nodes
out
are
useful
for
maybe
in
the
future
getting
to
the
tangled
tree
and
they
handle
the
sort
of
hierarchy
of
nodes
that
we
need
for
a
dag.
A
The
thing
that
makes
it
difficult
compared
to
a
lot
of
other
data
visualizations
is
that
jobs
can
have
multiple
parents
and
multiple
children
and
that
really
narrows
the
level
of
data
visualizations
that
you
can
use
even
most
hierarchical
views,
presume
that
there
is
a
single
parent
and
that's
not
the
case,
so
we
said
okay,
how
can
we
make
this
crap?
How
can
we
make
this
stinky?
Look
as
much
like
what
we
want
that
tangled
tree
as
possible,
and
then
can
we
keep
iterating
to
get
it
closer
and
closer?
Also
right.
A
We
wanted
to
be
able
to
get
this
out
in
front
of
users,
because
we
only
know
so
much
about
what
people's
data
looks
like
and
we
can
generate
things
and
we
can
like
try
to
uncover
little
edge
cases.
But,
having
worked
with
any
data,
I
can
promise
you.
It
looks
totally
different
than
you
expect,
no
matter
what
you
expect,
because
people
are
like
amazing
and
inventive,
and
things
will
happen
so
getting
it
out,
so
that
people
can
see
it
is
really
important.
So
what
we
made
is
this.
A
A
A
You
can
see
that
you
also
might
want
to
say
how
many
jobs
are
leading
me
to
say
this
final
point,
so
we
can
click
on
it,
and
now
you
can
see
all
of
the
jobs
that
are
required
to
pass
before
production
d
is
called,
and
so
this
is
obviously
another
example
piece
that
we
did
it's
not
like
the
real
real
data.
Oh
right.
The
next
thing
I
wanted
to
talk
about
with
this
is
so.
This
is
what
we
have.
We
can
look
at
the
things.
A
Something
that's
very
interesting
is
you'll
notice
that
the
first
step
towards
getting
closer
to
that
previous
graph
is
being
able
to
draw
our
links
the
way
that
we've
drawn
them
right.
If
we
look
at
this
in
the
sankey,
it
has
all
these
like
swoopy
links
which
are
nice,
but
not
the
aesthetic
we're
going
for.
So.
A
Instead,
we
made
these
cool
little
box
links
with
the
mid
points,
and
it's
less
important,
maybe
or
less
obvious
in
this
one,
and
this
one
you
can
see
a
little
bit
more,
that
an
important
thing
that
we
needed
to
do
with
these
links
is
to
make
sure
that
they're
all
staggered
so
they're
not
sitting
on
top
of
each
other.
A
When
you
draw
the
graph
out
and
on
the
recommendation
of
andrew,
I
thought
I
would
show
you
guys
a
little
bit
of
code
real
fast
to
talk
about
even
with
d3
giving
us
a
lot
of
data.
Making
something
custom
can
take
a
lot
of
work,
so
this
is
literally
the
very
exciting
math
code
that
tells
you
and
a
like
little
essay
comment.
I
wrote
about
it
so
that
when
I
or
anyone
else
comes
back
in
six
months,
we
have
a
vague
idea
of
what
the
heck
is
going
on
in
here.
A
So
even
just
to
make
these
points
right,
we
have
to
go
through
and
find
like
where
each
node
is
sitting,
and
then
we
scatter
these
points
along,
but
we
have
to
make
sure
that
as
we
scatter
them
along
if
they
become
too
far
on
this
side
or
too
far
on
this
side,
we
can
move
back
around.
I
also
use
a
little
bit
of
randomness,
which
is
like
I
like
to
think
of
as
svg
drawing
magic.
A
You
can
see
over
here
this
math.random,
and
that
makes
it
so
that
nodes
that
might
sit
all
at
one
end
because,
as
you're
going
around
the
edge
right,
you
get
different
nodes,
but
they
don't
all
sit
on
top
of
each
other.
I
guess
I
don't
have
a
really
good
example
in
these,
but
they
don't
sit
all
on
top
of
each
other,
so
that
was
a
really
fun
thing.
Another
very
fun
like
low
level.
Svg
problem
you
have
to
solve
is
how
to
do
these
labels.
A
This
also
has
lots
and
lots
of
code
behind
it
to
try
to
figure
out
where
the
label
is
and
keep
it
from
overlapping.
The
line
too
much.
You
can
see
here
that
nothing
is
perfectly
possible
that
when
you
have
data
some
things
just
happen,
so
staging
c
is
overlapped,
but
overall,
that's
also
custom
code
to
make
sure
our
labels
are
showing
up
with
svgs.
It's
a
really
interesting
problem
that
I'm
happy.
If
people
want
to
learn
more
about
it
technically
to
talk
about,
but
basically
you
can't
wrap
code
in
a
cat
wrap
code.
A
You
can't
wrap
text
in
svgs,
so
all
of
these
labels
are
a
correct
length,
but
if
we
jumped
into
another
one,
I
don't
think
I
have
an
example
of
it.
The
titles
can
be
any
length.
You
want
right
talking
about
data
again,
people
can
put
in
whatever
they
want,
so
we
actually
like
inject
divs
into
svgs.
Like
you
have
this
svg,
and
then
you
create
a
new
context
and
you're
like
okay.
A
Now
this
is
regular
html
again
and
those
are
like
the
kinds
of
problems
that
we
solve
to
get
labels
that
can
wrap
and
look
good,
which
I
think
is
really
interesting.
A
A
So
this
also
brings
us
up,
though,
to
an
interesting
problem
that
we
were
even
unaware
of
with
some
of
the
other
ways
we
viewed
the
graphs,
which
is
you
can
positively
have
a
link
where
neither
end
of
that
link
is
visible
on
the
graph.
At
the
same
time
when
you
scroll,
but
given
the
layout,
it
is
not
possible.
A
So
our
next
step-
and
you
can
see
sort
of
a
hint
of
it
here-
this
was
in
the
sort
of
pre-work-
is
going
to
be
adding
annotations
so
that
you
can
click
on
links
and
click
on
paths
and
the
users
can
sort
of
hold
their
whole
annotation
in
front
of
them,
and
that
will
be
the
next
step
and
once
we
have
the
annotations
ready,
hopefully
by
the
end
of
13
1,
we
will
also
have
a
little
beta
tag.
Asking
users
to
come
to
an
issue
and
tell
us
about
their
dags.
A
Tell
us
about
their
weird
dags.
Tell
us
what
they
love
tell
us
what
they
hate
tell
us
what's
broken,
because
we
can
only
guess
so
much
and
I'm
actually
super
excited
to
hear
about
that
and
to
keep
iterating
on
different
ways
to
make
our
pipelines
comprehensible
to
our
users,
because
I
think
this
is
like
so
cool
and
so
interesting
and
it's
such
a
core
of
what
sets
us
apart
and
also
I
like
putting
weird
math
in
the
front
end.
So
it's
basically
everything
I
can
look
for.
C
D
I
I
know
where
we've
been
thanks
for
showing
by
the
way,
sarah.
I
think
this
is
amazing,
work
and
indeed
beautiful
and,
as
I
said
in
the
comments
I
I
love
the
iterative
thinking
here
and
I
love
what
you
said-
that
you're
kind
of
like
trying
to
implement
the
solution
and
then
you're
going
to
be
like
also
at
the
same
time,
checking
in
with
people
and
seeing
like
what
else
could
we
take
into
account
here
a
question?
D
I
know
that
earlier
we
have
started
from
the
beautiful
was
a
d3
right
graph
for
the
that
visualization,
and
I
know
that
you
worked
with
dimitri
a
lot
on
that
curious.
What
is
the,
what
is
the
collaboration
with
the
product
designer
right
now
looks
like?
Is
there?
Is
anyone
involved
with
you
know?
Would
you
like
to
have
more
support
there.
A
Yeah,
that's
a
good
question.
It
was
a
very
interesting
process.
I
think
dimitri
kind
of
went
on
vacation
and
then
he
came
back
and
I
was
like
hi.
A
I
changed
everything
we're
building,
so
that
went
really
well
and
I
highly
recommend
doing
that
when
you
work
with
designers,
nothing
bad
ever
happens
when
you
do
that,
so
we
have
gone
back
and
forth
and
like
right
now
I
think
I
know
where
our
aim
is,
but
right
now
I've
been
focused
on
getting
this
first
step
out
and
then
I
think,
with
either
dimitri
or
with
our
new
designer
I'm
hoping
there
will
be
more
tinier
iterations
to
be
like
okay.
This
is
what
we
have.
This
is
what
we've
heard
now.
A
How
can
we
once
we
have
this
like
nice
base
surface?
I
think
it
will
be
really
fun
to
like.
Do
the
smaller
iterations.
D
Yeah
definitely
definitely,
and
I
will
make
sure
that
we
try
to
be
more
helpful
there
as
we
now
have
a
stable
counterpart
on
the
design
side.
We
have
talked
with
darby
and
we'll
share
a
little
bit
about
the
iterative
design
and
we
will
be
trying
to
be
a
better
partner
there
in
the
future,
but
great
work
thanks.
So
much
for
sharing
and
yeah
looking
forward
to
see
this
coming
forward.
A
I
think
a
good
learning
is
we
could
have
done
a
more
iterative
design
even
to
the
level
of
being
like
we
did
in
iteration
office
hours,
the
ci
team-
and
we
talked
about
this
too,
and
I
think
one
of
the
things
that
would
be
good
would
have
been
not
even
drawing
a
graph
first
like
making
a
list
of
the
nodes
and
being
like
this
is
what
we
can
do
and,
like
you
know,
making
some
like
nice
little
rectangles
around
those
nodes
to
see
what
kinds
of
questions
people
were
answering
and
like
even
building
from
there
could
have
been
an
interesting
way
to
do
it
like
I
love
this
graph,
so
I'm
not
like
sad.
A
We
did
it
this
way,
but
I
think
that's
a
way
that
it
could
have
been
also
a
little
bit
more
iterative.
I
noticed,
too
that
sean
asked
how
we
write
tests
for
this,
which
is
a
very
good
question.
Let
me
see
if
I
can
grab
the
spec
really
fast.
A
And
I
might
be
able
to
pop
this
back
up
on
here.
Share
screen.
I
don't
know
how
useful
it
is
to
look
at
the
code,
but
I'm
going
to
show
you
anyway,
so
the
most
important
way
that
I've
sort
of
fallen
down
to
testing
it
is.
This
is
a
case
where
we
use
the
where
we
actually
use
snapshots,
I'm
not
always
a
huge
fan
of
html
snapshots
just
because
they
can
be
really
brittle
a
snapshot
for
folks
who
don't
do
this
every
day.
A
Basically,
there's
a
way
to
write
a
test
where
you
say
mount
this
component,
pretend
like
it's
in
the
dom
just
this
like
little
section
of
it
and
now
save
a
file
that
just
has
all
the
text
of
the
html
of
the
code
that
renders
this
and
then
every
time
we
run
tests
again,
it
checks
the
new
version
against
the
version
that
it
saved,
and
it's
like
did
this
change
and
we
ended
up
using
that,
because
svgs
can
be
very
hard
to
sort
of
like
look
into
programmatically
and
sometimes
things
can
seem
to
render.
A
So
we
use
snapshots
for
that
and
then
the
other
thing
is
I
just
sort
of
look
into
like
you
know:
are
there
as
many
linear
gradients,
which
is
the
color
for
that
link
as
there's
links
in
my
parse
data
same
with
like
nodes
and
labels,
so
a
lot
of
it
is
counting
and
then
likewise,
there's
actually
this
whole
other
universe
of
parsing
the
data
when
it
comes
from
the
back
end
that
I
didn't
even
talk
about
that
again.
A
If
somebody
wants
like
a
technical
run-through
of
this
pricing,
I'm
super
happy
to
do
again,
but
so,
in
this
case
we're
literally
sometimes
just
checking
that
the
node
structure
comes
out
with
the
properties
we
want.
I
think
it's
a
little
bit
imperfect,
but
I
think
it's
pretty
good
and
when
I
wrote
the
tests
I
found
some
bugs
so
they're.
Definitely
working
correctly.
E
It's
so
awesome.
Sarah,
thanks
for
explaining
that,
by
the
way
about
the
snapshots.
E
So
will
this
be,
is
this:
when
will
this,
you
know,
eat
production.
A
Hopefully,
by
the
end
of
thirteen
one,
so
I've
been
doing
many,
many
tiny,
mrs,
I
think
I'm
on
like
if
we
count
the
back
end.
Mrs
at
fabio
also
did
I
feel
like
we're
on,
like
mr,
like
number,
nine
or
ten
or
something
at
this
point.
It's
a
bunch
of
small
pieces
so
like
I
did
the
mvc
and
the
proof
of
concept
work
that
we
worked
on
and
then
I've
been
moving
it
over
in
chunks
and
making
the
code
more
production
ready.
A
So
there's
two
left
there's
the
interactions
one
which
I'm
in
the
middle
of
working
on,
which
I
demoed
for
you
and
then
there
will
be
the
annotations
one.
Hopefully
that'll
flip
in
thirteen
one.
If
annotations
don't
go,
I
think
it's
worth
having
a
discussion
whether
we
still
wanna
send
the
graph.
It's
sad,
because
if
things
are
really
tall,
then
you
might
not
know
what
you're
looking
at.
But
if
that's
you
know
a
two
percent
case,
and
you
know
we
can
still
get
98
percent
of
people
looking
at
it.
A
All
right,
I
think,
that's
it.
I
went
over
the
recommended
15
minutes
by
only
two
minutes.
I
think
that's
not
so
bad
and
now
peyton
is
going
to
talk
more
about
pipelines
about
different
new
other
exciting
pipeline
features.
We're.
A
A
Peyton
just
texted
and
says
his
zoom
dropped,
so
I
think
maybe
we
can
give
him
a
minute
or
two
and
see
if
it
will
come
back.
Otherwise.
I
don't
think
I
can
also
demo
that,
because
I
don't
think
I
I
don't
know
if
it's
from
behind
the
feature
flag
in
production,
although
it
might
be.
B
B
What
what
maybe
maybe
another
question,
if
you
don't
mind,
sarah
yeah,
on
the
on
the
visualization
there,
which
was
really
cool
by
the
way,
thanks
for
sharing
that
it
was
awesome
looking
at
it
now,
what
would
you
do
differently
now,
you've
got
to
where
you
are.
If
you're
going
to
go
back
and
start
this
again.
A
That's
a
very
good
question.
I
definitely
think,
like
I
said
before,
I
would
have
gone
back
to
doing
sort
of
just
like
representations
as
rectangles
like
can
we
display
this
data?
What
does
it
look
like
because
even
answering
that
question
opened
a
whole
bunch
of
other
ones?
You
know
and
be
like
great.
What's
the
question
we
want
to
answer
great,
we
don't
necessarily
have
to
show
every
relationship.
We
can
just
show
like
a
generation,
zero
job,
a
generation,
one
job,
a
generation,
two
job
and
sort
of
like
see
those
stack
up.
A
I
think
that's
the
biggest
thing.
I
would
change
the
other
decision.
I
made
that
I
think,
is
the
right
one.
But
if
I
had
like
infinite
time,
I
might
have
like
tried.
Both
versions
is
the
way
we're
doing
this
with
d3
and
end
view.
Is
that
so
d3
and
vue
both
operate
on
the
dom
and
they're
both
written
to
operate?
That
way
right,
like
they're,
not
necessarily
meant
to
go
together
or
they
don't
think
about
how
they
would
interact.
A
So
we've
chosen
to
do
it
with,
like
a
view,
shell
and
then
mostly
d3,
operating
the
dom
partly
too,
because
since
view
puts
watchers
on
every
object,
you
add
into
the
dom
through
view.
I
think
it
saved
us
a
lot
of
performance
headache
to
use
d3
because
we're
not
like
instantiating
view
objects
with
all
of
their
getters
and
setters
on
it.
But
I
would
have
been
interested.
A
It
does
mean
that
there's
a
certain
amount
of
like
managing
how
you're
referring
to
pieces
that
you
don't
have
in
view,
and
I
would
be
interested
to
see
what
that
would
look
like
architecturally.
If
I
like,
did
it
both
ways.
So
I
don't
think
it
was
the
wrong
decision.
But
it's
a
decision.
I
would
like
to
have
time
to
dig
into
more,
but
I
think
seeing
how
people
use
it
is
sort
of
more
important
than
the
like
code
structure.
B
That's
that's
a
really
good
answer.
Thank
you
very
much
for
that.
What
I'm?
What
what
I
find
interesting
in
your
answer
is
like.
I
always
wondered
about
this
myself
when
you
get
to
a
point
you're
like
oh
man.
I
wish
I'd
done
this
thing
or
that
thing,
but
I'm
also
hearing
your
discussion
on
performance
considerations
around
implementation
and
that's
like
I'm
lining
that
up
with
the
career
matrix
that
I'm
working
on
and
thinking
about
how
people
think
about
these
things.
So
thank
you
so
much
for
sharing
that.
I
appreciate
it.
B
Peyton
says
that
his
internet
is
flaky.
Did
he
make
it
back
on
yet
I'm
not
sure
he'll
be
able
to.
B
Yeah,
it
looks
like
I
maybe
just
check
in
with
him
and
see
if
he's
gonna
make
it
back
on,
if
not
we'll
probably
just
end
it
here,
unless
someone
else
wants
to
randomly
demo
something
cool.
F
B
A
I
had
one
other
shout
out
for
this,
of
course,
which
is
actually
for
andrew.
He
reminded
me
so.
A
A
But
it's
been,
I
think,
a
great
example
of
the
process
that,
like
we
took
this
big
chunk
of
work
and
said,
okay,
we're
going
to
be
the
people
who
know
how
all
of
this
works
right
now
and
like
keep
building
on
it,
and
I
think
that
it
would
have
been
a
lot
harder
to
do
our
like
10
000,
mrs,
if
we
didn't
have
some
like
consistent,
really
helpful
reviewers
for
the
big
chunk
andrew
and
I
actually
even
did
a
phone
call,
which
I
kind
of
recommend
that
I
was
like
all
right.
A
F
C
Hey
yeah,
sorry,
I
don't
know
if
I
should
probably
keep
my
video
off.
Does
that
typically
help
with
internet
connection?
C
B
C
No,
I
do
not
okay,
so
in
13.0
we
released
pipeline
filters.
This
is
probably
not
as
exciting
as
sarah's,
but
it
was
a
well
sought
after
feature.
C
C
We
are
introducing
status,
which
I
have
an
open,
mr
on
that
so
we'll
be
able
to
filter
by
status
and
kind
of
get
more
granular
on
what
we're
actually
filtering
by
and
also
my
tag
name.
C
So
that's
a
git
tag,
so
that's
pretty
cool
as
well
kind
of
how
it
works
behind
the
scenes
is
we
render
the
first
20
trigger
authors
on
load
and
then
each
subsequent
trigger
author
so
like,
if
you're
going
to
search
for
peyton
like
each
each
keystroke
actually
is:
let's
try
that
again,
so
we
can
see
it.
C
Each
keystroke
is
actually
delayed
with
d
balance
and
low
dash
so
for
performance
reasons,
we're
searching
each
keystroke
to
find
out
where
the
user
is,
and
that's
really
important,
to
have
an
api
that
supports
search,
allows
us
to
do
things
like
this,
without
rendering
way
too
many
branches
users
or
anything
like
that.
We're
actually
working
on
some
performance
improvements.
It's
decent
right
now,
but
not
the
best,
so
back
ends
actually
got
a
few,
mrs
open.
C
C
You
know,
especially
when
status
is
released,
we
won't
have
redundant
filters
and
what
all
makes
this
possible
is
the
sweet,
gitlab,
ui
component,
filtered
search
and
then
so
you
pretty
much
use
this
for
your
tokens
and
the
styling
and
everything
and
then,
as
far
as
like
the
actual
implementation
of
filtering
and
any
anything
to
actually
make
it,
work
is
done
on
the
implementation
site
and
that's
my
quick
little
demo
of
pipeline
filters.
C
C
Yeah,
that
is
a
good
question.
I
think
it
was
a
ux
decision
because
it
actually
is
a
little
hard
on
the
implementation
side,
because
branch
and
get
tag
actually
both
use.
The
ref
query
parameter,
so
you
can't
have,
if
I
had
the
tag.
Branch
open.
It'll,
probably
take
me
a
while
to
get
that
open,
but
with
tag
name
like
we
kind
of
have
to
hide
branch
name.
C
If
tag
name
is
selected,
you
know
because
we
can't
have
two
ref
parameters,
but
I
assume
my
probably
that
say
if
you
came
to
branch
name
and
you
wanted
to
render
the
first
20
branches
and
also
the
first
20
tags-
or
you
know
like
how
do
you
handle
that
in
the
ui
like?
C
Would
we
break
it
up
with
you
know,
maybe
like
branch
up
here
at
the
top
and
then
down
halfway
down
like
tag
and
then
like
you
have
to
use
one
api
to
find
branches
and
tags,
so
you
have
to
handle
input
from
the
user
and
still
make
two
api
calls
to
return
the
data
for
that.
So
I
don't
know
how
performant
that
would
be.
A
C
Oh
yeah,
absolutely
so
if
I
can
actually
find
the
okay
yeah,
so
let
me
find
epic
okay,
so
originally
the
epic
was
pretty
huge
to
all,
introduce
it
into
one
milestone
that
was
like,
or
it
used
to
just
be
an
issue,
not
epic,
so
it
was
trigger
author
pipeline
status,
trigger
source
branch
name
tag
name,
and
when
I
was
looking
at
this,
I
was
like
yeah.
That's
that's
going
to
be
super
hard
to
do
and
one
milestone.
C
So
what
we
did
was
was
promoted
this
to
an
epic
and
then
we
introduced
trigger
author
and
branch
name,
which
were
the
most
sought
after
filters,
and
then
we
looked
into
doing
pipeline
status
and
tag
name
in
the
next
iteration
and
trigger
source
isn't
supported
from
back
end.
Yet
so
we'll
need
to
get
that
in
place
before
we
actually
put
that
into
effect,
and
everything
for
this
is
currently
behind
a
feature
flag.
So
we
can,
if
anything
goes
wrong.
You
know
we
can
flip
it
back,
really
quick,
but
so
far
so
good.
C
I
haven't
heard
any
bugs
or
anything
like
that.
Only
anything
was
we
got
a
few
internal
performance
questions
that
we
had
some
concerns
about,
like
we
were
getting
anywhere
from
like
five
to
six
seconds
network
response
on
a
few
of
the
bigger
queries,
so
back
ends
kind
of
looking
into
that
to
see
how
we
can
manage
that
with
pagination
and
more
performing
queries.
E
C
Okay,
any
any
other
questions.
C
Share
and
sorry
about
the
video
drop,
I
don't
know,
I
don't
know
if
it's
having
a
little
one's
home
and
they're
watching
youtube
and
stuff
or
I
don't
know,
what's
going.
B
B
Cool
does
we're
kind
of
like
pretty
early,
and
I
don't
mean
to
be
stepping
in
here,
but
I
guess
I'm
wondering
if
people
feel
like
this
format
is
good
and
while
we're
like
people
that
are
interested
are
here,
do
we
have
any
suggestions
on
how
we
might
change
or
any
thoughts
there?
B
D
I
think
this
is
an
amazing
format.
It
really
helps
you
to
to
see
what
work
is
actually
being
done,
like
kind
of
like
hear
the
real
story
behind
that,
it's
really
really
helpful
for
me
so
really
appreciate
these
sessions.
I
wish
we
could
have
the
same
in
other
stage
groups
as.
C
What
happens
if
no
one
has
anything
to
demo,
you
just
just
skip
it.
Just.
B
Yeah
cancel
it.
I
tried
to
account
for
that.
Well,
I
want
to
say
hi,
there's
a
lot
of
people
that
have
been
trying
to
set
this
stuff
up.
So
we
tried
to
account
for
that
by
saying
like
if
we
don't
see
anything
in
the
agenda
a
couple
hours
before
the
meeting-
oh
just
skip
it,
but
we
want
to
be
as
flexible
as
we
can
and
make
really
be
very
careful
about
the
synchronous
time
we're
using
because
it's
it's
nice
to
chat
with
everyone.
B
That's
awesome
but,
like
maybe
people
want
to
do
other
things
with
their
real
focused
time
at
the
same
time,
so
I
don't
really
mind
if
people
want
to
do
something
different.
I
thought
I
saw
something
in
the
handbook
ages
ago.
If
we
didn't
have
questions
up
like
nine
hours
before
or
something
I
forget
where
that
was
though
it's
that
whole.
My
brain
tells
me
something
about
the
handbook
that
may
may
not
be
true
kind
of.
A
I
really
like
this
format.
I
was
happy
to
get
to
come
this
time
and
to
see
I
always
want
to
see
what
other
people
are
working
on
too,
just
because
too,
our
product
is
so
big.
Even
our
feature
area
that,
like
knowing
what
other
people
are
working
on,
tells
me
a
lot
like.
I
always
learned
something
about
how
our
product
works
too.
I
want
to
see
some
back
end.
Demos,
though
you
guys,
should
do
demos,
even
if
it's
just
like
typing
something
in
and
something
coming
out,
the
rails
console.
A
I
think
that
still
counts
as
a
demo,
and
I
want
to
know
what's
lurking
in
there.
So
I
want
you
guys
to
show
me
what
you're
doing.
E
I'm
in
demo,
as
always
much
cooler,
it's
like
yeah.
I
just
spent
two
weeks
on
this.
You
know
small
amount
of
code
and
front
end
is
like
wow.
Look
at
this
flashing
glowing
thing.
F
C
D
B
F
B
All
right
don't
have
any
emacs
pedals,
yet
cool.
I
think
we're
good.
Does
everyone?
Is
everyone
good
with
stopping
the
recording
there
yeah
awesome?
Thank.