►
From YouTube: Kubernetes SIG Release 20200210
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
Right,
hello,
hello,
everyone
today
is
Monday
February
10th.
This
is
a
edition
of
the
bi-weekly
sig
release
meeting.
This
is
a
meeting
that
is
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say
and
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
in
general,
just
be
awesome
people.
So
we've
got
a
few
agenda
items,
the
first
of
which
is
mine,
so
I
recently
enabled
a
set
of
plugins
for
the
repo
for
both
the
cig
release
and
the
kubernetes
release
repos.
A
Those
are
the
release,
notes
plugin
for
ke
release
only
as
well
as
the
merge
commit
blocker
plugins
and
the
missing
label
plugin.
So
the
merge
commit
blocker
plug-in,
does
kind
of
what
it
sounds
like.
If
there
is
a
merge
commit
within
your
PR,
it
will
block
the
PR
from
merging,
so
don't
have
merge
commits
in
your
PR.
B
A
That's
the
it's
one
of
the
plugins
that
we
use
on
kerbin
a
days
kubernetes
to
enforce
the
usage
of
kind
and
sake
labels
so
for
the
kubernetes
release
and
kubernetes
sake,
release
repos
I've
enabled
the
plug-in
for
both
kind
and
priority,
which
means
moving
forward.
You
should
begin
to,
if
you
haven't
already
been
doing
so,
make
sure
that
you're
putting
kinds
and
priorities
on
your
issues.
This
is
something
that
makes
it
easier
for
us
to
do
triage
to
figure
out
what
is
what
is
more
pressing
and
who
to
assign
what
to
the
the
release.
A
Note
again,
you're
familiar
with
anyone.
Who's
worked
on
the
release,
notes,
tools,
you're
also
familiar
with
that
basically
art.
As
part
of
the
the
new
issue
and
PR
templates
that
are
in
ke
release
and
Kasich
release.
They
have
a
block
for
release
imps
so
or
rather
it's
just
on
release
right
now.
It's
just
on
K
release.
So
the
idea
there
being
weakened
dog
food,
our
own
tool
right
and
as
we're
moving
towards
having
the
repo
version
and
thinking
about
branching
strategies
for
the
repo.
It
would
be
good
to
also
be
able
to
aggregate
all
the.
A
That
stuff
right,
so
that's
why
those
are
owned.
I
sent
an
email
to
both
the
release
team,
as
well
as
the
release
managers
aliases
earlier
today,
detailing
all
of
what
I
just
said.
The
last
point
on
that
email
was
a
note
about
commit
messages,
and
that's
the
second
point
within
also.
Anybody
who
is
interested
in
taking
notes
feel
free
to
put
your
self
down.
As
the
note
taker,
I'll
have
thee
at
that
illustrious
honor.
A
A
A
So
I've
noticed
quite
a
few
pr's
that
have
had
less
than
ideal
commit
messages
and
I
want
to
make
sure
that,
like
us,
especially
as
the
cig,
who
makes
changes
that
have
the
ability
to
affect
pretty
much
all
of
the
kubernetes
repos,
we
want
to
be
mindful
that
we're
providing
good
commit
messages
within
that
email,
I
linked
a
really
good
article
that
lays
down
like
what
you
should
put
in
a
commit
message.
What
should
be
in
the
body
what
should
be
in
the
footer?
A
So
please
take
a
moment
to
check
that
stuff
out
and
in
general,
do
but
make
better
commit
messages.
The
the
last
piece
of
the
whole
issue
and
PR
templates
thing
is
now
that
they're
enabled
please
do
not
remove
them
when
you
are
when
you're
filing
issues
are
filing
PRS,
they're
they're
there.
For
a
reason,
I've
I've
already
noticed
that
some
people
have
removed,
remove
the
template
information
while
filing
an
issue
or
PR.
A
C
A
D
Hello,
I
wasn't
necessarily
expecting
to
talk
to
us
terribly
much.
This
is
something
we
were
discussed
a
little
bit
in
the
release,
notes,
kind
of
sub
team
for
the
communities
1:18
release
team
was
right.
Now
we
have
a
relatively
manual
process
as
outlined
in
our
vol
handbook,
and
we
wanted
to
try
and
automate
that-
and
we
talked
about
this-
a
little
bit
internally,
I'm
a
kind
of
taught
a
little
more
widely
with
the
sig
and
kind
of
had
it
suggested.
This
come
evolved
into
a
ke
rel
tool
which
is
used
for
releases
I.
D
Think
our
current
plan
is
mostly
just
to
talk
with
Sasha
I.
Believe.
Forgive
me
if
I'm
saying
your
name
incorrectly
and
crystal
new
to
everyone
to
try
and
find
a
way
of
doing
that
very
unclear
on
the
exact
way
forward
and
exactly
what
we
need
to
do
with
that.
So
there's
anything
else,
I'm
difficulty
to
say
so,
even
though
I
think.
A
E
E
Basically,
we
are
all
set,
so
the
change
focus
working
right
now.
I
did
some
optimizations
which
go
beyond
the
actual
migration
from
bash
to
going
so,
for
example,
and
we
decided
to
sort
notes
for
particularly
and
uppercase
the
first
character
so
that
it
looks
clean
and
nice
and
yeah.
This
looks
right
now.
The
only
thing
we
have
to
add
is
the
creation
testing
and
the
decoration
testing
part
is
mostly
done.
E
It
works
that
we
pre
records
the
API
from
github,
and
then
we
replay
that
API
and
check
if
the
results
coming
out
from
the
change
look
to
are
the
same
as
we
would
expect
it.
So
that's
the
basic
approach-
and
this
looks
pretty
well
so
one
example-
PR-
would
be
this
one.
So
there
you
can
see
that
we
have
a
lot
of
JSON
files
added
to
the
repository
which
allow
us
to
replay
the
API
from
github
without
accessing
github
at
all,
and
then
then
we
are
mostly
done
with
that.
E
So
we
can
still
add
Hance
testing.
So
this
is
obvious.
We
can
do
it
as
well
and
we
have
to
move
forward
with
the
push
build
tool
which
is
I.
Don't
think
it's
completely
done,
but
maybe
then
can
update
us
on
that,
and
there
are
some
other
smaller
to
is
like
fine
Korean
build
and
they
release
notified
tool.
And
then
we
are
just
migrating
to
a
huge
ones.
Ccp
manager
and
an
echo.
D
E
More
or
less
uses
the
release
notes
to
it,
but
it
also,
for
example,
modifies
the
repository
during
the
build
process.
So
we
are,
we
also
commit
the
new
change
lock
into
the
KK
repository
after
generating
them
and
the
release
notes
tools
are
just
available
for
generating
release,
notes,
so
I
think
a
good
next
step
would
be
if
we
have
two
additional
features.
E
The
first
one
is
about
creating
pull
requests
from
Krell,
so
this
is
not
available
right
now,
and
this
would
be
a
necessary
step
in
my
point
of
view,
and
the
next
thing
would
be
a
dedicated
sub
command
for
release,
notes
based
workflows,
which
would
mean
that
we
generate
the
release,
notes
for
alpha
3
and
then
create
a
pull
request
to
the
release
notes
website.
We
had
a
chase
and
the
draft
in
markdown
to
the
SiC
release
repository
and
that's
it
I
think
so.
D
E
Yeah,
first
of
all,
we
have
to
I
think
that
the
most
complex
part
is
the
actual
handling
in
the
repository.
Because
if
you
want
to
create
a
pull
request,
then
you
have
to
somehow
commit
the
changes
to
your
own
fork
and
then
create
from
that
fork
to
pull
request
to
this
Kasich
release.
For
example,
a
repository
and
having
that
and
I
think
the
workflow
might
be
more
complex
and
it
looks
like
because
handling
remotes
and
stuff
like
that,
but
usually
I,
think
it's
it's
straightforward
to
implement.
Okay,.
A
So
I
would
say:
I
would
say
before
getting
to
the
niceties.
Let's
just
make
sure
that
we
can
output
the
website
right.
I'll
put
the
website
at
the
JSON
for
the
website,
as
well
as
whatever
y'all
need
on
the
release
notes
ID
to
commit
drafts
back
to
the
repository
from
there.
Once
that,
all
all
that's
done,
then
people
can
look
at
doing
automated
pull
requests
and
all
that
stuff
I.
A
A
We
will
cross
that
bridge
when
we,
when
we
get
there
right
now.
The
token
that's
in
it's
in
the
repo
attached
to
attach
to
the
stage
and
release
builds
are
it
is
for
writing
two
repos
for
the
token
that
you'd
be
using
locally.
Obviously,
it's
something
that
you
would
need
to
write
to.
Your
would
need
to
have
access
to
write
to
your
personal
repos
doesn't
need
access
to
write
to
any
of
the
kubernetes
repos,
so
just
keep
that
in.
C
A
C
B
A
It's
so
show
me
an
example:
I
mean
essentially
what
I
did
was
just
dump
the
usage,
the
current
usage
with
and
within
Cobra,
and
add
some
here's.
What
we
did,
here's,
what
we
haven't
done
yet
notes,
but
eventually
I
would
like
to
I.
Have
it
on
my
to-do
list,
I'm,
not
sure
if
it
is
in
an
issue,
if
it's
not
I
can
file
it.
But
basically
there
was
an
update
to
the
contributor
site
that
added
that
added,
like
release
timeline
stuff,
are
links
to
release
timelines.
A
I
would
like
us
to
build
an
elephant
for
the
reliefs
Docs,
both
the
the
all
of
the
release
manager
handbooks,
as
well
as
describing
how
we
use
the
tools
that
we
use
right.
I
think
that
some
of
that
is
kind
of
tribal
knowledge
where
it
assumes
that
you
have
been
working
on
that
tool
to
know
exactly
how
to
use
it.
So
that's
kind
of
what
I'm
saying
now.
C
C
I
see
this
is
like
I
totally
agree.
We
need
the
bigger
picture,
but
if
somebody's
just
consuming
from
an
API
perspective,
that's
the
one
place
I
tend
to
use
go
doc
still
is
like.
Oh
there's
a
nice
API,
it's
got
nice
documentation,
it's
authoritative,
because
it's
in
sync
in
the
code,
yeah
yeah,
yeah,.
G
A
A
Okay,
I
think
we
can
put
it
on
the
list
of
things
to
consider.
Maybe,
but
I
would
prefer
any
effort
in
documentation
to
be
pushed
towards
clean
user
documentation,
as
opposed
to
your
API
documentation
like
people
who
are
writing.
The
code
today
continue
to
write
clean
code.
That's
well
commented
and
the
people
who
are
going
to
be
focusing
on
user
facing
documentation
should
spend
more
time
doing
that
then
implementing
this
not
saying
that
we
can't
do
it
I,
don't
think
it
should
be.
Our
first
focus
thank.
C
You
those
two
overarching
goals
that
we
have
good
documentation
for
the
maintainer
x'
of
the
project
and
good
documentation
for
the
consumers
of
the
prod
checked
the
specific
implementation
of
those
might
not
matter
so
much,
but
I
mean
we
got
into
that
with
go
doc,
obviously,
and
natla
Phi
or
whatever,
but
swagger
is
certainly
a
common
one.
I
feel
like
swagger.
It
doesn't
have
some
additional
benefits,
but
I
also
feel
like
it
comes
with
some.
As
with
any
of
these,
maybe
besides
go
talk
where
it's
completely
automatic.
A
B
A
Awesome
so
I
not
on
the
schedule
with
announcement.
Dan
has
been
doing
some
really
awesome
work
on
the
release
engineering
side,
so
we
have
decided
to
make
him
a
release.
Manager
associated
officially
I
actually
was
surprised
that
he
was
not
already
because
he
does
a
lot
of
that
work
already.
So
thank
you,
Dan
for
your
continued
efforts.
Dan
will
be
cutting
the
118
alpha
for
release
tomorrow.
As
long
as
we
fix
the
the
issue
that
we
currently
have
with
it.
So
maybe
I
should
talk
about
that.
A
little.
A
Yeah,
okay,
so
essentially
what
happened
is
I
think
during
one
of
the
releases,
the
most
recent
release:
118
zero
alpha
3,
one
of
the
jobs
failed
and
the
job
is
responsible,
so
I
I
think
it
was
the
CI
kubernetes
build
job
and
that
job
is
responsible
for
essentially
pushing
builds
right.
So
the
push
build
rewrite
that
we're
talking
about
is
a
rewrite
of
script,
called
push,
build
and
the
root
of
K
release,
and
that
script
is
responsible
for
pushing
builds.
A
Fleshing
CI
builds
to
two
to
CI
bucket,
as
well
as
as
well
as
changing
the
updating,
the
version
markers
that
we
use.
So,
if
you've
ever
seen,
something
like
DL
Cates
that
io
/
/
CI
/
latest
dot,
txt
right,
that's
one
of
our
version
marker
files
and
it
represents
the
most
recent
successful
build
version.
When
that
job
failed.
A
A
C
A
A
Rather,
it's
they're
currently
running
at
one
18.0
alpha
3,
some
build
version
get
sha
right,
so
it
should
be.
Actually
it's
done.
2.2
build
number
get
shot
right
so
when
we
send
our
when
we
send
a
staging
job
into
GCB,
it's
looking
to
see
if
the
current
tag
for
that
branch
is
behind
the
build
version.
If
it's
behind
the
little
version,
it
won't
build
right.
So
that's
currently
the
issue
that
tag
should
have
been
once
once
we
let
out
alpha
three
one
of
those
old
versions
should
have
been
bumped
to
2.
A
Alpha
3
build
number
get
shop
right,
so
we
need
to
figure
out
how
to
bump
that
version
so
that
it
can
actually
build
alpha.
4
I've
written
up
an
issue
about
it,
which
maybe
explains
it
a
little
bit
more
eloquently
with
some
bill
blogs
as
well,
so
that
is
here
in
chance
and
if
someone
can
transpose
that
into
the
notes,
that'd
be
great,
so
yeah
I'm
gonna
be
investigating
that
ok,
yeah!
That's
it
for
push;
that's
it
for
push
bill
at
least
any
questions
on
that.
A
It's
possible,
but
I
think
it
has
more
to
do
with
the
I.
Don't
think
we
change
anything
related
to
the
version
markers
so
I
think
it's
a
failure
of
that
that
build
job
that
bill
job
may
be
based
on
something
that
could
be
looking
at
Anagha,
but
I.
Don't
think
it
is
that's
the
one
of
the
that's
one
of
the
bootstrap.
That's
one
of
the
bootstrap
scenarios
so
see:
I
kubernetes,
build
uses
the
kubernetes,
build
a
trap
scenario
and
that
one
I
I
think
just
does
it.
A
A
It's
also
possible
that
the
the
way
that
it
kind
of
coalesce
is
the
version
based
on
partially
based
on
the
job
results,
cache
dot
JSON.
There
was
an
issue
filed
for
that
by
been
a
few
releases
back.
That
was
not
high
high
enough
priority
to
take
a
look
at,
but
I
think
it
is
now
a
and
I
can
almost
guarantee.
It
has
something
to
do
with
the
code
that
that
coalesce
is
that
build
version.
A
Yeah
fun
funfun,
so
any
questions
on
that
I
also
did
a
test
of
so
I
tested
this
from
the
reason
I
discovered
this
was
there
the
way
I
discovered
this
was
I
was
working
on
a
change
for
something
entirely
unrelated
and
I
noticed
that
the
change
failed,
so
I
have
a
feature
branch
prototype.
That's
essentially
testing
the
what
it
would
look
like
for
us
to
be
able
to
run
the
staging
and
release
jobs
on
kubernetes
in
front,
as
opposed
to
Google
infra.
That
issue
that
PR
is
here
and
essentially
what
happened
was
well.
It
failed.
A
The
staging
job
failed
and
I
thought
it
was
related
to
the
PR,
something
I
missed
and
then
I
tried
it
on
master
as
well.
Using
against
kubernetes
release
master
I
noticed
the
same
thing
was
happening.
Basically,
it
says
that
the
build
version
is
old
and
the
workspace
is
unclean,
the
Onaga
workspaces
on
clean.
So
it's
not
going
to
build
the
build.
A
So
in
the
background
we've
been
working
on
a
staging
job
that
runs
on
kubernetes
that
runs
on
the
Google
infrastructure
to
test
whether
or
not
we
can
do
the
staging
job
right.
Just
it's
a
very
simple,
like
GCV
manager,
stage
master
right
so
that
job
has
been
failing,
because
the
well
one
you
can
send.
We
could
have
that
job
be
successful
by
simply
not
asking
it
to
pull
pull
the
logs
right.
A
So
basically
looking
for
the
success
of
the
job
within
prowl,
but
then
that
wouldn't
tell
us
what's
going
on
with
the
job
ahead
of
time
right,
so
I
made
a
change
to
a
Naga
arts,
a
GCV
manager
that
allows
the
that
allows
you
to
flip
the
async
flag
for
the
Google.
So
basically,
a
JCB
manager
is
a
rapper
for
people
who
are
not
familiar
with
the
stuff.
I
know
like
going
into
the
leads,
so
there
is
a
so
GCV
manager
is
essentially
a
wrapper
for
the
substitutions
that
we
provide
to
to
the
G
cloud.
A
Build
submit
command
right.
So
basically,
we
have
templates,
for
we
have
templates
to
run
nago
commands
and
hago
is
our
primary
release.
Engineering
tool
and
those
are
in
GCB
stage
and
or
release
cloud
build
yeah
mo
right.
So
basically,
we
run
it
through
GCD
manager,
GCV
manager
set
spits
out
a
set
of
substitutions
for
those
commands
and
then
and
then
submits
the
build
right.
A
So
as
I
was
looking
at
this
and
realizing
that
the
async
was
failing,
the
flipping
on
or
off
the
async
bit
was
failing.
I
said
well:
well,
we've
got
to
fix
this,
but
does
it
make
more
sense
for
me
to
try
to
fix
this
in
GCP
manager,
or
does
it
make
more
sense
for
me
to
start
to
rewrite
GCB
manager,
so
so
I
started
to
rewrite
JCV
manager,
hey
because
no
more
bash
and
kind
of
sick
of
it?
A
Essentially
what
we've
been
doing
if
you're
familiar
with
the
image
building
process,
we
have
a
tool
that
was
worked
on
primarily
by
Katherine
in
tests
infra.
That
kind
of
does
a
very
similar
thing
right.
It
does
a
figures
out
the
substitutions
that
prior
to
submission
and
then
does
does
the
thing
right.
So
you
wire
up
a
prowl
job
to
do
image.
Building
you
specify
some
like
get
tags
and
and
the
pole
ref
and
a
few
other
things
if
you
want
to
see
one
of
those
jobs.
A
If
you
want
to
see
an
example
of
that,
it's
basically
here
right,
so
you
have
your
GCB
steps
listed.
There
are
things
like
get
tagged
and
go
version
that
it
uses
internally
to
figure
out.
What's
a
substitute
right,
the
so
I
was
working
on
this
a
little
earlier
and
it's
out
of
place
where
it's
doing
more
than
it
was
before
I
placed.
A
A
You
see
that
actually
starts
to
run
within
GCP
manager,
and
the
biggest
thing
I
was
looking
at
was
the
the
async
flag.
I
know
that
these
I
know
that
proud
jobs
triggered
off
of
the
GCB
builder
or
image
builder,
or
whatever
we're
calling
it
today,
I
call
it
JCB
builder
GC
builder,
so
you
can
see
some
substitutions
I
have
some
fake
information
in
the
code
right
now,
so
I
faked
the
whole
point:
fake
version,
fake,
build
version.
A
This
needs
to
be
fixed,
fake
user,
so
on
and
so
forth
right,
but
this
is
further,
along
than
it
was
before,
and
I'll
I'll
wire
it
up.
So
that,
like
we,
can
flip
the
async
flag
again
here,
but
essentially
what
it's
doing
right
now
is
it's
it's
sending
it's
streaming
with
the
logs
directly
to
my
computer
right.
So
this
is
essentially
the
experience
that
we
want
within
prowl,
so
that
we
can
see
that
the
stages
are
actually
running
successful
successfully.
A
A
A
So
that's
available
or
will
be
available
once
the
pr
emerges
at
package
g
cv,
j
CP
build
build,
co
right,
so
the
functions
that
are
there
are
then
used
in
the
GCB
manager
go
sub
command
of
Krell
right.
So
you
can
see.
Essentially
it's
doing
its
basically
looking
for
one.
It's
making
sure
that
you
don't
specify
both
stage
and
release
it's
doing.
A
set
of
GCB
substitutions,
which
are
these
are
some
of
these
fake
values
that
I
created
and
also
allowing
you
to
specify
the
release
tool
repo.
A
If
you
want
to
target
this
against
a
fork
or
you
wanted
to,
and
if
you
target
against
the
fork,
then
targeting
against
some
branch
that
you
have
on
that
fork
and
then
a
simple
switch
and
some
some
cases
for
stage
our
release.
So
if
you
were
to
look
at
GCB
manager
today,
you'll
see
that
we
kind
of
have
a
similar
situation
going
on
it
will
do
it.
A
Yeah
so
release
it
right.
It's
checking
to
make
sure
you
have
a
branch
set.
It's
setting
the
cube
cross
version
right
now.
We
have
a
dummy
version
in
GCV
manager
are
a
working
version,
but
it's
hard
coded
and
and
then
finally
does
this
submit
it
right
and
then
submit.
It
is
right
here
and
submitted
as
doing
as
I
mentioned.
It's
essentially
aggregating
a
set
of
substitutions
to
provide
to
the
g-cloud
builds
submit
command
right.
So
this
is
this
async
flag
that
I
was
talking
about
and
then
the
async
flag
I
did
the
thing
yeah.
A
C
Question
back
at
the
end
of
that
this
is
maybe
a
philosophical
one
for
the
group
for
people
who
haven't
done
the
build
and
seeing
what
goes
by
and
GCB
manager.
One
of
the
things
that
you
would
see
is
a
whole
bunch
of
preparation
in
terms
of
go
getting
modules
like
what
Steven
showed
there,
with
the
the
compilation
step
that
compilation
step
local
mildly
freaked
me
out,
because
it
was
a
whole
bunch
of
go
get
latest
s--.
C
We
had
a
slight
issue
recently
where
the
latest
bash
brokest
magically
like
these
dependency
management,
is
a
thing
we
should
be
thinking
about,
but
we're
actually
in
a
really
bad
state
on
that.
If
you,
if
you
see,
if
you
look
I
just
pulled
up
one
of
the
blogs
and
I
see
back
here,
mouse
focus
590
equivalents
of
go
get
during
our
our
build.
C
That's
that's
in
the
cloud,
so
we
don't
see
any
of
it,
but
that's
stuff
that
we
should
need
to
think
about
managing
as
we
shift
over
things
from
bash
or
it
was
completely
implicit
to
go
where
we
have
mechanisms
for
controlling
it.
We
need
to
think
about
controlling
it,
but
I
would
assert
the
apportion
that
we
should
be
thinking
about,
limiting
that.
How
can
we
have
as
few
external
dependencies
as
possible
because
590
or
whatever
it
was
a
scary
number.
C
C
H
C
A
I
think
one
of
the
things
that
we'll
be
able
to
start
doing,
if
you
notice
in
some
places
in
our
and
our
GCB
templates
we
do
have,
we
do
have
explicit
version
set
and
in
some
places
it's
set
to
latest.
The
reason
we
have
it
set
to
latest
in
some
places
is
so
that
now
that
we're
I
mean
we're
kind
of
iterating
over
this
stuff
quickly
and
it's
nice
to
be
able
to
know
that
the
latest
version
of
what
we
did
in
the
repo
will
be
produced
in
CI,
but
I.
A
Think
as
we
as
some
of
this
tool
creation
starts
to
slow
down,
we
should
start
locking
in
some
of
those
things
the
I
totally
lost.
My
thought
so
I
think
it's
give
me
a
second,
but
I
know
you
were
saying
something
so
go
for
it.
No.
I
I,
just
I
just
wanted
to
say
that
I,
agree
and
I
feel
like
we
should
start
to
think
about
it
earlier
sooner
than
later,
because
when,
for
example,
we
will
be
will
have
like
a
huge
pile
even
bigger
than
now
of
the
dependencies,
we
be
harder
much
harder
and
I
feel
like
we
can
do
already
with
some
small
steps.
We
can
walk
it
and
I.
Don't
think
that
it
needs
to
be
done.
100%
at
this
point,
but
I
feel
like
it
is
important
to
start
working
on
that.
A
Okay,
now
I
remember
what
I
was
going
to
say
and
it's
about
the
variance
file
right
so
moving
moving
the
GC
v
GC
builder
over
here
allows
us
to
I
mean
one
moving.
It
doesn't
really
do
anything,
but
using
GC
builder
allows
us
access
to
what
we've
been
calling
a
variance
file
right.
So
the
idea
with
the
variance
file
is
that
you'd
be
able
to
produce
a
set
of
images
or
a
set
of
things
right
for
the
the
release
for
the
release.
Variance
we
actually
don't
use
I'll
show
you
the
release,
variance,
do.
A
All
right
so
within
GC
v
and
then
build
so.
This
is
like
our
prototype
job
to
test
this
out
that
you
can
see
the
variance
specify
whether
or
not
it's
running
in
CI.
So
this
is
a
very
name
and
then
the
variant
name
specifies
a
set
of
substitutions
right.
So
this
one
I
know
we're
running
in
CI.
This
is
like
the
old
concei.
I
configuration
I
think
these
are
somewhat
equivalent
roughly
equivalent
outside
of
the
registry
and
the
bucket
name
right
now.
A
But
the
idea
here
is
that
we'd
be
able
to
specify
a
set
of
variants
and
target
a
variant.
So
one
example
of
that
is,
if
you
look
at
the
cubic
ins
e
to
e
variance
right
where
we
we
specify
configure
as
experimental
and
then
go
versions
and
different
versions
right
that
may
skew
from
what's
used
on
master
right.
A
So
when
the
cubic
in
CDE
images
are
spit
out,
it
will
walk
through
all
of
these
variants
and
produce,
or
all
of
these
yeah,
all
of
these
variant
names
right
and
produce
images
based
on
the
versions
that
are
specified
here
right.
So
you
can
see
that
you
know
for
for
master
and
117
they're,
roughly
equivalent
outside
of
the
the
Cates
release
version,
but
for
experimental
you
see,
the
Basel
version
is
is
different
right
and
you
see
that
upgrade
very
specified
rate.
So
this
this
image
will
try
to
upgrade
docker
within
the
within
the
script.
A
Argo
version
are
the
Basel
version
right,
so
I
think
we
can
using
the
variants
I
think
we
can
do
something
similar
and
think
about
the
external
dependencies
that
we
have
and
try
to
and
try
to
be
a
little
bit
more
stringent
about
the
the
things
that
we
view
there.
There's
also
do.
How
do
you
spell?
How
do
you
spell
all
right?
So
there's
also
is
it
hack
and.
A
Okay,
alright,
so
we
have
a
script
in
HACC
called
verify
external
dependencies
version,
dot
Sh,
which
eventually
runs
cme,
verify
dependencies
or
fi
dependency
stuff.
Go
I,
sent
out
an
email
about
this
a
while
ago,
I
guess
last
year,
some
time
and
someone
reached
out
to
me
and
was
like
wow.
This
is
really
cool.
What
y'all
are
doing?
Essentially
this?
A
This
goes
through
a
set
of
dependencies
specified
in
some
yamo,
as
as
you
do,
and
and
looks
for
a
reference
path
right
and
and
in
a
regex
match
right
and
we'll
try
to
verify
that
the
places
that
you
have
specified
in
the
in
in
the
match,
or
the
places
that
you've
specified
in
the
reference
path
match
the
version
of
match.
The
version
that
you've
specified
within
do
within
this
dependencies.
That
yeah
also
build
dependencies
dot,
yeah
mole
and
you
can
see-
we've
started
to
do
this
for
the
kubernetes
kubernetes
repo
right.
A
A
A
C
Mildly
skeptical
having
written
something
like
that
before
it's
in
the
attempt
to
manage
these
things,
we
tend
to
start
building
tools,
naturally,
and
across
all
of
the
patterns.
It's
really
hard
to
come
up
with
a
a
meta
description,
language
and
and
mechanism
around
it
and
policy
around.
All
of
that
that
covers
all
of
the
different
possibilities,
and
then
you
also
have
a
kind
of
garbage
in
garbage
out
problem
because,
as
with
our
Bosch
example
like,
of
course,
we
depend
on
Bosch.
C
This
is
a
whole
bunch
of
Bosch
there's
a
ton
of
things
that
are
just
implicitly
assumed
and
there's
a
fan
out
across
that.
So
you
might
depend
on
something
and
it's
being
provided
by
the
thing
that
you
requested
the
helm
chart.
But
that
depends
on
a
specific
version
of
Ubuntu,
perhaps
and
this
all
of
the
packages
that
happen
to
be
in
that
specific
image
and
it
gets
really
complicated.
But
so
I
I'm
cautious.
C
A
So
I
think
that
you
know
the
part
of
using
that
tool
is
explicitly
defining
the
things
that
we
care
about.
So
I.
Don't
think
that
we're
we're
we're
kind
of
casting
off
that
that
responsibility.
It's
doing
it's
doing,
essentially
what
we
wrote.
So
the
you
seen
I
think
originally
wrote
that
the
verify
dependency
is
that
go
and
we
we
need
to
expand
on
some
of
it
to
allow
us
to
to
allow
multiple
approvers
right.
So
that's
something
that
was
on
my
plate,
but
we
also
need
to
I
mean
we
need
something
right.
A
We
need
something,
and
essentially
it's
it's
the
it's,
the
more
sophisticated
version
of
specifying
a
version
looking
through
all
the
files
on
the
repo
and
seeing
if
that
version
matches
relative
to
something
right.
The
bash
one,
like
you
said,
is
a
little
trickier
because
we
I
mean
it
doesn't
need
to
be
I
guess
because
we
could
specify
a
version
of
bash.
It.
C
A
So
I
think
we
should.
We
should
try
to
have
maybe
a
deeper
discussion
about
the
verify
dependencies
stuff.
My
one
concern
about
using
an
external
tool
as
our
ability
to
manage
it,
manage
and
update
it,
but
if
it
is
net
improvement
to
what
we
did
and
verify
dependencies
I
do
think
we
should
check
it
out
as
long
as
we're
not
trying
to
boil
the
ocean
with
it
as
long
as
we
keep
it
simple
and
we're
just
like
here's,
a
path,
here's
a
version,
I
think
I
think
it's
usable.
A
A
The
for
the
label
side,
basically
renaming
these
labels
to
conform
with
the
area
category,
the
area,
category
kind
of
setup
that
we
have
for
most
label.
So
if
you
see
like
sake,
/foo
right
or
area,
/
bar
conforming,
the
cherry-pick
and
release
notes
labels
to
do
the
same
and
then
the
second
issue
is
adding
a
kind
test
label
which
we
talked
about
a
while
ago,
but
I'm
not
sure
if
it's
required
so
yeah
Bob.
Please.
J
Keep
the
stock
it's
been,
causing
me
more
problems
anyway.
Yeah
I've
been
going
through
just
like
all.
The
issues
that
like
contributes
is
a
part
of
trying
to
see
sort
of
where
they
are
and
if
it's
still
like
worth
poking
them,
and
these
two
came
up
like
they've
had
a
couple
pokes
they've
reopened
them,
but
they
keep
going
into
stale
I,
mostly
just
wanted
to
see
from
the
release
side.
Is
it
still
worth?
Even
you
know
having
these
open,
I
think
like
especially
on
the
release,
notes.
J
Eight,
we
now
have
released
no
sight
and
adding
like
some
of
the
label
stuff,
so
I
think
at
least
that
portion
is
done
and
the
other
one
the
kind
test
one
has
been
debated
back
and
forth
and
was
reopened
with
like
someone
dressed
like
it
was
like
kind,
wolf
and
so
I
I
think
they're
there
they
can
probably
be
closed.
I,
don't
know
if
there's
there's
more
to
get
out
of
them
being
discussed.
A
So
today
we
have
a
an
area
test
label
right
and
the
area
test
label
will
hold
trigger
if,
if
it's
described
in
the
owners
file
for
some
area
right.
So
if
you
had
so,
you
know.
Theoretically,
if
you
had
a
owners
file
within
a
test
directory
of
some
repo,
you
could
add
a
label
to
automatically
add
area
test
to
it
right.
So
we
have
a
solution
at
least
for
for
PRS
right,
but
for
issues.
A
I
think
the
original
idea
was
like
well
what,
if
we're
trying
to
describe
a
test
that
we
need,
or
or
so
I
think
what
we
were
originally
thinking
about
is
something
like
contest,
plus
area
component
right.
Whatever
component,
this
test
would
be
related
to,
but
I
think
that
that's
just
as
easily
solved
with
area
test
and
area
some
component
I,
don't
think
that
we
need
a
kind
test
label
anymore.
But
if
anyone
from
CI
signal
or
anyone
who
generally
has
opinions
about
that,
yeah
go
for
it.
A
A
A
Yeah,
it's
documented
on
our
side
or
whatever
our
side
is
I've
got
it
in
my
to
do
list
I
think,
but
we
should
I
I
guess
we
should
add
it
to
this
issue
so
yeah.
Let
us
some
lettuce
action,
all
those
okay
cool
all
right,
so
I
had
one
more
that
was
on
this
on
this
list
for
the
KK
image
building.
But
Hannes
is
not
here
and
I.
Think
there's
an
unresolved
comment
that
he
made
on
the
PR.
So
let
me
before
we
go.
Let
me
just
link
that
PR
to
the
yeah.