►
From YouTube: CI/CD workspaces, DAGs, and more
Description
Join Mark, Kenny, Brendan, and Jason for a discussion about DAGs, workspaces, simple primitives in the pipeline, and more.
A
Okay,
cool
well
thanks
what
I
wanted
to
do
was
just
temperature.
A
bunch
of
thoughts
that
you
could
argue
I
was
just
not
whatever
too
lazy
to
put
in
an
issue
but
more
pointedly.
It's
really
complicated
and
spans
like
a
whole
bunch
of
different
issues,
and
so
I
wanted
to
sort
of
just
transfer
knowledge
as
much
as
I.
Could
this
effects
verify
more
than
release,
so
it's
unfortunate
Brendon
can
be
on
it,
but
at
least
he
gets
to
watch
the
view
later,
but
I
wanted
to
sort
of
do
it.
B
A
Yeah
so
I
just
wanted
to
at
least
do
a
knowledge
transfer,
but
then
also
try
to
capture
some
of
the
things
that
have
been
in
my
head,
that
I
haven't
written
down
or
articulated
because
there's
this
interplay
between
like
four
or
five
or
even
more
issues.
That,
in
my
mind,
make
this
beautiful
direction.
But
it's
like
totally
unobvious
and
I
wanted
to
at
least
have
an
attempt
at
starting
to
articulate
it
and
see.
If
we
can,
you
know,
get
this
written
down
somewhere
so
that
it
makes
sense.
A
A
A
I
wanted
to
basically
just
do
a
knowledge
transfer
on
a
bunch
of
issues
to
at
least
sort
of
explain
what
they
were
about,
because
some
of
these
issues
only
two
years
old,
but
then
also
trying
to
pull
them
together
and
see
if
I
can
create
a
story
about
how
they
fit
together
to
create,
like
a
really
wide
believe,
is
a
really
compelling
vision
of
how
to
move
forward.
So
I'm
just
pulling
up
a
couple
of
issues
right
now
to
see
to
start
off.
A
A
I'll
jump
in
okay,
so
the
topic
here
is
like
how
how
a
bunch
of
pieces
play
together
but
directed
acyclic
graphs
and
then
actually
I'll.
Give
you
a
little
bit
of
a
story
here
too,
because
this
was
sort
of
my
the
start
of
my
tracking
this
inspiration
and
then
a
bunch
of
things
sort
of
distilled
down.
We
have
a
bunch
of
users
that
find
our
artifacts
in
caching
and
things
like
that
to
be
really
confusing.
A
They
don't
know
when
to
use
what
we
end
up
using
artifacts
for
inter
job
communication,
so
that
you
know
you
have
one
job
that
builds
a
thing
and
there
another
job
that
tests
it
well.
You
need
to
pass
the
thing
that
you're
gonna
test
as
a
matter
of
fact,
but
then
we
also
use
artifacts
for
like
okay
after
the
whole
thing
is
done
now.
This
is
the
build
that
you
should
download
to
get
the
software
in
those
cases,
it's
a
simple
like
oh
they're,
both
artifacts
same
thing,
but
it's
not
always
that
way.
A
Sometimes
like
give
me
a
job
and
like
oh,
you
just
need
to
pass
this
one
piece
of
information
to
the
next
job
and
it's
like
a
text
file
or
it's
a
variable
or
it's
something
else
and
like
artifact,
feels
like
the
wrong
thing
and
anyway,
lots
of
people
have
confusion
and
a
lot
of
times.
Actually
the
content
between
the
thing.
This
is
just
files,
and
it's
really
like
I
have
one
job
that
forum.
It
does
a
bundle,
install
and
then
I
have
another
job
that
actually
does
a
run
of
the
thing.
A
But
if
you're
not
careful
well,
then
that
all
the
files
you
just
downloaded
in
the
bundle
install
disappear
and
it's
really
confusing
people
and
you
can
try
to
use
cache
because
that's
what
logically
people
think
about,
but
then
sometimes
cache
fails
because
it's
the
best
effort
basis
to
cache
right.
It's
not
a
permanent
record.
It's
not
guaranteed
record
it's
supposed
to
be
just
like
sort
of
like.
If
there's
an
avarage
like
a
space,
then
you
cache
so
then
am
I
gonna
work
sometimes,
but
then
occasionally
like.
A
Oh,
you
don't
have
cash
this
time
in
that.
My
second
job
fails,
village
is
really
confused,
and
the
answer,
of
course,
is
these
artifacts.
But
people
are
really
confused
by
that
because,
like
this
is
really
heavy
and
like
on
my
local
machine,
all
I
would
do
is
just
type
these
two
commands
and
the
space
would
be
consistent.
So
people
have
questions
like
how
do
I
get
started
so
for
a
while
we
talked
about
like.
A
On
that
same
runner
and
that's
fine
I,
don't
think
that
only
works
if
you've
got
a
single
like
parallelism.
Oh
you've
got
one
runner
like
there's
no
way
to
sort
of
do
multiple
jobs
in
parallel
that
all
use
the
same
runner
you'd
have
to
that
sequential
azzam.
And
so,
while
it's
nicer,
it's
conceptually
nicer,
it's
not
nearly
as
effective
and
in
particular,
there's
this
jarring
sort
of
move
where
you
like.
A
I
really
wanted
to
avoid
that
and
I
think
that
workspaces
is
a
really
great
way
to
do
it
because
there's
a
there's,
nothing,
you
can
just
start
off
and
say
well,
the
simple
mode
is
that
everybody
share
the
workspace
by
default
or
maybe
not
even
by
default.
Maybe
you
have
to
declare
it
because
we're
backwards
compatible,
but
the
point
is
would
be
like.
Oh
the
one
little
declaration
I've
got
works.
A
A
Especially
as
they
get
older
I
think
they
literally
what
our
batteries
are
dying
anyway.
So
I
think
workspaces
is
just
a
really
elegant
solution
for
it,
because
it's
like
one-line
declaration
and
then
now
it
does
behave
differently,
but
it's
it's
intuitive,
it's
understandable
or
whatever
so
I
feel
like
it's.
A
really
particularly
good
solution
to
the
problem
of
I
want
to
just
get
started.
Not
worry
about.
Caching
artefacts
just
make
it
easy,
but
also
be
really
powerful,
so
that
I
can
do
multiple
parallelism.
A
I,
don't
need
to
worry
about
using
the
same
runner
over
and
over
I.
Don't
have
to
buy
a
machine
to
have
my
state
because
it's
the
other
thing
people
coming
from
like
a
a
Jenkins
kind
of
thing.
They've
got
a
machine
and
it's
like,
oh
well,
you
did
the
bundle
install
like
everything's
cached,
it's
because
it's
just
a
directory
structure
using
the
same
directory.
Every
time
you
do
a
run
and
it's
really
easy
mental
model,
because
that's
a
it's
an
extension
of
my
local
machine.
A
It
behaves
just
like
my
local
machine
would,
but
it's
just
not
good.
We
know
that
there's
huge
problems.
Like
then,
I
write
like
I,
run
my
job
once
I
run
it
again
and
I've
got
different
behavior,
oh
because
somebody
else
might
have
bundle
installed
differently
and
they
did
something
different
you're
like
what
it's
like
things
should
be
that
brittle.
So
I
really
love
that
we've
got
this
repeatable
thing.
A
I
know
many
workspaces
is
a
really
good
answer
and
circusy
I
specifically,
did
it
in
such
a
way
where
you
can
have
parallelism
and
then
I
think
it
might
even
like
do
a
union
of
the
file
systems
afterwards.
But,
however,
it
is
they've
solved
this
problem
so
that,
like,
if
you
touch
a
file
in
one
stage,
then
the
next
stage
will
get
the
changes
to
that
file.
A
But
if
you
don't
touch
anything,
then
you've
been
great
like
you
just
pull
in
things
and
it's
relatively
efficient
and
you
don't
have
to
worry
about
using
the
same
runner.
So
it's
a
good
solution,
but
the
other
side
of
that
is
so
that's.
The
easy
side,
like
the
other
side
of
CI,
is
like
okay,
now
I
want
a
really
advanced
one,
and
this
is
where,
like
okay,
I've
gone
way
beyond
just
having
a
single
pipeline,
I've
got
lots
of
parallelism,
but
now
parallelism
is
even
wrongly
that's
enough.
A
I
now
need
like
I
need
a
directed
acyclic
graph.
I
need
to
be
able
to
have
really
complicated
stuff
that
I
don't
want
to
wait
for
everything
to
be
lockstep,
I
want
it
to
be
as
efficient
as
possible
and
I
want
to
be
able
to
like
if
I'm
gonna
build
I
owe
s
in
Android.
At
the
same
time,
if
I
OS
succeeds,
I'm
gonna
call
that
success
and
still
deploy
the
iOS,
even
if
the
Android
one
fails,
whereas
like
a
current
pipelines,
it's
like
well.
A
A
How
we
saw
the
advanced
case
and
I
believe
that
these
two
things,
these
small
primitives,
are
really
great
at
solving
this
in
a
really
really
elegant
way,
like
workspaces,
is
actually
a
really
powerful
tool,
but
also
just
makes
things
really
really
simple
and
the
way
that
I've
specifically
talked
about
the
direct
database
says
it
graphs,
because
you
got
like
smart
defaults,
makes
it
like
if
I
don't
want
to
deal
with
drug
today.
Second
graphs,
they
just.
A
Oh,
this
is
just
I
would
just
declare
my
stages.
That
I
mean
works
exactly
as
it
is,
but
if
I
want
to
say
oh,
but
now
I
want
to
have
an
exception.
I
will
actually
have
this
not
depend
on
all
the
results
of
this
previous
stage.
I
want
to
depend
on
one
specific
job
of
this
previous
stage.
You
kick
it
off
as
soon
as
that
one's
done.
A
Well,
then,
you
just
declare
a
specific
predecessor
or
triggered
by,
or
you
know
some
other
word
dependency
and
I
just
declare
a
smaller
dependency
than
the
default,
but
then
also
within
a
stage
being
able
to
say
what,
if
I've
got
two
jobs
in
a
stage
that
depend
on
each
other.
Well,
then,
they'll
just
have
to
happen
in
sequence,
but
but
you
know
it's
really
easy
like
the
default
would
be.
They
would
just
both
work
in
left,
lock
stop,
but
by
just
declaring
a
different
dependency.
Now
suddenly
I've
got
directed
acyclic
graphs.
A
If
you
really
have
a
complicated
graph,
then
it
it
might
mean
you've
got
now
complicated,
see
I
yamo
rather,
but
but
at
least
it's
like
well
but
complication,
goes
with
complication.
The
simple
case
is
still
simple,
so
I
think
these
two
primitives
are
really
really
powerful,
though
the
predecessor
thing
and
the.
A
The
workspaces
thing
I
can
basically
ignore
workspaces
from
now
on
the
rest
of
the
things
now
branch
off
in
really
interesting
areas.
When
I
started
talking
about
the
predecessors,
whatever
we
call
it
the
dependency,
then
it
gets
really
interesting
when
you
start
talking
about
multi
project
pipelines
and
then
also
when
you
talk
about
artifacts,
because
they
all
kind
of
dovetail
together.
If
we
have
a
mechanism
to
say
that
this
job
depends
on
this
other
job,
but
what
does
it
depend
on?
Does
it
depend
on
the
successful
completion
of
that
job?
A
Does
it
depend
on
the
artifact
that
that
job
produced?
We
already
have
a
mechanism
that
actually
declares
that
this
job
depends
on
that
artifact
and
by
default
every
job
depends
on
every
artifact.
So
if
you
don't
specify
anything,
you
just
get
all
the
artifacts
that
are
produced,
but
you
can
narrow
it
down
and
say
well,
I
only
depend
on
this
more
matter-of-fact.
A
So
then,
like
there's
a
logical
question
of
well
once
I've
got
that
like.
Why
don't
I
just
say?
Well,
then,
let's
start
running
as
soon
as
that,
the
artifact
is
available.
Why
don't
I
use
it
for
not
just
the
data,
the
artifact,
but
also
the
triggering
mechanism,
the
obvious
failure
mode?
There,
though,
is
let's
say:
I've,
got
build
test
and
deploy
and
really
simple
pipeline
right,
but
my
deploy
clearly
depends
on
the
build,
artifact
and-
and
maybe
the
test
stage
also
has
artifacts
that
gets
God,
j-unit,
XML,
output,
right
and
I.
A
Don't
need,
like
my
deploy,
doesn't
need
the
junior
XML
artifact,
but
does
need
to
be
triggered
when
the
tests
work,
because
otherwise,
if
I
just
said
well
as
soon
as
the
build
is
done,
let's
start
deploying
it
you've
totally
sidestepped
the
security
of
the
CI
pipeline
that
doesn't
make
any
sense,
so
that
deployed
job
actually
depends
on
the
artifact
from
build
and
the
result
from
test.
And
so
then
you
got
is
like
okay.
How
do
we
do
this?
How
do
we
deal
with
the
complexity?
A
A
A
But
if,
for
whatever
reason,
I
wanted
to
say,
oh
but
I've
got
this
other
pipeline
over
here,
you
know:
I've
got
an
Android,
build,
we've
got
an
iOS,
build
and
I
declare
the
dependencies,
and
you
can
realize
that
oh,
the
iOS
build
the
iOS
deploy,
does
not
depend
on
the
Android
build.
Well,
then
great,
it's
free
to
run
as
quickly
as
possible.
So
this
the
the
cognitive
load
of
that
deployment,
like
that
the
model
is
really
really
light.
With
the
caveat
that
there's
a
there's,
a
certain
amount
of
cost
involved.
A
A
There's
a
backward
compatibility
problem
that
if
it
were
to
have
to
work
through
because
right
now,
if
I
do
have
build
tests
and
employee
and
I
literally
declare
dependency
on
that
other
thing.
I
don't
want
to
suddenly
break
my
build
because
I
start
deploying
because
I've
changed
that
effort.
You
can't
change
the
definition
of
dependency,
so
maybe
we
have
to
still
make
another
word
for
this,
but
maybe
this
becomes
the
successor
for
dependency.
A
You
know
we
talked
about
needs
as
one
of
the
things
like
what,
if
we
declared
needs
as
the
successor
to
all
of
this
and
just
say
needs
says:
oh
I
need
the
artifact
from
here
or
I
need
the
trigger,
and
then
we
can
evolve
it
if
and
when
necessary,
to
have
another
like.
Oh,
when
I
declared
this
job,
maybe
then
I
can
tell
well
what
do
I
need
from
that
job
and
I
could
say
well.
I
do
I
need
the
artifact
join
me.
The
success
status
do
I
need
something
else
for
that.
A
Maybe
in
fact
I
need
the
failure
status
and
that's
something
we
don't
talk
about
very
often,
but
we
have
a
failure
mechanism
right
now.
It's
at
the
stage
level
and
I
and
a
lot
of
people
are
need
more
granularity.
There
I
need
to
be
able
to
this
job
failed,
go
ahead
and
it
send
a
slack
notification,
but
that
doesn't
mean
you
stop
the
pipeline,
like
you,
keep
going
and
the
rest
of
the
pipeline
might
succeed.
A
A
Well,
what
if
I
just
say,
I
need
and
I
reference
a
job
in
another
pipeline
awesome
and
then
now
you've
got
the
same
thing,
though
now,
because
if
we
built
this
broad
primitives
nicely,
though,
as
they
layer
on
top
of
each
other
as
soon
as
I
say
well,
I
know
I'm
referencing
another
pipeline
well
great,
but
also
now
pull
that
artifact
from
that
pipeline.
Boom,
I've
grabbed
the
artifact
and
and
then
that
way,
you've
got
this
instead
of
having
a
like.
Oh
now,
cross-project
pipelines
are
a
different
keyword
and
they
all
behave
differently.
A
The
smaller
primitives
add
up
and
you've
got
a
really
nice
way
to
do
across
bunch
of
pipelines.
So
I
feel
like
again.
These
two
keywords
end
up
solving.
Yes,
there
is
an
issue
for
needs,
there's
several
issues,
unfortunately,
so
one
of
the
reasons
to
try
to
do
this
is
to
try
to
conjoin
these
things
back
anyway.
So
I'm
not
saying
this
is
like
a
mandate
or
whatever,
but
it's
possible.
If
we
said
look,
we've
got
just
one
way
of
doing
this
backwards.
A
If
one
produces
it
with
a
certain
name,
the
other
thing
needs
to
consume
it
with
that
name.
But
it'd
be
kind
of
really
nice
to
just
be
able
to
say
this
thing
spits
out
an
upper
image.
This
other
thing
consumes
that
Ducker
image
as
an
artifact,
and
so,
if
there's
some
other
way
and
I,
don't
have
a
good
proposal
for
that.
A
So
if
there's
some
other
way
that
we
can
fold
in
all
of
the
rest
of
our
like
docker
image,
but
also
the
rest
of
our
binary
management,
all
of
package
management
in
to
the
artifacts
system-
and
maybe
the
current
artifact
keyword-
is
only
file
based
I,
don't
know
if
that's
that
keyword,
but
there's
some
kind
of
thing
which
is
like
using
the
artifact
as
a
generic
term.
This
is
the
output
of
a
job.
It
can
either
be
files.
It
could
be
binaries
that
get
uploaded
to
a
package
registry.
It
could
be
a
container
images.
A
I'd
love
to
see
some
way
to
unify
that
stuff
together,
especially
then,
if
we
can
relate
to
this
whole
needs
thing
because
then
you
can
get
in
some
really
interesting.
Stuff,
like
like
oh
I,
just
built
a
another
docker
image
on
this
other
cross-project
pipeline
and
somehow
that
gate
that
triggers
this
thing,
because
that
new
image
was
there
or
that
image
failed
to
upload,
and
so
that
causes
sell
the
trigger
to
happen.
Like
there's
a
lot,
there's
some
really
thing.
A
D
A
Okay,
so
then,
let's
get
to
the
the
the
pipeline
stuff.
So
the
thing
here
is
that
the
directed
acyclic
graph,
its
expand
on
that
one
more.
It
can
get
really
complicated,
syntactically
to
start
declaring
all
these,
like
whatever
to
declare
like
things
that
in
a
lot
of
people's
minds,
would
be
really
independent.
Things
like
I've
got
an
iOS
pipeline
and
an
Android
pipeline
and
they're
not
related,
except
that
they
just
happen
to
share
our
code
base.
Maybe
that's
a
little
bit
too
extreme,
because
you
probably
should
design
them.
A
A
All
right,
yeah,
I'm
good
to
keep
going
sorry
just
got
a
calendar
I'll
try
to
speed
it
up.
Those
I
can
so
people
want
to
be
able
to
manage
pipelines
as
like
sort
of
discrete
things,
though,
and
we've
seen
from
like
github
actions
and
bitbucket
pipes
and
and
some
other
things
that
people
want
to
be
able
to
incorporate
and
reuse
third-party
declarations.
A
So
most
of
those
other
tools
are
still
at
the
job
level
like
I'm,
gonna,
reuse,
this
one
deployment
job
or
this
one
test,
job
and
I
think
if
it
says
more
than
that,
like
all
pipelines,
but
there
are
definitely
two
lenses.
There's
this
a
third-party
sharing
and
there's
just
really
like
within
that
company.
Like
you
know
the
mono
repo
example,
I've
got
different
services
and
they
each
need
a
pipeline.
A
Now
we
could
go
ahead
and
a
lot
of
proposals
are
things
like
well,
let's
put
a
dot,
give
up
CI
llamo
in
each
subdirectory
and
then
we'll
just
run
multiple
pipelines,
and
we
could
do
that.
But
another
way
potentially
to
do
it
is
just
to
have
still
one
get
web
see.
I
am
will
declaration,
but
then
split
out.
A
The
files
we
have
an
include
capability,
you
could
say
well
include
the
service
pipeline
from
this
service-
include
the
service
pipeline
for
this
service
and
include
all
of
these,
and
then
you
amalgamate
them
together
and
that's
your
massive
pipeline.
That's
fine.
It
would
be
functional,
but
it's
cognitive
load,
because
once
you
declare
that
the
pipeline
like
well
visualizations
gonna,
look
like
one
massive
pipeline,
but
maybe
that's
ok,
but
I'm
gonna
pick
up
editing,
it
is
gonna,
be
hard
like
you
now
need
to
make
sure
like.
A
Oh,
like
it's
like
everybody's
working
in
a
global
namespace,
you
know
like
you've
got
oh,
I
name
this
job
and
that
no
conflicts
with
this
other
job,
and
now
I
just
overloaded
because
they
llamo
work
so
just
merge
the
things
together
and
just
from
a
syntax
here.
It
just
you
know,
does
weird
stuff,
and
so
it's
just
gonna
be
really
really
hard.
So
pipeline
is
a
proposal
for
maybe
it's
an
iteration
of
include
I,
don't
know
MIT.
Maybe
it's
an
alternate.
A
Maybe
it's
just
another
keyword,
that's
a
type
of
include
I,
don't
know,
but
specifically
my
thought
process.
There
is
akin
to
a
function.
Call
with
variables
like
if
I
cut,
if
I
include
a
pipeline,
then
treat
that
pipeline.
Anything
that's
declared
locally,
just
as
treat
it
independently
and
so
like,
maybe
even
to
the
extent
that,
like
I've
got
jobs
that
are
declared
I've
got
stages
to
they're
declared,
but
those
are
like
independent
stages
and
they
don't
conflict
with.
Actually
that
may
be
too
far,
but
variables
is
particularly.
A
A
Probably
I'll
also
have
some
resolution
about
like
job
names
and
stuff
like
that
good,
but
basically
something
along
those
lines
where-
and
this
needs
a
little
bit
more
flex,
but
there's
something
here
where,
if
I
can
treat
that
pipeline
as
a
as
a
whatever
command
atomic
unit,
I
guess
it
helps
the
case
where
people
just
have
a
mono
repo
of
multiple
services
that
they
need
declaration,
but
it
also
might
help
the
third
party
in
the
marketplace
like
I,
could
just
package
up
a
pipeline?
Put
it
out
there
and
I
need
your
say.
A
Oh
and
you
know
I'm
just
gonna
reference
that
pipeline
and
it's
just
gonna
do
it
and
then
you
know
you
can
pass
it
a
few
variables
to
customize
it.
You
know
just
like
a
function
call
you
got
a
PL
pass
variables
in
and
then
there's
also
variables
internally,
that
are
local.
It's
all
about
scope,
I
feel
like
there's
something
really
interesting
there,
but
again
it's
all
just
gonna
be
related
to
in
the
end,
they're
just
gonna
be
directed
acyclic
graphs.
A
It's
just
that
that
graph,
like
everything,
that's
in
that
pipeline,
would
having
a
saved
trigger
like
a
predecessor
or
needs,
and
that
needs
would
be
just
scoped
to
the
pipeline
file.
And
so
if
I
say
that
my
deploy
stage
depends
on
test
well,
but
that's
only
the
test,
as
defined
in
this
file
and
it's
not
going
to
fund
depend
on
some
other
test
stage.
It's
only
gonna
depend
on
their.
A
So
again,
it's
still
using
the
primitives
of
the
directed
acyclic
graph,
but
it's
just
giving
now
a
syntactic
way
of
making
that
cleaner-
and
you
know
and
I
can
imagine
some
well
a
couple
of
other
enhancements.
One
simple
enhancement
would
be
when
you
do
the
include
or
the
pipeline
and
something
just
referencing
a
specific
file
like
what,
if
I
just
reference
a
directory
or
a
pattern
and
say,
look
for
this
like
directory,
slash,
star
or
start
Yammer
or
whatever
the
hell
and
then
I
could
just
feel
like.
A
Oh,
if
you
want
to
add
a
new
pipeline,
then
all
you
need
to
do
is
just
add
it
into
this
directory
and
then
now
you've
declared
your
pipeline.
That's
some
level
like
you'd.
Have
this
really
the
top
level
get
lab
CI
mo
can
be
really
really
trivial.
It
just
look
for
anything
under
the
next
directory
structure.
In
fact,
you
could
potentially
go
farther
and
say
what,
if
I
looked
for
like
dot
gitlab?
Well,
maybe
that's
the
wrong
place.
Maybe
I'd!
A
Look
at
like
star
slash
dot
gitlab
CI
mo
like
I,
could
put
a
regex
there
and
basically,
when
the
thing
runs,
it'll
just
look
for
all
the
sub
directories
and
look
for
a
get
live.
Ci
yo!
That's
in
that
top
level,
which
is
exactly
what
customers
asked
for,
but
we've
done
it
by
doing
these
small
primitives
and
saying
well
it
all
you
have
to
do
is
like.
If
that's
how
you
want
to
operate
great,
you
declare
a
gitlab
CIA
move
this
way
and
we'll
have
a
documented
and
then
now
hey.
A
Every
subdirectory
under
here
is
treated
as
an
impending
project,
but
we
don't
have
to
build
that
in
as
a
first-class
citizen.
It's
just
oh,
that's
just
the
nature
of
this
building
on
these
small
primitives
and
because
we
use
star
patterns,
it
just
makes
it
really
trivial,
because
what
will
happen
is
like
well
whatever
we
don't
necessarily
want
to
say.
Oh
the
right
way
to
do.
This
is
any
directory
that
has
a
get
web.
A
Cia
mole,
spins
up
a
separate
thing,
I
personally,
I'd,
rather
just
sort
of
build
on
what
we've
got
and
let
you
get
to
there,
but
but
using
smaller
primitives
I
guess
is
the
most
important
part
so
anyway,
so
I
think
that
pulls
in
a
bunch
of
the
areas.
The
topics
today
there's
got
two
more
topics:
I
want
to
sort
of
get
into
about
variables
and
some
other
kinds
of
stuff,
but
that
was
the
topic
I
want
to
capture
today,
thoughts,
questions,
shouts.
D
A
C
A
Snapshot
in
time
of
like
triggered
by
specifically
about
multi
project
pipelines,
but
there's
also
this
conversation
around
cross
project
dependencies.
Yes
and
there's
another
one
that
about
within
project
triggers,
and
it's
just
like.
Well,
if
you
unify
them
all
together,
you
can
use
one
keyword
and
then
just
purely
a
like
a
backwards
compatibility
at
an
evolution
thing
of
like
we
maybe
can't
use
the
word
dependencies
dependencies
might
be
the
perfect
word,
but
you
can't
break
functionality
right.
So
therefore,
we.
A
A
new
word,
your
app
on
the
other
side
include
and
pipeline
is
exactly
the
same
deal
like.
Maybe
we
can,
in
fact
just
extend,
and
in
fact
I've
seen
it
now
include,
has
been
extended
to
have
all
sorts
of
like
it
used
to
just
be
include
was
a
string
and
now
it's
an
array
of
different
kinds
of
hashes
and
you
can
have
all
sorts
of
different
kinds
of
things,
so
it
could
be
really
easy
to
just
be
like,
let's
add
another
boolean
to
that
structure.
A
That
says
you
treat
this
as
an
encapsulated
pipeline
with
local
variables.
Yeah
you
know,
or
for
that
matter,
maybe
even
go
the
opposite
direction
and
say
in
the
include
itself.
Maybe
you
have
a
top-level
declaration.
They
give
a
a
global
namespace
declaration,
and
if
you
declare
that
namespace,
then
every
variable
under
here
sort
of
gets
name
spaced
under
there,
and
maybe
you
know-
maybe
that's
even
the
right
way.
A
Maybe
so
a
little
include
is
literally
the
same,
and
it's
just
some
other
mechanism
by
which,
if
this
file
happens
to
be
included,
it
will
then
behave
the
way
that
we
talk
about
that.
The
difference
is
actually
I'm.
Gonna
go
one
more
matter
here.
There's
also
extends
when
we.
It
includes
the
product
vision
that
I
asked,
for
we
delivered
something
very
different
for
good
technical
reasons,
but
we
needed
then
do
extends
in
order
to
make
the
functionality
work,
but-
and
so
that's
where
they
go,
let's
make
another
third
variable.
A
Another
keyword
rather
sorry
another
variable
to
like.
Oh,
let's
make
it
this
way,
but
the
reality
is
there's
probably
a
rewrite
and
you
know
possible
to
say:
okay,
let's
actually
just
make
includes
do
all
this,
but
I
don't
know.
But
last
time
we
looked
at
it,
we
decided
to
go
with
extends
as
a
separate
keyword,
but
but
pipelines
might
not
be
the
same
argument.
Maybe
pipelines
is
just
the
augment
includes
with
this
capability,
so
don't
focus
on
the
syntax
matters
and.
D
A
A
Part
is
if
we
do
pipelines
this
way
and
and
they're
all
independent
decoupled,
small
primitives,
so
we
could
do
a
directed
acyclic
graph
with
existing
includes
it's
just
that
it's
gonna
be
a
little
bit
painful
because
you
now
need
like
you're
all
working
in
the
same
global
namespace,
so
pipelines,
or
that
capability
of
local
namespaces
is
just
a
nicety
to
be
like.
Oh
now,
just
boom
we're
just
on
the
right
thing,
but
we
could
do
these
all
independently.
A
Like
that's
one
of
things,
I
love
about
this
whole
thing
like
we
can
do
workspaces,
we
can
do
needs
and
we
can
do
pipelines
in
any
order
because
they
all
add
value
independently,
but
when
you
put
them
together,
it
fulfills.
This
vision
of
this
is
what
like
an
advanced
pipeline
either.
A
really
simple
pipeline
means
yeah.
D
And
and
yeah,
so
that's
where
I've
drawn
like
the
first
part
like
the
needs
part
is
like
trying
to
like
up
level
of
my
thoughts
on
that.
It's
like
a
job
has
outputs
right
like
and
status,
has
not
put
the
get
labs,
binary,
artifact
thing
as
an
output,
the
cash
isn't
output.
Any
of
our
packages
to
our
package.
Repository
is
now
put
any
the
work
space
or
something
like
some
action
take
on
the
workspace.
If
there
were
workspaces,
would
be
an
output
and
so
yeah
this.
D
This
concept
of
needs
is
like
okay,
what
you
know
back
to
your
like
the
J
unit,
job
versus
the
build
job
it's
like
for
my
deploy.
I
need
the
status
of
the
Dana
job
to
be
passed
and
I
need
the
build
to
have
an
artifact
right
so
that
that's
kind
of
how
I've
grown
need
into
the
general
thing
we're
doing
is
what
what
of
the
various
kinds
of
outputs
of
the
job,
which
right
now
are
very
disparate
right,
like
there's,
no
way
unifying
needs,
as
the
unification
of
this
is
declaratively.
C
There's
also
a
component
of
needs
are
what
you
need
to
start,
but
there
might
be
some
other
trigger
that
says
what
you
need
to
finish
right,
like
you
could
say,
to
mark
support
about
deployment.
You
could
say:
I've
got
the
package
I've
built,
I'm,
gonna,
start
the
process
and
jobs
in
deploy,
but
not
finish
or
officially
finish,
deploy
until
I
get
the
results
from
test.
This
is
like
the
whole
point
of
a
cyclic
graphs
is
that
you
can
use
those
dependencies
to
determine
proper
sequencing
or
efficient
sequencing
there.
A
It's
interesting,
though
you're
just
the
way
you
describe.
That
is
a
little
bit
problematic
because
we
don't
have
like
I,
think
what
you
mean
by
that
is
an
end
like
Oh
before
you
deploy
check
to
make
sure
that
the
test
succeeded,
but
the
reality
is
that
our
jobs
are
atomic
in
some
sense.
That's
the
wrong
phrase.
Our
jobs
are
only
triggered.
There's
nothing
like
in
the
middle
of
a
job.
We're
gonna
be
like
okay,
going
to
do,
half
these
steps
and
then
I'm
gonna
wait.
A
If
you
need
to
wait,
you
break
them
up
into
two
jobs,
so
you
have
one
job
that
builds
the
docker
image
and
then
you
have
another
job
that
deploys
that
docker
image.
Let's
say
we're,
maybe
that
maybe
most
you
have
a
a
job
that
prepares
a
bunch
of
stuff
and
then
a
job
that
actually
executes,
but
techne
speaking
I.
Don't
think
you
could
say
we
need
this
thing
before
you
can
end
its
no.
We
need
this
thing
before
something
new
is
triggered.
Does
that
make
sense?
It.
C
Does
what's
the
difference,
then,
if
you're
saying
the
actions
that
I
would
take
are
the
same,
regardless
of
whether
I
declared
a
dependency
as
a
needs,
or
it
depends,
is
that
the
two
words
we're
using
we're
for
the
two
different
words
are
they're
describing
a
dependency
if
you,
if
the
actions
you
are
going
to
take
from
those
are
exactly
the
same,
whether
or
not
you
declared
it
one
way
or
another.
What's
the
difference
between
the
two
of
those.
B
C
I
guess,
let
me
think
about
it
in
terms
of
graphs,
graphs
are
States
and
transitions
between
states
and
you
declare
dependencies
between
those,
and
that
is
what
creates
a
graph.
If
we're
saying
we
want
to
create
another
type
of
definition
of
dependency,
but
it's
the
action
I'm
gonna
take
with
that
distinction
is
the
same.
If
I
still
wait
for
the
other
one
to
start
before
I
move,
then
it's
it's
still
the
same
dependency.
What's
the
value
in
me,
calling
it
a
different
type
of
dependence.
A
Right
so
it's
pretty
but
backwards
compatibility.
So
if
we
have
so
in
all
cases,
it's
about
the
trigger
and
the
dependency
and
it's
saying
like
what
needs?
What
conditions
need
to
be
necessary
for
this
thing
to
start
right
now,
the
problem
is,
we
have
a
word
called
dependencies
and
that
is
defined
as
when
you
start
go
and
fetch
the
artifacts
from
this
job,
and
so,
if
we
now
change
the
definition
of
what
dependencies
mean
to
be
about
triggers
because
it
was
not
about
triggers,
it
was
purely
about
the
data.
A
But
if
you
now
say,
oh
well
as
soon
as
you
have
like,
if
literally
I
say,
I've
got
build
test
and
deploy
and
I've
got
a
deploy
job
that
depends
on
build.
If
we
change
the
definition
of
depends
for
dependencies,
then
you
would
start
running
in
parallel
with
the
test
and
it
would
deploy
before
the
test
finish.
So
you
would
be
breaking
people's
flow
because
you've
changed
the
definition.
That's
the
only
reason
without
adding
a
new
keyword.
A
What
I'm
suggesting
is,
we
could
add
a
new
keyboard
and
deprecated
the
old
one
we
could
say
dependencies
is
no
longer
a
word
that
we
want
to
use.
You
can
continue
using
it
until
dilib
13-point,
oh,
but
going
forward.
You
should
use
needs,
and
literally
you
know,
maybe
we've
make
it
so
you
just
do
a
G
sub
and
swap
it
out.
If
you
understand
what
the
ramifications
are
right
now,
the.
A
So
what
it
means
is
that
the
test,
the
deploy
job
previously
only
needed
to
declare
the
build,
because
it
automatically
had
a
flow
based
on
all
the
previous
stage
of
the
finish,
and
now
you
would
have
to
specifically
say
well,
no
I
depend
on
build
and
test.
You'd
have
to
be
explicit
about
you
defeat
comprehensive
there
would
you
have
to
like
if
you
stated
a
dependency
you
now
you
have
to
state
all
your
dependencies,
whereas
some
of
them
are
still
implied
today
or
still
are
implied
yeah.
A
A
So
in
here,
so
in
many
ways,
I
think
that
needs
to
me
it's
pretty
obvious
that
it
could
just
be
a
replacement
for
this
nothing.
It
has
to
be
right.
We
could
still
one
of
the
options
on
tables
decouple
these
things
and
declare
data
separately
from
flow
in
that
world
test
would
just
declare
I
need
or
I
predecessor
or
prerequisite.
I
would
have
a
predecessor
as
my
test
job,
but
that's
implied
so
I
probably
would
never
specified,
but
if
I
really
wanted
to
I
could
and
then
separately.
A
Declare
oh,
but
I
also
depend
on
data
on
this
one,
but
then
clearly,
if
I'm
depending
on
data.
Well,
then
that
job
has
to
finish
so
there's
actually
you're
already
in
this
weird
thing,
like
dependency
to
have
an
implied
trigger
as
well,
but
I
guess
you
know,
you
either
have
a
situation
where
it's
possible
for
the
the
wrong
thing
to
happen.
A
A
It
might
make
more
sense
cognitively
to
to
treat
them
as
two
separate
things
like
because,
honestly,
four
months,
that's
four,
maybe
even
literally
a
year
I
was
in
that
boat.
Where
I
was
saying
look,
these
are
two
different
things
like
trigger
and
data.
Two
different
flows
like
they
shouldn't
be
correlated
and
now
I'm,
just
saying
that
you
know
but
they're
there
there's
like
a
70%
correlation
between
these
things
so
like
why
not
just
make
that
the
default
and
then,
if
you
deviate
from
that
default,
then
I'm
gonna
declare
this
separately
like
if
I.
A
If
I
said
the
deploy,
depends
on
test
and
build,
it
would
work.
It's
just
a--,
but
I
also
have
this
extra
XML
file
that
I
don't
need,
but,
like
you
know
what
I'd
be
willing
to
do
that
and
then,
if
some
point
like.
Oh,
that's
a
bit
of
a
pain.
Great
then
make
this
exclusion
and
say:
okay,
yes,
I
depend
on
this,
for
the
data
bit
or
for
the
trigger,
but
not
the
data,
but
then
like
I'm
progressively
as
I'm,
getting
more
complicated
or
more
advanced,
then
I.
A
Add
the
syntax
instead
of
the
other
way
around
so
I
like
that
as
a
single
flow
and
then
I,
especially
like
being
able
to
say
oh
well,
I've
got
this
need
on
build
all
right:
hey
I
got
need
on
build
from
a
different
pipeline
or
hey.
I've
got
need
for
this
docker
image
from
this
registry
or
I'm
not
need
for
this
gem
file
over
here.
A
But
I
can
imagine
that
as
a
as
nobody
see
at
some
point
saying,
like
oh
I'm,
just
gonna
point
to
a
gem
file
and
every
referenced
gem
in
there
I'm
just
gonna
magically,
add
it
to
a
watch
list
and
I
literally
set
up
notifications
from
the
NPM
registry
or
the
Ruby
gems
registry,
or
the
docker
hub,
and
whenever
those
things
modify,
I'm
just
gonna
go
and
trigger
a
new,
build
and
consume.
The
latest
item.
Yeah.
C
And
let
me
try
to
say
this
like
you're,
saying
if
I
say,
if
I'm
declaring
needs
and
I
have
both
the
need
for
an
artifact
and
was
say
yeah
yeah,
an
artifact
or
a
result,
if
I
write
down,
I
need
the
result
test
and
I
need
the
artefact
from
build
I'm,
not
there's
no
sequencing
change
for
me
there.
It's
just
a
being
declarative
about
what
components
I
need
from
various
ones.
So
maybe
then,
in
test
I
throw
away
the
artifacts
more
quickly
right,
don't
put
them
into
the
next
stage
right.
A
Exactly
but
again
we
could
do
progressive
enhancement
here
and
say:
if
you
really
want
to
be,
you
say:
ok,
like
I,
don't
want
to
grab
that
artifact
then
say:
okay,
I,
don't
need
that
artifact
or
maybe
I
declare
what
I
do
need
a
more
granular
level.
I
need
success
of
this
thing
like
if
I
just
said,
I
need
I
need
this
job.
We
would
assume
you
need
success
and
they're
facts
yeah,
but
we
take
an
override
that
say:
oh
no
I
need
failure
of
this
job.
Okay,
okay!
A
Well,
then
we'll
set
that
up
and
only
on
failure
will
you
get
triggered
or
I
need
success
without
the
artifact,
and
we
look
great.
We
have
some
syntax
for
doing
so,
but
by
default,
we'll
just
kind
of
do
the
logical
thing
which
is
like.
Oh,
you
probably
need
and
the
artifacts
that
it
generates,
and
especially,
if
you
throw
into
like
workspaces
and
stuff,
then
the
artifacts
are
just
like.
Oh,
you
just
have
an
artifacts
at
all,
it's
one
of
the
things
when
it
now
finally
bringing
workspaces
back
right
now
we
declare
workspaces.
A
Sorry
we
declare
artifacts
for,
inter
things
that
we
may
not
normally
need
to
do.
If
we
just
said
all
this
is
a
workspace,
then
you
don't
actually
get
the
workspace
when
your
job
runs,
and
so
then
I
wouldn't
need
to
declare
a
specific
dedicated
needs.
I
would
just
naturally
get
the
right,
workspace
content,
and
so
then
I
would
only
really
ever
declare
things
that
are
sort
of
I.
Don't
know
not
obvious.
A
C
A
A
Exactly
but
again,
if
you
look
at
like
the
ios
and
android
scenario,
if
I
wanted
to
rerun
the
pipeline
to
redeploy
the
iOS
I,
don't
have
to
also
redeploy
the
Android,
we
can
back
port
and
say
look.
This
is
how
far
we
need
to
go
great.
Now,
we've
got
this
artifact
and
we
know
what
to
do
with
it
or
oh.
That
artifact
was
deleted,
like
if
I
a
month
later
hit
retry,
but
the
artifacts
already
gone.
We
can
actually
deduce
what
exactly
we
need
to
do,
because
everything
is
deterministic
right.
A
You
think
that's
really
really
valuable,
and
then
it
gets
interesting
again.
When
you
talk
about
cross-project
and
stuff
like
that,
like
you
can
say,
I've
got
this
dependency
over
there
and
really
you're,
saying
and
then
I'm
gonna,
throw
them
or
think
about.
The
needs,
then,
is
like
you
could
also
do
regex
kind
of
stuff
and
say
well.
I'm
gonna
watch
this
again.
A
There's
this
dock,
your
image
registry
and
maybe
I,
got
a
file
regex
and
say,
like
anything
that
is
like
or
like
a
tag
with
v
and
then
a
number
like
okay
take
those
ones,
but
anything
that
doesn't
have
a
V,
don't
take
those
and
so
I'll
just
build
them
anytime,
there's
a
V.
Maybe
he
didn't
get
a
little
bit
more
prescriptive
and
say
were
like
holding
monotonically
increasing
or
something
along
those
lines.
A
We
could
just
put
a
bunch
of
small
privilege
together
they'll
each
have
value
independently,
but
then
you
put
them
together
and
they
make
a
really
really
good
story,
and
it's
one
of
those
things
where,
if
you
just
tell
people
here
the
features
we
ship,
they
may
not
got
it,
but
then
you
put
it
together
and
you're
like
oh,
they
actually
solved
this
huge
problem,
and
so
it
becomes
the
documentation
just
like
in
some
ways
like
review.
Apps
review
app
doesn't
exist
in
the
mo
anywhere
there's
no
such
thing,
but
we
absolutely
have
review
apps.
A
It's
interesting
when
you
started
looking
at
like
the
Bill
of
Materials
kind
of
like
people
want
to
be
able
to.
They
got
multiple
repos
involved
multiple
projects
and
they
need
to
be
able
to
like
reproduce
it,
but
they
also
just
need
to
be
able
to
add
it
and
say
this
is
exactly
what
went
in
Annecy
guns
that
go
out.
Then
it's
like
I,
don't
know
I,
just
whatever
the
version
of
the
file
was
but
like.
How
do
you
have
it
so
the
Bill
of
Materials
can
be
like,
oh
well,
we
take
a
snapshot.
A
We
know
exactly
what
version
of
the
include
was,
but
then,
when
we
get
these
needs,
you
know
that's
an
implicit
need
like
I've
got
an
included.
Another
file
I
effectively
need
that
file,
but
it
isn't
thing
like
or
does
that
file
change
it
shouldn't
just
regenerate
like
do
I
need
it
in
that
same
way,
we
should
that
trigger
like
it'd,
be
interesting.
A
If
you
looked
at
and
said,
we've
got
a
company
and
we
all
share
the
same
sort
of
common
base
things
and
then
somebody's
like
oh
I'm,
gonna,
bump
the
base
level
of
Ubuntu
and
that
instantly
triggers
20/80
pipelines,
because
this
common
included
file
was
modified
and
and
now
that
just
triggers
in
your
pipeline
for
everybody,
I,
don't
know
if
that's
a
good
thing
or
not,
but
it
could
be
real
interesting,
but
it
ties
in
again
to
the
more
we
are
aware
of
what
these
dependencies
are,
the
more
we
can
do
with
them.
Alright,
everybody.
D
Yeah
no
I
mean
you've
spoken
directly
to
the
product
manager,
verify
who
likes
to
say
really
good
in
the
middle
and
we
need
better
stuff
at
the
beginning
for
new
people
and
better
stuff
for
advanced
team,
so
you've
piqued
my
interest
very
a
lot
mission
accomplished
on
that
also
happy
birthday.
Kenny
thanks.
D
A
Like
to
see
us
a
vision
for
this,
for
CI
I
mean
it's
your
category
of
vision.
I
would
like
to
see
this
folded
in
and
somehow
a
story
told
about
how
these
pieces
come
together.
You
know
right
now
our
category
visions,
we
focus
on
the
MVC
part,
but
the
intent
is
to
tell
the
story
so
I
would
love
to
see
this
as
an
important
part
of
the
story.
There's
more
to
it.
One
of
these
days,
I'll
do
another
one
of
these
on
variables
and
integrations,
but
but
this
is
a
nice
epic
probably
contained
yeah.