►
Description
Project Shipwright in Depth - Adam Kaplan, Red Hat & Enrique Encalada, IBM
Speakers: Enrique Encalada, Adam Kaplan
Shipwright is a framework for building container images on Kubernetes, but how does it work? And how is it powered by Tekton? In this session, Adam Kaplan and Enrique Encalada will peel back the layers of Shipwright’s interface and reveal how Tekton’s core features drive the application build process. This information will then help attendees learn how to write their own BuildStrategies through a live coding demonstration. This presentation will also preview new Shipwright features that will be available to developers and build strategy authors in a future release. After this talk, attendees will understand how Shipwright compliments Tekton and will be able to write strategies for their own build tools.
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
A
So
yesterday,
hopefully
some
of
you
attended
jason
hall's
talk
where
he
introduced
project
shipwright
and
gave
a
high
level
overview
of
shipwright
builds.
If
you
are
unable
to
attend.
I
encourage
you
to
watch
the
replay.
As
this
talk
will
assume
you
understand
the
information
jason
presented
today.
We
are
going
to
dig
under
the
surface
and
reveal
the
technical
details
of
how
shipwright
builds
work
I'll
start
with
the
anatomy
of
a
build
and
explain
how
shipwright
builds
run
on
kubernetes.
A
So
to
understand
how
builds
work
think
of
the
build
api
as
an
onion
onions,
have
layers
container
images
have
layers,
shipwright
builds
and
the
shipwright
build.
Api
also
has
layers
we'll
start
with
the
outermost
layer.
The
build
run
in
front
of
you
is
the
simplest
kind
of
build
run
you
can
create,
and
yet
it
has
all
of
the
information.
Shipwright
needs
to
extract
your
source
code
and
assemble
a
container
image.
A
A
So
let's
peel
back
this
layer
and
take
a
closer
look
at
the
build
object
here,
we
define
where
the
source
code
is
located,
where
we
want
to
push
the
image
and
which
strategy
we
want
to
use
to
assemble
the
image
you
can
see.
This
particular
build
is
cloning
source
from
github,
since
no
branch
or
tag
reference
is
provided,
the
source
is
cloned
from
the
repos
default
branch.
A
So,
let's
peel
it
back
once
more
now
we're
at
the
innermost
layer.
The
build
strategy
in
front
of
you
is
a
snippet
of
conoco's
example
build
strategy
which
you
can
see
in
full
detail
on
shipwright's
github
repository
conoco
is
a
tool
published
by
google
that
can
assemble
an
image
from
a
dockerfile
within
a
linux
container
like
one
that
runs
on
kubernetes
here,
we
outline
the
steps
needed
to
build
and
push
a
container
image
with
conoco.
A
A
The
shipwright
maintainers
catalog
build
strategies
for
common
image,
building
tools
like
conoco
builda
and
cloud
native,
build
packs
which
can
be
added
to
your
cluster
after
installation,
engineering
team
leads
and
maintainers
of
image.
Building
tools,
however,
may
wish
to
write
their
own
build
strategies.
A
A
A
We'll
apply
the
yaml,
and
now
we
are
on
our
way
to
creating
a
container
image.
You
can
see
up
top.
We
have
our
build
run.
It
has
the
succeeded
state
as
unknown,
because
well
we
are
running
our
build
below
that
you
can
see
that
we
have
a
pod.
The
pod
status
is
currently
not
ready,
but
clearly
something
is
going
on
here.
A
A
A
A
A
A
A
A
This
command
will
start
a
build
run
from
the
reference
build
and
will
follow
the
logs
once
the
build
run
starts
notice
that
when
I
start
the
build
run,
the
tekton
taskrun
object
is
created.
Its
status
is
reflected
directly
in
the
build
run
status.
The
task
run
in
turn
reports
its
status
based
on
the
underlying
pod
state.
A
B
Right
so
thanks
a
lot
adam
for
the
nice
explanation
with
all
of
those
details
in
mind
around
build
and
build
runs.
Now,
let's
take
a
look
on
the
details
behind
build
strategies,
so
I
would
like
to
do
a
quick,
deep
dive
on
you
know
all
of
the
concepts
behind
the
strategy,
so
at
the
end
of
this
call,
people
will
be
able
to
build
strategies
in
an
easier
way
or
also
to
achieve
optimal
strategies
for
building
their
container
images.
B
B
B
So
let's
speak
a
little
bit
about
the
scope.
This
is
really
simple.
We
have
two
types
of
scope,
a
cluster
scope
and
a
name
special
scope.
The
difference
is
like
the
first
one
makes
the
strategy
available
across
all
of
the
nine
spaces
in
the
cluster.
The
second
one
is
just
for
a
specific
namespace.
Keep
in
mind.
The
kind
is
different,
depending
on
the
scope
you
would
like
to
have.
B
The
next
thing
is
the
steps
the
steps
are
kind
of
the
core
behind
the
strategy,
as
a
step
defines
the
behavior
of
that
particular
strategy.
Typically,
in
shipwright,
we
define
strategies
with
a
minimum
amount
of
steps,
usually
one
or
two
and
steps
have
two
main
key
points.
The
first
one
is
that
the
steps
are
basically
going
to
be
executed
sequentially,
so
you
can
define
on
the
respect
that
builds
steps,
multiple
steps
and
all
of
them
will
be
executed
one
after
each
other.
B
The
second
one
is
that
the
content
of
each
individual
step
is
really
analogous
to
containers
in
in
kubernetes.
So
if
you
take
a
look
behind
the
object
of
a
step,
you
will
find
basically
the
same
kirby.
One
container
object
as
in
keep
upstream
so,
depending
on
the
use
case,
you
can
use
fields
like
resources
to
constrain
the
execution
of
the
step
security
context
and
so
on.
B
B
What
we
try
to
achieve
is
that
users
that
define
strategies
should
not
take
care
too
much
on
how
to
make
sure
that
the
source
code
could
be
available
in
the
rest
of
definitions
and
also
they
don't
need
to
develop
any
sort
of
binary
to
make
sure
that
they
can
pull
source
code
from
an
external
external
external
artifact.
In
this
case
kit-
and
we
provide
under
like
under
the
hood
all
of
the
the
steps
that
they
need
to
have
so
that
they
can
put
the
source
code
so
when
they
define
their
bill
and
push
step.
B
The
only
thing
they
need
to
know
is:
how
can
I
reference
the
path
to
the
source
code
that
is
located
on
this
particular
step?
If
you
will
try
to
do
that
through
technotus
runs
or
a
port
in
a
vanilla
queue,
and
it
is
closer,
the
complexity
will
definitely
be
higher,
as
you
need
to
do.
First
ensure
that
you
can
run
the
container
sequentially,
and
then
you
need
to
make
sure
that
you
can
share
data
between
the
two
containers.
B
The
next
thing
is
system
parameters,
as
I
said
before,
we
make
sure
that,
on
your
definition,
the
source
code
that
you
want
to
build
a
container
image
from
is
already
available
there.
You
just
need
to
know.
Where
is
that
store,
and
we
achieved
that
through
system
parameter
system
parameters
are
basically
reducing
the
techno
feature
about
parameters.
B
B
I
use
source
root
and
output
image
system
parameters
are
usually
prepended,
but
by
shp,
which
stands
for
shipwright,
and
what
I'm
simply
doing
in
this
example,
is
I'm
telling
my
step
to
look
for
the
source
code
under
the
source
root
param,
which
is
going
to
give
me
a
path
to
the
to
the
source
code
in
this
container,
and
the
second
thing
I
do
is
I
use
the
output
image,
which
is
going
to
give
me
the
value
on
where
to
push
that
image.
I
want
to
build
strategy.
B
Parameters
are
similar
to
system
params
in
a
way
that
they
use
the
same
feature
from
tecton,
which
is
parameters
where
strategy
parameters
are
basically
parameters
that
the
user
needs
to
define
in
advance.
In
this
case
is
the
same
example.
I
define
a
new
parameter
called
registry
insecure,
and
then
I
define
a
new
flag
on
my
screen
on
my
binary
definition
that
uses
the
registry
insecure
flag.
B
The
image
to
an
insecure
registry,
tooling
is
really
important.
There
are
two
things
behind
tools.
You
need
to
understand
why
you
need
to
use
a
particular
tool,
and
then
you
need
to
understand,
like
all
of
the
details
behind
the
tool
to
see
if
there
is
like
any
feature
that
you
can
take
advantage
of,
for
example,
if
I
would
like
to
have
a
container
image
build
from
source
code
that
have
an
option
of
a
docker
file,
I
will
probably
use
scannicon
buildkit.
If
that's
not
the
case,
I
will
probably
use
speedbox.
B
The
second
thing
is
like
I
know
that
candycomb
buildkit
have
nice
features
that
allow
me
to
generate
the
digest
of
the
image
into
a
file,
or
also
that
allow
me
to
have
a
caching
functionality,
so
those
are
definitely
things
that
you
want
to
keep
in
mind
so
so
that
you
can
understand
how
to
use
them.
When
you
define
your
strategy
today
in
shipwright,
we
have
six
default
tools-
the
ones
I
list
here
to
the
left
and
for
each
of
these
tools
we
have
an
independent
strategy
definition.
B
The
last
thing
will
be
surface
results.
This
is
a
feature
that
is
not
yet
in
place
same
as
the
strategy
parameters
and
surface
results,
basically
reduce
the
feature
from
tecton
around
results
and
in
combination
with
the
tools
we
use.
We
can
make
sure
that
valuable
metadata
will
be
surface
to
our
build
runs
once
they
run
to
compilation.
So,
for
example,
if
I
just
build
a
container
image,
I
should
make
sure
that
my
build
run
knows
about
the
container
image
digest
that
I
just
generate.
B
That's
all
for
now.
Let's
move
to
the
demo,
and
I
will
explain
here
how
to
use
these
concepts
in
practice.
Basically,
what
I'm
going
to
do
is.
I
will
show
you
that
I
have
already
a
build
right
in
the
devnet
space.
This
field
is
called
buildkit
build
and
that
reference
ability
the
strategy
name.
So,
let's
see,
how
can
we
apply
those
concepts
I
mentioned
before
in
the
definition
of
this
strategy,
so
we're
going
to
modify
the
strategy
now
right?
I
would
first
let
me
explain
you
what
is
happening
here.
The
first
concept
is
the
scope.
B
The
second
thing
is
like
the
the
strategy
have
a
single
step,
and
the
idea
behind
this
step
is
that
it
should
build
and
push
a
container
image
for
that
I
define
buildkit.
This
is
the
the
tool
of
choice
that
I
will
be
using,
but
so
far
on
the
execution
of
this
step,
nothing
is
happening.
So,
let's
modify
this.
I
would
like
to
show
you
now:
how
can
you
use
system
parameters
or
what
are
the
contents
behind
them?
B
B
Okay,
so
again
we
define
a
strategy
with
a
single
step,
but
at
runtime
we
have
to
step
source
default
and
bill
and
push.
So
this
is
the
nice
thing
about
shipwright
that
shipwright
will
repent
and
step
for
you
that
will
make
sure
that
the
source
code
is
available
to
you
from
this
repository
into
the
next
step.
You
don't
need
to
worry
about
the
source
default
step.
That
is
something
that
happens
under
the
hood
under
the
hood
for
free.
B
The
second
thing
is
this
parameters,
so
on
the
step
definition,
we
need
to
know
where,
on
this
step,
I
have
the
sources
and
where
I
want
those
sources
to
go
in
the
form
of
a
container
image.
So
if
you
take
a
look
on
sourcefruit,
which
is
a
system
parameter,
you
will
find
this.
This
value,
which
is
a
part
of
this
step
source
context,
is
the
same
case,
a
path
on
this
step,
where
the
sources
where
we
wanted
that
we
want
to
use
for
build,
are
and
then
output
image
is
basically
the
value
on.
B
B
So
let's
do
that
we
need
to
pipe
here.
Let's
make
sure
that
is
inline,
and
then
we
will
also
use
results.
Keep
in
mind.
Results
is
not
available
today
in
any
of
them
official
releases
and
also
the
api
may
change,
but
I
just
wanted
to
use
this
for
educational
purposes
again,
what's
happening
here,
so
I'm
using
the
ability
to
scripts
available
under
the
image
appeal
kit
and
buildkit
asked
me
for
three
things
it
asked
me
for:
where
is
the
sources
context,
so
I
use
the
system
parameter.
B
Where
is
the
docker
file,
which
happens
to
be
on
the
same
path?
So
I
use
the
same
system
parameter
and
where
you
want
this
image
to
be
pushed.
So
I
use
the
other
parameter,
which
is
output,
image,
with
the
build
kit,
full
20
and
not
to
put
an
insecure
registry,
and
also
then
we
use
the
techno
feature
about
results.
So
we
can
populate
a
result,
called
shp
image
digest,
and
I
will
tell
you
in
a
minute
how
this
one
is
very.
How
can
this
one
be
very
helpful?
B
So
we
save
that
we
go
back
here
and
now
we
see
the
locks
again.
So,
let's
take
a
look
on
the
new
build
run,
so
the
build
one
is
an
unknown
state,
so
it's
actually
on
the
process
of
building
the
container
image
and
the
bill
and
push
step
is
already
using
buildkit
to
build.
So
eventually
I
get
access.
B
I
basically
successfully
build
the
image
and
push
that
to
my
registry.
Now
I
spoke
of
results.
You
can
do
something
like
this
to
get
basically
the
digest
of
that
image
that
we
just
pulled,
and
you
can
basically
use
that
digest
to
pull
the
image
here
in
my
local
machine.
Okay.
So
that's
really
awesome.
Let's
move
back
to
the
presentations,
because
this
is
all
for
the
demo.
The
next
thing
is
a
code
for
action
or
join
us.
We
have
community
sessions
every
week
or
community
meetings.
B
We
have
a
lot
of
docs
and
examples
for
you
to
try
out
and
if
you
want
to
reach
out,
just
don't
hesitate
to
do
that.
We
love
to
hear
from
you.
We
are
available
at
the
slab
on
the
ship
right
under
the
shipwright
channel
and
also
we
have
a
twitter
account.
She
brought
that
shipwright
io,
that's
all
from
us
and
we're
really
happy
to
be
here
and
now.
Let's
open
the
session
for
q,
a.
A
B
A
B
B
You
will
basically
get
from
us
a
large
catalogue
of
images
that
are
already
well
known
in
the
kubernetes
landscape
and
you
can
easily
choose
on
which
one
to
to
use
for
for
building
the
the
type
of
source
code
that
you
have.
I
usually,
when
I
refer
to
type
of
source
code
or
flavor
of
source
code,
is
usually
a
source
code
that
have
a
notion
of
a
docker
file
as
a
way
to
dictate
how
to
build
that
particular
image.
But
also
we
have
situations
where
we
just
have
source
code
and
the
best
choice.
A
Yeah,
I
think
the
only
thing
I
could
add
there
is
one
of
the
more
interesting
things.
I've
observed
is
frameworks
that
are
and
tools
that
are
more
opinionated
for
the
language
and
they're
focused
on
specific
languages,
so
build
packs
is
that
first
kind
of
like
framework
where
it
lets
people
create
packs
that
can
work
with
either
like
go
java,
node.js,
ruby
and
so
forth.
A
But
then
you've
got
even
more
specialized
ones
like
jib
and
co
that
are
really
tuned
to
just
one
programming
language,
one
way
of
assembling
things
and
they
all
all
work
inside
of
a
container
which
historically
has
been
very
hard
to
do.
So.
That's
something
that
we
certainly
feel
like.
There's
going
to
be
more
of
that
in
the
future,
and
we
want
shipwright
to
be
a
place
where
those
things
can
come
and
be
distributed
in
the
hands
of
developers.
B
Yeah
also,
I
also
find
interesting
that
brian
mentioned
k.
Native
I
mean.
The
only
thing
I
could
say
on
relationship
with
k
native
is
is
that
today,
for
example,
you
can
allow
an
integration
where
you
have
shipwright
as
the
block
that
is
building
the
container
image,
and
you
can
definitely
integrate
that
for
with
something
like
a
native,
which
would
be
like
the
block
for
deploying
that
a
particular
container
image,
so,
I
would
say,
like
shipwright,
definitely
complements
a
full
end
to
end
story
in
a
kubernetes
cluster.
A
A
B
You
know
like,
for
example,
git
web
hooks
have
all
of
these
different
actions
on
what
happened
in
your
github
repository
from
pull
requests
that
get
married
to
issues
that
someone
open.
So
that's
definitely
something
that
k
native
eventing
can
support
today
and
that,
together
with
cheap
red,
that
could
also
be
a
good
story
for
someone.
A
Yep
another
thing
that's
worth
mentioning
that
we
have
a
I
either
it's
some
r
d
or
a
proposal.
That's
out
there
is
to
integrate
shipwright
with
tekton's
custom
task
feature.
So
in
that
case
you
can
declare
create
a
run
of
a
custom
task
and
then
shipwright
would
understand
that,
and
so
that
could
also
be
another
integration
point
between
shipwright
and
on.
B
Like
so
far
since
the
inception
of
the
project,
we
have
been
really
focused
on,
you
know,
making
shipwright
just
do
one
one
type
of
job
which
is
building
container
images,
but
just
going
back
to
the
question
is
shipwright.
You
know
like
ambition
to
build
persistent
images.
I
I
think
so
I
think
that's
that's
a
good
way
to
describe
that.
B
B
A
A
We
want
to
create
an
interface
where
it's
a
lot,
simpler
experience
where
you
know
what
you're
getting
in,
and
you
know
what
it's
going
to
be
executed.
There
are
some
things
that
we're
doing
in
an
opinionated
fashion
like
obtaining
source
code
and
but
then
there
are
other
things
that
using
the
build
strategies
you
as
a
developer
or
team
lead
or
someone
who's
managing
a
development
organization.
You
can
provide
to
your
developers.