►
From YouTube: Kubernetes 1.17.0-alpha.3 release
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,
everyone
today
is
October
22nd.
This
is
a
special
edition.
Release
call
it'll,
be
a
live
cut
of
a
kubernetes
alpha
release
for
117,
so
it's
a
117
alpha
3
release.
This
is
a
call
that
will
be
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
just
in
general,
be
awesome
people,
so
we're
gonna
have
Marco
work
on
the
release
today
and
we've
been
going
through
a
few
of
the
steps
in
the
background
to
prep.
B
Okay,
so
what
we
have
first
done
at
the
beginning
of
the
day,
I
can
create
an
issue
for
release,
cut
and
I
have
tried
to
run
the
mockery
of
the
stage
and
we
encountered
some
problem.
First,
we
had
the
problem
that
occupation
was
not
as
expected
and
stiphu
manager
to
fix
the
end,
build
a
new
image
and
the
mob
field
has
we
restarted
the
mock
stage
and
it
seems
to
pass
these
checks.
It
usually
takes
plenty
of
times,
so
we
will
see
how
it
goes
and
I
have
created
a
screenshot
of
boards.
B
There
was
some
problem
with
the
screenshots
tool
because
it
refused
to
upload
to
the
sub
server,
but
I
can
to
change
the
script
by
copying
the
file
from
some
temporary
to
not
April
location
and
applauding
it
manually
we
have
several
jobs
running
fail
in
gusik
release
master
informing
dashboard.
It
is
this:
a
cost
master,
Syrio
master,
slow,
GC,
mastered
skill
correctness,
GC
master
scale,
performance
in
GC
windows
master,
and
if
you
open
the
each
here
github,
you
will
see
the
screenshot
of
what
is
exactly
failing.
So
this
is
something
we
have
done
so
far.
B
A
B
So,
to
start
from
the
beginning,
it
here
is
the
branch
management
book
I
feel
sharing
just
want
to
see.
Is
it
possible?
For
me
it
is
okay,
so
it
first
explains
some
general
requirements,
and
now
we
have
some
things
that
we
had
to
do
at
the
beginning.
The
first
one
was
to
get
the
recipe
from
Isha's
and
I
have
got
that
at
the
beginning
of
the
day
was
different,
and
then
this
one
there
is
a
problem
with
kubernetes
announced
and
probably
the
permission
about
the
of
that
mailing
list.
So
we
are
going
to
see.
B
How
are
we
going
to
handle
that
when
we
come
to
this
part
machine
setup,
it
is
aquaria
to
have
the
linux
machine,
and
I
have
found
out
that
you
must
have
fedora
or
a
boot
to
machine
like
it
is
not
going
to
work
with
our
tree
notes.
It
is
not
going
to
pass
the
prerequisites
checks,
so
I
believe
I
update
that
at
some
point,
and
so.
A
B
B
What
we
have
here
is
the
release
repository.
It
is
github
kubernetes
release
to
use
the
screen
that
is
running
all
the
stuff.
It
is
called
GC,
b
MGR
and
to
use
it
first,
you
need
to
clone
the
repository
and
you
must
clone
it
to
see
the
HTTP
endpoint,
because
if
you
use
each
protocol
here,
the
check
is
not
going
to
pass
and
we
are
going
to
run
the
tool.
If
you
run
without
any
arguments,
it
is
just
going
to
run
safety
checks
and
it
is
going
wait
Whitefield
now,
because.
A
B
But
it
is
very
shiny.
Okay,
there
were
some
changes
and
yeah.
If
you
get
this
such
message,
it
says
around
it
falls.
So
maybe
something
change
it.
Maybe
you
have
changed
something,
or
maybe
something
on
change
about
the
upstream,
so
it
is
going
to
add
some
checks.
It
is
going
to
Green,
okay
sandblast
five
jobs,
which
means
that
it
should
be
safe
to
run
the
process,
how
it
goes
on
next,
alright,.
A
B
B
A
So
that
Shack
is
basically
comparison
between
your
between
the
upstream
remote
and
your
local
copy
right.
So,
as
people
just
saw,
if
you
have
an
issue
or
new
changes
in
the
repo
that
you
haven't
pulled
in
yet
the
tool
will
not
allow
you
to
run
it.
There
is
a
there's
a
way
to
work
around
that
there's
a
release
tool
repo,
as
well
as
a
release,
tool,
ranch
environment
variables
that
you
can
use
to
specify
the
repo
in
the
branch.
A
So
you
can
still
what
you
could
do
is
say:
you're
testing
out
changes
and
you
want
to
that.
Haven't
emerged
yet,
and
you
have
access
to
GCP
to
test
them
out.
You
can
use
those
environment
variables
to
to
try
them
out
before
you
before
the
pr
is
merged
right,
so
then
yeah.
So
then
you
would
essentially
point
to
your
your
remote
and
and
the
branch
that
you
were
your
your
PRS
against
to
try
those
changes
at.
B
Okay,
so
after
that
I
guess
we
can
continue.
The
next
step
is
usually
after
you
run
the
safety
track.
Is
this
one
also
required
you
to
have
Google
Cloud
SDK
at
1g
called
in
it?
Basically,
it
will.
When
you
run
that
command.
It
will
show
you
to
log
in
page
for
Google
account,
and
if
you
want
to
check
the
version,
you
can
run
check
out
version
on
their
website.
It
is
going
to
be
the
same
one,
so
you
noticed
phone
is
recommended
before
running
the
process
and
after
that
safety
track
that
we
have
run
we.
B
This
is
some
general
recommendations.
We
have
already
created
the
issue.
I
have
shown
it
at
the
beginning
of
the
meeting
and
we
are
going
to
need
this
for
later.
This
one
has
the
format
how
we
should
post
the
comment
with
comments
at
how
much
it
took,
and
then
we
are
at
the
alpha
release
and
the
alpha
stage.
A
B
A
B
When
you
run
the
command
from
here,
it
is
going
to
show
you
this
URL
that
you
can
paste
in
your
browser
and
seen
now.
This
is
requiring
permissions,
but
if
you're
cutting
the
release,
you
will
be
able
to
see
it.
He
says
that
it
is
in
progress.
Is
some
information
about
that
and
we
have
rocks
here
so
in
the
beginning
it
is
pulling
the
needed
images
and
after
that
is
done,
we
have
so.
A
B
A
A
A
A
A
A
Now
you
can
see
there's
a
version
file
here
at
version
1
112
12-1.
So
what
this
is
is
basically
it's
a
it's
a
divert
its
pointing
to
the
version
of
NGO
that
we're
using
right
and
and
the
reason
we're
doing.
This
is
the
reason
we're
basing
our
some
of
our
stuff
on
this
image
is
because
we
want
to
make
sure
that
we're
trying
to
stage
and
release
the
artifacts
using
the
same
version
that
the
kubernetes
kubernetes
repo
is
using
right.
A
So
going
back
here.
If
we
take
a
look
at
GCB
manager,
again
all
right,
so
assuming
that
and
then
it's
using
and
then
it's
going
for
the
submitted
function
right
and
submit
it,
it's
going
to
do
a
few
things
right
submit
it,
and
so
these
substitutions
this
local
variable
here,
if
you're
familiar
with
google
cloud
build
right,
I
don't
need
so
many
g-cloud
build,
submit.
A
Right
so
I
mean
here's,
the
here's,
the
help
for
google
google
cloud
build
submit
and
if
you
just
go
down
you'll
see
that's
right,
so
substitutions
parameters
to
be
substituted
in
the
build
specification
right.
So
if
you
were
to
submit
this
job
yourself,
you
would
have
to
go.
Google
cloud
build,
submit
and
use
the
correct,
config
and
then
set
up.
These
substitutions
substitutions
are
basically
variables
that
are
subbed
in
for
the
google
cloud
build
and
so
so
variables
that
are
present
in
a
Google
cloud.
A
Build
need
to
be
prepended
with
a
underscore
right
that
lets
that
less
GCB
know
that
it's
a
user-specified
variable
right,
but
you
can
see
that
this
can
get
depending
on
how
many
variables
you
have.
This
can
get
kind
of
hairy
right,
so
favorite,
color,
blue
number
of
candy
is
ten
blah
blah
blah
blah
blah
right.
A
So
what
we
want
to
do
instead
is
basically
seed.
The
set
of
substitutions
you
can
see
that
there
are
a
bunch
of
them
right
whether
or
not
we're
using
an
official
tag,
whether
or
not
it's
an
omok
release,
whether
or
not
it's
an
RC,
and
then
we're
just
doing
some
additions
right
to
that
string.
So
the
build
point,
the
GCP
user
tag,
whether
or
not
to
build
a
head
and
what
the
cube
cross
version
is
and
then
more
stuff
right
release.
So
imagine
typing
this
all
out
on
the
command
line.
That's
not
pretty
right!
A
A
Yeah
the
am
will
file.
Where
is
that,
anyhow,
the
llamo
file
there?
There
are
a
few
different
llamo
files
to
look
at
we'll
look
at
the
stage
one
first,
it
sets
disk
size
as
well
as
passing
in
the
substitutions
that
we
said
earlier
right
and
then
the
log
echoes
are
essentially
runs
that
will
write
to
standard
out
as
well
as
to
a
log
file
and
the
log
files
are
viewable
later
in
GCS,
right
or
Google
Cloud
Storage
right,
and
then
it
tells
you
after
you
do
the
submission
exactly
where
to
look.
A
You
can
look
at
the
specific,
build
that
you're
running
at
that
point
or
you
can
use
the
G
cloud
command
to
do,
builds
log
stream
right
for
that
build
ID,
and
then
we'll
also
give
you
a
link
for
that
bill
for
where
the
build
is
happening
right.
So
that
is
that
will
resolve
to
this
link
right
of
the
running,
build
right
now
for
the
stage
you'll
see
where
all
of
these
substitutions
kind
of
come
into
play.
A
So
we
have
a
directory
here
that
is
GCP,
so
k
release
/g
CB,
and
you
can
see
that
there
are
a
few
different
GCB
configs
here,
build
release
and
stage
the
variance
yeah
Mille
is
used.
I
talked
about
this
briefly
on
an
another,
rather
sig
release
or
a
release.
Engineering
call
around
using
the
image
builder.
So
I
won't
go
into
details
here,
but
build
say
stage
and
release
are
the
ones
that
we
care
about
right.
A
So,
within
the
stage
one
a
few
things
going
on
secrets
are
set
right,
so
everyone
freaks
out
a
little
bit
about
this
token
being
in
here.
The
token
is
basics,
before
it's
a
base64
encoded
encrypted
blob
right.
The
encryption
key
for
that
blob
is
only
stored
in
kms
and
Google
DCP
kms
right
so
I've
added
a
note
here
to
say:
don't
freak
out
about
seeing
this
here,
it's
okay!
A
Now
we
can
also
see
translating
kind
of
from
the
from
the
build
steps
that
you
can
see
in
the
GUI.
Compared
to
what
it
looks
like
in
in
a
build
config
file
right,
you
can
see
step.
The
name
of
the
step
is
essentially
the
image
that
you're
going
to
use
right,
so
this
one
says
we're
going
to
use
to
get
cloud
builder
with
this
directory
right
notice
that
the
directory
is
doesn't
have
a
slash
in
front
of
it.
It
is
relative
to
the
workspace
directory
right
within
GCD.
A
The
workspace
directory
is
is
the
directory
that
persists
artifacts
right.
So,
if
you
specify
a
directory
that
is
relative
to
it,
it
means
that
these
artifacts,
that
you,
that
are
their
artifacts,
that
are
created
from
any
release
step,
will
get
persisted
across
the
next
one
right.
So
the
first
thing
we're
doing
is
we're
cloning,
we're
cloning,
the
release
tool,
repo,
so
we're
cloning
K
release
right.
A
The
next
thing
that
we're
doing
is
we're
using
this
q
cross
version
where
we're
using
this
image,
that's
specified
by
the
cube
cross
version,
which
is
which
is
apparently
not
set
here,
but
set
in
GC
B
instead
right.
So
this
is
one
of
the
EC
that
this
has
an
underscore
here.
That's
one
of
the
substitutions
that
are
submitted
before
the
build
is
actually
is
actually
run
right.
A
So
it's
saying,
let's
go
into:
let's
go
into
the
K
release
directory
set
these
environment
variables
and
do
then
do
a
compile,
release
tools
right
so
compile
release
tools
will,
as
the
name
implies,
compile
the
release
tools.
So
it
will
do
a
check
just
to
make
sure
you
have
the
correct
dependencies
in
place.
They'll
set
up
the
environment,
making
sure
that
the
the
go
binaries
path
is
set
in
your
in
your
actual
path
right
and
then
it
will.
It
will
compile
the
blocking
test
grids
test
right,
so
the
this
is
essentially
used
to
verify.
A
If,
if
you
don't
specify
a
build
with
build
at
head,
it
will
attempt
to
find
a
green
build
right.
So
it'll
look
for
master
it'll,
look
at
master
blocking
and
try
to
discern
if
there
is
a
green
build
and
then
use
use
that
built
to
use
that
Chau
to
to
do
the
staging
right
here,
we're
using
Bill
that
head
we're
probably
going
to
remove
the
functionality
here,
because
the
way
that
we
pull
the
build
numbers
is
going
to
change
very
soon.
But
that
is
a
story
for
a
different
time.
A
So
going
back
to
the
stage
we
can
see
that
the
next
step
is:
let's
pull
the
K
release
cloud
builder:
let's
go
back
into
that
release
directory
using
that
token
that
we
set
above
right.
So
this
is
a
token
for
the
release
bot
and
which
is
just
a
github
user
that
has
access
to
do
the
github
user.
That
is
part
of
the
release
managers,
github
team,
which
allows
it
to
to
write
to
github
and
more
specifically,
push
a
new
release
to
github
right.
A
So
eventually
we're
going
to
want
to
say
that
okay,
the
stage
was
successful.
Let's
release
this
thing
and
make
sure
that
it's
tagged
and
that
bot
will
be
responsible
for
doing
that
right.
So
we're
running
the
Onaga
tool
with
the
release
branch,
we're
saying
that
it's
a
stage
and
a
pre
build
whether
or
not
to
build
it
head.
So
if
these
are,
if
these
substitutions
are
specified
it
will
it
will,
it
will
drop
in
a
command
line
flag
right,
if
not
it'll
just
be
blank
right.
A
No
mock
official
build
so
at
different
stages,
it'll
discern
whether
or
not
your
this
is
an
official
build,
whether
or
not
you're
doing
an
RC
or
whether
you're
using
a
buildin.
Right,
yes,
means,
let's
any
prompts
any
user
prompts.
Let's
enter
yes
to
them,
so
that
we
can
run
it
in
an
automated
fashion.
Gcb
lets
it
know
that
it
is
running
within
GCB
as
opposed
to
locally,
because
you
can
also
use
this
to
run
locally.
A
If
you
wanted
to
using
just
this
an
AA
go
command
right
and
then,
where
we're
starting
off,
that
base
directory,
that
I
mentioned
to
workspace
and
then
where
the
temp
directory
is
going
to
be
right
so
again,
we're
making
sure
that
this
temp
directory
persists
across
the
releases
right
now
we're
using
a
cube
cross
local
image
that
was
built
within
this
step
and
then
we're
doing
a
build
only
right.
So
this
is
pre
build.
A
We'll
do
the
release
itself
right
so
releasing
those
artifacts
removing
those
artifacts
from
the
staging
area
into
release
buckets
that
people
can
actually
access
right.
So
that
is
the
some
of
the
overview
of
some
of
these
tools.
There's
lots
of
hidey
holes
and
scary
bits
of
some
of
this
stuff.
For
example.
Nago
is
a.
A
Naga
is
a
in
eighteen
hundred
and
sixty-eight
line
bash
script
right
which,
if
we
look
up
here,
you
can
also
see
that
it's
importing
three
other
pass
scripts
right,
that
our
bash
libraries
that
do
a
lot
of
the
so
common
does
a
lot
of
the
things
like.
Let's
validate.
Let's
validate
that
you
have
the
correct
amount
of
arguments
or
let's
do
a
common
exit,
so
it'll
kind
of
wrap,
an
exit
code
as
well
as
an
error
message.
A
So
common
we'll
do
some
of
that
stuff
and
then
get
lib,
as
the
name
implies,
has
a
bunch
of
functions
around
handling,
git
commands
and
then
release.
Lib
has
a
bunch
of
functions
around
manipulating
artifacts
within
GCP
right.
So,
let's
go
back
to
I
was
hoping
that
by
the
time
I
was
done
talking.
This
would
be
done,
but
it's
still
going.
B
A
A
Yes,
so
when
so,
the
reason
for
that
it,
the
the
median
is,
is
closer
to
like
45
52
minutes
right
there,
the
reason
for
the
longer
build
as
we
approach.
So
this
is
the
final
alpha
build
as
we
approach
the
the
the
only
one
that
takes
the
one
that
takes
the
longest
is
the
beta,
zero
right
and
the
reason
for
the
the
beta
zero
taking
longer
is
it's
doing
two
things
right,
it's
cutting
in
alpha
as
well
as
a
beta
right.
A
B
B
B
B
If
you
don't
like
the
UI
and
once
this
is
done,
he
the
next
thing
we
are
going
to
do
after
stage
is
release,
and
this
is
basically
to
build
your
stuff
and
then
to
push
the
artifacts
once
done,
but
first
we're
running
the
mock
stage
and
we
will
probably
run
amok
release
too
after
we
confirm
that
everything
works.
We
are
going
to
run,
nan
mark
builds
for
stage
and
for
release,
and
then
you
should
have
the
release.
B
I
guess
that
process
is
going
to
take
a
little
bit
more
time.
So
B
we
have
our
find
like
few
hours,
and
how
is
this
going
to
look
like
then?
The
previous
comment
is
the
early
stage.
It
should
output
the
comment
such
as
this
one.
It
is
going
to
contain
the
build
version
and,
as
we
know,
we
are
going
to
run
that
one.
It
is
going
to
do
the
release
process
and,
after
the
most
part
is
done.
A
Right
so
I'm
gonna
steal
the
screen
again
and
I
said
what
I
want
to
try
to
do
is
okay,
so
today,
so
first
answer
the
questions
about
the
go
rewrite
its
yes,
fun,
I
think
is
a
word
for
it.
It's
going
to
be
hard
right
and
yes,
Daniel
and
a
few
others
that
have
expressed
interest.
You
can
feel
free
to
have
at
it.
I
just
need
to
make
sure
that
people
go
about
it.
The
right
way.
There
I
have
an
active
PR
open.
If
you
want
to
look
at
it
is.
B
A
A
A
A
A
A
So
the
bootstrap
image
by
default
has
like
a
CI
runner.
The
CI
runner
points
to
a
CI
runner
takes
a
few
arguments.
It's
basically
saying
I
want
you
to
check
out
the
kubernetes
repo
first
and
use
this
as
your
primary
workspace
I
want
you
to
then
check
out
the
release.
Repo
I
want
you
to
use,
go
slash
source
as
the
root
of
this
workspace,
there's
a
timeout
of
two
minutes
and
then
to
run
a
scenario
right.
A
So
this
is
stuff
that
people
usually
never
see
the
scenario
kubernetes
build
and
then
we're
going
to
pass
some
arguments
to
that
scenario
right.
So
it's
a
loud
OOP
extra
publish
file
case,
master,
I
per
cube
and
registry
right
now.
If
we
go
over
to
the
scenario
itself
right,
it
takes
a
little
while
to
do
the
do
the
investigation
to
figure
out
where
all
these
things
live.
But
if
you,
if
you
want
to
read
more
about
it,
I'm
gonna
speed
over
it.
A
A
It's
actually
something
that,
like
it's,
it's
confusing
and
basically
what
happened
is
we
made
some
changes
to
some
of
the
release
tooling,
which
broke
builds
across
all
of
kubernetes,
which
we
had
to.
We
had
to
revert
some
of
those
changes,
but
digging
into
it.
I
think
not
enough.
People
know
where
all
of
the
places
to
go
to
find
information
on
some
of
these
things
are
so
I
figured
writing
it
up
would
be
a
good
thing,
so
I
walk
through
some
of
the
the
test
failures
that
happen
and
then
explaining
actually
what
the
job
does
right.
A
So
the
push
filled
script
is
in
the
release,
repo,
and
you
can
see
it's
doing
a
few
things
like
checking
the
release
bucket,
just
staging
their
artifacts
locally
hashing,
all
of
those
artifacts
pushing
the
artifacts.
If,
if
we
specify
a
registry
it'll,
do
a
docker
build
and
then
release
those
artifacts,
those
container
images
to
that
registry
and
then
finally
publish
the
versions
and
yeah,
there's
there's
quite
a
bit
of
stuff
there,
so
that
so
because
this
is
so
hard
to
kind
of
nail
down.
A
What
I
wanted
to
do
was
write,
something
that
will
kind
of
mimic
the
flow
that
we're
doing
here
with
the
GCB
manager,
but
without
GCB
manager,
so
that
build
that
yeah
mole.
That's
in
there.
This
just
got
merged.
Essentially
it's
doing
the
clone
of
the
Chi
repos
kubernetes,
and
then
the
release
repo,
doing
the
make
clean,
make
release
in
a
container
and
then
doing
push
build
right.
So
push
builds
push
build
is
in
this
repo.
If
you
want
to
check
it
out
here
and
again,
another
long
script
are
it's
not
too
bad.
A
That
essentially
does
some
of
the
steps
I
I
mentioned,
so
checking
prerequisites.
Doing
copies
of
the
release
artifacts
and
then
pushing
docker
images
if
that
flag
is
specified
right.
So
what
was
the
reason
for
me
saying
all
this
stuff
to
explain
these
failures
right?
So
a
bunch
of
these
are
me
just
kind
of
vetting
out
the
process,
but
we
what
we
care
about
since
this.
A
A
A
A
If
we
go
speed
through
the
logs
you'll
see
that
comment
that
marco
pointed
to
before
and
after
the
push
binary
releases
portion,
let's
see
it
gives
you
an
instruction,
here's
here's
what
you
can
do
if
you
want
actually
release
and
I,
don't
know
so
you
can
see
that,
but
here's
what
you
can
do
if
you
actually
want
to
release
that
version
right.
So
that's
that's!
What's
in
the
that's,
essentially,
what's
in
the
documentation.
B
B
About
flags
here
reflects
use
it
for
the
release
comment.
It
seems
like
you,
Commissioner.
There
is
like
official
flag,
but
it
seems
so
I
keep
it
for
official
release
that
I
I
think
I
can't
see,
need
for
better
tool.
Is
it
something
we
only
going
to
use
for
alpha
or
no?
When
is
it
use
it
exactly?
It's.
A
C
A
Yeah
so
I
mean
the,
and-
and
really
you
know
we
have
to.
There
are
a
few
things
that
we
have
to
do.
We
have
to
figure
out
what
the
structure
of
this
role
actually
looks,
like
the
reason
that
I
brought
a
lot
of
you
on
specifically
people
who
have
been
on
the
release
team
before
as
release
manager.
Associates
is
because
I
rescue
you
have
done
the
work
for
quite
a
few
sessions
of
understanding,
at
least
how
cig
release
works.
A
A
So
it's
a
lot
of
it
is
exploration
some
of
this
I'm
learning
on
the
fly
as
well.
So
the
hope
is
that
the
people
that
are
part
of
this
role
will
be
like
hey
I
noticed
this
is
broken.
Can
I
go
fix
it
like?
Yes?
Yes,
you
can
that's
exactly
why
I
want
you
working
on
this,
so
more
stuff
forthcoming
in
terms
of
of
write-ups
and
and
maybe
more
of
these
sessions,
but
for
now
just
start
looking
around
the
repos
see
see
what's
broken,
see
if
someone's
working
on
it
and
go
to
work.
A
A
All
right,
so
these
are
staging
essentially
staging
images
right,
but
we
do
use
the
kate's
cloud
builder
to
run
the
staging
and
release
process.
The
staging
and
release
GCB
runs
right,
so
the
problem
that
marco
was
mentioning
earlier
is
that
we
have
a
as
you
can
see.
We
have
a
few
images
that
are
oh,
this
is
weird
okay.
We
have
a
few
images
that
are
kind
of
old
right.
You
see
that
you
know
summer
from
2017
2018.
A
The
image
that
we
were
using
was
actually
from
2018
September
4th.
It
looks
like
people
were
updating
the,
and
this
is
the
kind
of
thing
that's
like
you
only
know
it
because
you've
run
into
it
and
it
might
not
be
documented
yet
right.
So
one
of
those
things
are
that
there
was
a
there
was
an
image
around
September
or
fourth
or
7th.
This
actually
might
be
the
right
one
where
that
one
was
tagged
as
latest
since
the
since
we're
using
the
same
image
and
it's
wired
into
the
image
pushing
process
in
testan.
A
For
essentially
when
those
images
get
pushed,
we
can
see
a
cloud
build
yeah
Mille
here
right
when
those
images
get
pushed
we're
using
kind
of
like
a
docker
tag,
variant
which
is
like
the
version,
the
year-month-day
plus
G
and
the
hash
right.
So
you
can
see
that
here
right.
This
tag
will
be
so
the
the
release
repo
is
currently
at
0,
1
3
right
and
this
will
be
like
a
build
number
+,
G
+,
a
short
hash.
A
A
Sorry,
the
old,
the
old
newest
one
was
not
the
latest
and
it
was
and,
like
I,
think,
a
previous
old
one
was
used
being
used
as
the
latest
tag
for
the
stage
stage
and
releases
right,
so
we're
running
into
basically
issues,
because
no
one
has
tried
to
touch
these
images
in
a
year
right.
So
I
held
off
on
I,
held
off
on
merging
the.
A
One
of
these
PRS
because
we
recently
had
a
set
of
releases
I
think
was
last
Thursday
or
so
we
cut
four
releases
and
I
didn't
want
this
issue
to
to
be
a
problem,
and
apparently
it
is
now
a
problem.
So
if
you
want
to
check
out
this
issue,
I
walk
you
through.
Basically
how
we're
going
about
building
the
new
images
as
well
as
you
can
see
kind
of
exactly
how
it's
set
up
the
variants
file
right.
So
it's
passing
in
the
substitutions
that
we
were
talking
about
earlier
in
a
slightly
different
manner.
A
So
it's
circumventing
it's
using
this
variants
file
to
circumvent
the
GCB
manager,
which
eventually,
what
I
would
love
to
see,
is
all
of
the
variants
moved
into
this
variants,
IMO
file
and
not
using
GCB
manager
at
all
right.
So
you
can
see
there
are
quite
a
bit
of
additions
to
this
docker
file
to
add
G
clouds,
add
docker
and
to
update
some
of
the
Python
dependencies.
A
A
This
is
push
build,
publish,
okay,
this
one
is
no.
This
is
not
the
right
one.
This
is
the
one
we
care
about
all
right,
so
it
will
so
the.
A
A
A
A
A
Right,
so
it's
telling
me
that
you
know
I
do
not
have
I,
do
not
have
the
get
I,
don't
have
get
access
on
this
bucket
right
and
the
reason
for
that
is
because
we
want
to
protect
those
assets
right.
So
even
I
don't
have
access
to
kubernetes
release,
which
is
the
official
bucket,
so
it
makes
it
kind
of
hard
to
it
makes
kind
of
hard
to
figure
out.
A
A
A
Said
remember:
I
said
that
a
nago
will
a
my
I'm
gonna
run
out
of
screen
here:
yeah,
okay,
all
right.
So
basically
the
logs
its
it
was
saying
that
the
logs
are
too
long
to
display
logs
are
true
large
to
be
fully
displayed
on
this
page
right,
which
means
that
if
I
wasn't
running
the
tale
I
would
have
lost
what
was
going
on
right
and
what
was
going
on
is
here.
A
The
positions
of
the
tower
arguments
right
so
I'm
just
going
to
grab
that
error
message
before
I,
lose
it
and
yeah.
So
it's
saying
the
following:
options:
use
after
any
non
optional
arguments
and
archive
or
create
or
update
mode.
These
are
positional
and
only
effect
argument
follow
them.
Please
arrange
them
properly
right
so
somewhere.
Somehow
this
happened
right,
and
this
happens
in
trying
to
remember
exactly
where
this
is.
If
we
take
a
look
at.
A
B
A
A
Okay,
all
right
so
yeah,
one
of
the
things
to
note
about
the
release
process
is
its
I
mean
the
the
whole
point
of
us.
Putting
it
into
GCB
is
so
that
it
can
be
semi
unattended
right.
So
when
we
have
calls
like
this
there's
a
lot
of
waiting
and
nothing
happening
right,
you
notice
that
we
kind
of
like
we
stared
at
the
bill
of
a
few
times
after
you
run
that
GCB
after
you
run
that
GCV
stage
command,
it's
okay
go
grab
a
cup
of
coffee,
maybe
grab
something
to
need.
A
You
know
check
out
your
emails
come
back,
see
if
the
thing
is
done,
so
it's
not
something
that
we
necessarily
need
to
do
synchronously
for
these
calls.
These
calls
are
really
about
just
asking
questions
to
understand
a
little
bit
more
about
the
process.
So
if
you
were
to
go
through
the
process
and
to
end
doing
I'm
doing
the
mocks
for
each
stage
stage,
so
it
would
be
a
mock
stage,
it
would
be
a
mock
release
and
then
the
actual
stage
and
the
actual
release
and
then
release
notifications
and
all
that
stuff
right.
A
If
you
go
through
that
process
right,
so
we
said
about
45
plus
minutes
for
the
staging
bit
right,
so
we're
looking
at
an
hour
and
a
half
between
the
mock
and
the
actual
stage
right
plus,
let's
give
it.
You
know
another
thirty
minutes
for
each
of
the
release
sides,
although
it's
closer
to
20
right.
So
that's
you
know,
you're
looking
at
two
and
a
half
hours
right.
So
again,
these
calls
are.
These
calls
are
not
for
people
to
sit
on
for
two
and
a
half
hours
to
see
how
the
process
is
going.
A
It's
kind
of
a
thing
that
we
we
shoot
off
into
the
cloud
and
we
come.
We
come
back
and
check
eventually,
so
we're
obviously
not
done
with
the
the
alpha
for
today.
What
we've
done
in
the
past
for
recorded
releases
is
to
have
multiple
sessions.
I,
don't
think
we
need
to
do
that,
since
there
are
already
multiple
sessions
of
recorded
releases
out
there
today.
C
B
A
Yeah
then
back
over
to
you.
I'll
be
I'll,
be
poking
at
stuff.
In
the
background,
so
you'll
see
you'll
see,
builds
running
in
the
background
as
well,
because
I'm
working
on
some
other
stuff
but
yeah
once
that's
I
mean
once
I
push
a
PR
for
that
you
can
and
and
we
get
that
merged,
you
can
proceed.
It's
funny.