►
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
Hello,
hello,
everyone.
This
is
a
special
edition
release
engineering
meeting.
It
is
October
29th.
This
is
a
meeting
that
is
recorded
and
available
on
the
internet.
So
please
be
mindful
of
what
you
say.
What
you
do
please
be
sure
to
adhere
to
the
kubernetes
code
of
conduct
and
just
in
general,
be
awesome
people,
so
we've
been
we've
been
doing
a
few
code
based
tours.
A
So
in
that,
in
that
video
I
went
through
some
of
the
staging
process,
I'm
going
to
post
it
in
the
chat
for
people
who
are
who
are
here
and
what
I'd
like
to
do.
This
time
is
not
go
through
the
same
stuff
that
we
did
last
time,
which
was
staging
stuff.
So
this
time
we're
going
to
talk
a
little
bit
about
some
of
the
stuff,
that's
involved
in
doing
the
actual
release
right.
A
A
We
also
have
the
staging
process.
The
staging
process
essentially
does
a
build
and
checks
some
permissions
to
ensure
that
artifacts
land,
where
they're
supposed
to
right
and
then
finally,
the
release
process
actually
pulls
the
trigger
on
those
staging,
builds
copies
them
from
a
staging
bucket
into
into
the
actual
product
and
then
also
releases
the
container
images
and
updates
version,
markers
and
so
on
and
so
forth,
so
scripts
that
may
be
leveraging
markers
that
use
something
like
DL
kto.
A
A
It's
the
best
way
to
put
it
if
you're
not
familiar
with
dealing
with
this
stuff
day
to
day
so
I'm
going
to
share
my
screen
and
give
me
a
second
to
do
that.
Just
closing
some
sensitive
windows
all
right-
and
here
we
go
alright.
So
the
first
thing
that
you
might
do
is
a
branch
manager
or
as
a
release
manager,
is
go
and
view
the
the
handbook
right,
which
is
somewhere.
A
A
Right
now,
let's
just
walk
through
this
really
quickly,
so
there's
some
prerequisites
that
you
read
over
and
you
finally
get
to
the
safety
check.
Release
management,
some
of
the
general
bookkeeping
so
general
bookkeeping,
will
tell
you
to
open
a
cut
a
release
issue
on
K
release.
So
let's
go
take
a
look
at
that
issue.
A
In
progress
and
milestone,
117
all
right,
so
the
first
thing
that
we
do
is
we
screenshot
master.
We
have
a
tool
called
test
grid,
shot,
that's
in
the
kubernetes
release
repo
and
if
you
were
to
look
at,
if
you
actually
take
a
look
at
some
of
the
comments
here,
it
will
tell
you
exactly
what
you
should.
You
should
be
doing
in
certain
stages.
A
Right
so
add
some
things,
the
checklist.
If
you
want
here's,
a
template
for
how
to
snapshot
these
things,
essentially
we're
just
using
that
test,
grid,
shot,
good
shot
tool
and
I
can
show
that
to
you
really
quickly
do
do
all
right.
So,
if
I,
just
so
from
k,
release
if
I
do
test
grid
shot
and
then
master
do
a
branch
that
I'm
targeting
okay,
so
I
can't
show
you
that,
because
I
would
expose
my
key
okay.
A
So
let's
get
that,
but
what
it
ends
up
giving
you
is
what
it
ends
up
giving
you
is
a
pretty
printout
of
the
set
of
boards
and
how
green
they
are
or
how
not
green.
They
are
right.
So
this
lists
the
failing
boards,
the
failing
jobs
on
the
master,
blocking
and
mash
forming
boards.
Right
so
note,
cubelet
master
is
one
of
them
and
it
also
gives
you
a
link
to
the
test
grid
of
that
test.
A
Script
page
for
that
right
and
you
can
see
that
some
of
these
are
starting
to
go
green,
so
yay
and
then
you've
got
the
GC
cause
master
serial
and
GC
windows
master
right
and
again
there
are
links
to
each
of
these
boards.
If
you
want
to
check
it
out.
The
next
thing
that
you
kind
of
do
is
so
there's
a
log
that
we
keep
and
the
log
kind
of
looks
like
this.
A
A
The
link
to
the
cloud
build
run
right,
so
if
I
click
into
that
I
can
view
what's
going
on
on
GCP
or
someone
else
can
for
future
reference
right
as
well
as
a
set
of
so
the
set
of
commands
that
it's
running
a
clone
compiled,
release
tools,
doing
a
pre
build,
build,
only
build
that
head
for
the
staging
process
and
then
at
the
end
of
it.
What
it
gives
you
and
let
me
just
make
that
a
little
bigger
what
it
will
give.
You
is
a
command
that
you
can
use
to
release
the
staged
build
right.
A
So
that's
the
command
notice
for
the
mock
stage
that
it
does
not
have
the
no
mock
flag
by
default.
A
lot
of
our
release
tools
will
run
in
a
mock
mode,
so
you
don't
accidentally
shoot
yourself
in
the
foot
right.
So
each
of
those
runs
take
about
take
about
50
minutes.
In
the
case
of
the
beta0,
what's
actually
happening
behind
the
scenes
as
we're
doing
two
releases
right:
we're
cutting
the
beta0,
but
we're
also
staging
the
1:18
alpha0
right.
A
So
every
time
we
do
this
release
process,
it
basically
increments
the
counter
right,
where
it
figures
out
what
the
next
release
would
be
on
master
right
so
because
we're
now
moving
to
one
we're,
cutting
a
new
branch
and
we're
moving
we're
moving
the
essentially
development
process
for
117
over
to
that
branch.
And
that's
what
you'll
see.
A
Basically,
during
the
code
freeze
period
where,
where
the,
where
submission
to
that
branch
will
required,
cherry-picks
right,
there's
a
there's,
a
time
which
is
now
between
now
and
end
code,
freeze
where
we
will,
where
we
will
essentially
fast-forward
the
117
branch,
the
release,
117
branch
from
master,
and
so
while
we're
doing
that,
everyone
is
safe
up
until
the
point
that
code
freeze
hits
and
everything
else
becomes.
Everything
else
becomes
to
cherry-pick
directly
to
release
117
if
you,
if
you're,
trying
to
get
it
in
under
the
the
wire
right.
A
A
Yeah
so
each
of
the
the
releases,
whether
it
be
a
mock
or
otherwise
take
about
20
minutes.
So
you
can
see
like
this
stuff
was
done
a
little
earlier
today,
and
this
was
done
more
recently.
So
since
so,
since
this
release
has
happened,
I've
been
working
on.
Essentially,
let's
go
talk
about
the
special
pieces
of
the
beta
right
before
I
continue
any
questions
so
far.
A
Okay,
cool
all
right,
so
there
is
also
kind
of
a
release
manager,
scratch
pad
right
sober.
So
as
you're
going
through
the
release
you
can
see,
there
are
a
few
releases
that
are
documented
here,
where
a
release
manager
will
essentially
document
their
experience
right
and
think
about
things
that
might
need
to
be
fixed
and
so
on
and
so
forth.
So
here
you
know
some
of
the
things
that
I
noticed
immediately.
What
was
one
open?
The
issue?
Let's,
let's
make
sure
that
issue
is
linked
to
the
release,
the
release
cut
issue.
Template
needs
to
be
updated.
A
It's
currently
labeling
area
release
team.
Now
that
the
release
managers
have
all
moved
out
of
the
release
team,
there
should
be
area
release
ng.
We
should
also
mention
and
mentions
the
cig
release
channel,
but
we
also
have
the
release
management
channel,
which
is
supposed
to
be
dedicated
for
exactly
these
kind
of
things.
So
we
should
mention
that
in
the
in
the
in
the
issue
template
now,
that's
so
the
template
also
links
to
a
gist
of
Han
is's
test
grid,
shot
tool.
A
Since
that
issue,
template
was
created,
we've
created,
we've
migrated
that
tool
into
the
kubernetes
release
repo.
So
there's
no
need
to
continue
pointing
to
that
gist.
Our
output
for
test
screenshot
doesn't
show
you
the
signup
page.
This
is
kind
of
you
know.
The
user
will
need
to
walk
through
this.
Not
a
big
deal
essentially
what's
happening
here
is
for
test
card
shop,
we're
storing
it,
we're
storing
it
in
a
bucket
from
VG
v
gy
AME,
but
they
have
recently
had
some
some
abuse
of
their
terms
of
service,
so
they've
required.
A
So
we
used
to
be
able
to
do
anonymous
uploads.
They
now
require
an
account
to
generate
a
token
and
then
use
that
for
upload.
So
we
so
any
release
manager
will
need
to
sign
up
for
account
an
account
I'm
wondering
if
it
makes
sense
for
us
to
have
just
one
goober
Nettie's
account
that
we
share
around,
but
I'll
have
to
look
into
it.
But
it's
also
not
a
super
huge
deal,
I'm
wondering
if
this
scratch
pad
should
actually
become
PRS
to
the
repo
or
restore
you
know,
that's
just
a
thought.
A
So
at
least
we
have
it
committed
to
get
history
as
opposed
to
some
Google
Doc
that
not
everyone
knows
about
right.
So
then,
there's
also
rearranging
the
references
to
the
branch
creation
and
jobs
you'll
see
in
the
branch
manager
handbook.
That's
we
mentioned
beta
zero
and
the
branch
creation,
and
then
we
mentioned
beta
1
and
the
other
beta
releases,
but
the
tasks
that
we
care
about
are
actually
here.
A
So
it's
a
little
confusing
to
have
them
down
here,
so
we
should
shift
this
down
and
push
this
stuff
up
right.
So
we're
essentially
at
the
step
where
we're
starting
to
look
at
all
of
the
tasks
that
are
related
to
the
branch
cut
and
to
establishing
CI
and
let's
walk
through
them.
These
PRS
have
been
most
of
them
are
merged
at
this
point,
but
let's
just
talk
about
what
they're
doing
right.
So
let
me
and
any
questions
so
far-
am
I
going
too
fast,
too
slow.
A
Okay,
cool
all
right,
so
you
might
have
noticed.
I
was
working
on
kind
of
a
prototype
of
testing
out
our
testing
out
our
kind
of
build
stage
and
release
flow
on
the
kubernetes
infra
on
the
Cates
infra,
like
CN
CF
sponsored
infra
instead
of
Google
infrastructure.
So
when
I
push
when
I
do
fast-forwards
to
that
branch,
it
will
shout
at
you
in
in
slack
and
the
reason
for
that
is
so
we
have
a
so
this.
The
shout
right
here
and
just
Augustus
did
a
bad
thing,
and
people
almost
always
put
this
alarm
flash
on
it.
A
A
A
A
Okay,
so
under
the
slack
heading
you
can
see
a
configuration
for
merge,
warnings
right
and
merge
warnings
event.
Then
it's
a
it's
a
set
of
repos
repos,
the
channel
to
notify
and
who's
whitelisted
right.
So
you
can
see
the
kate
see
I
bought
Kate
CI,
but
does
a
lot
of
magic
behind
the
scenes.
So
we
don't
want
alerting
on
PR
pushes
and
stuff
like
that.
That
would
get
untenable,
but
you
can
see
for
some
of
these
repos.
You
know
so
enhancements.
Well,
it's
a
p.m.!
A
So
if
someone
pushes
manually
to
that
repo,
we
should
get
an
alert
and
say
p.m.
so
on
and
so
forth.
Right.
The
kubernetes
repo
breaks
out
a
little
further
right.
It
allows
it
allows
the
CI
bought,
as
well
as
the
release
for
about
the
release.
Robot
is
the
token
that's
used
by
a
Naga
which
is
our
release.
Engineering
tool
are
staging
release,
tool
to
authenticate
against
github
and
to
actually
push
tags,
push
releases
right
to
github,
so
you'll
see
within
this.
A
A
In
addition
to
the
patch
release,
managers
they're
also
the
branch
managers
so
Cheryl
Carlos
and
myself
right
and
then
you
can
see.
We
also
have
feature
branches
and
so
for
some
of
the
feature
branches
we've
assigned
like
branch
managers,
so
they're
able
to
maintain
these
branches
without
alerting
people
that
they're
doing
pushes
or
fast
forwards.
What
have
you
and
then
that
prototype
branch
that
was
alerting
us
before
in
the
release
channel
I've
added
a
whitelist
so
that
when
I
push
you
won't
know
about
it.
A
A
A
Well,
no,
not
a
similar
concept,
but
the
config
is
in
the
same
place.
Right
right
here,
so
milestone
apply
er
again,
another
proud
plug-in.
What
it
does
is
it
allows
you
to
apply
a
milestone
after
a
PR
has
merged.
So
this
is
pretty
cool,
because
if
we
for
organization
sake,
if
someone
forgets
to
apply
a
milestone
or
someone
doesn't
have
access
to
apply,
a
milestone,
it'll
ensure
that
a
milestone
gets
applied.
A
So
it's
easier
to
search
easier
to
you
know
to
get
history
on
what
happened
when
right,
so
we
have
a
set
of
so
basically
it.
This
is
the
way
this
is
configured
is
org
repo
branch
and
then
the
name
of
the
the
milestone
to
apply
right,
so
in
kubernetes.
So
you
can
see
each
of
these
are
set
to
117
right
now
in
kubernetes
we
also
have
the
release
branches
and
each
of
them
are
set
to
the
the
appropriate
milestone
right.
A
So
this
needs
to
be
rebased
now
that
the
other
one
has
merged.
But
I'll
do
that
once
code
thought
comes
any
questions
on
that:
okay,
we're
groovin
all
right,
so
the
next
one
is
a
little
bit
more
involved,
which
is
why
I
saved
it
not
super
involved.
Okay,
but
yeah.
It's
helpful
to
understand
what's
happening
here.
A
Then
your
you'll
be
somewhat
familiar
with
this.
Essentially,
what
variance
does
is
it?
It
supplies
a
set
of
variants
right.
These
variants
are
used
as
substitutions
in
a
Google
cloud,
build
run
right
so,
basically,
depending
on
how
you
have
whatever
you
have
configured,
you
can
use
these
as
substitution.
So,
basically,
in
this
case,
you'll
see
that
this
one
is
in
images,
cubic
ins,
e
to
e
/
variance
rate
and
what
it
does
is
it
provides
variations
on
the
way
the
cubic
ins.
Été
image
is
built
right,
so
you
can
see,
for
we
have.
A
So
to
see
how
that
kind
of
ties
in
if
we
take
a
look
at
the
dockerfile
right,
there
are
certain
places
in
the
dockerfile
all
right
so
like
gates
release
that
looks
familiar
right.
The
go
version
right,
so
this
go
version
is
like
okay.
Well,
here's
the
tarball
go
install
this
version
right,
so
you
can
see
that
those
are
eventually
used
in
in
the
docker
file,
but
they're.
Also,
if
we
take
a
look
at
the
and
I
won't
do
too
much
on
the
image
builder,
because
there's
another
there's
another
recording
for
that.
A
Alright,
so
the
image
builder,
so
here's
the
cool
part,
here's
a
important
part.
At
least
it's.
It
might
be
even
better
to
view
this
as
gates
release
test
alright.
So
we
also
have
these
image
pushing
jobs
right
and
the
image
fishing
jobs
do
exactly
what
it
sounds
like.
They
submit
images
to
be
pushed
I,
don't
think
all
of
them
are
here.
This
might
be
yeah.
Those
might
be
in
I
think
the
cubic
ins
one
is
in
the
test
in
for
a
trusted.
Config.
B
A
A
So
each
step
is
a
different
container
right
and
they
are
they're
essentially
layered
into
a
workspace
right.
So
it
considers
workspace,
slash
workspace
to
be
the
root
directory
and
what
it
will
do
is
it'll
persist,
slash
workspace
across
each
of
the
steps
right.
So
what
you
can
do
is
build
a
small
piece
and
then
have
that
have
that
land
in
in
slash
workspace
and
then
move
into
and
move
into,
another
step
that
that
continues
on
that
work.
A
A
Right
so
there's
a
cloud
builders,
repo
that
will
show
you
a
bunch
of
these
pre-built
images
that
you
can
use
from
G
cRIO
cloud
builders,
alright,
so
basil,
curl,
yada,
yada,
yada,
what's
cool
about
those
is
they're
purpose-built
for
doing
exactly
what
the
name
of
the?
What
the
name
of
the
image
is
right,
so
docker
will
run
a
docker
command
as
the
entry
point.
Docker
will
be
the
entry
point
for
that
one
and
so
on
and
so
forth
right.
So
here,
I'm
saying
docker
build
use.
A
We
also
have
this
image
this
images
declaration
here
right
and
what
the
images
declaration
will
do
so
substitution
option
allow
loose,
basically
means
if
a
substitution
is
missing.
Normally,
if
that's
not
said,
if
substitution
is
missing,
it
will
bomb
the
it'll
bomb.
The
Google
cloud
build
run
right.
So
so
too,
sorry
to
answer
your
question.
It
runs
in
multiple
containers.
That's
that's
the
answer.
A
So
what
it
will
also
do
is,
if
you
use
the
docker
image
and
say
that's
by
specifying
images,
you're
saying
that
I
expect
an
artifact
of
this
release
to
be
G
cRIO,
slash
whatever
your
project
name
is
so
whatever
project
name.
You
run
this
cloud,
build
as
whatever
the
get
tag
is,
and
whatever
the
config
is
right.
A
So
there's
also
a
process
that
is
the
image
bumper
I
think
image
bumper,
which
which
basically
go
since
it
runs
a
job
that
goes
into
the
repo
you
see
how
all
of
these
are
the
same
image.
There's
not
a
human
doing
that
there's
a
machine
doing
that,
checking
for
latest
images
and
then
submitting
a
PR
to
bump
each
of
these
search
and
replace
and
bump
those.
A
So
where
was
I
all
right?
So
sorry
did
that
answer
your
question.
Yeah!
No
totally
appreciate
it!
Coco
Coco,
all
right!
So
within
the
cloud
build,
so
we
we
actually
so
within
the
main,
go
right.
You
can
see
that
we're
doing
something
pretty
simple
here:
we're
taking
a
build
directory,
GCV
config
log
directory
scratch
bucket
projects,
whether
or
not
we
allow
dirty
build
for
the
git
repository
to
be
dirty,
whether
or
not
we
want
to
upload
that
source
to
to
GCD
and
whether
or
not
we
want
to
specify
a
specific
variant.
A
If
we
don't
specify
a
variant,
then
all
of
the
variants
we'll
try
to
build
right,
so
it
will
so
we
have.
This
run,
builds
job,
and
so
you
can
see
it's
running
builds
it's
going
to
try
to
get
the
variants.
If
the
variance
are
equal
to
zero,
then
it's
going
to
run
a
single
job
right.
It's
going
to
run
a
single
job
with
whatever
you
specified.
A
It's
a
substitution
and
call
it
a
day
right,
so
you
don't
need
to
supply
the
variance,
but
if
you
do-
and
you
don't
also
supply
the
flag
to
to
choose
just
one
variant,
it
will
run,
it
will
run
all
of
the
variants
which
sometimes
you
want
right.
So
you
can
see
that's
if
you
look
at
some
of
the
tests,
infra
trusted
jobs
or
any
of
the
jobs
really
in
config,
slash
job,
slash
image,
pushing
you
can
see
that
they're
using
they
may
be
using
some
image,
but
they're
also
doing
a
CI
runner.
A
A
A
Which
is
in
that
directory-
and
all
it's
doing
is
running
that
builder
running-
that
builder,
supplying
a
log
directory
which
is
supplied
by
prowl
when
it
runs
the
the
prowl
environment
right
and
then,
if
artifacts
is
not
specified,
then
it
will
just
build
with
the
arguments
that
you
supply
it
right.
So
those
arguments
that
we
saw
on
the
go
script
before
that's
what's
happening
in
the
CI
job,
so
basically
it's
just
running
a
container
to
trigger
a
job
in
GC
B
right.
A
So
the
actual
execution
of
the
job
is
not
happening
on
the
Proud
cluster,
outside
of
the
initial
instantiation
of
that
job,
all
the
processing
is
delegated
for
those
jobs.
All
the
processing
is
delegated
to
delegate
it
to
GC
p
at
that
point
right.
So
that
is
part
of
the
puzzle
right.
So
what
we're
doing
here
is
essentially
removing
the
config
for
113
and
adding
the
one
for
117
now
that
you
understand
all
those
pieces
not
as
complicated.
A
A
Great,
so
here's
a
cloud
bills,
but
it's
purpose-built
for
the
it's
her
purpose-built
for
release
as
opposed
to
doing
image,
image
stuff
right.
So
basically
it's
cloning,
kubernetes
branch
and
the
Rio
and
the
repo
and
then
the
release
repo
doing
a
meet
clean
on
a
see
that
these
are
relative
paths.
These
are
all
relative
to
the
workspace
right.
So
basically,
we're
saying
we're
using
the
the
we're
using
the
workspaces,
essentially
like
your
your
go
path
and
then
moving
into
each
of
these
directories.
To
do
a
make
clean
then
a
make.
A
This
is
a
make
release
in
a
container
and
then
a
release,
push
build
the
push
filled
script.
Alright,
so
the
push
filled
script
is
used
and
then
you
can
see
the
set
of
substitutions
that
we
have
here
great
and
if
I
look
at
the
variants
right,
we
can
see
that
different
variants
are
configured
I
want.
No
mock
I
want
to
send
it
to
a
certain
bucket
I
want
to
send
it
to
a
certain
registry.
I
also
want
to
also
publish
this
file
right.
A
What
I'll
see
is
I'll
see
this
tag
right,
oh
and
this
tag
is
basically
what
a
bunch
of
our
automation
uses
to
key
into
if
you've
ever
seen
like
an
extract
equals
latest
or
something
in
a
in
a
test.
Infra
config.
It's
essentially
trying
to
extract
the
latest
text
that
write
our
latest
one
or
latest
C
latest
one
18
just
popped
up,
because
we
recently
did
the
the
cutover
right.
A
A
The
reason
that's
super
important
is:
if
we,
you
know,
if
I
do
a
quick
search
for
wrong
repo.
If
I
do
a
quick
search
for
extract
equals
right
and
we
can
see
all
of
these
extracts
right
so
like
our
our
info,
require.
You
know
iron
for
relies
heavily
on
this
on
this
piece
existing
right.
If
we
click
into
even
one
of
these
jobs,
we
can
see
that
it's
running
a
scenario,
ete
scenario
right
this
ET
scenario-
is
it
interesting?
A
You
can
take
a
look
at
it
at
your
leisure,
but
essentially
we
have
a
set
of
scenarios
in
test
infra.
The
scenarios
are
basically
packaged
into
bootstrap
and
if
you've
ever
heard
of
bootstrap,
you
know
the
bootstrap
has
been
deprecated
for
a
long
time.
Bootstrap
will
even
tell
you,
while
it's
running,
that
it
is
deprecated
somewhere.
A
To
build,
you
can
see
bootstrap
what
we're
using
to
build
the
cubic
ins
ete
test
the
cubic
in
CTE
image
and
then
that
key
we
can
see
the
e
image
is
used
all
over
the
place
within
testing
for
all
right.
So
a
lot
of
your
jobs
if
you're
running
jobs
on
prowl
are
dependent
on
on
those
two
things
right,
but
the
underlying
image
is
a
thing:
that's
supposed
to
be
deprecated,
alright.
So
what
I
kinda?
What
I
like
about
moving
the
the
build
process?
A
So
there
is
a
prototype,
build
job
right,
so
this
CI
kate's
prototype
build,
is
running
on
the
test
and
for
a
trusted
cluster
right
and
that's
what
I
just
showed
you
this
dis
variance
here
right.
It's
running
the
CI
version,
the
build
CI
version
of
it
right,
so
variants
build,
see,
I,
don't
upload
any
of
the
source
and
point
at
GCD
build
as
your
config
directory
right.
So
you
can
see
that
this
is
located
in
GC
b,
GC
b
builds
cloud
camel
right.
So
that's
where
it's
going
to
go.
A
Look
for
its
artifacts
first
configs
right
for
submitting,
and
what
this
will
eventually
give
us.
Is
you
can
see
it's
checking
out
the
release
repo
and
it's
doing
a
path
alias
of
kate's
release?
Okay,
so
that
io
/
release
this
job
encapsulate
s--
the
same
the
same
stuff
that
we're
doing
in
the
standard
job
kubernetes
CI
kubernetes
build
right,
you
can
see
CI
kubernetes
build
is
using
that
scenario
right
and
the
kubernetes
build
scenario.
A
A
Right
and
if
you
scroll
to
the
bottom
of
kubernetes,
builds
I,
know
I'm
starting
to
go
fast
on
some
of
the
stuff,
but
you've
got
that
make
clean,
make
clean,
make
quick
release,
make
R
or
make
release
and
then
finally
check
the
arguments
and
do
that
run
the
push
build
script
right?
You
can
see
that
the
push
filled
script
by
default
will
be
release,
push
build
sh,
and
then
you
can
see
that
if
we
look
at
the
steps
for
that
cloud,
build
we've
got
the
clone
clone
made
clean,
make
release
and
then
push
build
right.
A
So
we've
replicated
we've
replicated
the
steps
that
were
happening
in
a
deprecated
image
on
something
that
is
essentially
infrastructure
that
we
only
sort
of
have
to
manage
right.
So
this
is
a
net
win
for
us,
and
this
is
also
running
in
the
kubernetes
infrastructure,
the
the
Kate's
infra
and
not
the
Google
infrastructure
right,
so
I'm,
essentially
working
on
prototyping,
a
bunch
of
jobs
for
the
build
stage,
release
process
to
cut
over
all
of
those
processes
to
Kate's
infra.
So
it's
going
well,
if
you
want
to.
A
A
Okay,
so
we
said
we
were
doing,
we
did
the
whitelist.
We
did
the
we
started
on
this
stuff,
the
pretty
submit
jobs
right,
so
we've
updated
the
variants
tamil.
We
have,
then
we
sort
of
skipped
ahead
and
did
the
dashboards,
because
the
dashboards
are
dependent
on
the
branch
being
cut.
We've
run,
this
experiment
prepare
release
branch
basil
command,
which
generates
generates
new
jobs
for
the
release
and
and
then
also
updated
some
of
these
dashboards.
A
A
So
there
was
an
error
from
one
of
the
jobs
was
using
for
per
release,
which
basically
that's
the
annotation-
that
the
release
job
preparer
will
key
into
when
deciding
whether
or
not
to
create
a
job
within
within
the
the
release
branch
jobs
directory
right.
So
let
me
show
you
that
let
me
close
a
few
of
these.
A
A
So
they're
CIP,
which
is
a
container
image
promoter
and
then
there's
these
release
branch
jobs
right,
so
you
can
see
114
and
114
has
a
set
of
jobs.
If
a
job
is
tagged
as
let's
see,
if
we
do
see,
I
can
form
in
siphon
right,
we'll
get
a
few
different
places
right
and
one
of
them
will
be
latest
if
a
job
has
an
annotation
for
per
release.
True,
that
means
that
it'll
be
targeted
to
to
be
forked
when
you
run
the
config
for
worker
right
now.
There
are
a
few.
A
A
So
if
I'm
cutting
for
117
when
I
run
the
config
for
kur,
this
will
essentially
transpose
a
job
that
is
CI,
kubernetes
g
c
e,
conformance
latest
117
and
then
it'll
also
fill
in
117
here.
So,
let's
see
if
it
actually
did
that
right
so
I'd
run
the
config
for
work
and
you
can
see
again
it's
CI,
kubernetes,
GCE
conformance
latest
117
and
then
see
that
fork
per
release.
That
I
forgot
the
annotation
name.
It's
fork
per
release
replacements
right,
so
it
was
CI
latest
here
and
now
it's
CI
latest
117.
A
So
it
did
exactly
what
it
was
supposed
to
right
and
then
you
can
also
see
that
the
image
used
is
cubic
ins,
but
it's
cubic
ins,
117
right
and
cubic
inch.
117
is
coming
from
you
guess
it
that
variance
that
we
merged
in
right
using
the
config
from
here
right,
so
we're
making
sure
that
we
we
regenerate
an
image
that
is
used.
Is
this
purpose-built
for
that
branch
with
a
certain
configuration
and
then
we
make
that
the
components
within
that
image
are
what
they're
supposed
to
be
right.
A
So
that's
why
I
went
into
the
feel
about
the
variants
earlier,
because
it's
important
for
all
of
these
tests,
so
the
if
you're
interested
in
seeing
that
code,
it
is
under
test
infra
experiment
config
for
Kerr
and
config
for
Kerr,
is
essentially
I,
won't
drill
into
it
too
much.
But
I
thought
it
was
a
Python
script,
but
maybe
it's
not
a
Python
script
or
maybe
I'm.
Thinking
of
the.
A
A
Alright,
so
I'll
run
this
experiment
and
prepare
release
branch
we'll
do
prepare
release
py,
which
is
there
right.
So
you
can
see
it's
doing
a
few
things.
It's
going
to
figure
out
what
the
current
version
is.
It's
going
to
kill
the
dead
branch.
It's
going
to
try
to
rotate
some
of
the
file,
the
some
of
the
old
files,
it's
going
to
try
to
fork
the
new
file
and
then
update
the
the
test
config
right.
A
Basically,
what
the
job
configs
will
run
against
to
verify
that
they're
accurate
and
then
try
to
regenerate
some
of
the
files
right.
So
that
happens
in
this
commit
right
and
then
afterwards,
I
ran
its
mirrors,
because
the
117
dashboards
did
not
exist.
So
then
I
create
the
117
dashboards
and
remove
the
113
dashboards.
Those
dashboards
are
sig
release,
/,
test
grids
right,
so
that
is
located
in
config
test
grid
kubernetes,
cig
release,
/
config,
dot,
yeah
Mille
right.
A
Basically,
we
were
defining
a
set,
as
can
dashboard
groups,
dashboard
names
right,
so
you
can
see
all
of
ours
here:
master
blocking
and
forming
one.
You
know
x,
dot
y,
all
blocking
and
informing
the
image
pushes
miscellaneous
publishing,
bot,
release,
notes,
pre
submits
the
prototype
master
blocking,
and
then
I
recently
created
a
new
dashboard
called
job
config
errors,
or
rather
it
exists
in
this
commit,
but
it
doesn't
exist
in
real
life.
Yet,
if
you're
curious
about
the
test
grid
boards
and
specifically
the
cig
release
ones,
you
can
see
them
here
for
those
on
the
call.
A
There
you
go,
but
you
can
see
each
of
those
tabs
that
are
configured
pop
up
here
and
then
you
can.
This
is
essentially
what
the
release
team
is
using
quite
frequently,
especially
a
CI
signal
to
determine
the
health
of
certain
areas
of
the
project,
so
we're
going
to
mosey
on
ahead
and
I.
Think
I
think
that
I
would
like
to
see
this
run
against
CI.
So
we
can
catch
some
things
that
I
might
not
be
doing
directly
or
might
have
missed
so
push.
A
A
A
So
I
expect
one
or
two
things
to
fail
here,
and
this
will
take
a
little
time
to
run
so
I
scheduled
this
for
an
hour,
but
I
have
more
time
if
people
people
are
happy
to
hang
out
while
we
go
through
some
of
this
stuff.
I
want
to
see.
If
there
are
any
questions,
I
know
I've
been
running
through
things.
A
A
All
right
so
I'm
gonna
assign
Catherine
because
she's
seen
some
of
this
stuff
already
yeah
for
sure
and
outside
of
this
I
I
guess
I
guess
I
should
maybe
you
can
just
we
can.
We
can
wrap
it
up
since
we're
at
we
are.
We
are
at
the
top
of
the
hour,
but
let's
go
check
out
the
handbook
one
more
time,
so
you
can
see
afterwards
after
we've
submitted.
This
PR
will
do
the
milestone
of
pliers
that
is
actually
already
merged.
A
A
A
A
Yeah,
so
all
of
yeah,
so
a
lot
of
the
CI
jobs
will
use
like
CI,
Kate's
gates,
beta
so
on
and
so
forth.
So
eventually,
so,
essentially
we
just
try
to
keep
some
of
these
up
to
date,
the
ones
that
are
the
ones
that
our
dev
and
beta,
the
and
latest
those
are
I,
get
ya.
Dev
beta
and
the
stables
actually
are
all
of
the
CI
versions.
Right
they're,
also
like
variants
of
those
like
basil
and
basil,
remote
build
execution,
dot,
txt
and
stuff
like
that.
A
They
just
let
you
know
that
there's
a
certain
variant
of
the
build
that
was
run
in
a
specific
way.
I
was
I,
ran
it
in
basil.
I
ran
it.
You
know
in
basil,
using
remote,
build
execution
or
right.
We
also
have
the
the
the
release
versions
right.
So
the
release
versions
are
the
latest
and
stable
ones,
so
so
latest
cftc
are
stable,
dot
txt
are
are
either
one
of
those
x
dot
y
will
give
you
the
latest
tag
or
the
stable
tag
for
one
of
the
releases.
That's
in
support,
depending
on
what
you
choose
right.
A
So
the
merge
automation
that
doesn't
come
till
later,
yeah,
okay,
so
I
think
at
this
point,
once
we
land
that
PR
there
are
some
announcement
things
that
are
it's
kind
of
the
there's.
Nothing
super
exciting
about
the
announcements
outside
of
getting
people
hype
that
a
new
version
of
kubernetes
is
out
right.
You
can
see
within
the.