►
From YouTube: Working Group: 2020-06-03
Description
* Publish a Buildpack with Pack: https://github.com/buildpacks/rfcs/pull/75
* Increase Build Plan Flexibility: https://github.com/buildpacks/rfcs/pull/82
* Lifecycle Arguments: https://github.com/buildpacks/rfcs/pull/84
A
A
A
A
A
B
B
B
C
A
A
A
A
D
D
D
A
B
E
E
The
cases
in
question
the
spec
says
you
should
return
a
404
status
code
and
then
also
has
additional
error
codes,
like
domain-specific
error
codes
and
the
body
of
the
response.
We
were
doing
our
logic
based
on
the
error
codes,
but
really
we
want
to
treat
all
before
a
force.
The
same
anyways
so
I
think
it's
the
training.
Just
fine
and
conscious.
D
B
B
A
B
B
B
B
Route,
buildpack
I,
think
that's
in
the
list
for
today,
so
I
write
Jojo
in
Chapter
this
one
cool,
publish,
build
pack,
attack,
I,
think
this
is
the
list,
so
many
RFC's
today
process
specific
environment
variables.
This
can
get
closed
because
it's
being
replaced
by
the
one
jesse
opened
here
number
83.
Is
that
right,
correct.
D
A
B
Yeah
I
think
in
general
we
wanted
to
block
it
on
the
route
buildpack
discussion,
because
driving
up
that
interface
will
help
and
it's
a
draft
just
because
we
didn't
want
to
forget
that
we
do
need
to
support
CA
cert
somehow
and
then
we'll
either
close
it
or
it
might
just
go
away
and
there's
routes
to
a
circle.
Peg,
don't
plan
merging
this
one,
probably
close
this
one
that
you
owe
us
I,
don't
know
that
I'm
gonna
be
pursuing
anything
more
than
this.
A
B
Were
some
structural
changes
to
the
build
plan
that
we
talked
about
like
not
having
single
it,
not
having
single
entries
for
all
the
individual
ones?
That
would
make
me
nervous
about
proceeding
what
other
changes,
unless
we
did
that
it
was
anybody
gonna
pick
up
those
structural
changes
like
combining
the
entries
into
a
single
item
list
instead
of
arbitrary
unordered
things
with
unmatching
names,.
A
D
It
was
that's
the
last
time
I'm.
Definitely
in
support
for
that
particular
thing
like
a
simplification
there,
so
a
I'd
be
happy
to
see
that
and
Terrance
I
don't
think.
Actually
this
was
in
particular
opposition
mine
is
removing
a
key
that
exists,
so
it's
somewhat
orthogonal
to
combining
the
multiple
names
thing
so.
D
B
E
B
Awesome
app
image
extensions:
this
is
part
of
route,
build
pack
I'm,
still
leaving
it
open
until
we
there's
I
get
to
a
more
narrow
consensus
on
route
buildpack,
although
I
think
we're
pretty
close
to
that
already.
So
I'll
probably
close
it
this
week,
all
right-
and
that
is
our
RFC
review.
Jumping
down
next
to
the
list,
I'm
gonna
go
kind
of
I'm
gonna
try
to
be
a
little
more
strict
of
a
moderator
for
this
one
cuz.
We
have
so
many
RFC's.
B
C
D
Look
and
I
believe,
Joe
and
or
Terrence
for
the
final
commenter
on
every
single
outstanding
comment
today
and
I
assume
Terrence
just
added
something
recently
and
Joe
can
sort
that
out
with
them,
meaning
that
we're
ready
to
vote
or
if
or
if
a
response
has
come
in
to
a
comment
as
you've
done.
Can
you
please
either
resolve
it
or
continue
that
conversation
so
that
we
have
an
indication.
A
D
Joe's
concerned
that
he
doesn't
know
what
needs
to
be
done
for
us
to
go
and
vote
and
I
would
say,
the
outstanding
thing
is
looking
at
all
the
comments
that
have
been
put
in
here,
including
by
you
to
Xavier.
Although
there's
my
name
there
as
well
so
I'll
call
myself
out.
Joe
is
the
final
comment
on
all
of
them.
So
can
we
resolve
those
conversations
if
we
feel
that
their
results
or
continue
them
on,
so
that
we
know
that
we
need
to
wait.
B
I'm
doing
the
last
group
meeting
a
comment
verbally
but
didn't
leave
a
comment
and
a
github
issue
that
the
schema
for
the
registries
list
could
use
execute
my
instead
of
key
names
or
like
arbitrary
key
names
at
the
table.
Names
so
like
default
registry
and
registries
as
an
object
list
with
a
name.
Key
I
can
add
a
comment
in
there.
But
that's
that's
what
was
holding
on
my
dog.
F
B
Let
me
share
my
screen.
This
is
real,
quick,
it's
a
simple
thing:
I
thought
Joey
wasn't
last
week.
Maybe
was
some
other
some
other
point,
but
just
this
you
see
sorry
did
my
share
work.
Yes,
oh
cool,
just
this.
If
we
could
move
to
and
like
I
can
be
convinced,
we
shouldn't
it's
just
everywhere
else.
We
seem
to
stick
to
something
more
like
this
name
equals
github
or
whatever,
and
then
a
top-level
key
like
default
registry.
F
We
have
another
place
that
we
have
this
sort
of,
not
the
structure,
that's
being
proposed,
but
more
or
less
the
objects
in
the
way
where
one
references
another
and
then
there's
attributes
on
that
other
thing.
If
that
makes
sense,
because
I
couldn't
really
think
of
any
tamil
file,
where
this
is
the
case.
But
if
I
look
for
like
prior
art
on
I
believe
nginx
and
Apache,
like
you'd,
see
references
where
they
use
this
sort
of
config
mechanism,
where,
if
you
have
something
that's
being
referenced,
it
would
be
then
named
under
that
object.
F
If
that
makes
sense,
so
I
have
a
very
slight
preference.
I
wouldn't
say
that
I
have
any
strong
preference
here,
but
it
does
look
cleaner
and
then
my
only
other
thought
to
that
was
kind
of
the
whole
idea
or
premise
of
how
you
would
manipulate
tumble
objects.
Is
that
isn't
that
one
of
like
the
selling
points
where
you
could
append
to
that
object?
If
you
use
the
same
name,
if
you
want
it
to
update
a
property
or
I
guess
I
should
say,
add
a
property
to
that
object.
B
B
B
We've
done
this
in
the
past
for
in
other
places,
and
so
my
only
comment
is
it's
less
consistent
with
the
configuration
we
have
files
we
have
other
places.
I
don't
have
a
strong
opinion
that
we
should
keep
doing
what
we're
doing
other
than
I'm
going
to
keep
saying
that
this
is
what
we
have
been
doing
like
when
we
propose
something
different,
but
if
we
want
to
change
direction
on
that
seems.
Ok,
there's
some
really
there's
some
weird
things
about
having
this
like
table
names
very
like
because
they
have
special
characters
of
them.
D
C
F
C
C
B
F
C
C
C
A
B
B
C
D
You
need
to
negotiate
an
OAuth
token
so
that
you
can
open
the
PR
right
against
the
github
repo,
and
so
the
the
token
will
be
passed
to
a
github
API
to
behave
against
a
build
packs
repo,
but
never
shows
up
into
any
running
piece
of
code,
server-side
from
the
build
pack
from
the
CMB
project
and
only
ever
exists
in
storage
and
I'm.
Actually,
okay
with
the
idea
of
storing
the
the
Refresh
token
itself
only
exists
on.
B
D
Yeah
and
to
be
clear,
like
we
control
a
bit
of
that
code,
right
like
we
could
do
something
nasty
with
our
CLI,
but
that's
sort
of
a
trust
thing
that
you're
gonna
have
to
go
because
we'll
ask
like
I,
think,
implicitly,
a
man.
How
else
really
confuses
me
around
this
implicitly
we're
going
to
get
a
relatively
low
permission
token
in
the
first
place,
like
the
thing
we're
going
to
request,
probably
needs
whatever
the
minimum
thing
is
to
like
it
doesn't
even
necessarily
need
identity.
It
means
whatever
the
minimum
requirements,
are
to
open
a
TR.
Yes,.
B
I
mean
at
the
point
where
we're
running
local
code
on
their
machine
like
there's
plenty
of
nasty
things
we
could
do
at
that
point.
So
that
doesn't
worry
me
I
just
just
want
to
understand
the
operational
aspects
of
you
know.
Do
we
need
to
operate
something
that
has
to
be
secured
to
a
certain
extent
and
yeah.
D
F
So
there
is
no
service
per
se,
but
kind
of
going
back
and
I'm,
not
sure
if
I'm
just
misunderstanding
something
but
the
headless
in
the
way
that
I
would
think
we
need
is
more
for
CI
purposes
and
not
so
much
for
anything
like
you,
wouldn't
even
have
the
capability
of
signing
in
through
OAuth
at
that
point
right
so
to
me,
I,
don't
know
that
that's
the
right
solution.
If
that's
what
we're
thinking
here.
F
D
A
D
A
C
D
I,
don't
think
that's
the
case.
I
like
I'd,
like
the
idea,
so
headless
is
a
thing
it
just
tied
to
the
wrong
behavior
headless,
given
an
access
token
right,
where
you
pass
in
an
access,
token,
is
great
right
or
a
username
and
password
or
whatever.
This
is
the
way
you
want
to
do
it.
You
use
the
substitution,
behaviors
and
github
actions
to
get
all
about
information.
I've
said
list,
meaning
that
is
a
feature
worth
having.
D
F
The
only
I
guess
the
things
that
are
at
odds
with
each
other.
With
that
proposal
versus
opening
the
browser
directly.
Is
you
know
if
they,
if
they
were
the
only
two
options
that
we
could
pick
from
right,
but
we
technically
could
have
more
I'm,
not
sure
if
I'm
explaining
it
correctly,
but
the
default
behavior
is
that
it's
going
to
open
up
the
browser
and
you're
gonna
be,
and
it's
going
to
have
a
pre
template
right
and
we're
saying
an
alternative
to
that
is.
F
D
F
D
D
B
Less
it's
less!
It's
not
reviewing
the
correctness
of
the
thing
you're
submitting.
It's
understanding
that
we're
about
to
act
on
B
we're
a
local
CLI
to
Lenoir,
about
to
act
on
behalf
of
your
user
and
making
you
actually
do.
The
acting
part
seems
safer
than
having
a
tool
that
does
an
action
in
a
place.
You
know
automatically
for
you
without
you,
knowing
necessarily
that
that's
what
it's
gonna
do.
D
B
D
F
So
why
don't
as
a
proposal
right
we
go
with
that
as
the
first
iteration,
so
we
have
that
option
where
pre-fills
we
have
the
option
of
headless
and
then
we
have
the
get
option
right
and
and
then,
if
there's
desire
to
improve
the
UX,
which
I
believe
been
that's
what
you're
after
and
I
I
agree
with
it
right,
but
we
could
kind
of
take
that
on
as
a
second
sorry,
I,
don't
know
that
we
want
to
battle
out
those
two
in
this
particular
issue.
I
can.
F
C
D
Since
mine
are
the
next
three
in
a
row,
first
one
is
increased
buildable
flexibility.
This
was
in
an
attempt
to
be
a
bit
more
constructive
than
just
complaining
about
the
one
about
build
plant.
Merging
I
decided
that
I
wanted
to
put
my
money
where
my
mouth
was
and
say:
hey,
actually,
I
think
we
should
be
advocating
for
something
that's
less
complex
than
what
we
have
today,
which
isn't
particularly
complex
and
part
of
that
was
removal
of
the
version
key
which
it
turns
out
is
not
it's.
D
You
know
we
glue
it
together
when
you've,
given
a
bunch
of
these
things,
you
can
do
straight
replacement
where
last
wins
it's
completely
up
to
you.
It
doesn't
have
a
particular
pride
of
placement
within
the
API,
so
that's
build
plan
flexibility
next
one.
Oh
sorry,
anybody
have
any
questions
on
that
before
we
go
further.
Yes,.
B
But
the
final
image
you
generate
doesn't
change,
and
it's
irrelevant
where
you
know
like
what
version
of
the
build
tool
was
used
to
create
the
image,
because
it
hurts
build
reproducibility
not
to
be
able
to
exclude
that
thing.
The
solution
to
that
could
be.
You
know,
separate
out
the
bill
of
materials
and
build
plan,
things
right.
That
seems
like
a
relatively
simple
path
forward.
There
I
I'm
a
little
afraid
of
making
a
breaking
change
here
without
thinking
about
the
larger
end
state
of
what
we
want,
so
part
of
that
is
excluding
the
build.
B
The
only
thing
that's
come
up
is
for
us
mentioned
to
be
open
to
opening
a
PR
and
is
restructuring
how
they're
received
so
that
you
don't
get
repeated
arguments
with
the
same
name,
kind
of
out
of
order
that
you
get
one
argument
with
a
name
and
then
a
list
of
the
our
white
box,
just
a
whiteboard
things
under
it.
Yeah
the
I'm
wondering
how
we
want
to
handle
the
execution
of
so
good.
D
Yeah,
so
all
very
good
points,
all
your
concern
about
multiple
breaks,
I
find
very
compelling
as
well.
My
strategy
for
dealing
with
that
is
these
are
a
bunch
of
RFC's.
These
aren't
even
spec
changes,
I
think
each
one
of
them
should
be
handled
individually
so
that
we
can
actually
get
these
through
and
get
agreement
on
small
things
and
then
batch
the
changes
into
a
single
spec
change,
possibly
multiple
commits
to
a
single
spec
increment.
What's
called
that
spec
version
increment
well
as.
A
I
guess
my
the
comment:
I
made
I
agree
with
Stephens
comment
about
like
on
Bill
plan
or
bill
materials
and
how
this
impacts
that
so
I
think
right
now
build
the
bill.
Plan
is
pretty
highly
time
and
I.
Think
if
you
connect
your
remove
versions
like
and
it
is
super
flexible,
it
may
not
actually
plug
the
bill.
Materials
like
you
can
put
whatever
you
want
to
build,
Glenn
right
and
that's
kind
of
by
design
of
your
purples.
D
E
D
B
Plan
it
looks
well,
we
also
add
information
about
the
build
packs
came
from
into
it.
So
it's
like
it's
influenced
by
the
fact
that
version
is
primarily
coming
from
the
build
plan
like
if
you
changed
it
to
the
version
wasn't
special
there.
You
would
almost
certainly
change
it,
so
the
version
isn't
special
to
build
materials
if
we're
not
going
to
make
the
build
materials
change
as
part
of
the
RFC,
it's
probably
worth
calling
out
in
this
RFC,
but
it
also
gets
demoted
the
dilib
materials.
Yes,.
A
B
A
D
B
A
Suggestion
I
guess
the
only
complication
someone
actually
has
a
virgin
thing
already,
which
I
don't
know
why
they
would
plus
you
in
the
old
salad,
but
that
was
kind
of
my
proposal
was
like.
Can
we
just
like
automatically
move
that
and
to
metadata
for
them
or
something
or
something
along
the
lines
like
make
it
more
today,
I
think
there
are
ways
we
can
do
it
where
it
doesn't
require
us
to
like
be
like
well
break.
This
just
breaks
the
world
like
I
think
there
is
a
bad
yeah.
D
D
Okay,
command-line
arguments.
Some
comments
have
actually
already
come
back
for
this.
The
motivation
for
this
particular
thing
is
today.
You
only
have
two
options.
You
can
run
a
pre.
Your
application
can
run
with
Acree
built
process
type,
including
a
default
one.
If
you
don't
specify
one
or
you
can
specify
an
entire
command,
but
going
back
as
far
as
call
it
five
years
now
over
on
the
Cloud
Foundry.
Sorry,
the
there
is
an
idea.
D
It
mostly
relates
to
running
with
tasks,
but
it's
by
no
means
exclusive
around
this,
where
what
you
want
to
do
is
take
most
or
take
all
of
a
pre-built
process
type,
because
you
don't
want
to
know
what
it
means
to
actually
run
java,
but
you
want
to
add
some
command-line
arguments
to
it.
So
it's
really
common
sort
of
in
the
spring
batch
case
so
describing,
if
you're,
going
to
run
ten
things
in
parallel
partitioning
up
the
data
set,
that's
an
input
to
those
batch
processes
so
that
you
know
each
one
works
on
a
different
piece.
D
So
you're
gonna
need
to
start
it.
You
don't
want
to
know
what
the
Java
command
actually
started.
It
was
what
you
need
to
give
them
some
information
about
what
exactly
they
want
to
do.
We
don't
have
a
strategy
for
this
as
it
exists
today,
because,
as
I
said,
you
only
have
those
two
particular
options.
We
hashed
out
in
slack
in
some
slack
somewhere
exactly
how
it
happened.
It's
a
strategy
for
this
that
basically
says
take
what
we
want
and
add
slightly
more
to
it.
D
If
there
are
0
arguments,
we're
going
to
execute
the
default
process
type.
If
there
are
n
number
of
arguments
and
the
first
one
happens
to
be
a
process
type,
you
execute
that
process
type
and
all
subsequent
arguments
or
arguments
appended
to
the
original
command.
If
there's
n
args
and
the
first
argument
doesn't
match
process
type,
but
it
does
match
something,
I'm,
sorry
and
it
does
not
match
something
on
a
resolved
path.
They
will
execute
the
default
process
type
so
basically
in
element
2
there.
D
D
B
However,
I
have
two
big
concerns.
One
is:
it
feels
very
weird
to
arbitrarily
upend
things
to
a
shell
command
separated
by
a
space.
The
shell
command
could
have
could
be
weird
bash
syntax,
with
a
conditional
at
the
end.
Right
like
the
it's,
it's
very,
it
seems
very
risky
and
I
haven't
seen
that
pattern
used
anywhere
else
to
just
you
know
space
this
based
this
at
the
end
of
a
shell
command.
D
So
you'd
made
a
suggestion
there
about
making
the
command
the
pre-built
commands
aware
of
incoming
arguments
in
some
way.
We
attempted
to
do
this
originally
in
the
Cloud
Foundry
world
and
it
was
roundly
rejected
by
everybody,
so
it
is
definitely
safer.
You
won't
catch
an
argument
for
me
on
that,
but
as
a
UX
people
really
really
didn't
like
it.
B
For
instance,
like
dollar
sign
one
in
the
thing,
so
the
currently
it
works
with.
If
you
specify
command
and
args
and
your
direct
equals
false,
then
the
arrows
get
provided
properly,
like
as
arguments
to
the
original
thing
as
a
function,
that's
quotable
and
you
don't
have
issues
with
trying
to
con
cat
pieces
of
that
stuff
together,
that's
what
you're
saying
was
rejected
for
Cloud
Foundry.
Initially,
no.
D
B
B
D
We
should
I'm
really
interested
to
for
this
one
to
actually
get
quite
a
lot
of
sort
of
practical
feedback
on
I.
My
read
from
specifically
spring
teams
who
are
asking
for
this
is
what
they
want
is
logically
for
you
to
append
this
to
the
command
that
was
going
to
execute
we're
gonna
ignore
for
a
moment.
You
know
trying
to
do
delimiting
and
evaluation
arts
art
delimiting
and
guaranteeing
that
the
argument
set
is
the
same
set
of
arguments.
B
You
could
imagine
you
shove
the
command
into
a
script
right
and
you
pass
the
other
arguments
to
that
as
a
script.
Right,
I,
guess
that
that's
essentially
the
same
as
the
behavior
right
now:
indirect
false.
If
you
pass
the
arguments
through
and
can
reference
them
yeah,
but
but
you
still
look
like
you,
could
you
could
see
a
way?
We
can
do
this
where
you
get
shell
parsing
on
the
arguments
and
the
arguments
get
passed
to
the
commands
and
but
their
proper
properly
received.
A
B
Yes,
quoted
dollar
at
to
the
end
of
the
command.
Without
you
having
to
do
that
right
and
then
those
arguments
get
shell
parsed
in
and
then
interpolated,
then
it
would
be
very
clean
right.
It
wouldn't
just
be
string
appending
so
that
that
could
be
path.
Word
I'm,
not
not
opposed
to
that
at
all
worth.
E
Noting
and
I
played
with
that,
the
wasn't
getting
evaluated,
necessarily
at
that
point
in
the
command
that
you
might
think
you
can
sort
of
see
the
comment
I
put
on
that
issue
like
if
you
pass
in
that
argument
yourself,
you
could
put
a
dollar
at
at
and
it
works
when
you
put
it
in
the
tunnel
file.
Something
was
going
wrong
with
the
where
it
got
evaluated,
then.
B
E
D
B
B
B
A
C
Like
I
worry
about
the
confluence
of
two
things,
one
is
that
for
some
platforms,
this
might
be
difficult
to
implement
and
certain
that
it's
true
with
Heroku
whether
you'd
have
to
expose
like
what
was
previously
kind
of
touch-free
other
than
like
completely
overriding.
You
have
to
introduce
some
kind
of
new
mechanism
to
to
support
this,
but
that's
fine
like
we
could
just
not
support
it,
but
then
I
worry
about
build
packs.
C
That
are,
you
know,
a
whole
bunch
of
build
packs
come
around
that
are
expecting
this
and
then
their
process
types
don't
work
unless
you
use
this
capability.
So
those
two
things
coming
together
worries
me
a
little
bit,
whereas,
like
the
the
alternative
you
have
with
the
n
bars
like,
while
it's
brittle
doesn't
really
encourage
you
to
like
make
process
types
that
would
break
I,
guess
but
I
think
what
would
make
me
more
comfortable
is
if
we
also
exposed
a
mechanism
in
like
project
Tamil,
which
is
I
know.
C
D
D
B
Last
other
thing
that
I
want
to
call
out
is
there's
a
lot
of
overloading
involved
on
a
single
list
in
this
case.
So
like
there's,
there's,
for
instance,
the
behavior
of
checking
to
see
if
a
binary
exists
and
then
passing
a
thing
as
an
argument.
If
a
binary
doesn't
exist
seems
like
it
could
lead
to
really
unexpected
behavior,
where
your
first
argument
happens
to
be
the
name
of
the
binary,
and
so
it
executes
that
binary.
Instead,.
D
That
I,
just
that
slot
discuss
from
which
I
maybe
I,
should
actually
put
it
in
the
entire
discussion.
I
have
the
exact
the
original
exact
same
objection
to
it
like
there
is
enough
vagueness
in
the
fact
that
you
sort
of
it's
like
not
just
a
pure
look
ahead.
There
is
some
retreat
in
certain
cases,
really
disturbs
me,
but
again,
I
think
it's
a
pragmatic
choice
given
how
we
use
or
visualizes
the
resolution.
E
Feel
like
the
more
breaking
alternative,
which
is
probably
safer,
would
be
to
say
that
you
can't
pass
a
process
type
as
a
bike
directly
into
the
long
term
and
said
you
have
to
set
CMB
process
type
and
then,
if
you
want
to
write
a
command
you'd
said
it
like
see
any
process
type,
none
or
something
like
that.
But
that,
like
what's
nice
about
this,
is
it
kind
of
works
with
things
as
they
are
now.
B
E
B
E
F
Yeah
and
I
mean
to
step
back.
This
is
already
pretty
confusing
right,
like
I.
Think
it's
not
very
well
documented
I
think
this
is
probably
the
best
documentation
that
we
have
about
how
the
launch
sequence
works.
So
I
don't
know
that
there
would
really
be
a
lot
of
challenges
for
breaking
anything
that
currently
exists.
If
we
were
to
better
define
what
you
know
would
be
best
for
the
UX,
essentially.
B
My
general
feeling
is
that
people
expect
docker
images
to
behave
where
they
pass
arguments
and
then
they
get
passed
in
as
arguments
and
that
that
should
be
like
the
default
ii
thing
and
that
we
should
figure
out
ways
of
not
breaking
that
and
supporting
the
other
functionality
on
top
of
it.
So
we're
not
building
images
that
are
less
compliant
seeming
than
what
other
people
are
building,
which
is
hard
because
we
had
this
launcher
thing,
but
it's
probably
not
impossible
right.
Yeah.
D
D
The
problem
is
that
it's
not
and
we
have,
if
the
let's
take
a
step
back
and
say
actually,
if
the
launcher
had
never
taken
arbitrary
commands,
if
you
couldn't
do
docker
run
in
bash,
we'd
be
in
a
much
better
situation,
ready
to
be
totally
consistent,
but
the
fact
that
today,
when
you
pass
a
very
specific
argument,
we
actually
execute
that
thing.
Instead,
rather
than
as
an
argument
to
the
launcher
or
to
your
process
type
yeah,
okay,
yeah,
like
I,
don't
think
we
need
to
beat
a
dead
horse
here.