►
From YouTube: Kubernetes KubeBuilder Meeting 20201105
Description
KubeBuilder Meeting for 2020/11/05. See https://sigs.k8s.io/kubebuilder for more details.
A
A
B
B
B
All
right
so,
what's
going
on
is
we
want
to
add:
support
for
server
side
apply
in
kubernetes
client
go
implementation
which
really
doesn't
have
apply
right
now.
The
only
way
that
you
can
call
apply
right
now
is,
if
you
use
the
untyped
client
and
you
provide
a
byte
array
of
whatever
you
want
to
apply.
B
So
what
I'm
going
to
be
doing
is
discussing
some
options
on
how
to
how
we
would
support
that
just
for
reference,
that's
what
plain
old
ghost
trucks
look
like.
I
think
we're
all
pretty
familiar
with
that
on
the
left.
You
have
what
the
structs
would
look
like
for,
like
a
kubernetes
native
type
on
the
right
is
the
corresponding
yaml
I'll,
be
showing
some
other
slides
of
other
examples
in
the
same
format.
B
So
why
can't?
We
just
use
the
ghost
structures
they
exist
today.
So
there's
a
key
problem
which
is
in
apply.
You
only
send
the
fields
that
you
want
to
own,
so
ghost
trucks
don't
work
for
that
because
they
have
non-optional
like
non-pointer
field
values.
That
will
that
go
will
zero
value
in.
If
you
don't
provide
anything
they're,
actually
not
that
uncommon.
I
did
a
little
audit
there's
a
ton
of
required
boolean
fields
all
over
the
place
that
cause
problems.
B
So
it
looks
like
this
would
almost
work
and
it
would
kind
of
seem
to
work,
but
then,
if
you
actually
get
into
the
nitty-gritty
and
start
using
it
for
real
for
real
stuff
you're
going
to
run
into
really
weird
corner
cases
where
you
accidentally
took
ownership
of
fields
that
you
didn't
intend
to
and
maybe
even
set
them
to
values
that
you
didn't
want
to.
So
it's
it's
a
little
dangerous
to
go
down
that
path.
B
B
Basically,
what
you
do
is
you
say:
I'm
going
to
create
a
deployment
type
by
calling
a
deployment
function,
and
then
you
just
chain
calls
to
set
various
values
for
that.
It
still
corresponds
the
line
by
line
one
to
one
with
what
we
had
in
the
go
struct
but
you're
using
functions
to
do
everything
if
peop
people
have
probably
seen
this
in
other
programming
languages,
it's
pretty.
It
looks
very
java
like
because
of
all
the
set
calls.
B
This
also
has
some
really
nasty
quirks,
so
this
one
it
actually
works,
not
so
bad
when
you're,
when
you're
referencing
other
structs,
you
just
have
to
put
an
ampersand
in
front
of
all
of
them
now,
but
with
primitive
literals
go
is
not
quite
as
nice,
and
so,
if
you
don't
get
any
utility
support,
you
would
have
to
like
define
the
strings
elsewhere,
and
actually
I
did
this
wrong.
Then
you'd
have
to
put
ampersands
in
front
of
each
of
them,
so
you
would
actually
have
to
have
one
of
these
everywhere.
B
I
am
currently
favoring
the
builder's
approach.
I
am
not
in
love
with
either
of
these
approaches,
but
I
will
at
least
make
an
argument
for
it.
So
I
think
I
think,
having
to
construct
the
pointers
for
pretty
mobile
literals
is
actually
really
inconvenient
and
there's
one
advantage
to
the
builders
which
is
functions
can
be
part
of
an
interface
and
because
we're
defining
a
new
representation
of
our
types.
B
We're
now
going
to
have
two
representations
of
those
types.
So
there
is
actually
potential
usefulness
to
having
an
interface
that
they
both
share,
and
you
could
do
that
right.
You
could
have
a
ghost
truck
that
also
implements
the
set
function.
There's
nothing
preventing
you
from
doing
that,
and
then
you
could
have
an
interface
that
both
these
apply
types
have
and
that
the
that
the
the
usual
structs
that
you
typically
use
for,
update
and
create
and
so
forth,
also
use.
So
there
are
there
is
that
potential
upside
now
on
the
kubernetes
go
client.
B
It's
pretty
basic,
there's
not
a
lot
to
say
about
this,
I'm
just
showing
it
so
people
will
know
this
would
be
new,
and
we
don't
have
this
today
right
now.
You
can't
call
apply
on
the
type
to
go
client.
You
can
only
do
it
on
the,
though
I
think
it's
called
dynamic,
the
one
that's
untyped
and
it
just
takes
a
bite
array.
B
B
So
that's
kind
of
the
constraint
that
encouraged
me
to
consider
putting
the
sets
in
front
of
there.
I
don't
really
like
it.
I
think
it
looks
a
lot
nicer
in
the
example
with
the
builders.
If
you
take
the
set
away,
it
actually
starts.
Looking
like
pretty
straightforward,
the
main
things
I
was
looking
for,
I
can
go
full
screen
again
and
the
reason
I
brought
it
to
this
group
one
is
this:
is
since
it's
a
controller
runtime
group-
and
this
really
is
all
about
controllers.
B
I
think
it's
very
important
that
this
group
know
about
what
we're
thinking
about
doing
and
get
to
see
the
design
before
we
finalize
anything
right.
I've
gone
back
and
forth
on
what
the
best
solutions
are,
and
I've
considered
a
bunch
of
others
that
are
in
the
design
dock,
there's
a
link
in
the
agenda
and
at
the
top
of
this
presentation
too,
if
you
want
to
see
the
whole
design
doc
and
comment
on
it,
I'd
really
like
to
get
feedback
on
that.
I'm
also
very
interested
in
anybody
who
wants
to
try
this
out.
B
B
We
send
the
apply
call
right
here.
So
that's
this
actually
works
and
then
right,
everything's
together.
It's
all
working
no
surprises.
We
have
a
bunch
of
like
fuss-based
round-trip
testing,
so
it's
kind
of
all
together,
but
you
know
the
generator
could
be
changed
to
generate
something
differently
right
now,
but
yeah
very
interested
in
any
volunteers.
So
if
you
are
interested
in
trying
this
out,
you
could
contact
me
on
slack.
I
would
be
totally
interested
in
any
help
I
can
get
trying
it
out.
B
I
can
help
to
get
the
generator
working
with
anybody
that
needs
it
working
as
long
as
you
know,
I
can
have
reasonable.
You
know
guidance
or
some
access
to
where
we're
putting
the
generator
it's
also
available
in
the
pr.
So
it
might
be
that
some
people
are
just
able
to
kind
of
make
sense
of
it
and
use
it,
but
it's
there
and
that's
it.
I
will
open
up
for
questions.
C
B
Yeah,
so
the
problem
is
that
when
we
define
our
ghost
trucks,
we
don't
make
all
the
fields
optional,
because
some
of
them
are
required
and
that's
really
convenient,
because
then
it
means.
When
you
do
reference
into
a
field,
you
can
say
something
about
something
something
if
it's
required.
You
know
it's
going
to
be
there
right.
It'll
get
zero
valued
in
by
go
you're,
not
going
to
get
a
nil
pointer
exception
doing
that
if
it's
a
required
field,
you're
guaranteed
it's
not
possible.
B
B
It's
because
there's
not
a
there's
a
lot
of
things
in
our
pointer
types,
so
some
fields
are
just
some
just
some
struct,
but
it's
not
a
pointer
and
what
that
means
is
when
you
serialize
those
and
there's
a
bunch
of
cases,
there's
there
are
some
cases
where,
if
something
is
the
zero
value
that
we
do
omit
empty
and
we
don't
put
it
on
the
wire,
but
that's
not
always
the
case,
there's
a
whole
bunch
of
cases
where
we
still
put
it
on
the
wire.
So
basically
what
happens?
B
Is
you
have
these
fields
that
are
always
included
whenever
you
series
an
object,
you're
going
to
get
a
certain
amount
of
things
in
there,
and
it
might
be
only
if
you
add,
like
some
substanza
to
the
object,
but
once
you
add
that,
then
a
bunch
of
fields
get
pre-populated,
that's
not
compatible
with
apply
because
apply.
You
should
only
include
the
fields
that
you
really
have
an
opinion
about
and
want
to
say
what
their
value
is,
because
when
you
apply
that
you're
going
to
take
ownership
of
those
fields.
B
Yeah,
the
booleans
are
by
far
the
most
common.
We
actually
wanted
to
see
how
much
of
a
real
problem
this
was
before
we
fixed
it,
and
what
I
found
was
it
was
the
required
boolean
fields
were
by
far
the
most
likely
thing
you
were
to
hit
yeah.
It's
it's
an
annoying
problem.
It
would
be
great
if
the
ghost
wrecks
just
worked.
B
Changing
them
to
work,
unfortunately
also
comes
with
a
pretty
heavy
penalty,
so
I
I
kind
of
and
in
the
kubernetes
types
I
can't
change
them
right
like
they
are
part
of
the
api.
They
are
forever
for
my
for
my
design
purposes.
So
I
have
to
assume
that
they're
not
going
to
be
able
to
be
changed,
so
I
have
to
introduce
something
new
which.
A
I
should
say
existing
controller
runtime
controllers
might
be
just
to
make
sure
that
so
our
our
patch
function
on
our
client
has
support
for
like
pluggable
patch
types
that
can
be
implemented
like
either
entering
controller
runtime
or
out
of
tree.
So
if
you
wanted,
I
I
can't.
I
guess
I
can't
speak
for
the
other
folks
here,
but
like
probably
the
easiest
thing
to
do.
If
you
want
folks
with
controller
runtime
controllers,
to
try
it
out
would
just
be
to
provide
a
plugable
patch
type.
A
B
E
Sorry,
when
you
said
like
it's
annoying
to
work
with
the
I
mean,
I
agree,
it's
annoying
to
work
with
the
pointers
to
fundamental
types.
But
what
are
exactly
is
the
friction
you're
worried
about.
Are
you
more
worried
about
when
you're
reading
them?
Are
you
more
worried
about
when
you're
trying
to
define
like
a
structured
literal
with
with
these
pointers,.
B
With
apply,
we
are
more
concerned,
apply
is
right.
Mostly
it's
a
right
muscle.
Use
case
you
write
applies
a
lot
more
than
you
read
them.
We
think
there
will
be
some
read
use
cases.
The
truth
is
reading
them.
No
matter
what
you
do,
all
the
fields
are
optional.
There's
no
getting
around
the
fact.
You're
gonna
have
to
check
for
the
presence
of
things
if
you
want
to
safely
de-reference
into
it.
So
that's
actually
not
so
much
a
disadvantage
with
the
pointers.
That's
just
a
problem
with
apply.
D
B
E
B
E
B
Yeah
and
then
the
other
advantage
of
the
builders
is
that
you
get
since
now
we're
introducing
a
second
representation
of
types.
There
are
some
advantages
to
thinking
about.
Well,
are
we
going
to
want
interfaces
that
both
types
can
share
and
so
like?
If
we're
going
to
do
that,
maybe
we
should
just
start
with
the
interfaces,
which
is
basically
what
the
builders
do
you
build?
It
base
everything
around
functions
and
you
can
define
interfaces
for
all
that
and
then
other
types
can
also
implement
those
interfaces.
A
G
B
F
E
B
I
B
B
We
had
a
bunch
of
testing
criteria
to
make
sure
that
it's
actually
sound
right,
like
the
soundness
of
this
is
really
important,
but
I
I
think
the
like
the
the
usability
of
this
is
really
key,
and
so
I
want
to
do
more
than
than
meet
like
like
yeah,
I
kind
of
basically
I
want.
I
want
there
to
be
a
requirement
where,
like
peop
enough,
people
have
tried
this
out
and
said
like
this
works.
B
For
me
like
like
it's
like
it's
agronomic
enough,
like
I
didn't
like
whatever
rough
edges
we
found,
we
we
looked
at,
we
considered,
we
did
the
best
we
could
like.
I
don't
want
it
to
go
out
with
like
unnecessarily
rough
edges
after
working
on
it
for
like
a
couple
months
like
I
don't
know
how
to
get
around
some
of
the
rough
edges,
but
I
would
like
us
to
try
as
hard
as
we
can,
and
I
think
that
there's
probably
some
left
so
I
think,
having
people
bang
on
it.
Try
the
alternatives.
B
It
might
be
that,
like
we
actually
generate
the
pointer
structs
at
some
point
for
people,
if,
if
somebody's
is
very
curious,
what
the
alternatives
feel
like
when
they
actually
do
development
yeah.
I
would
really
like
to
get
like
a
couple:
successful
use
cases
where
people
tried
this
out
were
able
to
do
what
they
wanted
to
do
and
gave
some
really
good
feedback.
B
They're,
not
in
fact
right
now.
The
way
I
have
it
implemented
is.
I
have
an
unexposed
struct
that
with
everything
optional
behind
the
builders-
and
I
could
just
expose
that
right
and
like
then
you
would
have
both
it's
it's
unclear
to
me.
If
it's
a
good
to
be
that
unopinionated
about
this,
to
start
with,
because
I
double
my
api
surface
area
pretty
early
on
in
the
project
I
mean
we
could
always
add
that
later.
B
But
if
we
add
it
now
and
it
becomes
part
of
the
api,
we
can
never
remove
it.
So
I'm
biasing
towards
trying
to
figure
out
which
one
of
these
two
works
the
best
as
soon
as
I
can
and
then
move
forward
from
there
and
maybe
in
the
future,
at
both
or
maybe
it's
the
result
of
feedback
from
people
they
do
say
like
actually
having
both
is
okay
and
I'm.
Okay
with
that.
If
I
got
a
bunch
of
feedback
like
that,
we
would
definitely
like
reconsider
it
and
just
expose
it
because
it
might
be.
B
H
B
Yeah,
so
right
now
the
builder
I
have,
I
have
a
compatibility
matrix,
so
you
can
take
either
ghostrect
or
yaml,
or
this
thing
called
unstructured,
which
is
how
we
do
a
bunch
of
dynamic,
stuff
and
kubernetes.
You
can
get
those
into
into
the
apply
structs
and
out
of
the
apply
structs,
so
you
can
move
it
around.
B
So
you
could
do
something
like
start
with.
A
yaml
like
a
load
of
yaml
in
to
apply
builders,
make
a
couple
hand
changes
with
the
builders
to
fields
that
are
dynamic
or
that
you're
templating
with
and
then
finish
it
out
right,
I'm
not
sure,
that's
the
best
way
to
template,
but
you
you
it's.
It
supports
that
right,
that's
possible!
J
B
B
No,
the
the
the
the
way
yeah
you,
you
don't
even
know
they're
there.
Basically,
you
have
like
these.
These
apply
configuration
types
that
represent
everything
and
you
compose
everything
on
those
got
it:
okay,
yeah
now,
if
we
did
expose
the
structs
we'd
have
to
work
out
like
what
types
we
represent,
but,
for
example,
one
thing
that
we
do
is
in
the
apply
function
that
I
generate
where
you
can
actually
call
apply.
So
the
server
side
applies
run
by
the
server.
B
I
only
take
an
apply
configuration
so
right
now
you
can't
pass
in
a
ghost
draft
and
that's
very
deliberate
right.
I
don't
want
people
to
accidentally
think
that
they
can
just
pass
in
the
normal
kubernetes
go
struct,
because
they
can
shoot
themselves
in
the
foot
doing
that,
for
the
reasons
we
discussed
earlier,
so
you
it
right
now.
The
two
types
are
very
distinct.
B
I
B
Yeah,
I
did
think
about
it
a
little
bit.
I
I
wanted
to
get
one
language
right
as
a
reference
to
start
with,
and
that's
typically
bingo,
I'm
very
interested
in
going
and
making
sure
that
we
do
other
things
in
the
other
languages,
so
any
design
feedback
that
people
have
that
also
applies
to
other
languages
would
be
really
interesting
because
I
would
like
I
would
like
the
next
language
implementation
to
be
easier,
because
we
have
like
all
the
thoughts
that
we
put
into
this
one.
B
So
hopefully
we
can.
Hopefully
we
can
be
a
little
bit
successful
in
there.
I
don't
know
if
we
can
provide
super
con
free
grinders
for
all
languages
yet,
but
I
I
think
whatever
we
do
here
would
guide
a
lot
of
type
safe
languages
pretty
well
and
then,
hopefully,
hopefully,
for
more
dynamic
languages.
We
could,
you
know,
start
getting
some
warnings
too.
A
I
I
I'd
probably
just
briefly
point
out
that
a
lot
of
modern
type,
safe
languages
don't
have
the
edges.
The
rough
edges
around
the
optional
fields
that
go
has
so
like.
If
you
look
at
rust,
for
instance,
you
have
like
a
concrete
option
type
which
makes
it
easier
to
define
optional
values,
inline
and
then,
if
you're,
looking
at
like
dynamic
languages
like
python
right,
you
you,
you
have
support
for
like
making
any
field,
none
potentially
so
like
yeah
that
that
is
like.
B
Yeah-
and
I
wouldn't
want
to
prescribe
something
under
the
other
languages
that
wouldn't
be
a
good
fit
idiomatically
for
them
right.
So
I
maybe
some
of
the
best
feedback
is
why
why
you
need
to
make
sure
that
apply
is
doing
what
you
think
it's
going
to
do
in
your
language?
Why?
You
can't
just
assume
that
your
existing
types
work?
E
B
E
B
Yeah,
so
basically
the
way
the
builder
works
is
it
it?
It's
not
actually
called
a
builder
when
you
call
the
types
it's
called
like
an
applied
configuration
types.
You
have
like
a
deployment
applied
configuration
and
you
just
call
set
on
it
and
sets
just
happen
to
return
that
same
object
again,
so
you
can
chain
them,
but
you
end
up
with
an
object,
and
that
object
is
the
representation
of
that
thing,
so
you
don't
actually
have
to
call
like
a
dot
build
at
the
end.
That's
the
way
I'm
imagining
this.
E
D
E
D
E
B
Probably
the
best
way
to
leave
choice
would
be
to
expose
the
fields
and
take
that
trade
off
I
am
we
could
yeah.
I
think
I
think
the
two
are
either
we.
We
would
agree
that
pointers
are
actually
the
way
to
go
and
we're
going
to
take
that
hit
or
we
expose
both
like
we
expose
both
the
setters
and
the
fields
and
let
people
pick
or
those
would
probably
be
the
two
that
would
go
that
route.
B
I
think
it
does
does
it
do
both.
I
think
it
does
yeah.
So
I
would
be
very
curious
in
fact,
what
we
might
want
to
do.
If
we
do
a
controller,
runtime
experiment
would
be
to
expose
both
and
let
people
try
and
then
have
them
come
back
and
tell
me
like.
I
tried
both
and
I
ended
up
using
this
one
and
here's
why
that
might
actually
be
a
better
experiment
than
just
like
giving
them
one.
I
I
think
what
might
be
slightly
different,
the
example
that
I
remember
you
showing
was
kind
of
from
greenfield
right,
you're,
creating
a
deployment.
You
know
from
a
controller
standpoint.
What
I
would
expect
is
I'm
pulling
something
out
of
a
cache
and
when
making
a
copy
and
then
making
some
modifications-
and
I
my
thoughts
currently
are
around-
you
know
how
to
what
would
that
look
like.
A
B
A
I
B
A
D
Yes,
I
added
a
agenda
for
the
wondering
when
we,
when
0.7
is
slated
for
release
for
controller
runtime,
we're
we're
trying
to
plan
for
kubernetes,
120
and
kind
of
figuring
out
the
timeline,
because
I
we
assume
that
zero
seven
needs
to
come
out
before
we
can
start
doing
any
120
work.
And
so
I
just
wanted
to
check
where
we
were
with
that.
A
Yeah
events-
I
I
don't
want
to
put
you
on
the
spot
too
much,
but
I
think
I
think
you
probably
have
you
you
and
camilla.
I
think,
and
gabby
probably
has
some
of
the
best
knowledge
of
like
the
state
of
things.
I
think
there
was
at
least
one
thing
that
we
wanted
to
tackle.
That
might
be
a
breaking
change
that
we
might
want
to
tweak
before
0.7.
J
J
J
H
J
I
would
I
don't
have
time
to
do
it
right
now,
but
like
there
is,
I
would
like
to
fix
it
before
we
release,
because
that
caused
me
and
others.
Like
a
lot
of
confusion
and
like
I,
I
like
to
pretend
that
I
know
a
bit
about
controller
runtime.
So
if
it
got,
is
this
causing
trouble
to
me
like
it?
Probably
it's
gonna
cause
trouble
to
others,
and
we
need
to
document
all
the
breaking
changes
as
well,
which
is
that
I
would
consider
a
release
blocking
thing.
H
H
Well,
we
can
keep
releasing
q
builder
to
be
using
zero
six,
but
when
we
go
to
zero
seven,
we
will
need
a
basically
a
brand
new
plug-in
because
we're
gonna
make
a
bunch
of
breaking
changes
in
scaffolding.
So
I
assume
what
we're
probably
gonna
do
unless
people
disagree
with
this
is
to
hold
the
v3
go
plug-in.
That's
currently,
like
you
know
the
next
one
up
wait
for
that:
to
wait
for
zero,
seven
to
be
releasing
controller
runtime
and
then
update
that
to
use
zero
seven.
Is
that
what
we
think
the
plan
is?
H
G
C
C
K
H
Are
there
other?
Are
there
other
user
facing
braking
changes
or
cue
builder,
facing
braking
changes
that
we
want
to
make
that
are
not
in
master
yet
or
not
slated
for
zero
seven?
Yet,
because
that
would
that
would
basically
again
necessitate
when
we
go
out
with
zero
eight.
That
would
mean
a
v4
cubicle
plug-in.
So
I'm
wondering
like
do
we
want
to
try
to
get
all
the
braking
changes
in
now
so
that,
when
we
bump
to
zero,
eight
q
builder
doesn't
have
to
have
a
new
plug-in.
K
K
No
jesse,
I
would
like
to
understand
because,
for
example,
if
we
in
my
mind,
suggest
it
to
clarify,
if
we
release
cool
builder
now
we
have
a
3.00.
We
have
the
v2
plugging
as
the
phone
that
you
can
cannot
have
the
brake
chains
and
all
brake
chains.
King
is
still
going
to
between
alpha,
but
when
we
make
ev3
alpha
stable
thing,
we
cannot
say
so
longer
working
with
it
breaking
things
on
that
thing,
you
need
to
do
the
v4
or
anyone
about
that.
Yes,.
K
H
H
I
think
I
know
maybe
it'll
be
like
a
month
early,
but
I
think
what
I'm
suggesting
and
I'm
hoping
we
can
start
driving
towards
us
having
control
of
runtime
much
more
closely
aligned
with
the
upstream
kubernetes
version
such
that
when
120
goes,
ga
we're
you
know,
maybe
no
more
than
a
week
later
we
have
a
version
of
controller
runtime
and
a
version
of
q
builder
that
supports
the
latest.
Ga,
maybe
that's
a
pipe
dream,
but
we
that's
kind
of
what
I'm
hoping
we
can
do.
A
H
In
this
case,
we
have
a
whole
bunch
of
breaking
changes
on
zero,
seven
that
are
going
to
necessitate
some
changes
to
queue
builder,
that's
going
to
take
a
little
longer,
so
I
guess
I'm
hoping
like
we're
if
we're
far
enough
in
advance
of
120,
now
that
if
we
can
talk
about
all
the
things
that
need
to
go
in
in
what
order,
then
we
might
be
able
to
make
120
faster.
That's
what
I'm
hoping
for.
A
What
day
is
the
next
of
these
meetings?
Should
we
sync
next
meeting
and
like
try
to
get
try
to
make
sure
like
in
the
interim
two
weeks
we're
good
and
like
we
get
all
the
features
in
and
we
do
all
the
review
and
then
like
do
a
sink
next
meeting,
make
sure
there's
nothing
final,
that's
about
to
explode
or
like
we
realized
that
we
left
a
pizza
in
the
oven
and
it's
about
to
burn
or
something
and
and
if
we're
good
next
meeting,
then
we
just
release
that
day.
H
A
H
K
C
K
K
A
Can
we
just
get
like
a
cloud
build
script
for
our
purposes,
then
so
that,
like
we,
don't
have
to
ping
someone
with
permission
to
to
push
directly
every
time
sure
because,
like
I
there's
very
few
people
on
the
hot
path
right
now
that
have
permissions
to
push
to
to
push
directly
to
that
registry,
which
I
think
is
like
probably
a
good
thing
like
we
don't
want
too
many
people
with
direct
write.
Permissions
we'd
rather
have
automation
and
ci
doing
the
push.
A
I
I
would
prefer
to
have
it
be
similar
to
the
way
we
do
our
release,
tools
and
stuff
like
that,
where
it's
just
like,
we
have
cloud
build
and
we
we
tag.
We
tag
a
tag
on
a
branch
and
it
just
pushes
I
I
would
prefer
to
have
something
set
up
like
that.
Instead
of
just
having
to
have
people
manually
tag
and
push.
K
K
A
Yeah
we
already
have
a
bunch
of
stuff
on
actions
anyway
and
I
never
finished
pushing
it,
because
if
you
has
some
rough
edges,
but
I'm
I
can,
I
can
push
it.
I
had
some
code
actually
that
I
worked
on
that
takes
the
results
of
our
a
lot
of
our
test,
runs
and
and
pipes
them
into
github
actions
in
a
way
that
we
see
like
inline
code
annotations
for
the
individual
test
runs
in
addition
to
like
the
lints
and
stuff,
which
means,
like
you
know,
nicer,
test
output.
A
You
can
just
like
view
them
as
comments
on
the
code
or
check
run.
Annotations
is
the
technical
term,
so
I
would
be
in
favor
of
doing
that.
Assuming
there's
no
like
serious
performance,
implementations
or
like
budget
like
assuming,
we
don't
accidentally
burn
through
like
org
budget
for
github
actions
or
something,
but
I
think
we're
probably
good
there.
So
I'm.
I
would
be
good
with
that.
K
Really,
nice,
you
know,
and
if
a
scientist
you
ending
today,
I
think
it's
possible,
we
probably
migrate.
Should
we
get
to
the
actions
but
see
if
I
see
that
we
are
not
able
to
achieve
the
goal
in
the
timeline
io.
Thank
you
just
to
migrate.
I
believe
it
joel's
gtt
thing
was
easy.
I
don't
think
I
have
the
permissions
just
because
that
I
need
some.
We
need
someone
who
that
has
affirmations
to
do.
A
K
G
G
So
one
of
the
big
things
is
that
you
know
we
wanted
a
solution
that
both
works
for
us
and
also
works
for
the
current
issue
that
that
controller
manager
is
seeing
where
the
inability
to
shut
down
informers
kind
of
creates
log
spam
in
garbage,
collector
and
and
resource
quota,
and
so
resource
quota
is
working.
But
the
garbage
collector
is
a
bit
more
a
bit
more
nuanced
or
has
a
bit
more
complexity
to
it.