►
From YouTube: SIG-Testing Weekly Meeting for 20220628
Description
SIG-Testing Weekly Meeting for 20220628
A
C
B
B
D
Hey
hi,
this
is
ritesh,
so
I
don't
know
if
I
have
logged
in
too
many
times.
I
think
it's
my
second
meeting
and
I'm
basically
joining
from
apple
and
we
work
on
some
cube
stuff.
You
know
over
here
and
we
would
like
to
know
what's
happening
in
the
kubernetes
testing
world.
So
that's
why
I'm
here
hi
everyone
welcome.
E
B
E
Yeah
sure
so
we
are
actually
planning,
as
I
mentioned,
to
onboard
our
ibm
club
few
of
our
resources
into
the
bosco's
pool.
So
right
now
we're
aware
of
like
we're
just
trying
to
understand
how
to
go
about
it.
So
I'm
aware
that
we,
just
so
it's
source
based
so
we'll
make
those
changes
to
the
deployments
and
somebody
among
you
all
just
deployed
on
the
build
cluster.
But
I'm
not
quite
sure
if
I'm
just
looking
information
on
the
text
aspect.
E
B
E
A
E
E
E
I
mean
basically,
we
just
had
like
two
high-level
questions.
First,
one
is
like
about
the
secret
manager,
like
you
mentioned,
that
they
were
using
kubernetes
external
secrets,
and
if
you
mentioned
that
they're
also
using
the
external
secrets
operator,
so
so
using
what
would
be
better
and
I'm
out
there
like.
We
are
planning
to
use
it
with
ibm
cloud
secret
manager,
but
is
it
being
used
on
any
of
the
build
clusters,
or
so
mohammed
recommended
that
we
use?
E
E
C
C
And
I
want
just
to
discuss
about
our
approach
and
you
can
see,
I
think
the
2p.
There
was
a
discussion
in
various
ways
in
which
we
can
set
a
windows
node
for
pro.
One
of
them
was
basically
port
pro
for
windows
notes.
That
means
all
the
utils
etc,
and
we
kind
of
scrap
that
for
the
moment,
as
it's
a
little
bit
more
complicated
than
it's
probably
worth
right
now
in
the
sense
that
we
just
need
the
signal
from
these
unit
tests.
C
So
what
we
did
is
just
implemented,
something
that
we
have
let's
say
precedent
for
our
current
e2e
tests
are
basically
using
the
runner
in
pro
the
runner
in
the
I
think
it's
bootstrap,
the
image
doesn't,
does
nothing
but
just
runs
a
script.
The
scripts
would
be
in
wind
windows
testing,
that's
our
repo
under
kubernetes
and
the
scripts
will
basically
be
in
charge
of
creating
an
azure
vm
running
the
test.
There.
C
The
unit
tests
collecting
basically
transforming
the
output
into
junit,
and
then
the
pod
utils
will
do
their
job
and
push
everything
to
the
bucket,
and
hopefully
that's
great
will
play
nice
yeah.
So
this
is
the
approach
we
settled
on.
I
think
I
just
want
to
ask
your
opinion.
If
it's
something
that
I
mean,
we
can
discuss
it
with
ben
on
slack
that
he
would
be
on
board
with
that,
but
I
just
went
with
the
larger
community
to
know
if
you
guys
are
on
board
as
well
with
with
this
idea.
B
B
C
Okay,
the
idea
is
that
basically,
these
pr's-
we
have
this
workflow.
We
have
for
each
with
us
with
cab,
z,
cluster
api
for
azure.
So
it's
basically
the
the
same
things
as
we
run
unit
tests.
Then
in
the
interest
of
time,
because
it
is
let's
say
a
bit
of
a
time,
sensitive
issue,
we
would,
since
they
only
touch
the
windows
testing
repo.
The
only
resources
in
prague
that
would
be
used
are
basically
a
pod
periodic,
every
12
or
24
hours.
I
don't
remember
and
we're
we're
on
it.
C
C
Since
the
vm
is
in
asia
created
in
asia
and
the
test
time
is
small,
I
don't
think
it's
a
impact
in
resources
or
anything
for
the
job,
so
yeah
that's!
This
is
basically
what
the
long
story
short
is.
We
would
like
to
merge
this
and,
if
you
guys
say
it's,
it
looks
good
with
understanding
that,
if
something
happens
where
we're
on
it
and
we'll,
I
mean
we're
not
going
to
let
a
lingering
job
that
doesn't
work.
B
Yeah,
I
I
know
nothing
and
I
don't
feel
like
I
have
authority
to
approve
anything
there.
So
it
looks
like
the
pr
already
has
approval
because
you're
an
owner
there.
So
if
you
can
get
someone
to
do
an
lgtm,
it
will
merge.
So
I
okay,
okay
yeah.
I
don't.
I
don't
feel
comfortable
enough
to
do
it
myself,
but
I'm
sure
someone
else
can
take
a
look.