►
From YouTube: Platform Sync: 2021-02-24
Description
Meeting notes: https://bit.ly/38pal2Z
A
A
All
right,
let's
get
started
so
the
first
thing
on
the
agenda
status
updates
since
I'm
already
talking
I'll
go.
First,
I
added
to
the
agenda
the
techton
build
packs
pipeline,
which
is
a
a
new
thing
that
we're
going
to
be
adding
to
the
tecton
catalog.
I
could
go
into
a
little
bit
more
detail
there,
as
maybe
a
notable
mention
myself
and
dan
are
setting
up
a
windows
work
station
on
equinix
metal.
A
I
think
that's
how
you
pronounce
it,
and
so
this
hopefully,
should
enable
a
lot
of
the
windows,
debugging
and
development
to
be
a
little
bit
more
accessible
to
those
that
either
might
not
have
a
vm
available
or
a
windows
machine.
You
know
physical
windows,
machine
available
and
so
we're
making
this
available
to
any
verified,
contributor
and
maintainer
of
the
project.
So
we'll
have,
I
think,
for
now
one,
but
maybe
two
machines
always
available
for
anybody
to
gain
access
to
a
little
bit
more
detail
coming
on
that.
B
I
can
throw
mine
in.
I
was
working
on
the
cache
image
bug
for
windows,
cache
images,
most
of
the
works
in
life
cycle
and
image
util,
but
it
should
fix
the
upstream
pack
issue.
It's
gonna
require
a
couple
changes
and
I'll
keep
it
short,
but
it's
gonna
introduce
os
awareness
into
the
constructors
for
image
util,
so
be
able
to
pass
in
the
kind
of
image
that
you
want
to
make
from
the
start.
A
A
A
A
A
A
A
Rfcs
again,
I
I
believe
the
purpose
of
having
rfcs
here
is,
to
you
know
a
make
people
aware
of
any
new
upcoming
changes
to
platforms
and
be
to
see
if
we
want
to
dive
into
any
of
these
specific
changes.
If
anybody
has
questions
about
them,
so
the
first
one
we
have
is
adding
builder
key
and
project
descriptor
right.
I
think
this
is
from
the
title
pretty
self-explanatory.
A
We're
adding
just
a
builder
key,
I
believe,
here's
the
sample
yeah,
so
there's
a
builder
with
a
string.
This
would
be
the
same
thing
that
we
would
provide
via
pack,
but
now
it's
in
a
way
that
it's
specified
at
the
project
level
and
maintained
in
the
source
repository
so
that
it's
portable,
the
other
one
group
additions
to
the
build
order.
I
believe
that
the
description
of
the
title
isn't
all
too
clear,
but
I
believe
this
is
a
pre
and
post
build
packs
yeah.
A
A
I'm
not
sure
yeah
here
so
packs
that
create
you'd
be
able
to
kind
of
pass
in
the
image
that
you
want.
The
run
images
a
couple
of
flags
that
are
detailed
here
and
it
should
add,
metadata,
mix-ins
and
and
so
forth,
information
to
the
image
so
basically
taking
any
base
image
and
creating
a
stack
from
it.
A
C
Yeah
sure
so
I
think
this
is
probably
something
that's
come
up.
A
couple
times
is
that
we
keep
getting
requests
for
different
options
for
people
to
manage
the
build
cache
when
they're
running
a
pack
build
whether
that's
making
a
remote
image
that
they
can
then
save
between,
runs
or
specifying,
where
the
cache
is
coming
specifically
and
the
image
that
it's
going
to
locally.
C
There
is
like
some
small
changes
that
will
be
made.
Did
tim,
I
think
let
the
creator
have
some
of
this
functionality,
specifically
when
you
have
differences
between
whether
you
want
to
import
a
image
like
a
cache
image
and
export
a
local
volume,
or
vice
versa,
but
that's
just
kind
of
like
something
that
would
be
possible
already
with
just
running
the
binaries
independently.
Just
don't
really
have
it
on
the
creator
yet.
A
A
A
C
Yeah
100,
and
I
think
that
the
like
the
fact
that
we
can't
do
that
is
just
a
constraint
kind
of
imposed
by
pack
and
not
really
imposed
by
the
underlying
life
cycle
binaries.
So
it
feels
like
something
that
shouldn't
be
too
difficult
to
do
right
and
if
it's
already
possible
with
the
underlying
lifecycle,
binaries
should
probably
do
it.
We'll
make
this
simpler.
A
A
C
A
A
C
B
A
Then
we'd
want
to
also
add
it
to
the
creator,
and
so
I'm
thinking
about,
like
the
domino
effect
right
of
all
the
effort
versus
the
demand
and,
like
I
said,
like
I
haven't,
heard
this,
I
don't
know
if
you
could
point
to
any
specific
request
to
have
a
migrating
cache
versus
just
is
it?
Is
that
really
the
reason
why
we're
doing
it
or
is
it
that
we're
just
trying
to
collapse
the
the
idea
of
having
you
know,
cache
image
versus
cache
volume,
flags.
C
Yeah,
I
think
that
the
start,
the
reason
why
I
wrote
this
was
definitely
simplify
the
user
experience
when
using
all
these
options
like
and
the
interactions
between
them
right,
like
you,
can't,
publish
and
specify
your
the
name
of
a
volume
that
you're
gonna
use
right
like
there's
just
like
a
lot.
There's
gonna
be
a
lot
of
interaction
between
these
things.
Right.
C
Yeah,
I
was
just
curious
what
so,
what's
the
the
migrating
use
case?
May
I
miss
that
part
of
the
discussion,
so
you
want
to
have
an
input
cache,
but
then
you
want
it
to.
You
want
to
write
to
a
different
cache
on
output,
yeah
and
so
it'd,
be
a
difference
in
type,
so
you'd
be
able
to
read
from
a
cache
image
and
write
to
a
cache
volume
or
switch
those
two.
That's
I
mean
that's
one
of
the
things
this
would
let
you
do.
A
Cash,
so,
ultimately,
like
hypothetically
right
like
if
we
wanted,
if
someone
was
really
saying
like
hey,
I
want
to
be
able
to
migrate
cash
right
like
would
we
instead
then
have
like
a
pack
cash
migrate
command
right?
That
then
takes
an
input
and
an
output
versus
having
to
do
the
build
process
for
it.
C
C
A
It's
interesting
so
again,
I
guess.
Maybe
I
want
to
determine
the
demand
for
for
the
migrating
use
case,
but
if
we
were
to
think
of
simplifying
the
fact
that
we
have
two
flags
and
potentially
making
them
one
flag,
I
think
that
sounds
more
reasonable
or
I
guess
maybe
more
actionable
right,
because
then
that
the
scope
is
a
lot
lower,
I
would
think
right
and
then
it
doesn't
require
for
us
to
hopefully
have
to
like
also
change
the
creator
right
or
maybe
the
change
there
would
be
also
minimal.
C
A
Yeah,
because
I
could
definitely
think
of
flags
that
we've
condensed
right,
like
I'm
thinking
of
pull
policy,
we
definitely
condensed
that
and
we
definitely
allowed
for
some
room
where
we
could
add
complex,
pulling
logic
which
we
haven't
implemented
again,
because
the
desire
hasn't
been
quite
there
yet
right,
but
I
feel
like.
Maybe
we
could
do
something
similar
here,
where
we
could
simplify
it
to
a
single
flag
right
and
then
determine
exactly
like
what
the
format
for
that
should
be
and
make
sure
that
it
doesn't
lock
us
in
into
anything.
A
A
A
A
Okay
over
right
now
sounds
good
I'll,
go
through
the
techdown
thing,
real,
quick,
and
if
we
have
maybe
a
few
minutes,
we
could
also
glance
at
that
one
all
right.
So
this
is
a
pull
request
on
the
tech
dyn
integration
repo.
So
I
realized
that
this
is
like
a
relatively
new
repo
as
far
as
being
worked
on.
A
The
purpose
of
this
repo
is
to
provide
a
lot
of
tooling
and
automation,
automation
and
testing
around
some
of
our
tasks,
and
one
of
the
things
that
kind
of
came
up
in
one
of
our
discussions
was
the
fact
that
we
have
two
tasks
and
it
it's
very
difficult
for
the
user
to
really
understand
which
task
they
should
be
using
right
like
they
want
to.
You
know,
do
they
use
this,
build
packs
task
and
we
kind
of
explain
what
it
really
is
here
right
to
some
extent
or
do
they
use
this
like?
A
So
in
trying
to
replicate
that
one
of
the
limitations
with
tecton
right
now
is
that
in
these
tasks
there
are
steps,
but
these
steps
cannot
be
conditional
right.
So
like
there's
no
way
to
conditionally
execute
these
steps.
The
conditions
lie
at
a
higher
level,
which
is
what's
called
a
pipeline
right,
so
you
could
conditionally
execute
certain
tasks
within
this
pipeline.
A
It
determines
whether
one
of
two
tasks
will
run
or
set
up
tasks,
which
is
the
build
untrusted
right.
We
have
this
condition
here
or
the
build
trusted,
which
I
guess
I
skipped
over
here-
build
trusted
which
then
executes
the
build
packs
task
versus
the
build
pack
phases
right.
So
very
simple,
I
guess
indirection
for
this
pipeline,
but
other
things
that
I
think
this
pipeline
will
allow
us
to
do
is
add
more
functionality
that
has
been
requested
in
regards
to
like
environment
variables.
A
One
of
the
things
I
want
to
do
is
like
determine
the
user
id
and
group
id
by
inspecting
the
image,
as
opposed
to
requiring
the
user
to
be
able
to
set
this.
So
I
think,
long
term.
What
I
want
is
the
pipeline
to
be
like
the
simplest
use
case
and
then
the
tasks
to
be
kind
of
like
implementation,
details,
that's
more
or
less
the
strategy
or
goal
here.