►
From YouTube: Working Group: 2021-02-17
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
B
I
do
not,
I
think
the
release
is
still
out
a
bit
and
same
for
tekton.
A
Cool,
I
think,
we're
sort
of
talking
about
maybe
cutting
a
patch
release
for
life
cycle,
but
we
haven't
really
officially
discussed
it
yet
in
any
capacity,
but
that's
the
otherwise
on
track.
I
think
for
implementation
as
well.
C
Screen
all
right
first
thing
in
the
list
this
week
is
pac
command
to
create
build
pink
repo.
This
is
an
fcp
anything
else
or
just
needs
to
be
merged.
Let's
see
when
starting
so
today,
someone
want
to
volunteer
to
merge
that
one
in.
C
D
A
C
Cool,
so
I
guess
this
is
just
looking
for
approvals
I'll
go
ahead
and
put
the
core
team
thing
on
it.
Next
thing
is
windows,
build
images,
use
sids
for
user
group
ownership,
okay,.
C
C
Closing
on
17th
cool-
and
I
guess
it's
mine
too,.
C
C
C
B
Cool,
so
I
added
this
to
the
list.
I
could
share
my
screen
for
the
recording,
but
basically
this
is
an
idea.
I
think
we
bounced
around
a
bit
at
previous
working
group
meetings
about
just
whether
or
not
this
is
something
that
we
had
an
appetite
for.
I
threw
down
a
couple
thoughts
on
here
that
I
think
kind
of
get
it
ready
enough
for
an
rfc
just
going
through
this
real
quick
in
preparation
for
the
rfc.
B
Sorry
yeah,
mounted
and
launched
directory
in
the
platforms
directory,
where
the
lifecycle
would
look
for
additional
configuration,
I've
kind
of
detailed
what
that
would
look
like
in
again
project
tamil
pack
build
and
then
what
it
would
look
like
inside
of
the
amv
launch
directory.
B
B
Lastly,
I
added
that
we
would
kind
of
have
a
breaking
change
in
the
platform
api
where
we
may
want
to
have
the
top
level
end
directory
apply
to
both
runtime
and
build
time.
Have
the
amp
build,
replace
the
current
av
have
launch
and
then
launch
process
types
to
match
with
the
buildpack
api
contract?
E
Hey
so
I
maintain
scaffold
one
of
the
maintenance
scaffold
and
particularly
around
scaffold
debug,
and
one
of
the
things
that
the
way
that
build
packs
does
environment
variables
like
this
by
putting
them
as
files
in
the
container
image,
makes
it
really
hard
for
tools
to
introspect,
and
I
use
use
environment
variables
for
whatever
purposes.
So
in
debug,
I
look
at
more
common
runtime
environment
variables
that
are
used
for
controlling
debuggers
or
the
the
right
type
to
guess
that
this
seems
to
be
java.
E
This
seems
to
be
go,
and
this
has
been
a
problem
with
build
pack
environment
variables
and
it
kind
of
makes
sense
in
some
respects
for
having
different
launchers
being
able
to
customize
their
environment
variables.
But
in
this
case
these
are
environment
variables
that
will
be
set
for
the
entire
image,
regardless
of
whatever
runners
are
using
or
sorry
an
entry
point
and
if
they
use
a
non-build
packs
entry
point,
we've
had
some
people
wanting
to
use
external
binaries
and
make
those
available
via
like
from
their
base
image.
E
So
it's
not
like
brought
in
as
a
build
pack
launcher
these
environmentals
don't
get
don't
get
slurped
up,
they're,
not
available
so
they're
hard
to
introspect
and
they
may
not
actually
be
loaded.
So
is
there
a
reason
why
we
wouldn't
put
this
into
the
container
image
environment
in
the
config
versus
putting
them
on
disk.
B
C
It
was
actually
a,
I
think
there
was
a
long
discussion
about
this
either
last
time
or
the
time
before
you
could
go
back
and
watch
the
recording
where
the
idea
was
brought
up
and
we
talked
about
like
I,
I
also
said
the
same
thing.
C
I
was
very
strongly
for
baking
them
into
the
environment
and
the
you
know
defined
in
the
config
blob
and
the
reason
I
think
there
are
a
couple
of
reasons
why
you
know,
even
besides,
being
able
to
scope
them
to
process
types
that
it
might
make
sense
to
keep
using
the
same,
at
least
until
unless
we,
you
know
refactor
some
larger
thing
across
it
right
to
keep
using
the
same
file
system
based
convention.
C
One
of
the
things
was
that
I
think
there's
a
strong
feeling
that
these
should
apply
after
the
environment
variables
that
are
set
by
the
build
packs,
and
unless
we
want
to
do
something
really
kind
of
interesting,
those
are
all
set
using
the
file
based
api
also,
and
so
you
know
you
could
put
them
at
the
end.
C
Also,
if
we
wanted
to
use
the
extensions
like
dot
append-
and
you
know
default.override
those
things-
you
know
I
kind
of
have
the
same
issue,
so
I
forget
all
the
arguments
that
were
made
last
time,
but
I
was,
I
was
pretty
convinced
that
at
least,
if
we're
gonna,
you
know
we're
gonna
make
an
option
to
bake
everything
in
the
image
afterwards.
That
should
be
something
that
happens:
sort
of
a
separate
rfc
that
be
a
separate
process.
D
I
agree
with
steven
that
it's
a
larger
problem
that
we
should
probably
solve
all
at
once,
not
right
here,
but
just
to
one
of
the
use
cases
that
you
brought
up
around
like
launching
arbitrary
processes,
not
one
of
the
process
types.
It
is
worth
noting
that
the
launcher
can
launch
an
arbitrary
process
for
you,
so
you
can
use
the
launcher
to
construct
the
environment
and
then
launch
anything
dynamically.
C
E
Or
for
my
uses,
it's
it's
people
wanting
to
be
able
to
set.
C
E
Overwritten,
when
they're
building
containers
and
for
debugging,
it's
really
looking
to
see
what
the
environment
variables
are,
that
have
been
said
so
having
them
involved
means
that
you
have
to
go,
and
so
scaffolded
runs
on
the
user's
machine.
We
could
be
building
a
remote
host
right
so
to
actually
introspection.
The
file
system
requires
then
downloading
the
layers
and
extracting
the
labels,
and
that's
that's
really
painful.
C
B
I
do
wonder
sorry,
it's
not
good.
I
do
wonder
if
we
could
satisfy
that
use
case,
though,
if
we
were
to
add
the
environment
variables
that
are
met
for
the
default
process
type
into
the
image
config
I'd
have
to
think
about
how
that
affects.
You
know
the
order
of
presidents
here,
since
the
image
config
does
apply
to
essentially
all
process
types.
C
And
then,
on
top
of
that,
we
want
to
apply
the
user
supplied
environment
variables,
and
so
I
I
think,
there's
maybe
a
different
feature
where,
like
there's
a
special
mode,
you
pass
that
you
know
disables,
that
ability
to
dynamically
modify
environment
variables,
the
user's
supplying
where
you
you
know,
pass
something
to
pac
build
and
then
it
runs
through
all
of
them
like
does
that
launch
runs
that
launcher
code
during
the
build
process
and
then
bakes
everything
on
right
and
just
maybe
disables
process
type,
specific
environment
variables
or
something
like
that
or
throws
an
error
if
they're
different
there's
like
there's
a
feature,
I
think
we
could
use
to
accomplish
that
outcome
for
certain
platforms
that
have
that
requirement.
C
D
Also
we're
thinking
about
what
happens
with
like
environment
variables,
set
by
exact
d
and
profile
scripts.
In
that
case
as
well,
because
I
know
sort
of
in
the
java
build
packs.
We
rely
heavily
on
dynamically
setting
environment
variables
with
build
pack
components
at
runtime,
so
you
can
do
smart
things
like
configure
the
jvm
based
on
the
amount
of
memory,
the
kinds
of
things
you
would
never
be
able
to
do
at
build
time.
So,
like
some
of
the
most
important
environment
variables,
aren't
the
kind
of
thing
we
can
bake
into
the
image.
Config.
C
D
A
Sorry
and
this
rfc
your
order
of
precedence
there.
That
number
one
item.
That's
not
true!
Today!
That's
a
change
right
because
today,
if
you
do
the
docker
run-ins,
if
it's
something
that
I
built,
I
guess
if
it's
something
that
a
build
pack
does
says
as
well,
then
it
takes
precedence
over
what
you
passed
in
with
docker
run.
B
Yeah-
and
I
think
that
was
the
surprising
bit
that
we
found
out
right-
and
I
guess
you
know
this
is
again
my
proposed
president's,
like
it
stephen,
had
an
idea
of
like
how
you
could
append
to
a
you
know,
image,
config
environment
variable
which
I've
never
thought
of.
I
didn't
even
know
that
that
was
a
feature
that
we
provided,
but
so
that's
interesting,
so
I
don't
know
again
exactly
how
that
plays
into
this.
B
D
I
know
in
the
paquetto
drop
a
build
packs.
For
this
reason
we
always
use.
We
almost
never
use
override.
We
always
use
default
so
that
the
user
provided
config
takes
precedence.
A
C
C
A
C
One
one
question
I
had
about
this
is:
if
you
scroll
down
you
mention
adding
up
or
like
you
know,
the
breaking
change
around
platform
and
venom
dot,
building
m.launch
the
I
have
some
questions
about
this.
Are
we
comfortable
with
like
at
some
point
in
the
beginning,
the
project
like
based
on
feedback
from
at
least
from
cloud
foundry,
but
probably
other
places
as
well?
C
We
were
pretty
strict
about
keeping
runtime
and
build
time
environment
variables
separate
because,
usually,
if
you're
you
know
arbitrarily
setting,
you
know
some
jvm
tuning
property
or
whatever
you
don't
really
need
for
it
to
apply
both
in
the
build
environment
or
the
runtime
environment
there.
There
are
some
things
where,
like
maybe
you
need
the
environment
set
up.
Similarly,
in
both
cases,
but
so
far,
we've
kind
of
said,
those
things
should
generally
be
kept
separate.
C
I
think
that's
even
mentioned
somewhere,
maybe
in
the
spec,
I
think,
maybe
in
the
platform
spec,
it
says,
like
specifically,
the
platform
should
not
combine
runtime
and
build
time
environment
variables
together
into
one
list.
Do
we
feel
differently
about
that?
Now.
B
C
B
Sorry,
I
have
to
switch
over
like
two
things
variables,
yeah.
C
There's
there
you
go
user
provided
environment
variables,
probably.
C
Yeah
the
platform
should
well
somewhere
in
here.
C
There
used
to
be
something
at
least,
that
said,
the
platform
shouldn't
combine
those
lists
together
that
you
know
in
how
the
user
specifies
their
environment
variables
we're
trying
to
be
very
intentional
about
about
keeping
those
separate.
So
you
don't
end
up
accidentally
setting
credentials,
for
instance,
in
the
wrong
environment.
Do
we
do
we
feel
like
we
want
to
keep
that
rule,
or
do
we
want
to
allow
the
user
to
specify
an
environment
variable
that
ends
up
in
both
places.
B
I
mean
that's
definitely
the
first
concern
that
came
to
my
mind
in
this
breaking
change
is:
if
they
don't
migrate
over
appropriately
right,
then
what
they
would
have
thought
to
be
only
a
build
time.
Environment
variable
all
of
a
sudden.
It
becomes
a
runtime
environmental
variable.
At
the
same
time,.
B
Who
is
the
intention
to
essentially
get
rid
of
this
non-suffixed
version?.
D
I
had
one
other
question
here,
which
is
right
now
we
provide
the
whole
platform
directory
to
build
packs
at
build
time,
but
there's
no
reason.
The
build
pack
should
necessarily
see
these
launch
time
environment
variables,
but
you
know
maybe
it
could
also
be
useful.
Like
do
we
think
where
we
put
them
now,
buildpacks
can
read
them.
Is
that
something
we
want
to
do.
C
D
Right,
but
we
can
there's
the
platform
directory
as
it's
given
to
the
live
cycle
in
the
platform
api
and
there's
the
platform
directory.
That's
given
to
the
build
pack
and
the
build
pack
api,
those
could
be
different.
Things
like
the
build
pack
platform
directory
could
be
one
level
down
from
the
top
level
platform
directory.
D
So
right
now
anything
that
goes
in
the
build
packs
platform
directory.
They
can
read,
and
I
can
see
a
case
why
bill
pecks
actually
might
want
to
read
the
launch
time
environment
variables,
but
typically
we
try
to
default
to
the
less
permissive
letting
bill.
Pecks
read
things
because
then
it's
a
breaking
change
if
we
remove
it
later.
So
I
didn't
want
us
to
let
the
bill
packs
read
this
by
accident
without
like
talking
about
why
we
think
that
would
be
good.
C
The
only
reason
that
build
packs
can
read
things
from
platform
directly
is
because
the
environment
variables
in
there
there's
a
mode
they
can
set
right
where
they
don't
automatically
get
added
to
the
environment,
but
most
built
x
don't
use
that
mode.
They
just
read
directly
from
that,
so
it
feels
like
it's
kind
of
a
niche
directory
for
this
special.
You
know
clean
end
mode
for
certain
secure
configurations,
and
then
there.
C
C
You
know
have
a
singular
view
of
you
know
what
they're
supposed
to
do
next
right
and
can't
kind
of
reach
outside
of
that
contract.
Then
you
know
it
feels
like
it's
almost
unintentional,
but
I
don't
know
what
the
original
intent
was.
I
just
I
don't
think
people
thought
of
that.
We
made
we
created
the
special,
clear
and
fun.
D
B
Do
we
know
what
the
use
case
for
arbitrary
things
are
because
I
definitely
know
bindings
and
nuts,
or
at
least
I
used
to
be
part
of
the
spec
and
extension
spec,
but
I'm
curious
to
know.
Like
maybe
you
know
we
could
have
just
provided
the
bindings
directory
to
the
build
packs
and
not
other
things
like
env.
D
C
That
was
sort
of
the
original
intent
was
like
if
you're
running,
on
a
particular
vendor's
platform,
and
they
need.
You
know
to
supply
some
kind
of
special
credential
as
a
file
or
you
know
whatever
right,
there's
a
safe
place.
The
platforms
are
allowed
to
extend
the
api
and
that's
that's
how
it
was
backed
originally
and
then
we
threw,
and
there.
D
D
C
There
was
a
use
case
around
environment
variables
as
files
that
was,
like
you
know,
user
provided
environment
variables
as
files.
That
was
like
some
build
packs
for
security
reasons,
want
to
start
with
an
environment,
that's
very
controlled,
so
I
think
if
we
talked
about
going
back
on
that,
you
know,
I'd
want
to
figure
out
make
sure
that
you
know
losing.
That
use
case
is
okay,
because
I
think
maybe
someone
on
the
heroical
side.
I
think
that's
where
that
came
from.
A
I
don't
I
don't
really
remember,
wasn't
around,
I
don't
think
during
those
initial
discussions,
but
it
makes
sense
that
you
know
like
I
know
we
have
at
least
in
bill
pack's
v2.
We
have
build
packs
that,
for
various
historical
reasons,
require
like
a
database
to
exist
and
that's
something
that
we
don't
mount
by
default.
They
don't
have
database
url,
but
they
can
access
it
through
the
build
pack
api,
and
so
it's
not
like
accidentally
there.
So
buildpack
has
to
intentionally
go
find
that,
and
so
that
might
be
one
of
the
reasons
got
it.
B
Cool,
so
I
have
a
couple
things
to
adjust
here,
but
is
there
anything
I
guess
big
that
needs
to
be
altered
for
this,
to
make
it
to
an
rfc.
C
I
think
this
is
just
a
mistake,
but
I
want
to
make
sure
it
says
in
life
cycle
implementation
configuration
runtime
kind
of
right
below
where
your
mouse
is
a
little
above,
where
your
mouse
is
a
runtime
configuration
should
be.
Is
that
supposed
to
be
layers
and
launch
because
you've
moved
it
to
layers
by
the
time
it's
in.
B
No,
it's
not.
It
was
a
feature
request
by
jose
which
I
believe
has
dropped,
but
the
same
feature
or
the
same
interface
for
providing
environment
variables
for
runtime
at
build
time
is
being
requested
for
runtime
environments
at
runtime.
C
So,
during
during
the
build
process,
all
everything
from
platform
m.launch
is
going
to
get
copied
into
platform
m.layers,
but
then
again
at
runtime
there'll
be
another
platform
m.launch,
that's
different!
That
has
additional
environment
variables
that
the
user
wants
to
set.
What's
the
purpose
of
having
that
directory
versus
at
runtime,
just
setting
the
environment
variables,
the
environment
of
the
container.
B
A
I
can
imagine
this
in
like
a
kubernetes
thing,
where
you
have
a
secret
and
you
just
want
to
bind
that
secret
to
platform
and
launch,
and
you
don't
you
could
set
it
at
the
environment
at
the
container
environment
but
like
binding,
the
entire
secret
volume
would
be
a
pretty
normal
thing
to
do.
I
think
in
this
situation
that
would
be
this
would
make
it
much
easier
to
do
that.
C
A
A
Yep
you
can,
you
can
as
well.
You
can
either
project
it
as
a
volume
or
you
can
actually
just
do
all
of
them
as
if
as
the
entire
secret.
So
I
think
it's
just
a
different
way
of
achieving
the,
but
I
guess
here
I
I
don't
know
like
you
said
jose's
not
on
but
like
maybe
the
platform
envelope
would
be
loaded
last,
where
it
reverses
the
order
of
loading
first,
if
you
do
it
in
the
infor
right
of
like
like.
Maybe
this
maybe
he's
suggesting
that
this
would
be
like
a
lasting
wins
situation.
C
B
Cool
that
makes
sense
all
right
anything
else
on
this
one.
C
Cool,
do
we
have
I
lost
the
doc?
Is
there
anything
else
in
the
doctor
chat
about
today.
A
Nothing
else
on
the
agenda.
I
would
like
to
make
scaffold
work
better
with
cloud-native
build
packs
to
be
certain
like
I
don't
know
what
the
I
wonder,
if
there's
some
use
cases
that
we
could
carve
out,
that
would
make
that
easier,
because
scaffold
is
something
I've
been
investigating
a
heavy
use
of
and
like
it
would
be
nice
to
write
bill
packs
in
a
way
that
scaffold
would
just
work
most
of
the
time
right.
E
So
I'm
all
ears,
I
mean
I
don't
test
with
other
build
packs,
but
we
do
we're
intended
to
work
with
other
build
packs.
So
if
you
have
problems,
definitely
open
issues
up
in
the
repo.
C
E
So
we
already
have
that
working.
It
does
require
right
now
require
stuff
in
the
gcp,
build
packs
and
having
to
talk
about
how
we
go
about
doing
that
either.
Now
or
later
I
mean
basically
just
use
metadata
labels
to
go
and
indicate
what
files
are
supported
by
we.
Sorry,
let
me
stand
back
and
say
when
we
run
scouting
in
dev,
we
set
an
environment
variable,
but
I'm
sorry
do
you
want
me
to
talk
on
it
now
or
do
you
want
to
do
this
later.
C
I
think
we've
actually
had
this
conversation
before
if
I
now
that
I
think
about
it
like,
but
there's
there's
more
interest
now
I've
been
you
know,
talking
to
some
contributors
in
a
develop
api.
That
kind
of
more
formally
defines
like
what
does
a
remote
orchestrator
look
like.
We
don't
have
to
talk
about
it.
Now,
if
you
don't,
you
know
it's
probably
kind
of
a
larger
thing,
but
I
can
let
those
folks
know
to
reach
out
to
you
if
you're
interested,
because
I
think
there's.
E
Totally
yeah
we're
looking
at
trying
to
redevelop
it
and
make
it
more
extensible,
because
right
now,
it's
very
fixed,
so
each
of
our
different
language
runtimes
that
we
support.
We
have
a
set
of
file,
extensions
that
we
look
for
and
anything
else.
We
have
to
rebuild
the
image.
C
It'd
be
great
if
there's
a
yeah,
sorry
it'd
be
great.
If
there's
a
standard
api
where
build
packs,
you
know,
ran
been
developed
instead
of
been
build
and
could
install
dev
dependencies
and
say
hey
here.
Here
are
the
files
that,
if
they
change
they're
safe
to
upload
directly-
and
you
know
kind
of
fix
the
app
directory
more
instead
of
moving
stuff
around
right
and
then
you
can
have
a
really
consistent
contract
there.
C
That
worked
and
it
could
work
with
tools
like
tilt
and
whatever
too
right
if
it
all
meets
a
common
interface
and
we
define
kind
of
a
generic
external
thing.
So
I
think
there's
there's
definitely
interest
in
that.
So
I'll.
Let
folks
know
to
reach
out.
B
E
C
All
right,
if
there's
nothing
else
in
the
agenda
today
or
nothing
else,
anybody
wants
to
talk
about
we'll,
go
ahead
and
call
it
thanks.