►
Description
[RI] Don’t forget to register your interest for a Korifi hoodie!
[GC] What should go in v0.5?
[JH] kpack consuming “prior builds” in analyze step
[TD] Security concerns?? Registry performance concerns? ^^
[GC] Spike per-app container registries
https://buildpacks.io/docs/concepts/components/lifecycle/analyze/
[GC] kpack 0.8.2
A
A
C
C
C
D
D
E
E
C
D
G
E
So
there's
an
item
about
hoodies
I,
think
Ram
put
it
in
possibly
but
he's
not
here,
but
I
guess
it's
quite
self-explanatory.
He's
put
together
a
this
form
where,
like
you,
can
register
interest
for
a
hoodie
and
you
give
them
the
your
indicative
size
and
that's
it
apparently
the
the
size
for
now
only
has
to
be
negative.
You
don't
know
you
don't
have
to
be
precise
at
some
point.
We
might
get
like
a
size
chart
so
that
we
can
actually
choose
the
proper
size
for
each
one
of
us.
E
We
have
at
least
two
big
changes
at
the
moment
going
on
concurrently,
which
I
think
we
should
coordinate
plus,
potentially
any
other
changes
happening
on
the
other
side
of
the
pond
and
deciding
like
I
think
that
we
all
agree
that,
like
the
maybe
AWS
slash
ekr
work
is
the
priority,
so
I
wonder
if
we
should
like
let
that
slide
in
I.
Think
it's
well
on
its
way.
We're
working
on
CI,
plus
docs
are
missing,
plus,
of
course,
see.
I
will
have
to
prove
that
things
actually
work
on
AWS.
E
That's
why
we're
setting
up
awsci
so,
but
if
there
is
no
surprises
it
should,
it
might
happen
soonish
there
is
this
change
about
merging
all
the
controller
images
into
one
and
leaving
just
API
image
and
control
this
image,
which
is
quite
I,
guess
it
will
conflict
with
pretty
much
anything
else,
because
it's
quite
invasive.
So
what
do
we
do?
Do
we
hold
off
that
merge?
E
E
Because
if
the
my
preference
I
think
would
be
to
just
get
to
get
AWS
stuff
in
if
it's
tested
and
it
works
and
without
the
image
merge
potentially
just
get
that
in
and
then
image
merge
can
be
zero.
Six
but
I,
don't
know
what
people
think
it
depends
on
how
far
off
you
are
on
the
different
tracks.
Etc.
F
F
F
E
F
E
C
E
H
Wondering
if
we
shouldn't
just
push
what
we've
got
in
Helm
and
karifi
now
so
it's
taken
a
while
to
sort
out
CI
we've
had
to
do
a
bit
of
refactoring.
So
all
the
stuff
works
on
both
gke
and
aw
and
eks.
At
the
same
time,
like
all
the
different
ways
to
create
your
Cube
config
and
log
in
and
everything
and
get
in
the
DNS
and
setting
that
up.
It's
looking
good
now
but
yeah.
We
we
can
manually,
deploy
Corinthian,
eks
and
and
push
stuff
and
it
works.
E
E
E
Okay,
yeah
that
sounds
good
to
learn
once
that's
in
we
work
on
the
docks
and
then
we
release
and
in
the
meantime
I
guess,
we'll
have
to
keep
the
merging
work
in
a
branch.
It's
fine
and
so
I
mean
as
long
as
that
branch
is,
you
know
periodically
rebased.
On
top
of
main,
then
it's
going
to
merge
clean
the
only
danger
of
a
long-running
branches.
When
it's
it's
not
periodically.
You
know
rebased
but
slash
merged,
but.
F
Branch
will
be
a
bit
of
a
fight
too
much
anyway
like
provided
that
and
I
mean
the
only
way
that
it
will
not
be
a
fight
to
merge.
This
Branch
will
be
to
stop
the
world,
which
doesn't
make
much
sense,
so
I
think
we
just
have
to
figure
it
out.
I
guess
these
we're
going
to
limit
the
changes
that
we
that
we
merged
before
it
to
so
they
guests
think
that's
currently
ongoing
right.
So
yeah.
E
E
E
E
Just
with
Amazon
work,
yeah
the
Amazon
work
and
then
zero
six
can
have
the
merging
of
the
images
Plus.
For
example,
if
you
finish
the
labels
work
that
can
go
in
I
see,
there
is
a
bunch
of
logs
stories
appearing
on
the
backlog.
If
those
are
done,
they
can
go
in.
I
will
see
what
we
want
to
get
into
zero
six
having
a
zero
five
that
works
on
Amazon
I
think
is
a
good
idea.
G
C
A
All
right,
I
think
the
wrong
microphone
yeah.
Yesterday
morning,
this
came
up
in
the
context
of
like
trying
to
get
our
closed,
Source
pipelines
working
because
we
were
giving
the
same
repo
tag
for
both
the
droplets
and
the
source
packages,
and
that
was
causing
Cape
active
fail
because
apparently,
when
you
do
a
build
in
the
analyze
step,
it
goes
to
see
if
there's
already
been
a
build
at
the
repo
that
you
give
it.
A
E
But
but
they're
using
an
older
like
how
do
they
know,
I
mean
it's
just.
It
would
be
really
weird
if
they
assumed
that
every
image
that
every
droplet
that
they
push
is
gets
pushed
to
a
unique
repository
right.
Okay,
so
I
mean
yeah.
What's
the
requirement
is
the
requirement
that
there
should
be
a
repository
per
app.
E
G
G
Think
if
you,
if
you
use
one
repository
per
app,
then
you
get
theoretically
actually
some
some
benefits
from
that,
because
you
could
reuse
existing
stuff,
and
this
is
also
making
me
think
I'm
wondering
if,
like
we're,
using
like
fancy,
Registries
like
right
now,
like
ECR
and
GC
and
gar,
and
everything
I'm
wondering
if
other
like
Registries
like
Harper
or
something
might
be
making
internal
like
assumptions
about
like
how
they're
storing
stuff
for
a
particular
repository
and
if
we
push
everything
to
the
same
one.
That
might
also
start
to
break
down
just.
H
H
H
E
Like
it's
not
designed
to
be
used
by
another
program,
it's
designed
to
be
used
by
by
a
human,
so
they
suspect
they
expect
the
human
to
figure
out
how
to
create
the
repository
by
themselves
and
then
give
it
the
repository
like
the
repositories
and
input
for
them.
They
don't
care
how
it
gets
created
yeah.
They
just
push
that
responsibility
to
Upstream,
which
I
think
they
expect
to
be
just
a
human
using
this
year
to
use
instead
of
a
instead
of
you
know,
another
program.
E
E
Because
the
thing
is
honestly,
all
of
these
behaviors
I
think
they're
contradicting
the
spec
like
the
spec,
doesn't
say
anything
about
the
images
inside
the
repository
being
related
right.
The
spec
doesn't
say
any
of
that
that
specs
as
you
you
push
me,
you
push
a
manifest,
that's
how
they
call
it.
The
Manifest
points
to
other
layers
inside
the
repository
which
are
all
identified
by
Sha
period,
like
there's
no
Assumption
of
correlation
so
like,
if
you
as
an
implemental
prune
stuff
arbitrarily
you're,
just
not
complying
to
this
pack
as
far
as
I'm
concerned.
E
A
I
think
there's
a
difference
between
a
hard
assumption
and
an
optimization.
Now
right,
like
you
might
you,
you
may
choose
to
compress
your
repository
by
looking
at
Deltas
between
different
versions
of
What,
supposedly
the
same
image,
and
if,
if
you
feed
it,
our
system
it'll
still
work,
it
just
won't
compress.
E
G
E
If
it's
the
most
natural,
because
again,
then
then
every
repository
has
a
sequence.
Has
a
history
of
each
image
is
one
step
in
the
history
of
one
conceptual
thing
right
and
that's
how
most
container
Registries
work
right?
You,
you
pull
the
Ubuntu,
the
docker
Hub,
slash
Ubuntu,
and
you
get
the
different
versions
of
Ubuntu
in
in
time,
but.
E
G
I
I
almost
think,
like
the
the
special
case
like
for
AWS
of
creating
the
repo
is
the
Lesser
Evil
versus
reusing
the
same
repo
for
every
app
I,
I.
Think
like
especially
even
as
we
we,
if,
if
and
when,
we
think
about
deleting
and
cleaning
up
stuff
like
I
I.
Have
this
vague
recollection
that
the
apis
around
deletion
aren't
very
kind
about
trying
to
delete,
buy
a
Digest
either.
E
F
H
E
G
H
E
H
G
I
I
guess
I
I
just
think.
There's
like
there's
this
k-pack,
like
probably
a
security
issue
right
now
and
there's
like
a
number
of
performance
issues
like
it.
It
almost
like
I'm
I'm,
really
thinking
that,
like
if
we
special
K-State
AWS
to
create
the
repo
like
that
might
be
it
and
then
like
the
others,
would
be
fine
with
our
the
current
like
creating
the
repo
strategy.
E
G
Feel
like
we
could
deal
with
that
when
the
time
comes
like
using
like,
if,
if
you
abstract
the
code
such
that
it
has
like
a
like,
we
already
have
like
the
registry
repository
or
whatever,
like
you,
have
an
AWS
one
and
then
like.
If,
if
others
have
Registries,
they
want
to
support
like
that's
something
that
could
be
contributed,
but
it
might
be
unlikely
that
people
actually
have
ones
that
aren't
in
the
set.
We
know
about.
E
B
A
G
E
What
happens
is
that
the
Builder
just
a
Panzer
argue
it,
and
then
we
changed
it
so
that
it
doesn't
append
anything
right.
So
that
doesn't
didn't
need
any
change
to
the
workload
spec
but
like
if
you
want
to
pass
it
to
the
app
name,
which
would
be
the
natural
thing
here.
If
we
want
to
have
her
app
repositories,
then
the
app
workload
needs
to
be
given
the
path
where
to
push
the
image.
A
E
Basically,
we
want
to
move
the
computation
of
what
the
path
you
push
to
of
the
tag.
Call
it
whatever
you
want
outside
of
the
Builder,
because
the
Builder
could
do
it
when
it
was
a
matter
of
adding
up
good,
and
you
can
do
it
now
when
it's
a
matter
of
just
using
it
verbatim,
but
if
it
needs
to
be
more
clever
and
use
information
that
it
doesn't
have,
because
it's
all
It
All
Belongs
to
higher
level
abstractions,
it
needs
to
be
given
the
thing
which
I
think
is
Pretty
Natural.
You,
you
create
a
build
workload.
E
You
tell
it
please
push
here
but
yeah
that
that's
sexual
work,
okay,
which
I
guess
we
can
Spike
together
with
the
rest,
so
I
can
create
a
spike,
and
tomorrow
you
can
have
a
pair
just
playing
with
this
and
see
how
far
it
gets,
because
yeah
I
agree
that
having
it
per
app
is
just
ideal.
It's
just
the
natural
way,
but
we
should
I
want
to
see
how
it
looks
like
to
have
the
all
the
special
casing
and
stuff,
because
if
it
might
be
very
ugly.
C
H
A
A
E
But
yeah,
but
for
the
Builder
always
so
the
Builder
is
that
image
that
it
builds
based
on
all
the
build
packs
right.
It's
nothing
to
do
with
the
droplets
or
the
sources.
So
I
guess
the
the
Builder
is
just
special:
it
doesn't
go
through
the
build.
The
Builder
is
not
built
with
a
build
pack.
The
Builder
is
the
thing
that
the
build
packs
use
to
build
stuff
with
the
build
packs.
That's
amazing,
so
I
guess
it
behaves
differently
than
for
droplets.
E
A
E
E
B
E
H
E
B
C
H
G
Yeah
and
I
know
others
do
that
too,
because,
like
at
the
end
of
the
day,
you're
you're
operating
this
thing
and
you
have
like
terabytes
of
of
storage
and
you're
gonna
want
to
clean
up
and
compact
stuff
and
I
I.
Don't
know
how
that
works
for
every
registry,
but
I
know
some
will
like
start
deleting
things
that
they
think
are
unused
or
like
older
versions
of
the
same
repo.
E
G
E
C
B
G
G
E
G
Don't
even
know
if
we
can
necessarily
like,
like
I,
think
people
are
gonna
like
just
run
these
things
or
they're
gonna
run
automatically
and
it's
gonna
mess
up
their
their
apps.
Even
if
you
documented,
like
don't,
have
any
garbage
collection
on
your
registry
like
I,
don't
I
have
no
idea
how,
like
the
is
ones
implement
this
stuff
or
if
they.
E
G
G
E
That's
also
impossible
to
garbage
collect.
How
do
you
tell
which
one
which
repositories
are
good
and
which
one
are
bad?
You
lose
the
you
in
the
opposite
way,
but
you
also
lose
this.
The
the
temporal
correlation
between
the
different
versions.
Right,
you
don't
know
if
two
are
just:
if
one
is
the
old
version
of
another
one
or
if
there
are
two
completely
different
ones,
there's
no
way
to
tell
the.
G
F
G
A
E
A
G
I
think
there's
a
a
bug
like
oh,
like
I
I,
think
it's
gonna
it'd
be
hard
to
to
prove
it.
But
people
like
on
sale
for
VMS
people
figured
all
kinds
of
things
to
exploit
like
the
the
build
pack
caches
and
stuff
like
hey
the.
If
kpac
is
pulling
an
image
and
analyzing
it
and
it
pulls
the
one
for
the
wrong
app
like
I,
have
a
feeling
something
subtle.
A
E
You
want
to
reuse
something
that
you
have
in
the
cache.
You
can
only
reuse
it
if
it's
the
same
identical
thing
to
the
to
the
one
that
you
would
have
computed
right.
The
whole
point
of
caching
is
like
okay.
This
computation
has
already
been
done,
yeah,
it's
not
about
returning
the
wrong
results,
it's
never
about.
If
you're
returning
the
wrong
results,
it's
it
has
to
be
a
bug.
You
know
like.
F
So
yeah,
let's,
let's
create
a
spike
for
this
I
guess
we'll
need
to
block
the
release
which
might
actually
well.
Let's
talk
about
this
again
tomorrow
stand
there,
but
maybe
we
can
just
do
the
merger,
then
the
camera
I
think
we'll
have
probably
enough
time
to
make
sure
it's
fine,
yeah
I!
Guess
we
don't
have
to
decide
now.
We
just
need
to
block
the
release
on
this
other
problem,
because
it's
more
serious.
C
G
B
C
G
E
B
E
E
E
So
yeah
this,
if
you're
wondering
what
the
hell
is
going
on
with
K-Cup
pack,
this
is
what's
going
on.
The
they've
asked
for
a
pull
request,
but
but
just
by
looking
at
the
code,
I
I
don't
think
it's
it's
an
easy
fix.
I'm
I'm,
asking
questions
and
I
hope
that
if
I
get
satisfactory,
answers,
I
might
manage
to
come
up
with
a
PR,
and
hopefully
it's
not
a
massive
one.
E
E
I
I
wonder
why
then
I
don't
know
why,
but
like
I
think
this
is
all
a
problem
with
just
not
using
controller
runtime,
which
seems
to
have
all
this
functionality
built
in
apparently
the
the
framework
they're
using
doesn't
so
they
had
to
come
up
with
this.
They
have
their
own
like
yeah
queue
of
like
they
have
their
own
tree
of
dependencies,
and
then
they
use
the
informers
to
trigger
this
code.
That
looks
at
the
tree
and
it's
like.
Oh,
this
has
changed.
Let's
see
which
things
are
it's
basically
the?
E
What's
it
called
informal
pattern,
no
Observer
right,
it's
basically
an
observer,
it
has
a
list
of
which
things
need
to
be
notified
about
changes
in
other
things,
and
it
does
it
but
like
in
our.
We
have
similar
needs
in
our
reposit
in
our
controllers,
but
we
can
just
say
dot,
watches
or
something,
and
it
just
does
it
automatically
so
I
wish
they
could
do
the
same,
but
they
can't.
E
Does
it
make
me
I,
don't
know
they're
using
the
K
native
stuff
doesn't
mean
k
native
also
needs
to
do.
All
of
this
is
a
pretty
common
thing
to
do
like
every
time
you
reconcile
a
resource
to
some
to
another
resource
you
want
to.
You
want
to
reconcile
both
ways
right,
so
you
want
when
a
changes
you
want
to
reconcile
into
B,
but
when
B
changes
you
want
to
put
it
back
to
where
a
is
right.
E
G
E
Maybe
it
was
a
bit
young
at
the
time
it
was
a
bit
yeah
I
wish
they'd
just
Port
it
it's
already.
It
might
be
expensive
now,
but
like
it's
gonna,
save
them
so
much
so
many
issues
anyway,
I
guess
I'll
keep
you
posted
if
I
can
make
the
pr
I'd
be
happy
to
because
also
I'd
like
to
understand
a
bit
more
about
the
code
base.
E
G
It
reminds
me
of
an
error:
I
saw
the
other
day
with
Capac,
where
I
registered
a
quota,
and
it's
Builder
would
build
an
image
that
was
over
the
quota.
But
all
the
intermediate
layers
just
hung
around
on
their
registry
and
their
garbage
collection
thing
only
ran
once
a
week
and
it
just
ended
up
crashing
the
registry.
So
I
wonder
if
they're
also
I
know
they
got
that
feedback.
I
wonder
if
they're
going
to
incorporate
that
into
some
of
their
retry
stuff
as
well.
Some
better
backgrounds.
G
E
And
maybe
that's
why
they
don't
want
to
retry
I
can
see
how
like
retries,
can
get
out
of
hand,
but
like
I
was
thinking
that
you
know
exponential
back
off
should
be
good
enough
for
everyone,
and
maybe
in
some
cases
you
don't
want
to
that's
when
you
raise
the
permanent,
but
they
went
the
other
way
around.
They.
They
always
raised
permanent
unless
they
there's
nothing,
they
can
do
about
it
and
then
everything
else.