►
From YouTube: Platform Sync: 2021-02-17
Description
Meeting notes: https://bit.ly/38pal2Z
A
A
So
I
talked
to
some
of
the
the
people
in
tecton
and
I
created
a
pr
or
sorry
I
didn't
create
the
pair,
but
I
I
definitely
have
the
code
changes,
but
that's
probably
not
going
to
make
it
in
for
a
good
while
and
so
I'm
probably
going
to
have
to
work
around
some
of
that.
So
I'm
looking
for
some
options
there,
which
is
most
likely
not
using
what's
called
pipeline
resources.
So
a
lot
of
you
know
in
the
weed
details,
but
overall
just
continuing
to
work
on
pipelines
with
some
bumps
in
the
road.
B
I
did
some
work
on
the
spec
part
or
for
the
bringing
the
current
builders
to
what
our
specification
was.
So
I
first
of
all
had
made
a
pull
request
to
the
spec
repo
core
team
is
checking
that
out
now
about
finalizing
the
specification,
and
I
also
did
an
investigation
to
see
what
we
actually
need
to
change
at
the
pack
on
the
platform
side
in
order
to
make
our
builders
compliant
with
the
specification.
B
I
also
did
a
bit
of
work,
doing
trying
to
close
out
that
epic
for
renaming
or
using
the
sub
commands,
so
so
this
was
renaming,
inspect,
inspect
image
to
inspect,
then
moving
inspect
builder
to
the
builder
sub
command
and
inspect,
build
back
to
the
build
pack,
sub
command,
deprecation
notices,
etc,
and
right
now,
I'm
doing
a
bit
of
work.
I'm
trying
to
pull
in
some
of
our
acceptance
test,
free
factors
from
simon.
A
D
A
A
Do
we
still
like
you
know,
typically
for
things
like
this,
is
if
it's
not
a
reoccurring,
theme
of
a
desire,
then
it
feels
like
it's,
maybe
not
as
high
of
a
priority
or
maybe
not
as
relevant
anymore.
Do
we
feel
like
this
is
still
something
that's
either
bitten
us
or
important,
or
should
we
just
close
it
yeah.
D
A
Yeah,
I'm
really
hesitant
about
this
because
I
feel,
like
you
know,
kind
of
like
the
question
mentions
here-
is
whether
this
should
be
on
the
pack
or
the
life
cycle.
It's
like.
You
have
now
two
components
that
are
continuously
moving
right
and
it
becomes
a
question
of
who
broke
the
build
right
and
then
both
parties
having
to
become
involved
to
try
to
rectify
the
issue.
A
Where
I
mean
I'm
trying
to
think
through
it,
if
we
just
cap
it
the
way
that
we
have
it
right
now,
where
it's
dependent
on
a
release
going
out
right.
So
the
lifecycle
already
makes
this
test
against
pac
when
it's
about
to
release,
and
we
also
do
it-
I
guess
on
pack,
when
we
we're
about
to
release
we
bump
to
the
latest
version
of
the
life
cycle,
I
think
we're
at
a
pretty
safe
spot.
There's
a
very
small
marginal.
You
know,
error
prone
ratio,
but
I
think
we're
overall
good.
B
I
think
especially
because
because
there
already
is
the
release
on
the
the
test
on
the
pre
lifecycle
release,
I
think
that
especially
convinces
me
because
on
the
pack
side
it
could
be
that
then
we'd
have
to
enforce.
You
know
require
hot
fixes
of
of
the
life
cycle,
but
once
we
know
that
they're
already
testing
against
our
master,
I
think
that's
pretty
good.
D
D
B
Oh
and
you
can't
it's
really
hard
to-
I
think
this
is
connected
to
another
issue
that
we
have
as
well
that
because
for
untrusted
build,
certainly
we
pull
the
life
cycle
image
down
from
docker
hub,
so
and
and
that
image
doesn't
exist
when
you're
that
image
doesn't
exist
before
you've
released
the
latest
life
cycle.
I
think
that
that
that
that
causes
some
issues.
B
D
A
All
right,
so
if
it's
okay
with
everybody,
I'm
gonna
go
ahead
and
close
this
with
just
this
comment
here.
If
you'd
like
to
add
more
context,
please
feel
free
to
continue
to
comment
cool
all
right.
There
you
go.
We
resolved
one
yeah,
all
right,
okay,
anything
else
on
here
I
was
going
to
bring
this
up.
If
there's
sufficient
time
for
the
user-defined
cache
volume
names,
I
feel
like
someone
said
they
were
gonna.
Do
it?
C
A
A
B
C
B
D
C
I
mean
there's
like
a
part
of
this,
is
like
once
we
start
doing
this
kind
of
semantic
of
letting
you
specify
stuff
like
some
of
the
other
tooling,
has
a
more
flexible
ways
you
can
specify
where
stuff
is
going,
etc.
Right,
so
I
think
this
individual
change
is
pretty
small,
but
like
we're
kind
of
reaching
a
point
where
there's
like
all
this,
like
flag
configuration
for
like
oh,
what
kind
of
cache
volume
am
I
using?
C
How
am
I
specifying
it
and
I
feel
like
we
might
want
to
come
up
with
like
a
comprehensive
way
to
be
like
this
is
where
it's
going.
This
is
the
type
so
that,
if
we're
going
to
give
people
configuration
or
this
ability,
they
can
like
kind
of
they
don't
have
to
mix
and
match
it
with
a
bunch
of
other
options
in
our
cli
right.
B
And
also,
if
you
look
at
the
image
it
doesn't
it's
not
really
about
user
defined
cache
value
names,
it's
about
being
able
to
give
the
same
cache
image
multiple
times.
So
I
think
that
this
was
solved
with
the
dash
dash
cache
image
flag.
It
was
just
users
to
find
cash
value.
Names
was
one
one
request.
I
think
I
agree.
I
feel
like
there's
so
many
flags
that
adding
more
is
just
making
build
more
and
more
incomprehensible
for
power
users.
A
I
guess
I
I'm
not
a
huge
fan
of
saying
that
cache
image
solves
this
use
case
and
the
reason
for
that
is
because
it
requires
a
registry
to
also
be
available
when
a
cache
volume
does
not
right.
Like
I,
I
recall
this
came
up
recently
as
someone
wanting
to
reuse.
The
cache
between
you
know
image
a
and
image
b,
but
they
were
both
the
same
app,
but
I
forget
exactly
what
it
is.
I
think
they
were
just
re-tagging
it
or
something
like
that
right
and
yeah.
Like
again
in
my
response.
You
know
it
was.
A
Ultimately
you
could
do
this
with
image
cache,
but
I
don't
see
why
we
wouldn't
allow
for
image
volume
to
or
sorry
cache
volume
to
also
be
named
or
specified
right,
like
the
the
caveat
or
concerns
that
we
have
for
cache
volumes
would
be
the
exact
same
as
caching
image
and
we
obviously
provided
cache
image.
So
I
don't
see
any
reason
why
we
wouldn't
provide
cache
volume
other
than
by
saying
that
we
don't
want
to
add
one
more
cli
flag,
which
doesn't
seem
to
be
a
good
argument.
In
my
opinion,.
C
Yeah,
I
think
we
should
add
this
right.
I
just
think
that
we
might
want
to
have
like
a
we've,
like
added
all
these
little
bits
of
functionality
right
and
now
we're
at
a
point
where
they
all
combine
in
kind
of
like
many
different
ways.
We
should
just
come
up
with
a
one
way
to
kind
of
specify
this
stuff
right
like
I
want
this
to
be
a
cache
image.
I
want
it
to
be
named
this
right.
A
C
B
D
C
D
C
C
A
So
I
I
maybe
I'm
misunderstanding
this,
but
like
this
ask,
is
very
minimal
and
very
specific,
and
it
seems
like
we're
not
talking
a
bigger,
more
holistic
issue
that
I
guess
now.
I
question
whether
or
not
we
need
to
solve
that.
For
you
know
in
the
immediate
you
know
before
we
provide
this
functionality,
or
can
we
just
basically
handle
that
as
a
secondary
discussion,
because
it
seems
like
we
want
a
bigger
discussion
revolving
that
holistic
issue.
A
It
is
of
my
opinion
that
I
think
we
should
be
able
to
provide
this
in
this
particular
issue
without
any
problems
or
concerns
right
and
then
improve
upon
it.
Once
we
get
to
that,
you
know
once
we
have
that
bigger
discussion,
which
I
think
dan,
are
you
volunteering
to
bring
up
that
discussion
in
the
in
written
form,
so
we
could
have
a
wider
conversation
about
it.
C
A
A
A
B
C
A
B
B
Reminder
to
look
at
things
and
make
sure
that
they're
okay
at
this
point
it's
pretty
hard
just
because
we're
pretty
limited
on
time
with
our
current
scope,
but
in
the
future.
Perhaps
when
we
have
some
more
time,
we
can
look
at
some
of
the
open
issues
and
discuss
that
here
before
bringing
it
over
to
to
muscle
again
they're
working
to
the
standard
yeah
working
groups,
yeah.