►
From YouTube: Working Group: 2020-04-29
Description
Dan Bentley from Tilt demos an integration with Cloud Native Buildpacks and it's live update feature.
A
All
right,
we're
recording
so
as
I
was
saying
at
Dan.
Bentley
is
joining
us
today
from
tilt
who
said
I.
Think
I
can
explain
this
better
than
I
can
but
tilt
provides
a
local
development
experience
where
you
can
change
the
source
code
locally
and
see
an
app
it's
deployed
to
cloud
native
platform
that
uses
container
images.
I
get
updated
as
you're
modifying
code
we've
been
chatting
a
little
bit
about
what
it
would
look
like,
because
we've
always
had
this
sort
of
idea
for
a
development
API
in
cognitive,
build
packs.
A
We
never
kind
of
fully
fleshed-out
would
be
something
like
looks
for
a
tool
like
scaffold
or
tilt
or
whatever
to
be
able
to.
You
know,
do
what
tilt
does,
but
cool
sort
of
with
more
language,
runtime
support
in
a
more
integrated
way.
So
I
don't
know
Dan.
If
you
want
to
give
an
intro
to
what
tilt
does,
and
you
know
talk
about
a
group.
B
Yeah
I'm
going
to
share
my
screen.
I
hope.
That's
within
the
the
etiquette
of
this
meeting
and
please
yeah
feel
free
to
interrupt
me.
If
anything
is
unclear,
so
I'm,
Dan,
CEO
and
a
software
engineer
at
tilt
were
an
eight-person
startup
and
we're
making
this
tool.
You
can
see
here
it's
at
tilt,
dev,
it's
all
open
source.
So
oh
no
I
don't
want
to
change
anything.
So
you
can
go
over
here.
You
can
see
all
the
code
that
I'm
going
to
show
you.
B
A
of
what
using
tilt
is
like
on
this
demo,
app
that
was
published
as
part
of
the
poquito
buildpack
samples,
so
I'm
going
to
go
into
my
editor
and
when
I
run
tilt
up
it
does
something
in
my
terminal,
but
really
the
UI
we
care
more
about
is
over
here
in
the
web.
It's
being
served
off
localhost,
so
tilt
is
just
running
on
my
machine
and
because
I
started
it.
It
knows
about
all
of
the
different
microservices
that
make
up
my
app
in
this
case.
B
There's
just
one,
and
so
you
can
see
that
it's
running
the
the
the
command
it's
running
specifically
is
here
pack
build
Paquito
demo
app
dock,
and
then
this
is
a
bunch
of
output
that
I'm
less
familiar
with,
because
I
don't
use
PAC
that
often
I'm
new
to
it.
Hi.
Thanks
for
welcoming
me
when
I
go
to
the
vaquita
node
tilt
port
forwards
and
I
can
see
this
page
if
I
go
to
greeting,
which
is
another
endpoint
defined
here.
B
You
don't
have
to
know
about
that.
You
don't
have
to
know
about
Kubek
little
apply
or
docker
push,
and
now,
when
I
reload
it
hello
to
working
group
meeting
from
your
application
image,
so
that's
kind
of
layer,
one
and
I'll
just
pause
for
five
seconds.
If
there's
anything,
that's
unclear
and
then
I'll
show
you
the
thing
I'm
proud
of
that's
how
you
use
this
in
a
way,
that's
as
fast
as
you're
used
to
so.
B
The
tilt
file
here
is
what
configures
tilt
and
so
I
actually
have
two
versions
of
a
tilt
file
and
the
it's
written
in
spiral
arc
a
subset
Python.
So
when
I
save
the
tilt
file
to
use
live
update,
which
is
this
feature
till
it
offers
it
does
that
initial
build,
which
again
is
going
to
call
PAC?
And
it's
going
to
do
that,
update
and
we'll
see
that
it
ends
up
taking
on
the
order
of
ten
seconds
yeah.
It
took
a
little
longer
this
time
now.
B
So
that
my
demo
most
people
then
ask
you
what
kind
of
sorcery
is
this?
Are
you
a
witch?
Do
you
weigh
more
than
a
duck,
etc,
etc,
and
so
I'll
kind
of
dig
in
to
the
the
first
tilt
file
that
I
showed?
You
looks
like
this.
You
just
point
it
at
the
kubernetes
yamo,
you
say
hey
to
build
the
image.
Poquito
demo,
there's
a
command
that
you
run
and
whenever
a
file
changes
in
this
directory,
rebuild
it
and
then
I
want
to
port
forward.
So
you
don't
need
a
load
balancer.
B
B
That
will
restart
it
when
a
files
touched,
and
so
we
touched
that
file
after
copying
the
code
in
and
so
this
kind
of
strategy
we've
seen
work
with
all
different
languages,
whether
compiled
or
interpreted
so
yeah,
that's
kind
of
my
demo.
My
explanation,
I
can
dig
into
other
things.
I
can
shut
up
and
take
my
seat.
What
would
be
useful
in
this
forum?
I.
A
Think
one
of
the
most
interesting
things
to
me,
though
we
talked
about
one
of
it
before,
was
using
tilt
to
develop.
You
know
like
a
larger
microservice
cluster,
where
you
have
multiple
apps
locally,
maybe
and
they're
talking
to
each
other
in
the
cloud.
Can
you
talk
a
little
bit
about
how
tilt
enables
that?
Because
I
think
that
was
a
lot
of
value,
yeah.
B
It's
so
easy
to
operate
multiple
services
because
of
tools
like
CI
CD,
like
observability,
that
you
have
more,
but
that
breaks
our
standard
UNIX
paradigm
of
like
there's.
You
know
one
binary
that
has
one
standard
out
in
standard
air,
and
so
the
existing
tools
for
dev
don't
work
that
well
tilts
a
tool
that
has
a
workflow
engine
to
be
able
to
start
and
update
multiple
services
and
a
UI
so
that
you
can
dig
in
across.
B
Multiple
lots
of
people
will
just
kind
of
run
all
of
the
services
in
in
parallel
and
just
take
all
their
standard
outs
and
standard
errors
and
throw
them
into
one
one
stream,
and
it's
really
easy
to
miss,
airs
there.
And
so
what
works
I
did
about
is
that
when
you
have
tilt
it
keeps
these
alerts.
That's
able
to
to
show
you
what
the
problems
are,
that
yeah
I
don't
even
know
what
that
is,
but
it's
good
to
know.
Yeah.
B
So
that's
what
we're
enabling
and
it's
cool
to
think
that
we
were
able
to
use
tilts
extensibility.
So
you
know
you
can
go
in
and
kind
of.
If
you
go
to
the
tutorial,
it
tells
you
about
how
to
do
a
docker
build
which
just
uses
a
docker
file,
but
we
can
also
use
other
builders,
because
we
know
lots
of
people
aren't
satisfied
with
docker
as
a
builder,
and
so
we
were
able
to
just
slot
it
in
without
what
I'm
showing
you
now
has
no
changes
to
to
tilt
the
binary.
B
So
yeah,
we
think
that
if
you're
using
cloud
native
build
packs-
and
you
have
more
than
one
binary-
and
you
don't
want
people
to
have
to
go
to
any
kind
of
boot
camp-
they
just
should
be
able
to
get
going
when
they
start
we're
saying
you
can
just
tilt
up
and
be
writing
code
that
day.
So
that's
what
we're
trying
to
enable
for
development,
we're
kind
of
more
like
an
IDE,
so
your
CI
and
CD.
We
don't
know
how
to
help.
You
improve
that
much
because
there
are
lots
of
people
who
have
thought
about
that.
C
C
B
B
Of
yeah,
sorry,
sorry,
so,
yes,
we
want
the
tilt
file.
We
want
the
tilt,
you
almost
be
a
menu
of
the
workflows,
and
so,
in
addition
to
having
the
resources
that
are
about
like
keeping
a
kubernetes
service
up-to-date,
you
can
also
have
what's
called
a
local
resource
that
will
just
run
a
command
that
might
be
received.
This
database
or
delete
the
database
start
over,
and
so
you
can
have
different
of
those
in
there
if
you're
just
adding
a
package
to
like
pack.
B
If
you're
talking
about
installing
a
package
by
like
adding
it
to
package
JSON,
then
there
are
a
few
different
ways,
but
people
definitely
use
tilt
is
kind
of
up
to
your
team.
To
pick
which
model
you
want
of.
Do
you
want
it
to
just
be
installed
in
the
container
or
do
you
want
it
to
also
be
installed
in
your
git
client,
and
you
check
it
in
or
maybe
check
the
lock
file.
A
In
the
example,
you
showed,
if
you
added
a
package
to
package,
JSON
I'd
have
that
fall
back
online,
and
so
it
would
automatically
do
a
rebuild
and
install
the
package
and
it
would
just
take
longer
before
the
you
know.
You
got
the
feedback
they.
Yes,
the
package
is
installed
in
the
app
you
can
see
it
running
yep,
yeah,
yep,.
B
B
B
Yeah
I
mean
I,
think
I.
Think
the
big
thing
here
is
that
we've
seen
lots
of
orgs
that
move
to
some
version
of
kubernetes
or
microservices.
You
know
find
that
their
dev
story
is
either.
You
know
we
can
only
edit
one
service
at
a
time
or
we
can.
You
know
we
just
lose
kind
of
the
scope
that
you
would
have
had
with
a
monolith,
but
we
get
advantages
of
iteration
as
faster
and
so
till
it's
really
about
now
you
can
just
develop.
You
can
have
full
stack,
live
reload
for
any
part
of
your
app.
B
So
if
you
have
those
pains
or
if
you've
heard
people
complaining
about
those
plain
pains,
you
should
tell
them
about
tilt
or
tell
them
to
talk
to
me,
I'm,
damn
it
tilt
des.
If
you're
a
spammer,
you
can
already
figure
it
out.
If
not
that's,
who
I
am
among
Twitter
and
say
dumb,
puns
and
yeah
with
were
in
the
slack
channel
in
kubernetes
the
tilt
channel.
So.
D
B
B
I
think
it
would
be
awesome
right
like
what
I'd
love
is
that,
instead
of
having
to
write
this
yourself,
you
tilt
can
kind
of
just
ask
what
I
think
is
called
the
platform
for
this
kind
of
information
and
know
what
steps
it
needs
to
do
instead
of
having
developers
have
to
hard
code.
This,
which,
I
think
is
a
good
experience
minute-by-minute,
but
like
a
bad
experience,
trying
to
maintain
it
month
by
month.
Does
that
am
I
answering
the
right
question
did
I
understand
it?
Absolutely
yeah
yeah.
A
A
lot
of
value
here
is
having
the
build
pack
Express,
all
the
language
specific
stuff
to
end
up
with
the
correct
workflow
right
there.
It
doesn't
run
into
problems.
I'm
really
interested
in
you
know,
I
see
two
types
of
changes
here.
One
is
like
you
change
local
source
code,
there's
no
local
process
and
it
gets
not
blend
right
into
the
container
right
and
another
one.
Is
you
change
local
source
code
that
needs
more
processing,
and
so
you
do
a
full
rebuild
locally
and
it
gets
a
blue
container.
A
A
lot
of
the
fast
development
workflows,
especially
an
enterprise
that
people
are
interested
in
our
rebuilding
a
jar
like
a
rebuilding
Java
class
files
locally,
when
a
Java
files
change
and
doing
hot
swapping
into
the
JVM.
There
are
a
few
tools
like
like
spring
boot,
dev
tools
that
don't
have
that
local
processing
and
then
then
patching
into
the
container
workflow.
So.
B
B
You
go
and
you
you
can
see
that
in
a
bunch
of
our
example,
projects
or
sorry
yeah
in
our
examples
that
are
language
specific,
you
can
see
that
we
start
having
like
this
idea
of
local
resource,
which
is
how
you're
able
to
do
something
on
the
local
machine.
And
so
here
we
have
like
we
actually
compile
outside
the
image,
build
and
then
just
put
the
resulting
binary
under
the
image
and
kind
of
I.
Think,
depending
on
your
language,
like
constraints
about
like
binary
size,
network
bandwidth
tilt
can
work
with
a
kubernetes
cluster,
that's
running
either.
B
You
know
on
your
laptop,
like
mini
cube
or
docker,
for
desktop
or
in
the
cloud
like
kind
of,
depending
on
the
constraints.
I
think
there
are
a
bunch
of
different
ways
that
you
might
want
to
do
this,
and
so
here's
how
this
is
kind
of
how
live
update
can
have
some
stuff
that
runs
but
like
I
have
before
like
on
the
local.
Then
you
just
sync
some
things
up
and
you
can
compose
what
you
blonde
and
so
I
think
I
was
saying,
and
this
will
be
one
of
the
last
things
I
say
before.
B
I
go
kind
of
my
understanding
of
the
platform
interface.
Is
that,
like
the
things
that
you
want
to
do
here
of
watching
files
and
knowing
where
the
running
container
is
and
how
to
connect
to
it
are
kind
of
so
different
from
the
core
of
the
platform
interface
that
I
think
there's
almost
like
a
new
layer?
That's
the
piece!
That's
just
doing
the
I
called
it
dev
or
the
development
orchestration.
B
B
Steven,
if
you
could
help
me,
get
that
the
text
of
that
email
I
sent
somewhere,
where,
like
that's
available
to
this
group,
and
also
to
me
that
would
be
good,
because
I
I
do
have
to
run
and
I
hope.
I
didn't
take
up
too
much
of
y'all's
time
and
I
hope
to
ya
continue.
The
conversation
I
think
I'm
planning
on
coming
to
the
working
group
meeting
tomorrow.
B
A
C
You
know
having
to
restart
the
launcher
fast
updates,
I,
don't
think
we're
ever
gonna
get
to
a
point
where
build
packs
are
gonna,
be
fast
enough
to
run
all
the
time,
so
I
think
having
a
strategy
for
allowing
bill
packs
or
a
bin
develop
as
it
used
to
be
called
to
kind
of
export
information
about
what
type
of
file
changes
can
be
a
fast
reload,
and
what
a
you
know.
What
does
that
look
like
would
be
important,
yeah.
A
I
think
that's!
That's!
That's
gonna
be
key,
also
like
being
able
to
support
local
processing
first
and
figuring
out,
if
that
needs
to
happen
in
a
container
like
if
we
need
to
run
a
persistent
container
locally,
that
continuously
rebuilds
local
things
or
something
or
if
we
can
just
redo
a
pack,
build
and
come
up
with
like
a
patch
or
update
err
that
just
uploads
to
layer
contents
into
a
remote
running
container
right.
It's
just
like
a
bunch
of
open
questions.
A
D
A
So
I
think
tilt
with
a
live
update.
Workflow
till
it
never
runs
any
processing
in
the
remote
container.
So
if
you
change
your
local
package
JSON,
it
does
a
local
pack
build
right
and
then
sinks
the
card
and
then
just
we
Bri
pushes
the
image,
if
that
makes
sense,
there's
no
concept
of
like
syncing,
something
in
the
other
direction.
That's
my
understanding.
So.
D
D
B
C
C
A
I'm
really
excited
about.
You
know,
thinking
about
how
we
can
expose
the
right
to
hooks,
so
that
runtimes,
like
potato
Heroku
bill
packs,
can
express
things
like
what
files
change
of
these
different
cases
and
then
not
having
to
implement
the
thing
like
tilt
ourselves.
If
that
makes
sense
being
able
to
rely
on
specking
that
and
then
relying
on
you
know
tools
that
the
community
builds
to
handle
all
those
update
workflows,
because
it
seems
like
there's
just
immediately
a
lot
of
value
you
can
get
without
us
making
changes.
A
Imagine
what
it
looks
like
if
you
know
that
tilt
file
configuration
has
provided
an
even
safer,
even
more
robust,
faster
way
coming
from
the
runtime
right,
all
right,
coming
from
the
dual
tax
definition
of
how
to
make
changes
like
just
could
really
see
a
very
simple,
very
powerful
user.
Workflow
would
not
very
much
work
come
out
of
that.
If
we
can
define
what
those
contracts
are.
C
Similar
with
the
whole
vs
code,
SSH
and
remote
containers,
it's
kind
of
the
same
story.
We're
like
they've
got
all
this
work
on
being
able
to
attach
to
containers
or
spin
up
containers
to
find
with
either
compose
or
docker
files,
and
if
we
could
get
into
that
ecosystem
with
minimal
work
by
even
building
a
death
image
or
deaf
container
definition
or
something
did,
that
would
be
a
great
path
forward.
To
give
us
all
sorts
of
community
support.
I
think
I
mean.
D
Like
what
files,
if
there
were
changed,
what
files,
what
would
cause
a
cache
bust?
Basically
so
could
we
like
has
build
packages
to
check
those
something
like
to
build
materials
and
like
a
field
or
something
like
that
just
on
the
image?
Initially,
when
you
do
the
initial
build,
you
have
the
Bill
of
Materials
for
all
of
the
files
that
what
if
there
was
a
change
cause
bus
I,
don't.
A
Think
in
use
the
Bill
of
Materials,
which
is
like
just
like
the
dependency
metadata
list,
but
I
think
that
the
idea
is
exactly
okay.
I
proposed
I'm
about
to
post
a
link
to
a
doc
I'm
copying
from
an
email
thread.
I
had
it
in
earlier.
That
basically
proposes
that
it's
like
build
packs
should
be
able
to
output
a
list
of
files
and
associate
a
command
with
them
right
when
these
files
change
this
command
gets
run
in
the
container.
A
In
order
to
you
know,
sync
the
container
with
those
updates
without
the
container
having
to
go
down
right
and
then
maybe
there
are
two
lists
of
files,
there's
one:
that's
like
here's,
some
source
code
and
there's
another.
That's
like
here's
our
like
here
things
that
if
they
change
a
local
rebuild
process,
has
to
happen
before
the
you
know,
an
artifact
that
matches
you
know
that
gets
generated,
I!
Think
there's!
C
I
didn't
say:
you're
wrapping
it
one
of
the
things
that
Terence
was
hinting
at
when
he
was
asking
about
the
package
lock.
That
is
still
a
problem
that
I
think
I,
don't
know
like
arbitrary
execution
needs
to
happen
inside
Dehner
like
doing
an
NPM
install
of
a
package
if
you're
not
unless
we
expect
users
to
be
running
in
p.m.
externally
before
they
run
pack
like
you,
sort
of
really
want
to
run
those
inside
the
container
and
make
sure
that
those
changes
from
the
package
law
JSON
are
reflected
in
the
users
work.
C
You
know
a
host
host
file
changes
as
well,
because
you
can't
just
edit
the
NPM
file
by
itself.
If
you're
committing
a
package
lock,
you've
got
to
have
the
result
of
that,
but
I
don't
know
whether
we
really
want
to
yeah
I,
don't
know
whether
bill
Sheffield
packs
should
be
able
to
export
tasks
to
be
able
to
execute
things
like
that.
Like
crack,
develop,
NPM
install,
you
know
then
you'd
be
able
to.
C
C
With
a
potentially
different
version
yeah,
you
know
if
you
do
it
from
Windows,
where
you're
running
Linux
containers.
This
could
be.
You
have
to
ignore,
what's
generated
on
the
client
anyway,
but
you
can't
bring
into
modules
because
it
could
be
different.
So
you
need
to
run
that
in
the
container
and
so
now
he's
paid
for
the
install
twice
basically
I'm.
A
D
I
I,
just
it
just
feels
really
like
it's
like
one.
The
real
problems
with
docker
dev
in
general
is
just
like
this.
If
you
think
or
see
between,
like
what
is
local
and
what
is
in
the
container
that
I
feel
like
unless
you
can
solve
that
problem
like
requiring
me
to
actually
set
up
an
entire
notebook.
Dev
work
flow
like
app
like
what
am
I
getting
doing.
A
My
resistance
to
that
is
mostly
that
it's
like
a
very
specific
thing:
host
mounts
on
Mac
with
docker
for
Mac
for
a
really
long
time
were
too
slow.
You
couldn't
run
npm
install
in
a
container
and
have
it.
You
know
correctly
update
an
app
that
was
host
mounted
between
the
container
and
the
remote
thing.
Due
to
like
how
a
docker
for
mac
was
set
up,
I
mean.
D
I
also
think
like
if
we
were
to
yeah
I
also
feel
like
for
a
local
scene,
be
experience.
You
also
wouldn't
want
to
actually
do
the
MPI
install
over
a
bind
ball.
You
mount
like
you,
don't
want
node
modules
being
written,
it's
just
so
many
files
right
like
we
were
just
doing
the
demo.
That
I
was
asking
Jesse
did
demo
in,
like
it
has
what
like
seven
dev
dependencies
but
installs
170
packages
like
yeah.
It's
just
like
a
lot
of
files
right.
D
It's
like
a
ton
of
iron,
like
I,
still
think
you'd
want
that
in
the
container
and
a
layer
that
could
get
reused
again
right,
like
in
a
docker
volume,
but
I
think
the
key
things
are
like.
You
want
the
JavaScript
files
and
package
JSON
and
package
JSON
lock
like
not
require
me
to
have
to
run
a
team
install
separately
or
whatever
right
like
be
able
to
do
the
things
I
need
in
the
container,
but
still
have
that
environment
I.
Think
it's
kind
of
the
Holy
Grail
yeah.
C
And
the
volume
mounts
are
almost
flexible
enough
to
kind
of
make
it
to
your
point.
Steven,
like
the
Windows
node
modules
thing
is
also
a
nightmare.
The
performance
is
absolutely
atrocious,
but
you
can
kind
of
bind
mount.
You
know
if
you
buy
them
out
to
the
hosts,
but
then
you
can
create
volumes
that
Shadow
those
basically
you're,
overlaying
them
and
then
like
so
then
the
node
modules
happens.
Only
in
so
actual
rights
don't
have
to
come
back
to
the
host
and
then
so.
C
B
A
A
Don't
know
forest
I
might
be
wrong
now,
but
the
you
know
I,
like
I,
wonder
if
a
solution,
that's
really
technically
targeted
at
solving
individual
problems
around
the
fact
that
it's
hard
to
keep
a
local
directory
sync
to
their
performance
problems.
If
it's
gonna
get
it's
going
to
create
too
much
complexity,
yeah.
C
A
C
C
C
A
At
least
you
can
imagine
a
workflow
where,
if
the
host
mounting
really
worked
a
more
performant
right,
you
could
have
a
been
developed
that
just
always
assumes
that
your
app
directory
is
host
mounted
across
and
then
you
could
do
live
updating
where,
if
some
files
changing
something
like
tilt,
just
patches
them
right
in
the
container
and
if
other
files
change
it
does
a
rebuild
process
before
uploading
the
container,
and
if
other
file
has
change
it,
you
know,
does
a
full
rebuild
right
pro
scratch
or
something
like
that.
I
mean
like.
A
C
D
C
A
That's
the
benefit
have
been
developed,
though
right,
it's
like
making
it
making
it
a
totally
separate
contract
that
it
don't
pack
has
to.
You
know,
creates
like
like
been
build.
There's
no
part
of
this
workflow
use
been
developed
to
make
its
development
image
that
ends
up
in
the
cluster
and
been
develop
is
what
you
know.
Does
the
rebuilding
of
you
know
whatever
so
been
developed?
Could
just
never
delete
source
code
in
a
go
case
right?
A
It
could
always
be
there
or
it
could
delete
the
source
code
right,
but
only
in
the
image
that
gets
generated
remotely
and
then,
when
it
runs
locally,
it
doesn't
delete
the
source
code
so
that
when
you
change
it,
it
can
compile
the
artifacts,
attach
them
and
clear
emotive
image
right
really,
yeah
did
the
layer
layer
patching
without
a
layer,
upload
the
registry
and
just
I
think
there's
a
lot
of
easy
wins
here.
I
feel
like
especially.
C
D
Know
one
of
the
things
that
we
did
in
our
local
spike
was
actually
create.
Images
like
if
we
just
were
building
on
top
of
the
Builder
image,
and
we
were
running
run
like
detect
and
build
manually
and
the
lead
cycle
then
had
volume
mounts
for
basically
the
various
layers
that
would
pop
you
over
the
next
time
we
launched
the
container,
so
you
they
would
be
there,
and
we
found
that
like
export
was
a
non-trivial
amount
of
time
like
as
part
of
pack,
build
yeah.
C
Because
then,
our
users
aren't
exporting
and
local
development
to
a
registry
right,
so
we
so
we
really
wanted
to
cut
out
having
actually
craft
images
that
someone
could
then
accidentally
push
up
to
a
cluster.
You
know
like
it,
I'm,
not
against
creating
an
image,
but
I
do
think
that
having
a
way
of
just
running
it
without
creating
an
actual
image,
artifact
would
be
preferable.
You're.
C
A
Like
I
I
am
very
uninterested
that
make
sense
in
being
able
to
do
that
locally,
because
so
many
applications
people
develop
require
connecting
to
a
whole
bunch
of
other
services
that
you
can't
reasonably
run
on
your
machine
to
a
point
where
I
implemented
something
as
privacy
off
local
a
couple
years
ago.
It
would
make
SSH
tunnels
into
a
remote,
app
running,
nothing
and
just
bind
all
of
the
services
you
could
possibly
talk
to
and
redirect
them
back.
D
D
C
A
I
mean
I
think
you
can
do
what
Tilt's
doing
and
do
the
build
locally
and
use
a
host
mount
as
part
of
the
build
to
keep
your
local
files
synced
in,
like
in
one
workflow
right.
You
still
build
the
development
container,
it's
still
runs
in
the
cluster.
You
still
do
rebuilds
locally
and
the
host
mount
is
just
used
to
make
sure
that
your
local
files
stay
up
to
date
with
what
ever
been
developed
does
in
your
app
directory.
A
The
app
process
run
in
the
remote
environment
regardless
it
like.
Maybe
maybe
you
don't.
Maybe
you
push
made
scratch
right.
You're
just
copying
the
whole
image
in
there
when
you
start
right,
it's
not
it's
not.
Building
the
image,
that's
important
to
me.
It's
just
the
app
runs
in
the
environment,
where
everything
else
that
needs
exists.
I
feel
like
is
it's
pretty
important
for
a
lot
of
like
when
people
are
developing
real
production
apps,
as
opposed
to
doing
demos
where
in
most
cases,
what
did
they
just
reproduce
that.
A
There,
my
understanding
of
the
demo,
is
that
it's
not
they're
not
running
anything
or
ideally
you're,
not
running
things
locally,
that
it's
building
a
final
image
and
then
that's
running
in
a
cluster.
And
then
your
tilt
is
taking
care
of
tearing
up
the
changes
and
transferring
them
to
the
cluster
right
into
the
container.
A
D
D
A
It's
important,
if
you
can
do
the
host
mount
or
not
into
the
final
image,
that's
running
the
app
process.
I
want
to
assume
that
you
can't
you
couldn't
host
mount
into
the
the
actual
app
process
and
that
that
has
to
be
taken
care
of
by
something
like
tilts
live
update
this
transferring
files
to
it
so
that
so
that
you
can
get
used
the
same
workflows
locally,
with
mini
cube
or
against
a
cluster.
A
C
It
and
I
think
that's
fine,
too
I
think
yeah
they're
modifying
slash
workspace
directly.
If
that's
something
that
we
can
obtain
two
or
even
having
the
code
always
present
in
a
different
location,
and
then
you
know
copying
to
workspace
if
needed
like
you
know,
okay,
because
I
think
the
same
thing
sure
if
you
do
like
a
remote
container,
for
you
know
vs
code
or
something
like
that
right
like
they
could,
if
they
can
buy
mount
to
the
host,
they
will.