►
From YouTube: SIG Interoperability Meeting - June 16, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
C
A
C
D
D
Yeah,
no,
it's
not
copied,
but
man
not
being
sick
for
more
than
two
years,
and
so
when
you
catch
a
bug,
it
seriously
hits
you
higher,
at
least
in
my
case
exactly
and
got
completely
lost
the
of
this,
this
rhythm
of
getting
sick
and
then
just
a
mildly,
because
it's
constantly
exposed
to
minor
bugs
right.
So
your
body
will
recover
much
faster,
but
nowadays,
given
that
we
were
separated
for
so
much
so
long.
For
so
many
people,
it's
like
wow
yeah.
D
A
F
C
Good
to
see
you
too
well,
we've
just
been
going
around
checking
on
everyone
making
sure
everyone's
okay,
we'll
wait
a
couple
more
minutes
and
see
if
we
have
any
others
that
join,
but
we
will
be
recording.
So,
oh
we
have
maria
yay.
We
will
be
recording,
so
we
will
spread
this.
C
C
C
Awesome
well,
I
guess
again
start
with
just
a
little
bit
of
background
on
why
we're
having
this
presentation
at
all
and
what
how
this
came
about
jerem
or
justin
abrams,
my
co-chair,
who
is
unfortunately,
sitting
in
an
airport
right
now.
He
was
so
disappointed
because
this
is
definitely
something
he's
interested
in.
He
brought
up
just
introduced.
C
C
Sometimes
it's
a
lot
of
scripting
just
trying
to
get
what
you
want
done
for
each
step
that
you
care
about,
and
our
group
has
been
spending
a
lot
of
time
talking
about
vocabulary
talking
about
pipeline
steps,
you
know
trying
to
define
the
things
that
people
do
regularly
in
their
pipelines
and-
and
this
is
a
good
timing
for
you-
josh,
because
I
think
you've
kind
of
added
one
like
a
preview
step,
which
is
an
interesting
idea.
We.
C
Start
after
the
presentation
too
anyway,
so
justin
presented,
you
know
just
like
a
short
yaml
file.
That
just
says
you
know
I
want
to
do
this,
you
know
and
then
whatever
underneath
can
decide
how
that
needs
to
be
done
and
get
it
done,
but
the
top
level
description
of
the
pipeline
is
something
that
is
by
intent,
and
you
know
we're
thinking.
C
Is
there
a
spec
here?
Is
there
something
that
we
can
do
to?
You
know
help
interoperability
across
the
board,
and
when
someone
in
the
group,
I
can't
remember
who
it
was
fatigue,
but
someone
mentioned
dagger.
C
I
think
it
was
in
the
mailing
list
where
it
came
up,
and
someone
mentioned
dagger-
and
I
was
you
know,
tasked
with
figuring
out
a
contact
and
andre's.
Thank
you
tracked
down
jeremy
at
our
swamp
up
and
we
got
this
on
the
books.
So
I'm
excited
to
hear
about
this
today
excited
what
kind
of
discussions
this
is
gonna
bring
up,
and
I
think
with
that,
I'm
gonna
pass
the
stage
on
to
jeremy
and
let
him
get
started.
E
H
Awesome
thanks
everybody,
I'm
jeremy
adams.
I
head
up
the
ecosystem
at
dagger.io,
and
I've
been
there
for
a
couple
months
and
previously
at
github
for
a
long
while
working
with
the
kind
of
the
partnerships,
business,
development,
realm
with
lots
of
clouds
and
ci
cd
partners
and
also
worked
at
some
startups
previously,
like
twist
lock
doing
kubernetes
cloud
native
security
and
worked
at
puppet
for
quite
a
long
ways
back
in
its
heyday
doing
a
lot
of
declarative
devops.
H
So
all
these
kind
of
topics
are
really
near
and
dear
to
my
heart.
Everything
from
you
know,
declarative
ci,
cd,
making
developers
and
sres
and
devops
folks
lives
better.
It's
all
stuff!
I
really
care
about
so
super
glad
to
be
with
you
today,
and
what
I
want
to
do
is
just
really
briefly
give
you
an
overview
of
what
dagger
is.
Let
you
see
a
little
bit
of
it
and
then
you
know,
answer
some
questions
and
then
I'm
just
also
very
interested
to
learn
more
about
the
thinking
around.
H
You
know
intent
based
pipelines
and
and
all
that
stuff.
So
I'm
going
to
stick
around
for
sure
for
the
discussion
afterwards.
I
H
And
what
they're
doing
in
ci,
we
have
lots
of
developers
that
tell
us,
oh
my
gosh
I
like
to
spend.
I
make
some
change,
I
push
it
to
ci
and
who
knows
5,
10
15
minutes
later
you
get
an
answer
that
there
was
a
typo
or
some
kind
of
a
simple
logic
error,
or
something
that
you
could
have
gotten
ahead
of,
if
you
could
have
only
kind
of
checked
that
out
locally
in
a
way
that
was
consistent
with
ci
and
production.
H
So
that's
one
of
the
big
goals
that
we
have
is
testing
and
debugging
locally
and
then
being
able
to
send
things
out
to
your
ci
environment
and
think
about
deploying
production
without
a
lot
of
rewrites.
This
is
all
developed
as
an
open
source
project
if
you've
been
following
dagger
at
all.
You
probably
know
that
some
of
the
founders
of
docker,
like
solomon
and
sam
alba
and
andre
luzardi,
are
founders
of
dagger
and
so
of
definitely
folks.
Who've
got
experience
and
passion
about
this
problem
space
as
well.
H
If
you
check
out
this
page
later,
you'll
see
some
more
things
kind
of
like
some
of
the
things
that
are
kind
of.
I
think
motivating
some
of
the
discussion
that
we're
having
here
today
and
more
broadly,
the
fact
that
folks
are
using
lots
of
formats,
many
of
them
in
json
or
yaml,
or
what
have
you
trying
to
wrangle?
H
What
they're
doing
today,
but
sometimes
you
know
having
to
manage
a
dozen
different
yaml
formats
for
everything
from
your
kubernetes
configuration
to
whatever
your
ci
tool
is
using,
can
be
very
difficult
and
error
prone
and
so
we're
trying
to
again
get
to
some
kind
of
a
unified
way
of
doing
things,
and
we
know
that
people
are
using
many
different
platforms
and
programming
languages
and
we
want
to
meet
people
where
they're
at.
We
think
that's
super
important
and
similar
to
some
of
the
efforts
I've
seen
here.
H
The
idea
of
you
know
creating
a
lingua
franca
that
you
can
use
to
describe
interactions
or
describe
you,
know
your
desired
state
and
then
have
the
execution
of
that
or
the
implementation
of
that
be
a
detail
that
you
don't
need
to
look
at
every
moment
of
the
day
is
important
and
we're
working
with
the
community
to
create
a
lot
of
content
around
this.
So
that
you
know
you
don't
have
to
think
about
that
implementation,
all
the
time
we
can
think
at
a
higher
level
of
concepts.
So
I
want
to
do
things.
H
You
know
deployed
a
particular
cloud
or
work
with
a
certain
technology
versus
what
are
all
the
commands.
I
need
to
do
to
do
that,
and
and
what
we're
going
to
talk
about
today,
a
little
bit
is
the
idea
of
being
able
to
run
locally
in
the
same
way
that
you
run
in
ci,
for
example,
and
get
that
early
fast
feedback
just
for
folks
who
care
about
things
like
architecture.
H
This
is
a
very
basic
architecture
diagram,
but
if
you
think
about
what's
going
on
under
the
hood,
we've
got
dagger,
which
is
sitting
on
top
of
build
kit
and
for
folks
who've
been
familiar
with.
You
know,
docker
build
and
like
build
x
and
and
the
moby
build
kit
project.
That
sort
of
thing
you'll
know
that
this
is
a
really
powerful
execution
engine
for
doing
things
in
parallel
and
really
strong,
caching
support
etc.
H
So
this
gives
us
a
kind
of
is
part
of
the
engine
of
the
dagger
engine
is
all
that
built-in
goodness
that
comes
with
build
kit,
and
then
it
also
means
that
we
can
run
dagger
anywhere
where
you
could
run
container
type
workloads.
So
you
could
run
this
in
kubernetes.
You
could
run
this
locally
on
your
laptop
with
docker
desktop
or
something
like
that.
You
could
run
this
all
over
the
place,
and
so
this
and
because
all
the
different
ci
providers
typically
have
some
sort
of
you
know
oci
container,
running
environment
available.
H
H
It's
not
json
we're
actually
using
right
now,
a
different
language
that
actually
came
out
of
google,
that
was
it's
called
q
and
you'll,
see
a
little
sample
of
it
as
I
go
in
the
cool
thing
about
this
language
is
that
it
was
invented
by
the
folks
that
came
up
with
some
of
the
original
configuration
languages
for
things
like
borg
at
google
right
so
borg,
which
became
essentially
kind
of
morphed
into
kubernetes
out
in
the
open
source
running
massive
workloads
globally
for
google.
H
The
lessons
learned
from
that
some
of
those
went
into
this
language
that
we're
using
as
the
front
end
right
now
for
dagger.
So
let
me
jump
in
and
kind
of
talk
about
the
the
sorts
of
things
that
a
developer
is
probably
going
to
want
to
do
so.
One
of
the
things
you're
going
to
want
to
do
is
be
able
to
build
an
app
locally
and
then
get
that
get
the
experience
that
you're
having
there
also
in
ci.
H
I've
got
this
to
do
app
in
here
that
I've
cloned
down
and
what
we've
got
in
here
is
essentially
a
static
website
that
will
eventually
deploy
to
netlify
is
the
idea
and
we're
using
yarn
and
we're
using
some
different
pieces
like
that,
but
let's
just
get
a
feel
for
what
this
looks
like
so
with
dagger.
All
you
do
is
dagger
do
and
what
dagger
do
does
is
it
tells
you
what
you've
got
available
in
your
plan?
H
So
in
this
case
I
can
I've
got
different
actions
that
are
inside
of
my
plan
and
I'll
show
you
the
source
code
in
just
a
second,
but
we
have
something
that
will
load
in
the
source
code
from
the
local
repo
that
we're
in
here.
It
will
build
the
app,
including
a
local
copy
of
it,
and
we
can
run
tests
and
then
we
can
go
and
deploy
out
to
you
know
maybe
a
dev
version
or
a
broad
version
of
the
site.
H
H
So
the
idea
here
is
that
you're,
seeing
a
lot
of
stuff
go
by,
but
essentially
what's
happening
in
the
background.
H
Is
that
we're
doing
all
the
sorts
of
steps
that
might
be
needed
and
right
now
we're
doing
a
yarn
install
fetching
some
packages
from
a
package
json
all
the
steps
you
might
need
to
kind
of
build
and
test
this
site
and
then,
when
we're
done,
what
we'll
be
able
to
do
is
we'll
be
able
to
take
a
look
at
this
locally
and
see
what
we've
built
and
then,
like
I
say
we
can
then
think
about
how
we
would
then
send
this
out
to
somewhere
in
production.
H
H
So
let's
see
what
we've
built
here,
so
I
think
the
one
difference
that
we
have
here
is
we
have
between
805
and
815.
We
built
this
build
directory
right
here,
and
so,
if
I
do,
if
I
take
a
look
in
there-
and
I
say,
let's
open
up-
build
index.html
we've
just
built
a
simple
react
site
here.
That's
a
to
do
app
that
lets
us,
you
know,
create
to
do
items
for
ourselves
right
so
talk
at
cdf
and
that's
one
of
the
things
that
we're
working
on
right
now
right.
H
H
So
essentially
we
mentioned
before-
or
I
mentioned
before,
that
we
can
pull
in
different
pre-made
packages,
so
we've
got
some
core
things
that
are
part
of
dagger,
and
then
we
have
our
dagger
universe.
So
we've
got
content
here
for
all
different
sorts
of
things
that
you
might
want
to
automate.
So
we've
got
say
a
netlify
package,
a
yarn
package
and
we
end
up
using
those
inside
of
this
plan
here
remember
before,
when
we
did
a
dagger
do
we
saw
things
like
actions
that
we
could
run
like
build?
H
So
let's
go
up
here
we
saw
source,
we
saw
build
and
then
a
little
further
down
in
the
list
we
saw
test
and
then
we
ultimately
saw
deploy
and
you'll
see
that
most
of
this
a
lot
of
this
is
some
comments
that
we
have
in
here
right
now,
but
if
we
go
and
take
a
look
at
build,
which
is
the
one
that
we
just
did,
you
can
see
it's
pretty
simple
again.
I
don't
want
to
think
about
all
of
the
implementation
details
of
what
it
takes
to
build.
In
this
case.
H
I'm
just
running
you
know
a
yarn
script
that
maybe
I've
got
set
up,
that
does
my
yarn
build
and
you'll
notice
that
it's
referencing,
something
else.
So
it's
the
source
of
what
I
want
to
build
is
actually
coming
out
of
the
another
action
previous
to
this
one.
So
this
is
a
way
to
link
together
actions
in
a
very
kind
of
simple
way
to
create
dependencies
and
we're
creating,
in
essence,
a
dependency
graph,
a
dag
that
describes
how
this
application
gets
built
and
deployed.
H
So
in
this
case
we're
referencing
an
action
called
source.
The
output
of
that
which
we
saw
right
above
and
source
here,
is
using
a
core
dagger
action
that
pulls
in
the
local
source
code,
from
whatever
path
that
we're
at
or
below,
and
so
we're
saying
just
pull
in
is
essentially
like
a
checkout
of
the
local
source
code
and
if
I
want
to
just
include
certain
things
or
in
this
case
exclude
certain
types
of
files,
I
can
so
I
don't
pull
them
in.
H
Something
gets
kind
of
unified
with
this
plan.
Here
is
the
fact
that
I
can
do
certain
things
in
local
dev
that
I
can
layer
in.
So
in
this
particular
case,
I
wanted
to
layer
into
my
plan
one
more
action
here.
That
is
a
local.
You
know
that
has
to
do
with
the
deploy
action,
and
here,
if
I
have
a
token,
that
is
an
environment
variable,
a
client
side,
environment
variable
called
my
netlify
token.
H
I
can
read
that
in
and
use
that
token
and
then
additionally,
I
can
write
out
to
the
file
system.
We
want
to
be
very
hermetic
in
the
way
we
do
our
builds
and
such,
but
we
do
have
an
escape
hatch
in
case
you
want
to
explicitly
write
to
somewhere
other
than
the
current
directory
somewhere
else
on
the
file
system.
You
need
to.
H
We
looked
at
that.
Did
the
yarn
build
the
output
of
that
gets
written
out
to
that,
slash
that
dot,
slash,
build
directory
and
that's
how
we're
able
to
get
a
static
site
going
like
that
fast
now
it
took
a
did.
Take
a
second,
let's
be
honest.
So
if
I
were
to
run
this
again
and
let's
take
off
the
log
for
the
extra
logging
here
and
see
what
we
would
kind
of
normally
see
so
in
this
case
I've
got.
You
know
a
completion
that
happened
very.
H
So
you
can
imagine
that
both
locally
and
ci
when
you've
run
a
dagger
plan,
once
you're
going
to
be
able
to
cache
a
lot
of
what's
been
done,
that
work
that's
been
done
and
then,
if
other
users
who
are
on
the
same
system
and
are
sharing
a
cache,
if
they're
running
similar
dagger
plans,
they're
going
to
be
getting
a
lot
of
performance
boost
as
well
and
certainly
for
a
developer
on
their
own
machine
they're
going
to
be
getting
a
big
performance
boost
from
the
caching.
H
H
You
saw
the
command
that
I
did
earlier,
which
was
dagger,
do
build
or
dagger
do
deploy.
So,
if
you're
running
say
in
github
actions,
for
example,
all
you
would
do
is
use
the
dagger
for
github
github
action,
and
you
do
something
very
similar.
You'd
say
dagger:
do
build
or
dagger
do,
deploy
whatever
it
is
that
you
want
to
do
with
dagger
and
then
every
time
in
this
case.
Every
time
I
push
to
main,
then
I
get
a
dagger
due.
H
Similarly,
if
I'm
running
in
anything
circle,
ci
gitlab
tecton,
whatever
you
could
imagine,
say
even
with
jenkins-
which
we've
had
a
lot
of
folks
who
are
interested
in
the
use
case
of
maybe
they're
on
jenkins
today
and
then
tomorrow,
they're
going
to
be
going
to
some
next
ci
or
ci
cd
system
and
they're
sick
of
rewriting
these
things.
Every
time
management
says:
oh
we're
going
to
vendor
x,
now
we're
going
to
vendor
y
or
we
need
to
support
both
or
there
was
a
merger,
and
we
need
to
get
everyone
on
the
same
page.
H
And
so,
if
we
go
and
look
at
a
jenkins
example,
you
can
see
very
similarly.
I
might
have
something
like
this,
where
I
run
dagger,
do
so
again,
very
very
simple
way
of
creating
a
a
dagger
plan
and
then
executing
it
locally
or
in
ci.
H
You'll,
see
us
doing
more
and
more
things
to
make
it.
You
know
kind
of
make
it
easier
to
learn
and
get
started
with
dagger
over
time.
One
of
the
things
we've
been
getting
a
lot
of
feedback
from
folks
on
some
of
the
different
types
of
examples
they
want
to
see
out
there
in
the
world
and
getting
tons
of
community
contributions
as
well.
H
So
just
to
give
again
an
idea
of
how
you
could
get
started
from
nothing
with
dagger,
you
could
grab
an
existing
repo.
That's
out
there,
like
our
to-do,
app
that
I
showed
you
or
you
could
do
something
like
this.
H
And
what
I've
just
done
now
is
I've
just
created.
You
know
a
very
simple
hello
world
app,
and
this
should
look
really
familiar
to
everybody.
Who's
seen
this
so
far,
we've
got
again.
We
use
these
package
names
to
kind
of
group
files.
Together
we
import
in
any
of
the
universe
or
core
dagger
packages
that
we
need
this
one's
going
to
use.
Instead
of
netlifying
yarn,
this
one
uses
bash
and
something
to
work
with
alpine,
and
then
you
can
see
a
very
simple
plan
here.
H
Right
we've
got
one
action
here
and
you'll
see
that
this
is
a
this
little
underscore
means
it's
kind
of
an
implementation
detail,
so
one
that
is
not
one
that
we
want
to
think
about
as
a
main
action
that
you
would
run,
but
just
one
that
runs
in
the
background.
H
So
here's
one
that
we're
doing
an
alpine
build
and
we're
adding
the
bash
package
to
it
and
then
we're
using
that
alpine
image
that
we've
just
built
and
we're
using
it
to
do
a
bash
run
of
a
simple
script
which
could
be
in
a
file
or
in
this
case
it's
just
written
in
line.
So
that
kind
of
gives
you
again
another.
H
And
so
you
can
see
here
is
kind
of
like
a
very
simple
hello
world,
again
right
so
again,
starting
with
something
a
little
more
complex,
taking
it
back
to
something
simpler,
but
hopefully
you're
seeing
a
little
bit
of
commonality
between
the
approach.
The
idea
is
figuring
out
what
the
steps
are
that
you
want
to
do,
creating
actions
within
your
plan
for
that
and
reusing
content,
that's
already
out
there
in
dagger
universe
and
then
linking
things
together
to
create
these
dependencies.
These
dag
dependencies.
H
And
and
then,
if
folks
have
any
questions-
or
you
know-
I'm
happy,
you
know
if
we
just
transition
the
discussion,
but
I
was
happy
to
share
that
with
you
and
if
you
want
to
reach
out
to
me
at
all,
I'm
jeremy
at
dagger.io,
you
can
also
come
to
dagger.io
and
we
can
jump
right
into
our
discord
and
we're
all
in
there
and
discord
chatting
about
all
these
topics
and
helping
people
work
on
their
projects,
and
you
can
also
check
out,
of
course,
dagger
on
github
as
well,
and
we've
got
all
of
our
all
of
our
contents.
C
A
Two
questions,
sorry,
was
it
you
josh,
you
were
going
to
speak.
A
Yeah
now
I
I'm
going
back
about
two
and
a
half
years.
Let
me
put
link
to
the
chat
as
well,
so
you
can
see
it
for
yourself
now
when
we
first
proposed
the
special
periscope
interoperability.
One
of
the
participants
in
the
group
put
a
comment
under
the
proposal,
so
I'm
not
sure
if
I
can
share
or
meditate.
If
you
want
to
share
that.
A
So
like
this
is
kind
of
this
tanha
we
worked
together
in
different
communities
and
he
managed
multiple
ci
cd
systems
like
jenkins,
gitlab,
zul
and
so
on,
and
one
of
the
pain
points
he
faced
like
many
of
us.
A
A
H
A
Yeah,
because
yeah,
we
don't
have
much
time
to
discuss
this
topic
over
the
past
two
years,
but
it
came
up
time
time
and
lately
this
based
pipelines,
it's
a
bit
more
intent
based
pipelines.
Discussion
was
around
making
things
even
more
simpler,
instead
of
describing
what
should
happen.
It's
just
something
like
I
want
this
make
it
happen.
I
don't
care
how
you
are
doing
it,
but
just
give
me
my
container
much.
Let
me
put
that
thread
as
well.
It's
on
cdf's,
like
it's
like
these
two
topics
are
kind
of
late
picture.
C
I
just
put
this
one
up
here.
This
is
something
that
we
were
going
to
try
to
post
as
an
article
to
the
cd
foundation
blog,
but
this
is
justin
abrams
hackmd.
This
is
what
his
idea
of
maybe
a
simple
yaml
file
would
look
like
something
that's
intent,
driven
and
I'm
not
sure
if
you
guys
can
get
to
this
link
or
not.
I
think
it's
public.
Let
me
try
putting
it
in
here.
G
H
H
C
F
Yes,
thank
you,
jeremy
for
that
overview,
so
I
run
an
open
source
project
that
does
on-demand
test
environments
and
we're
trying
to
figure
out
how
to
improve
interoperability
with
other
ci
cd
platforms.
Primarily,
we've
been
utilizing
github
actions
we're
trying
to
expand
that
so
we're
really
interested
in
dagger
and
just
started
looking
into
the
docs
this
week.
Actually
I
had
us
a
specific
question
so
when
you
were
showing
obviously
what
you
just
did
was
running
locally
and
then
you
were
showing
github
actions,
then
across
the
different
ci
cd
platforms.
F
I
noticed
so
to
run
this
to
run
what
you
just
did
on
github
actions.
Are
you
calling
a
specific
dagger,
github
action
to
run
that
plan,
and
I
kind
of
my
if
so
my
follow-up
question
is
like
to
what
degree
would
I
or
a
user
need
to
like
modify
that
action
to
get
dagger
to
work
with
with
github
actions
right.
H
Yeah,
no
we're
that's
a
great
point:
thanks
josh
the
the
dagger
for
github.
What
I'll
do
is
I'll
drop
in
from
the
I'll
go
to
github's
marketplace
and
I'll
drop?
This
link
in
here
really
quick,
so
did.
H
Yeah,
I
sure
I
mean
I
certainly
can.
Thank
you
so
much.
Let
me
do
that.
So
you
know
so.
Here's
our
github
action
in
the
github
actions
marketplace
and
essentially
you
know
kind
of
shows
you
how
you
use
it.
So
what
it
does
is
it
makes
sure
that,
on
the
github
actions,
runner
that
dagger
is
installed
and
installing
dagger
is
really
really
easy.
H
It's
pretty
lightweight,
and
so
that
happens
very
quickly
and
then
and
then
you
it
just
allows
you
to
do
dagger,
do
whatever
your
action
that
you
want
to
run
in.
So
if
dagger
do
test
or
build
or
deploy
or
whatever.
H
H
H
You
could
do
a
thing
like
this
since
we're
on
ubuntu.
Typically
as
a
runner
there
I
could
go,
and
I
could
you
know,
do
a
dagger
install
like
that
of
the
latest
version
of
dagger
or
a
particular
version
of
dagger,
and
then
I
could
run
the
next
line.
Dagger
do
deploy
or
something
and
then
so
yeah
you
could
you
could
do
it
even
without
the
action
it's
just
kind
of
a
convenience.
F
Okay,
I
got
it.
Thank
you.
That's
that's
helpful
one
more
question:
if
that's
okay,
when
when
have
you
seen
when
people
running
their
dagger
pipelines
locally,
is
it
possible,
are
you
seeing?
Could
I
build
my
image
locally
and
push
it
to
a
remote
container
registry
with
a
dagger
plan.
H
Yes,
absolutely
that's
like
a
super
common
use
case
so,
for
example,
I'll
just
kind
of
show
my
screen
one
more
time
so,
like
here's,
an
example
here
from
our
docs,
where
you
know
as
part
of
my
plan
like
maybe
I
have
a
an
action
in
my
plan-
that's
called
push
and
in
this
particular
one
I
use
one
of
our
built-in
from
our
dagger
universe.
We
have
a
docker
package,
it
lets
you
do.
Docker
pull
docker
push
it
lets.
H
You
do
a
docker
build
where
you
can
do
kind
of
a
little
pipeline
of
like
start
one
from
an
image
and
modify
it
by
doing
running
things
on
it
or
copying
things
to
it
or
setting.
You
know,
config
metadata
on
it
or
whatever
you
need
to
do
and
at
the
end
it
spits
out
a
new
image.
It
just
kind
of
pops
out
or
you
can
use
a
docker
file,
or
you
know
a
number
of
different
things
like
that,
but
yeah.
H
Yeah
that
would
be
like
something
at
the
end
of,
and
this
is
like
a
more
complete
here's
just
another.
We've
got
lots
of
examples,
essentially
here's
that
docker
build.
I
was
talking
about
right,
so
here's
somebody
that
went
and
they
we
pulled
some
source
code
and
did
a
go,
build
using
our
go
package
and
then,
after
you
did
the
go
build.
H
Maybe
then
we
did
something
here
where
we,
you
know
use
that
later
on
down
here
in
the
in
this.
We
copy
in
the
go,
build
step
right.
So
this
kind
of
you
want
to
do
like
a
kind
of
a
multi-stage
pipeline
kind
of
a
thing
right.
So
here
I'm
like
doing
that,
docker
build.
I
said
I
have
different
steps,
so
I
start
with
an
alpine
image
I
copy
in
the
results
of
my
go,
build
right
up
above
copy
those
results
into
user
bin.
F
Cool
that
that's
really
exciting.
I
will
we're
going
to
do
some
more
reading
and
probably
some
prototyping,
then
I'll,
probably
reach
out
to
you
pretty
soon.
J
Hi
great
presentation,
sorry
I
missed
the
the
beginning
today.
Unfortunately,
I
had
a
couple
of
questions,
so
I
I'm
a
maintainer
of
two
cdf
projects.
One
is
called
tacton
and
the
other
one
is
called
city
event,
so
one
question
for
each
so
for
the
tecton
integration.
I
I'm
trying
to
understand
whether
you
have
any
plan
to
like
a
deeper
integration
or
if
you
would
be
open
to
something
like
that
or
interested.
J
In
my
understanding
that
the
moment
I
I
ran
like
the
dagger,
do
something
if
I
want
to
do
it,
protect
on
basically
embed
in
a
techno
task
which,
from
a
title
point
of
view,
would
run
in
a
single
pod,
so
any
parallelism
that
actually
happens
there.
It
will
still
be
within
that
specific
part.
J
Well,
if
you
define
a
pipeline
on
tecton's
side-
and
you
have
like
the
dag
a
similar
concept
of
a
dhg
exit
part
of
the
execution,
then
you
can
have
this
different
task
being
executed
in
different
parts
in
your
kubernetes
cluster,
and
I
think
it
would
be
really
great
to
have
some
mechanism
to
kind
of
map
the
two
dags,
the
two
dags
between
so
yeah.
I
was
wondering
if
that's
something
that
you
vote
about
already
and
yeah.
H
No
yeah,
we
would
love
to
so
there's
already
ways
that
you
can
do
a
certain
kind
of
like
sharing
of
the
cache
you
know
across.
So
you
can
do
things.
For
example,
like
use,
even
a
container
registry
right,
you
can,
you
can
store
cash
and
other
arbitrary
artifacts
right
in
container
registries.
So
one
way
that
people
do
it
is
they
use.
They
have
a
common
cache
that
they'll
use
and
pull
from.
H
Sometimes
it
makes
sense.
Sometimes
it
doesn't
sometimes
it's
more
performant
just
to
rebuild
things
than
to
push
and
pull
from
caches
depending
on
where
they're
at.
But
I
would
love
to
think
about
more
about
yeah
like
at
that
level
of
the
pipeline
in
tecton
thinking
about
ways.
We've
got
actually
people
on
our
team,
who
are
very
deep
in
kind
of
the
build
kit
side
of
things
and
the
kubernetes
side
of
things.
So
it
would
be
wonderful
to
collaborate
with
you
and
come
up
with
something
that
would
work
best
for
our
mutual
users.
J
J
The
other
thing,
as
for
cd
events,
so
cd
events
is
a
spec
that
we
are
building
for
like
a
common
way
to
send
events
in
the
cicd
space,
so
that,
if
you
want
mounted
different
tools,
if
you're
using
a
combination
of
tools
in
your
ci
cd
workflow,
they
can
talk
to
each
other
through
like
common
language,
and
my
question
was,
I
don't
know
if
you
mentioned
it
in
the
initial
part
of
the
presentation-
sorry
about
that
in
case,
but
is
there
any
any
hook
or
any
way
in
dagger
to
say,
send
notification
or
send
events
whenever
a
certain
part
of
the
plan
is
executed?
J
H
Yeah,
there's
actually
there's
a
lot
of
so
you
can
do
you
could
certainly
wire
up.
You
know
actions
that
would
fire
whenever
you
wanted.
You
know
to
emit
events,
but
we're
looking
at
the
fact
that,
because
the
way
that
say
build
kit
works
and
the
way
that
dagger
works
and
the
way
that
these
these
dags
are
set
up,
there's
actually
an
opportunity
to
do
something.
H
That's
deeper,
you
know,
or
more
kind
of
built
in
and
think
about
like
a
particular
vertices,
you
know
to
be
emitting
events
in
some
kind
of
a
regular
fashion.
So
I
think,
there's,
I
think,
there's
a
lot
of
potential
to
to.
Possibly
you
know
have
to
to
work
with
something
like
the
cd
event
spec,
you
know
and
and
kind
of
consumer
emit
things
that
are
in
accordance
with
that.
H
So
I
don't
know
again
it's
like
something
that
it's
a
little
early
days
for
us
too,
but
it's
something
that
it
looks
like.
There's,
there's,
there's
kind
of
good
potential
hooks
where,
where
something
like
that
could
happen,.
D
Yeah,
so
I'm
understanding
what
to
follow
up-
and,
I
think
andrea
you
just
just
mentioned
one
of
the
questions
that
I
have
we'll
still
try
to
rephrase
in
a
different
way,
which
is
right
now,
if
you
invoke
the
the
gif
of
action
for
daca,
whichever
plan,
whatever
actions
you
have
in
that
plan
from
the
point
of
view
of
gift
of
actions,
will
be
seen
just
as
a
one
big
opaque
step.
D
So
if
there
are
any
way
for
the
the
plan
to
have
host
information
so
that
it
can
pull
out
events
or
actually
not
push
events
or
any
other
sort
of
information
that
the
hosting
environment
can
rely
on,
that
would
be
great
now,
of
course,
this
will
require
a
specific
host
integration
with
one
each
one
of
those
ci
systems
that
you
would
like
to
run,
and
maybe
you
will
need
something
for
a
local
environment,
but
that
would
be
great
to
have
and
that
kind
of
goes
into.
D
I
actually
have
ram
jagger
before
and
one
of
the
things
that
I
quickly
noticed
that
even
running
locally,
there
is
no
such
thing
as
a
dashboard
or
or
something
that
I
could
find.
The
only
thing
that
I
have
access
to
right
now,
which
is
great,
is
the
log
file,
but
it
is
something
that
I
would
like
to
look
further
into,
or
I
don't
know
have
some
visual
representation
of
what
was
the
the
plan
that
it
has
been
executed
when
it
was
successful
when
it
failed,
when
exactly
it
failed.
D
I
don't
know
if
you
guys
have
something
that
in
the
pipeline,
no
pun
intended
or
is
a,
but
is
it
not
going
to
be
there
because
it
may
be
a
responsibility
of
the
hosting
environment.
H
Right
right,
some
kind
of
a
dashboard
so
yeah
today,
we've
got
our
first
really
like
it's
a
very
alpha
release
of
dagger
cloud,
and
so
the
idea-
and
you
can
see
the
things
that
I
was
running
today,
like
the
hello
and
the
build
and
things
I
was
running
today.
You
could
see
that
they're
here.
H
Here's
the
the
plan
that
I
was
running
for
that
hello
world,
for
example
my
environment
and
and
then
you
can
see
broken
up
some
of
the
the
different
things
that
were
happening
inside
of
the
the
actions
that
we
were
running
so
yeah.
This
is
our
you
know
again
very
alpha
emphasis
on
the
alpha.
H
This
is
a
construction
zone,
type
of
an
experience,
but
absolutely
we've
had
because
what
we've
had
is
with
a
lot
of
our
users,
like
you
know,
if
they're
doing
something-
and
you
know
they
hit
some
kind
of
an
error-
then
what
we
want
to
be
able
to
do.
Is
you
know
if
we're
helping
them?
We
definitely
want
to
be
able
to
look
look
at
the
run
that
they
had
and
also.
H
Share
that
with
their
colleagues
potentially
so
yeah,
I
think
you
can
imagine
us
having
more
details
here
being
able
to
visualize
the
dag
and
more
and
more
things
there
right,
but
yeah.
That's
kind.
H
Stage
of
that
kind
of
thinking-
and
I
think
you're
totally
right-
we've
had
the
same
request
from
some
of
our
users
to
say,
like
hey.
When
I
run
this
in
a
particular
ci
system,
I
want
to
see
stages
that
you
know
are
familiar
to
me,
get
populated
for
example.
So
it's
something
that
we're
definitely
thinking
about
and
and
and
yeah.
We
totally
recognize
and
I'd
love
to
work.
You
know
with
with
anybody.
That's
got
great
ideas
about
it.
D
I'm
also
the
creator
of
an
open
source
tool
called
jrlisa,
and
I
couldn't
fail
to
notice
that
when
you
and
started
the
presentation
on
target,
the
website
explicitly
mentions
for
development,
build
test
and
debug
there's
no
mention
of
release,
so
I'm
very
happy
to
say
that
this
tool
can
be
combined
with
target,
and
I
have
given
a
little
bit
of
of
trying
an
error
in
that
one
and
the
the
question
that
I
have
in
my
mind
is
that
I
know
it's
possible
once,
but
once
it's
done,
is
there
like,
like
a
repository
of
community,
lab
efforts
or
recipes
that
anyone
can
use
so
right
now
you
show
the
universe
dagger.
D
H
Oh,
no,
that's
a
great
question
yeah
so
and
we
don't
here
here's
I
just
brought
this
up
on
my
screen
one
more
time,
but
this
is
this
is
kind
of
how
we're
thinking
about
right
now
the
process
so
where
folks
would
start
today
would
be
by
these
are
all
open
source
community
contributions
for
all
sorts
of
things.
Kubernetes.Net
lua,
one
password,
you
can
see
the
the
kind
of
the
spectrum
here
and-
and
we
have
this
alpha
namespace,
and
so
what
we're
doing
is
we're
doing.
H
I
think
I
can
show
you
in
our
discussions.
We
have
a
lot
of
community
discussions
where
we
ask
people
what
they
wanna,
they
wanna
see
next
and
you
know
etc.
So
this
is
where
we're
this
is
where
we're
going,
or
this
is
the
way
that
we're
working
right
now
is
that
you
know
it's.
Essentially
you
put
your
contribution
in
alpha
when
it
hits
certain.
You
know
it's
got
certain
test
coverage
and
kind
of
stability
bar.
H
It
goes
to
beta,
and
then
it
can
also
it
can
graduate
right
into
the
main
universe
packages
that
you
saw,
but
it's
immediately
usable
right.
So
I
can
immediately
use
it
inside
of
one
of
my
plans
just
by
saying
universe,
dot,
dagger,
dot,
io,
slash,
alpha,
slash,
ansible
and
then
I'm
using
it
yeah,
and
so
it's
a
great
that's
how
people
are
right
now
contributing
a
lot
of
content
and
yeah.
So
it's
please.
H
If
you
have
something
for
j
releaser,
a
love
of
pr,
so
that
other
people
can
can
start
using
it,
and
that
would
be
amazing.
D
Thank
you,
so
I
guess
the
recommended
path
will
be
to
open
a
discussion
topic
to
to
get
to
know
both
sides,
and
then
we
can
figure
out
where
to
go.
What
to
do
next.
After
that,
I
suppose.
H
H
We
want
to
get
you
on
in
the
in
the
kind
of
in
the
loop
in
terms
of
reviewing
you
know
more
contributions
to
what
you've
contributed,
so
yeah
kind
of
just
a
growing
network
of
of
folks
who
are
helping
to
create
content
for
each
other.
C
Thank
you
if
you
found
yourself
in
a
good
spot,
jeremy
right
in
the
middle
of
all
of
us,
you've
hit
on
a
really
big
pain
point,
especially
with
you
know,
trying
to
use
different
ci
solutions
and
having
to
transfer
between
them,
and
I
think
it's
a
really
good
I'm.
I
wish
I
had
discovered
you
sooner,
because
I
feel
like
there's
a
lot
I
could
have
done
in
the
past.
Past
melissa
would
have
really
appreciated
it.
C
So
I'm
looking
forward
to
see
what
what
is
coming
down
the
pipe
next,
in
fact,
are
you
presenting
on
dagger
anymore.
Are
there
any
conferences
or
anything
coming
up
that
you'd
like
to
plug.
H
Yes,
I
think
I'll
likely
be
out
at
a
devops
world
in
florida.
That's
coming
up,
I
think
it's
in
september,
so
yeah
I
I
did
have
a
talk.
There
accepted
around
dagger
and
jenkins,
so
I
will
likely
you
know.
Unless
something
else
you
know
conspires
against
me.
I'm
likely
be
out
there,
and
so,
if
anyone
else
is
there,
I'd
love
to
chat
I'll,
also
be
not.
I
don't
I'm
not
sure.
If
our
team
is
presenting
at
kubecon
north
america,
we
may
well
be
I'm
not.
H
I
haven't
totally
heard
back
for
people's
cfps,
but
I'll
definitely
be
I'm
planning
to
be
in
attendance
there.
If
folks
want
to
meet
up-
and
I
know,
melissa
and
I
had
a
chance
to
meet
up
at
swamp
up
jfrog
swamp
up,
and
so,
if
there's
anything
else,
I
should
be
going
to
that.
I
don't
know
about
yet
that
you're
gonna
be
at
please
folks.
Like
you,
my
emails
in
the
chat
hit
me
up
or
jump
on
the
dagger
discord
and
I'm
just
jeremy
adams.
H
I
don't
have
a
very
cryptic
handle
on
discord.
It's
very
easy
to
fuss
to
stalk
me
if
you
need
to
so,
but
that's
by
design,
so
yeah
happy
to
help
and
love
to
hear
more
about
what
everyone's
working
on.
C
H
H
That
from
the
from
the
cdf
from
the
the
cd
con
that
you
think
I
should
because
I
couldn't
see
everything
and
I
also
had
I
was
at
a
planning
session
in
san
francisco
at
the
same
time,
so
I
was
like
remotely
catching
stuff.
So
if
there's
anything
that
folks
now
that
you
kind
of
have
an
orientation
to
what
I'm
working
on,
if
there's
anything,
I
should
really
watch.
I
know
some
of
you
that
are
on
the
call
here
had
talks,
and
so
I
definitely
want
to
check
those
out.
H
C
Cool
cara,
we
have,
we
have
recordings
right
from
cdcon
that
are
posted
or
will
be
posted
soon.
A
G
A
Yeah
events
team
is
working
on
getting
to
main
conference
videos
but
andrea.
I
think
you
had
the
cd
when
school,
recording
upload
on
youtube,
yeah.
J
A
C
C
E
C
E
Huge
shout
out
to
andrea
who
has
been
amazing
with
the
city
events
project
and
also
really
fantastic
about
getting
the
word
out
very
clearly
to
the
community
about
what
cd
events
offers,
and
you
know,
cd
events
gone
was
awesome,
so
thank
you.
H
Oh,
thank
you
for
that.
Playlist,
andrea,
that's
amazing!
It's
perfect
and
it
doesn't
auto-start
playing.
So
that's
the
only
feature
request.
This
should
auto
start.
C
Well,
I
always
enjoy
these
meetings,
especially
when
we
have
an
awesome
presentation
like
this
something
to
discuss
and
leave
with
new
ideas
I'll
go
through
and
I'll
pull
out
some
of
the
ideas
that
would
come
out
and
get
them
in
the
notes.
I've
admitted
I'm
horrible
at
trying
to
do
that
at
the
same
time,
while
trying
to
listen.
C
So
if
anyone
else
wants
to
help
with
that
as
well,
I
think
that
would
be
greatly
appreciated,
but
in
the
meantime,
I'll
go
through
the
video
and
get
some
notes
in
there
with
a
little
bit
of
time.
We
have
left,
we
don't
often
get
like
new
members
coming,
so
I'm
very,
very
happy
to
see
some
new
faces
we
have
richard.
Do
you
want
to
just
say
hi
to
everybody?
Tell
everybody.
C
B
Hi
everyone
I'm
richard
kilmurry,
I'm
part
of
vodafone,
a
big
telecom
company
in
europe
and
africa.
You
may
have
heard
of
parts
of
the
network
strategy
and
architecture
team,
and
so
we're
responsible
for
how
the
network
evolves.
Very
briefly,
the
network
functions
are
either
the
parts
of
the
network
architecture
that
provide
the
telecom
service
they're
becoming
virtualized
and
containerized.
Now
so
in
in
the
future,
we
are
preparing
to
introduce
ci
cd
for
our
network
functions
as
well,
which
is
a
big
change.
B
So
I'm
responsible
for
that,
and
I'm
just
trying
to
find
out
a
bit
more
about
cdf
to
understand
the
level
of
involvement
that
we
should
have
because
things
like
interoperability
and
not
getting
vendor
lock-in
are
really
important
to
us
and
we
do
have
other
involvement
in
the
linux
foundation
as
well
like
aniket
as
well,
so
not
new
to
linux
foundation.
Overall,
so
that's
me.
Thank
you
very
much,
really
interesting,
first
presentation
as
well.
Thank
you.