►
From YouTube: Platform Sync: 2020-09-09
Description
* pack 0.14.0
* Expose functionality to download buildpacks - buildpacks/pack#761
* Windows Dev README
A
A
A
A
A
On
my
side
in
particular,
honestly,
I've
been
working
more
on
docs
than
anything
else.
My
goal
for
today
at
least
this
week,
is
to
publish
either
a
blog
post
or
a
guide
for
how
to
work,
ssl
or
add
ca
certs
to
the
build
process
right
now,
that
solution
does
involve
mounting
volumes,
so
it's
nothing
very
specific
to
pack,
but
that
is
the
way
that
you
would
get
that
result
for
pac.
B
I
got
a
quick
one.
We
were
working
on
getting
that
lifecycle
image
support
for
windows
in.
I
think
we
finally
figured
out
what
the
problem
was,
so
we
can
get
rid
of
the
sleeps
and
I
think
it
should
be
ready
for
review
pretty
shortly,
but
thank
you
all
for
the
input
on
that
one.
I'm
just
going
to
do
a
last
pass
to
make
sure
we
addressed
all
the
comments
in
there.
B
C
Just
real
quickly,
we
merged
last
friday,
the
github
actions
that
are
responsible
for
consuming
bill
packs
for
the
registry
and
indexing
them.
So
that's
good
in
addition
to
that
I'll
be
spending
some
time
this
week,
just
kicking
the
tires
on
it
and
making
sure
that
there's
no
other
obvious
bugs
that
need
to
be
addressed
before
making
it
public
and
yeah
slowly
making
progress.
But
it's
looking
pretty
good
right
now.
C
A
All
right,
let's
move
on
to
release
planning,
I
guess
one
of
the
things
that
we
could
start
doing
as
part
of
release
planning
well
before
we
actually
are.
You
know
in
kind
of
that
release
process
feature
complete
is
we
could
start
looking
at
the
milestone,
and
I
know
someone
had
called
out
previously
that
there
are
some
issues
in
here
that
have
the
status
of
discussion
needed
and
I
think
maybe
we
could
circle
around
and
focus
on
some
of
those.
Let
me
share
my
screen.
A
Okay,
am
I
sharing
the
right
one?
You
see
the
issues
cool
all
right,
so
discussion
needed.
We
could
go
down
here
and
we
can
see
whether
or
not
you
know
stop
me
if
this
is
something
that
you
think
that
is
worth
discussing
right
now.
I
know
for
some
of
these
david
fralick
who's,
not
on
the
call
probably
wants
to
discuss,
but
we
will
likely
skip
over
those.
A
So
the
first
one
on
the
list
is
add
labels
to
pack
volumes.
So
the
idea
of
this
is
to
like
during
pack
build.
We
create
these
volumes
that
we
use
for
caching
and
whatnot,
and
the
idea
here
is
to
enable
support
to
figure
out
what
those
volumes
are,
so
that
other
tools
and
maybe
a
tool
of
our
own,
could
then
go
and
clear
these
volumes
directly,
so
just
adding
annotations
to
do
better
clean
up
process
right.
I
don't
necessarily
know
what
the
discussion
is.
That
is
necessary.
A
I
think
this
is
ready
to
go
but,
like
I
said,
if
you
have
any
thoughts
or
conversation
that
you
want
to
have
around
this
feel
free
to
jump
in
next
one
adjust
container
limits.
This
one
seems
like
it's
not.
I
looked
through
it
ben
hill
requested.
This
sounds
like
the
build
packs
team
also
has
some
requests
to
this
from
the
pocato
side.
A
A
A
So
there's
a
pretty
big
open
question
here.
I
think
we're
talking
about
content,
trust
and
image,
signing
there's
a
lot
of
research
that
we've
been
doing
on
the
vmware
side
in
regards
to
image,
signing,
and
particularly
notary
v1
versus
notary
v2,
which
notary
v2
is
still
like
very
early
stages
of
the
discussion
or
the
spec
side
of
things.
A
So
no
looking
at
notary
v1
everything
is
currently
possible
without
introducing
anything
to
another
project.
So
I
don't
necessarily
think
that
this
is
something
that
we'd
like
to
achieve.
We
might
consider
adding
better
integration,
but
overall,
it's
the
notary
aspect
is
like
an
after
the
fact
operation
right.
So,
if
you
think
about
other
platforms
like
k-pac
or
tekton,
or
something
you
could
always
sign
or
notarize
an
image
after
the
fact,
if
that
makes
sense,.
D
A
D
C
A
Yeah-
and
I
think
that's
the
clarifi
clarifying
question
that
david
just
posted-
or
I
mean
I
say
just,
but
this
was
back
in
july
and
we
got
no
reply
right.
I
think
that
use
case
is
very
different
to
the
use
case
that
I
made
mentioned
to
so
I
think
those
those
are
discussions
that
maybe
are
worth
having.
I
don't
know
jesse.
If
you
want
to
attack
something
onto
this
issue,
sure
we
can
explore
it
further,
but
I
think
that
might
be
more
reasonable.
B
I
would
be
loads
of
forget
windows
in
here,
just
there's,
not
a
there's,
not
an
issue
with
any
issues.
I've
seen
with
windows,
sending
windows
images
despite
them,
having
sort
of
a
dynamic
piece
of
them,
the
foreign
layers,
so
long
as
that
original
manifest
and
config
stay
totally
intact,
and
it's
still
always
treating
them
as
foreign
layers.
The
image
signature,
every
signature,
implementation
that
we've
looked
at
so
far
is
fine.
With
that.
B
Cool
there's,
there
is
kind
of
a
weird
trick.
You
have
to
do
with
a
with
a
air
gapped
environment.
You
have
to
side
load
the
foreign
layer
into
that
private
registry,
but
if
you
add
it
as
a
layer
blob,
it's
just
there
it'll
be
pulled
from
the
registry
instead
of
the
foreign
layer
source.
If
it's
available
in
the
registry.
A
B
A
Yeah
to
add
to
that
right,
like
the
complexities
of
the
air
gapped
environments.
As
far
as
I
know,
one
of
the
challenges
that
notary
v2
is
trying
to
solve
is
for
that
use
case
right
now,
notary,
as
far
as
I'm
aware,
does
not
work
in
their
gap.
Environments,
because
there's
a
central
notary
server
that
it
needs
to
communicate
to
validate
the
signatures
that
make
sense.
B
A
D
A
C
A
Pack,
build
should
log
lifecycle
arguments.
Oh
this
one,
I
feel
so
bad
about,
because
someone
came
in
created
in
a
pr
for
it
and
then
I
think
during
the
pr
process
we're
like.
Oh,
we
don't
actually
want
it
implemented
that
way
and
ultimately
ended
up
being
that
we
weren't
necessarily
sure
exactly
what
we
wanted,
given
how
the
environment
itself
is
set
up
so
yeah.
A
A
C
B
C
D
A
B
Yeah,
the
short
version
is
that
this
is
kind
of
a
the
rfc
proposes,
sort
of
a
won't
fix
as
far
as
the
pack
and
life
cycle
is
concerned,
basically,
would
want
to
require
stack
authors
to
always
make
the
images
contain
a
config
path,
similar
to
what
the
linux
images
have.
Although
the
linux
images
inherit
that
field
from
they
inherit
it
from
their
base
images,
so
we're
just
kind
of
adding
the
missing
piece.
That's
not
inherited
from
windows
images,
then
all
the
detail
in
the
the
is
in
the
rfc.
A
D
D
D
Yeah
we
use
pac
as
a
library
to
build
the
images
today,
but
we
don't
currently
allow
custom
build
packs
in
our
current
implementation,
and
so,
if
we
start
doing
that,
like
I
don't
think,
there's
currently
a
way
for
us
to
like
download
those
inside
of
like
a
running
container,
for
instance,
is
kind
of
our
use
case.
We're
going
to
run
a
container.
We
want
to
download
these
build
packs
and
use
the
same
semantics
without
users
having
to
you
know,
figure
that
out
or
us
having
to
re-implement
all
of
it.
A
A
Where
it'll
just
provide
this
functionality
from
a
cli
perspective,
and
I
feel
like
that's
still
very
nebulous
right
like
we
haven't,
really
figured
out
exactly
what
functionality
would
go
into
that
utility,
but
for
this
particular
issue,
given
what
you've
mentioned,
I
think
it's
we
could
just
go
ahead
and
do
it
and
then,
if
we
ever
want
to
move
it
out
to
something
else,
something
stand
alone.
We
could
do
that
at
that
point
and.
D
I
know
there's
been
discussions
on
like
a
life
cycle,
prepare
phase
potentially
eventually
that
would
like
download
from
a
project
tamil,
and
so
I
could
see
this
being
useful
in
that
same.
You
know
similar
circumstances
where
life
cycle
itself
is
going
to
need
to
parse
things
that
are
in
project
tunnel
and
then
potentially
download
them
and
from
registries,
and
that
would
be
it
would
be
nice
to
be
able
to
not
have
to
reimplement
in
life
cycle
as
well.
A
Yeah-
and
I
think
that's
where
I
got
the
pushback
from
emily-
I
think
her
thoughts
are.
This
is
like
very
much
so
a
platform
concern
that
she
doesn't
feel
that
it,
it
should
be
part
of
the
life
cycle
right,
so
something
like
pack
light
or
platform
light
is
more
or
less
kind
of
where
what
we're
thinking
about,
but
again,
nothing
really
tangible
there.
So
I'm
gonna
go
ahead
and
move
this
oops
to
status
ready,
and
we
could
do
this
just
as
a
interim
step
to
unblock
you
at
least.
D
The
last
one
just
so
you
don't
have
to
switch
over
there.
I
added
one
thing
to
agenda
just
asking
about
the
windows
like
as
a
developer
story.
I
know
we
talked
about
improving
that
and
I
was
wondering
if
there's
an
updated
like
read
me
somewhere
for
someone
to
follow
or
or
is
it
only
sort
of
still
tailored
towards
vmware
accessible?
B
Apart
again,
what
I
was
hoping
for
is
that
that
you
know
if
those
in
an
ideal
world
we'd
have
a
individual
developer,
dev
machine
that
was
as
close
as
possible
to
a
github
actions,
runner
the
default
one,
and
so,
if
it
failed
on
ci
you'd,
be
almost
guaranteed
to
be
able
to
reproduce
it
on
that
on
that
dev
vm.
So
I
think
we're
what
we'll
end
up
was
is
pretty
close
to
that.
We
just
are
trying
to
make
sure
that
the
technical
pieces
make
sense
before
we
put
the
polish
on
the
dock.
D
B
B
D
D
A
D
D
But
yeah,
I
think
it's
the
case,
because
the
opposite
is
true.
Right
like
like
right
now
we're
working
with
the
canika
stuff,
and
you
can't
pull
that
stuff
when
you
do
any
sort
of
go
build
and
on
windows
that
just
doesn't
exist
for
that
platform,
and
so
the
so.
I
would
expect
the
reverse
to
be
true,
too.
I
think
you're
gonna
have
to
have
both
platforms
to
really
get
the
linting
and
stuff
at
that
level.
Probably.