►
From YouTube: CNB Weekly Working Group
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
A
B
C
C
And
there
yeah
there's
a
bunch
of
things
that
we
wanted
to
just
get
through.
First
is
a
builder
config
rfc.
Now
some
of
you
wrote
this.
I
know
a
bit
about
it,
because
this
is
something
that
I
think
we
incubated
internally
in
bloomberg,
and
I
think
it's
it's
a
really
good
idea,
because
we've
been
using
it.
Do
you
want
to
introduce
it.
D
I
think
we
did
that
yesterday.
E
A
B
B
Now
quite
a
few
of
these
build
packs
have
very
similar
logic,
except
for
maybe
for
some
use
cases
or
for
some
enterprises
you
want
to
be
able
to
set
or
default
some
behavior
in
the
build
packs
using
environment
variables.
B
And
currently
you're
not
able
to
do
that,
because
the
life
cycle
strips
out
any
environment
variable
except
for
a
bunch
of
allow
listed
ones.
The
file
version
is
like
still
somehow
doable,
because
you
can.
You
can
inject
these
files
in
the
build
image
and
if
the
buildback
or
like
the
tools
that
respect
them,
find
them
in
the
appropriate
place.
They'll
use
them,
but
that's
not
true
for
environment
variables,
which
are
just
stripped
away
during
the
detect
and
build
process.
B
So
the
idea
behind
this
rfc
is
like.
Let's
say
you
have
a
common
set
of
build
packs
and
a
builder,
and
you
want
to
customize
it
for
different
environments.
So
let's
say
you
have
a
builder
that
you
use
for
like
general
internet,
but
when
you're
using
the
same
builder
in
the
enterprise
context,
you
want
to
set
environment
variables
to
modify
like
what
your
go
proxy
configuration
looks
like
or
your
pip
index
url
or
you
wanna
default,
some
behavior
of
the
build
pack
which
is
configured
by
environment
variables.
B
So,
let's
say
externally:
the
build
pack
during
its
detect
phase
looks
at
a
file
name
called
foo,
but
you
can
change
that
value.
That
it
looks
at
using
some
environment
variable
to
bar,
so
the
idea
was
like
to
provide
some
way
for
builders
or
build
images
to
specify
a
set
of
environment
variables
that
are
available
during
build
and
detect.
B
So
again,
this
comes
down
to
more
of
a
security
concern
where,
like
individual
build
packs,
if
they
choose
to,
they
can
ignore
user
provided
environment
variables
by
setting
the
clear
end
flag
in
their
buildback
normal,
but
there's
no
way
for
the
operator
to
enforce
that.
Hey
only
use
these
environment
variables
and
disregard
the
user
ones.
B
And
the
proposal
is
that,
similar
to
our
inf
directory,
that
we
have
for
buildbacks
introducing
something
very
similar
for
build
images,
so
you
can
define
a
cnb
bill
config
in
directory,
where
you
can
again
put
key
value
pairs
where
the
key
is
the
name
of
the
environment.
Variable
plus
an
action
if
needed,
and
the
value
of
the
file
is
the
value
you
want
to
set
the
environment
variable
to
there's
a
slight
difference,
though
the
default
behavior
for
the
value.
B
So
if
you
don't
specify
an
action
is
dot
default,
so
it
will
not
overwrite
the
user
provided
environment
variables
in
the
platform.
Only
if
you
explicitly
set
it
to
override
will
it
override
it
and
similarly
for
prepend
and
append,
like
it
will
just
prepend
and
append
to
the
user
provided
environment
variables
and
that's
pretty
much
the
rfc.
I
also
have
a
reference
implementation
in
case
people
want
to
understand
a
bit
more
of
what
it's
doing
but
yeah.
It's
not
anything
too
complicated.
B
So
this
can
also
potentially
be
implemented
as
a
bill
pack,
or
at
least
parts
of
it
can
be
so
you
can
definitely
set
build
time
environment
variables
using
a
build
pack.
That's
the
first
buildback
in
the
group.
Now
it
doesn't,
let
you
set
detect
time
environment
variables.
It
also
doesn't
let
you
modify
user
inputs
for
other
build
packs.
B
B
I
think
the
life
cycle,
one
is
the
most
consistent
way
of
achieving
this.
The
other
question
I'd
gotten
was
like
the
overrides
one,
but
I
think
I
clarified
the
rfc
a
bit
more.
F
F
It's
interesting
because
we
like
almost
have
an
interface.
That
already
does
this,
which
is
why
I
think
it
does
make
sense
to
do
this
in
the
life
cycle
like
how
we
process
the
user
enter.
F
F
F
F
We
will
also
treat
this
way
whether
it
got
there
because
we've
baked
it
into
the
builder
which
maybe
we
you
know,
eventually
provide
a
mechanism
to
allow
people
to
do,
or
it's
like
a
platform
deciding
that
it's
going
to
mount
its
one
like
I
always
mount
this
here,
which
is
sort
of,
I
think,
was
the
original
intention
of
the
platform
directory,
but
that
requires
you
to
merge
stuff
with
the
user's
input
in
a
way.
That's
actually
not
that
easy,
like
it's
not
as
well,
designed
as
it
could
be.
Yeah.
B
I
don't
want
to
introduce
the
bindings
concept
to
the
builder,
because
people
will
likely
put
secrets
in
there
they
they
can
because
they'll
be
like.
Oh,
this
build
pack
lets
me
configure
like
the
secret
file
using
bindings.
Let
me
just
put
it
in
the
builder
for
everyone
to
use
so
like
I
wanted
to
limit
it
to
like
environment
variables
for
a
reason,
because
at
least
the
build
pack
like
the
buildback
documentation
wouldn't
be
like
hey
put
this
as
an
environment
variable.
B
It
will
always
be
like
put
this
as
a
binding
and
there's
no
there's
like
a
clear
distinction
that
bindings
are
only
user
provided
and
can
never
be
made
into
the
builder.
So
the
only
other
thing
that
leaves
us
with
is
this
environment
variable
directory,
and
we
already
have
like
the
same
directory
structure
in
build
packs
in
platform
in
and
in
this
builder
config,
and
so,
if
you,
even
even
if
you
look
at
the
reference
implementation,
there's
not
much
different,
I'm
doing
that,
like
it's
literally
reusing
the
existing
code.
B
So
if
we
change
one
I'm
guessing,
the
others
will
also
change.
The
only
difference
is
the
default
behavior.
If
you
don't
provide
an
action
in
the
build
packs
case
it
overrides
in
the
platform
case.
There
are
no
actions,
it's
always
over
right.
There's,
no
pre-pen,
there's
no
append,
there's
no
default,
and
in
this
case
default
action
is
like
set
it
only
if
it's
unset.
F
F
And
like
maybe
you
want
to
do
that
for
users
too,
because
users
aren't
usually
like
creating
this
directory
structure.
So
if
you
wanted
their
default
to
be
override,
like
you
could
do
that
in
whatever
interface
they're
providing
the
stuff
in
rather
than
at
this
level,
in
the
lifecycle
interface,
it's
like
when
things
are
exactly
the
same,
but
slightly
different.
It's
like
more
annoying
than
if
they're
literally
the
same.
B
Yeah
the
platform
men's
directory
also
does
some
other
special
things.
If
the
user
sets
a
path
variable
instead
of
overriding
it,
it
will
prepend
to
it
so
like
if
it
comes
across
the
posix
environment
variables,
it
prepends
without
any
preference
to
whatever
the
user
said,
and
if
it
comes
across
non-posix
variables,
it
will
override.
F
B
B
B
Yeah,
that's
what
I'm
saying.
That's
weird
yeah
like
from
a
user's
perspective
like
they're,
providing
those
input
variables.
First
then,
like
each
build
pack
is
saying:
hey.
I
set
these
environment
variables
right
like
for
the
next
build
pack,
that's
completely
unaware
of
it.
It's
like
I'm
gonna,
ignore
all
what
all
the
previous
buildbacks
thought.
B
F
Yeah
any
justification
I
give
word
is
going
to
be
like
just
retroactive,
because
I
think
these
decisions
even
predate
my
involvement
in
the
project.
This
was
like
og
og
prototype
decisions
that
we
just
never
changed,
but
if
I
was
trying
to
post
talk
justify
it,
it
would
be.
F
B
F
F
Somehow
it's
like,
if
you
know
you
can
have
any
number
of
directories
in
this
structure
and
they
get
applied
so
that
you
know,
if
maybe
they
were
like
two
extension
points
like
maybe
someone
wants
to
put
something
in
the
builder,
but
then
the
platform
wants
to
inject
other
things
later.
It
could
work.
F
B
F
F
So,
like
you
could
imagine
the
builder
you
know
having
the
build
config
baked
into
it,
but
now
imagine
like
hack,
wants
to
always
set
x
number
of
pack
environment
variables
right
now.
It
like
either
merges
them
into
user,
but
you
don't
know
which
ones
at
that
point
are
really
user
versus
really
platform
or
it's
you
know
it's
going
to
mount
over,
build
config
and
then
you've
lost
your
builder
provided
ones.
B
But
that's
the
argument
for
project
tomorrow
right,
like
project
tomml,
also
allows
you
to
a
way
to
do
that
and
like
you,
can
also
specify
it
using
pack
command
line
options
but,
like
you
might
want
to
have
some
back
defaults
enabled
at
the
end,
it's
a
platform
concern
right
like
how
it's
mounting
everything
like
it.
There's
no
new
concept,
that's
being
introduced
builder,
is
a
separate
concept
owned
by
the
operator
platform
is
owned
by
the
whoever
owns
the
platform,
and
then
you
have
the
application
owner.
B
F
Yeah,
I
don't
know,
I'm
not
saying
that
I
have
a
third
option
here.
It's
just
like
if
it's
easy
enough
to
support
n
versus
two
like.
Maybe
we
want
to
consider
it,
it's
like
here's
a
directory
and
then
you
put
a
directory
underneath
it
and
then
end
under
that.
And
then
you
know
you
can
mount
arbitrary
ones
in
the
future
sort
of
like
what
we
do
with
bindings,
where
the
name
of
the
binding
directory
doesn't
really
matter.
E
I
think
jesse
and
I
had
sort
of
touched
on
it
at
some
point
where
it
would
be
nice
if
some
of
the
sort
of
path
parameters
for
the
life
cycle
actually
worked
like
the
path
option
on
post-6
right,
where
you
could
put
a
colon
and
then
be
able
to
pass
multiple
paths
to
it,
and
then
it
would
do
a
sort
of
look
up
or
apply
based
on
sort
of
the
order
of
those
different
paths.
E
You
could
achieve
the
same
thing
with
just
one
argument,
so
that's
sort
of
just
a
general
idea
in
this
discussion.
The
thing
that
comes
to
my
mind
that
I
maybe
want
to
look
into
a
little
bit
deeper
is
order
of
presidents
and
it
seems
like
there's
a
certain
sort
of
like
keyword
or
functionality.
That's
desired
to
essentially
freeze
a
value
and
not
allow
for
any
further
sort
of.
E
So
I
think
the
order
of
presidents
might
be
easier
to
solve,
for,
I
think,
the
freezing
of
a
variable.
I
think
I
don't
know
that
I
want
to
attach
it
to
it
being
from
a
build
config
right,
especially
if
we're
saying
that
there's
n
places
where
things
come
from,
I
think
maybe
there's
value
in
having
in
a
different
a
different
keyword.
B
Then
it
should
be
like
the
bill
packs,
because
that's
that's
what
that
that's
what's
modifying
or
running
things
and
then
builder
is
a
combination
of
build
packs
with
the
base
environment.
So
whoever
created
the
builder
knows
about
the
build
packs
their
behavior
and
also
wants
to
inject
other
modifications
on
top
of
it.
So
purely
from
a
security
perspective,
my
preferred
order
would
be
user
bill
pack
and
then
builder.
B
Yeah,
you
start
with
the
user's
input
as
what
they
desire,
and
then
the
buildback
may
choose
to
do
whatever
it
wants
with
it,
like
that's.
What's
in
the
spec
right
now,
like
the
buildback,
can
completely
choose
to
ignore
all
of
those
environment
variables
and
like
that's
a
flag
we've
enabled
because
of
security
concerns,
so
you
can
set
clear
and
vehicles
true
and
all
the
user
inputs
will
be
discarded.
E
Yeah,
so
I
guess
maybe
I
mean
I-
I
definitely
don't
argue
that
there's
value
in
that
specifically
for
certain
use
cases.
E
I
I
think
for
me,
like
tying
the
override
keyword
with
order
of
presidents
and
and
sort
of
having
to
align
both
of
those,
doesn't
seem
like
the
best
possible
option
versus
like
a
hypothetical.
E
You
know
again,
I'm
just
gonna
throw
out
some
keyword
right,
but
if
we
had
instead
of
override
something
like
frozen,
constant,
explicit,
whatever
keyword
you
want
to
throw
on
there
right
and
basically
in
whatever
the
order
of
presidents,
is
that
we
ultimately
either
define
or
allow
the
platforms
to
set
right
again
kind
of
going
back
to
the
life
cycle
having
multiple
paths
immutable.
Thank
you,
aiden.
That
makes
sense,
then,
basically,
nobody
else
could
override
it
right
from
that
point
forward.
B
B
E
B
B
It
works
in
the
other
order
that
the
build
packs
are
on
so
the
first
build
pack
may
set
a
default
free
pen
or
override
or
append,
and
then
the
subsequent
build
pack
that
runs
has
the
next
like
has
higher
precedence.
So
if
the
next
build
pack
sets
an
override,
it
will
overwrite
the
previous
value
or
if
the
next
build
pack
does
a
prepend,
it
will
prepend
to
the
previous
value.
B
B
C
Yeah,
it
sounds
like
we've
got
the
ball
rolling
on
this
discussion,
which
is
great,
and
I
know
that
there's
two
other
things
on
the
agenda
for
today.
So
I'm
going
to
jump
in
and
push
people
to
maybe
talk
about.
It
got
one
more
thing.
Somebody
yeah.
B
F
B
So
clear,
and
again
I
assumed
was
something
that
tweeted
out
of
security
concerns
where
we
assume
that
we
don't
want
to
trust
the
user
input.
This
is
something
that
the
builder
has
set
or
the
set
in
the
build
image.
So
I'm
assuming
this
is
trusted.
B
F
B
F
F
It's
like
maybe
the
the
build
pack
like,
let's
say,
you're,
setting
something
an
environment
variable.
That's
meant
to
configure
a
tool
that
the
bill
pack
is
running,
but
if
the
bill
pack
itself
is
like
you
know,
written
in
the
same
language
or
something,
but
you
don't
want
the
build
pack
to
respect
the
environment
variable
like
that
is
where
clearance
comes
in.
But
this
is
me
like
remembering
conversations
we
had
two
years
ago.
I
know
paquetto
bill
packs
used
this.
I
don't
really
know
exactly
what
these
cases
are.
A
It's
better
sorry,
the
this
comes
from,
I
think,
roku,
because
we
wanted
a
way
to
basically
not
like
have
access
to
the
environment.
Variables
like
you
can
still
read
them
from
the
directory.
So
yes,
they're
not
set
so
like.
If
you
have
a
bash,
build
pack,
for
instance,
right
like
if
these
are,
if
all
those
environment
variables
are
set,
it
means
like
every
single
thing
I
do
inside
that
build
pack
has
those
environment
variables
like
for
any
kind
of
command.
I
run
so
clear.
A
Em
basically
gives
freedom
to
the
build
pack
to
choose
one
to
basically
source
them
or
not.
I
mean
they're.
Definitely
some
batch
build
packs
that
I
think
were
written
at
heroku
where
it
will
just
sources
the
entire
directory.
But
even
when
a
clear
m
set
you,
you
have
basically
the
choice
to
do
that
or
not
right,
like
kind
of
where
do
you
want
to
inject
them?
A
So
I
think
it
is,
to
some
degree
sometimes
security
thing,
but
then
also
to
emily's
point
like
build
tool
configuration
right
where
it's
like,
if
I
am
setting
say,
like
private
credential
thing
for
butler
or
something
I
can
choose
to
source
the
environment
in
that
one
step,
but
not
like
everything
else,
where
I
potentially
may
shell
out.
D
Yeah,
I
think
one
of
the
examples
that
comes
to
mind
was
like
a
java
ops
or
something
like
that
where
the
it
was
intended
to
be
applied
to
the
maven
process,
but
in
the
build
pack
there's
a
couple
other
java
processes
that
are
like,
I
think,
even
detecting
the
version
and
then
suddenly
they
take.
You
know
two
gigs
of
ram
to
check
the
version,
so
you
can
sort
of
selectively
pick
them.
C
Cool,
so
we've
also
got
the
rfc
rfc
to
hopefully
finally
put
to
bed.
F
I
was
going
through
comments
on
that
this
morning.
It
seems
like
thank
you
all
for
leaving
suggestions
and
helping
like
leave
suggestions
that
make
this
look
more
final.
I
don't
think
there
are
like
huge,
outstanding
sticking
points.
F
It
seems
like
in
most
of
these
threads
where
a
question
is
raised.
Everyone
appears
to
be
on
the
same
side
of
the
answer,
and
then
we
could
just
roll
with
that.
It's
like
we
can
happy
to
add
a
minimum
voting
window
of
a
week
happy
to
apply
the
lazy
consensus
process
to
team
rfcs
as
well,
and
is
anyone
aware
of
like
an
outstanding
source
of
contention,
or
is
it
just
like?
I
should
update
the
rfc
with
the
results
of
these
threads.
F
I
guess
there
was
one
thread
about
one
of
my
examples:
being
a
major
refactor
javier
brought
up
that
it's
subjective
and
it
should
be
a
judgment,
call
for
leads
and
maintainers.
F
D
F
B
F
Treating
it
like
that,
that's
sort
of
what
I'm
getting
at,
but
also
like,
if
you're
going
to
you,
know
radically
overhaul
a
library
that
20
people
are
all
actively
contributing
to.
You
know:
it'd,
be
probably
good
to
have
a
team
level
rfc
just
to
get
some
consensus
that
everyone's
okay
with
that
direction,
but
I
think
it's
subjective
in
that
sense,
it's
like
if
it
has
a
big
impact
on
consumers,
I
think
we
should
have
an
rfc
or
if
it
affects
enough
contributors
in
a
big
enough
way.
It's
probably
worth
having
a
conversation
about
it.
A
A
F
I
don't
know
that
we
do
that
right
now.
I
think
that'd
be
an
ideal,
end
state
and
then
anything,
that's
is
importable
should
be
treated
with
that
level
of
care.
C
D
F
E
Yeah
I
mean
in
my
experience,
I
think
this
is
probably
less
problematic
than
what
it
appears
to
be,
because
in
in
most
cases
when
people
update,
you
know
the
the
library,
it's
not
like
an
api
right.
It's
not
like
an
interface
people
update,
let's
say
the
pack
as
a
library
that
they're
using
for
their
application
and
obviously
things
may
shift
or
changes
may
happen,
but
they
could
always
pin
to
a
very
specific
version
without
a
problem.
E
That
being
said,
it's
really
hard
to
know
how
people
use
you
know
pack
or
like
certain
code
within
pack
itself.
So
we
have
gotten
feedback
in
the
past
of
you
know
different
contributions
of
things
that
they
want
to
do
that.
I
don't
think
that
we
could
have
sort
of
forecasted
any
of
that
or
foreseen
any
of
that,
and
so
that
makes
it
difficult.
E
So
I
for
me,
that's
the
part
where
it
makes
it
really
difficult
to
say,
like
oh,
let's
put
an
rfc
about
how
we
want
to
structure
this
without
really
knowing
exactly
how
it's
going
to
be
used
versus
something
like
live
cmd
that
is
sort
of
really
intended
to
be.
You
know
a
sort
of
framework
right.
Pac
is
not
really
a
framework.
B
I
would
also
argue
anything:
that's
zero
work
like
you
can
make
bring
breaking
changes
to
it
because
that's
like
what
the
google
community
expects.
If
it's
zero
word,
don't
expect
any
backwards
compatibility.
If
it's
v1,
then
yes,
like
every
major
version
bomb,
is
a
backwards
and
compatible
chain.
So
for
me,
that's
like
the
breaking
point,
if
you're
doing
like
v1
v2
v3
of
something
then
like
yes
rfc
for
that,
like
if
you're
making
like
if
you're
reordering
a
few
files
here
and
there.
F
B
F
B
F
F
Inherently
a
little
wishy-washy
right
like
there's.
No,
you
can't
just
apply
this
like
it's
more
like
the
law
than
like
a
piece
of
code.
You
know.
B
I
remember
because
last
time
this
bit
is
because
when
we
were
doing
the
life
cycle,
the
source
epoch
date
change.
I
don't
remember
what
the
environment
variable
was
it
like.
All
changes
to
life
cycle
must
have
an
rfc
like,
even
though
we
were
all
agreeing
on
the
fact
that
hey
this
needs
to
be
implemented.
We
still
had
to
go
through
the
rfc
process,
because
that's
what
it
said
there
with
the
must,
so
it
just
was.
F
F
Some
breathing
room
right,
like
this,
is
going
to
be
implemented
by
humans,
yeah.
C
Cool
and
have
you,
I
think
you
were
the
one
who
made
the
comment
on
the
thread
is
the
where
we
are
now
where
you
wanted
us
to
be.
E
Oh
yeah
yeah.
I
definitely
accepted
that
yeah,
I'm
uncomfortable
with
saying
major
is
sort
of
subjective.
C
Cool
it
sounds
like
emily.
We've
reached
reasonable
consensus
on
this,
and
the
next
step
then,
should
be
hopefully
straightforward.
C
Fantastic
and
then
I
suspect
natalie.
This
is
next
agenda
item
is
yours:
if
time,
spec
pures
for
dockerfiles
phase,
two.
G
G
Sorry,
I'm
just
looking
this
one.
Okay,
you
can
see
chrome
here,
one!
That's
looking
at
the
life
cycle.
Okay,
I
made
these
pr's.
I
need
to
update
both
of
them
with
small
changes,
but.
C
As
my
children
can
attest,
I
just
shout
more
loudly
at
the
computer
and
then
it
works.
G
Does
this
work?
You
can
see
this,
so
I
just
wanted
to
take
everyone
on
a
brief
tour
and
kind
of
talk
about
some
of
the
things
that
some
of
the
like
problems
that
had
to
be
solved
here.
G
So
what
did
I
do?
Okay?
So
I
added
in
phase
one.
We
said
that
you
could
have
a
generated.
Your
generated
directory
could
have
a
run
directory
with
docker
files
in
it.
Now
you
can
have
build
docker
files,
and
you,
additionally
can
have
extend
config
files,
which
would
be
the
file
that
contains
your
args,
your
build
arcs.
G
I
tried
to
make
it
a
little
generic
here,
because
this
is
defined
in
the
build
pack
api,
but
is
the
same
concept
as
with
run
docker
files.
They
get
output
by
the
build
pack
and
then
they're
copied
to
the
generated
directory.
G
We
had
talked
about
and
a
couple
working
groups
the
fact
that
currently
with
conico
the
registry
creds,
if
they're
present
on
disk
in
the
container
where
connico
is
running,
could
be
read
by
docker
files
or
like
the
dockerfile
instructions,
and
so
to
avoid
that
there
are
two
things:
two
changes,
basically
that
we
need
to
make
to
kanika
and
I'm
going
to
submit
the
prs
today.
G
Hopefully,
the
first
is
that
if
the
extender
is
present
in
the
builder
image,
you
don't
need
to
unpack
any
file
system,
because
it's
already
there
and
as
a
result,
the
county
code
doesn't
need
registry
access
because
there's
nothing
to
pull
right.
G
However,
in
order
to
you
know
correctly
determine
what
the
cash
key
should
be
and
do
a
bunch
of
other
things.
Kaniko
needs
access
to
the
man
effect
and
the
config
file
for
the
image.
G
So
anyway,
that's
what
this
build
image
is
for,
and
all
of
this
is
just
formatting,
because
my
ide
fixes
the
table
borders,
but
I
did
add.
This
is
also
a
little
weird
so
when,
when
the
restorer
pulls
the
manifest
and
the
config
for
the
builder
image,
it
has
to
put
it
somewhere.
I'm
saying
it's
just
going
to
put
it
in
that
kaneko
cache
directory
and
the
end
user
or
the
platform
operator
doesn't
really
need
to
know
anything
about
how
the
directory
is
structured.
G
G
Those
are
the
restore
changes,
any
questions
so
far
or
comments.
We
have
three
minutes
left
otherwise
I'll
just
breeze
through
the
rest,
the
extender.
I
need
to
make
a
small
change
to
allow
the
platform
to
configure
the
cache
ttl,
but
otherwise
these
are
all
the
inputs
that
it
requires.
G
The
reason
why
it
needs
things
like
build
packs
and
plan-
and
you
know
gid
and
uid-
are
sort
of
like
the
creator.
The
extender
is
going
to
well.
The
extender
is
going
to
extend
the
builder
image
in
the
container
that
is
running
and
then
it
will
drop
privileges
using
the
provided,
gid
and
uid
and
just
run
the
build
phase.
G
So
if
you
have
extensions,
you
don't
need
to
run
the
builder
container
and
this
I
guess
it
avoids
having
to
you,
know,
export
the
extended
builder
image
and
then
bring
up
a
new
container
from
that
extended
image,
although
you
could
do
that,
but
let's
just
see
more
efficient
and
yeah
like
made
a
comment
there
and
that's
it.
For
the
platform.
Changes-
and
I
guess
we
only
have
two
minutes
left,
but
the
bill
pack
changes
are
pretty
straightforward.
G
I
want
to
make
one
small
change
to
what's
here.
I
think
joe
left
some
comments
about.
I
need
to
update
a
must
to
it
should,
but
one
more
thing
I
want
to
do
is
somewhere
in
here.
We
say
that
an
extension
gets
all
the
same
variables
as
a
build
pack
during
its
generate
phase,
except
for
c
and
b
layers
dear,
and
I
want
to
change
that
to
say
like
it.
G
In
addition
to
not
getting
c
and
b
layers
dear
and
getting
c
and
b
output
gear,
instead
it
instead
of
getting
a
cnb,
build
packed
here,
it
should
get
a
cmv
extension
dear
because
that's
just
weird
and
but
then
other
than
that.
These
are
all
you
know,
enumerating
the
requirements
of
a
build.dockerfile
and
describing
the
the
schema
of
the
extend
config
for
the
build
arcs
and
that's
that's.
It.
C
Thanks
for
running
us
through
that
natalie,
I
suggest
that
if
people
have
questions
that
we
take
them
into
the
the
slack
chat
or
hold
them
until
next
week,
because
I
know
some
people
have
to
get
off
for
meetings
on
the
hour.
But
if
you
do
have
to
get
off
the
readings
on
the
hour
ciao.
Otherwise,
if
you've
got
time,
maybe
hang
on
and
talk
to
natalie.