►
From YouTube: 2022 10 21 Platform SIG
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
A
We
have
what,
if
you
subject
in
the
agenda
today,
the
first
one
being
open
actions
items
what
haven't
we
done
yet
we
used
to
have
some
PPC
64
Le
agents
on
CI
Jenkins
IO,
but
it
looks
like
we
lost
them
somehow
The
Loner
program,
as
is
finished
now,
so
we
have
to
drop
all
mention
of
ppc64le
in
the
infra
index
and
if
you
make
a
quick
search
on
Jenkins
I,
don't
think
we
will
still
find
some.
So
it's
still
open.
We
have
to
do
that.
That
could
take
quite
some
time.
B
It's
okay
for
you,
I'm
opening
an
infrastructure
on
the
desk
about
that
task.
I!
Will
we
will
take
care
of
listing
the
elements,
so
we
can
start
working
on
that
part.
A
Yeah,
that's
a
good
thing
thanks
a
lot
and
let
me
know
when
it's
done
so
that
we
can
modify.
C
B
So
two
CVS
have
been
fixed
by
the
version
2.38.1
of
git
that
covers
two.
So
the
version
2.38.0
was
concerned
by
the
security
issue,
but
also
the
previous
one
that
we
are
using
today,
2.7
37.,
so
we
have
to
update
to
that
latest
version
to
avoid
we
don't
risk
any
CV.
Even
if
the
exploitation
is
not
that
easy.
It's
a
it's
not
high
priority
I
I
criticity,
but
still
we
have
so
that
should
be
a
campaign
of
updating
the
Git
Version
on
all
our
images.
That's.
A
An
action
item
yeah,
so
let
me
just
change
the
indentation
that
it
looks
like
it's
part
of
the
action
items
cool
done,
so
it
should
take
quite
some
time
because
we
have
the
Linux
VM,
the
liner
container
for
TI
Jenkins
IO
and
windows
VMS
too.
Well.
It
has
to
be
done.
Nonetheless,.
B
A
That's
what
I
wanted
to
add:
it's
still
actionable
fast
period,
so
you
can
get
some
swag
just
by
changing
to
git
to
38.1.
Thank
you.
Damian
next
subject
is
also
you
Damien.
We
had
some
issue
opened
on
the
infra
saying
that
we
maybe
had
the
problem
with
the
volumes
in
the
docker
agents.
So
something
is
about
to
happen.
Somebody
should
work
in
the
following
weeks
about
that,
so
because,
for
the
time
being
the
volume
for
home
Jenkins
has
some
trouble.
We
have
some
issues
with
that.
Maybe
we
shouldn't
detail
them
here
now.
A
But
yes,
that's
something
we
have
to
work
on
in
the
following
weeks,
so
we'll
have
to
change
it
to
home
Jenkins
and
the
Agents.
Were
there
I,
don't
have
the
reference
of
the
issue.
B
Let
me
add
it
on
the
notes.
Documentation
is
important
here,
just
a
nuts,
that's
nice,
that
we
have
given
there,
because
I've
seen
that
quite
often
the
past
weeks
and
months
of
user
lost
when
configuring
a
Jenkins
segment,
they
were
lost
on
understanding.
What
is
the
roots
directory
when
configuring
an
agent?
The
root
directory
is
the
directory
in
the
remote
system,
where
the
agents
download
these
temporary
files
and
then
start
a
workspace
and
we'll
create
one
workspace
for
each
build
that
is
going
to
under
that.
B
One
is
not
always
by
default,
depending
on
the
images
or
the
plugins
or
the
setups,
that
directory
may
change,
but
that
directory
usually
is
recommended
to
be
under
the
home
directory
of
the
user
executing
the
agent,
because
you
could
have
multiple
agents
with
multiple
working
there
and
you
want
it
to
be
multi-toned.
B
B
Absolutely
and
I've
been
beaten
and
everyone
has
been
beaten
by
that
one.
So
we
have
a
usability
issue,
but
also
documentation,
because
we
have
numerous
locations
where
we
have
numerous
documentation
for
each
agent.
If
I
only
focus
on
Docker
inbound
agent
and
Docker
SSH
agent,
one
say
you
have
to
configure
an
object
on
Jenkins
an
agent,
and
then
you
have
to
connect
it
to
the
agent
and
you
pass
the
working
there
as
a
flag.
So
it's
One
Direction
with
the
SSH.
It's
the
opposite.
You
have
to
tell
the
controller
that
will
decide.
B
Where
is
the
agent?
So
that's
why?
Having
a
documentation
for
each
agent
that
mentioned
hey
the
working
directory
by
default?
Is
that
path
a
screenshot
eventually?
And
if
we
have
an
agent
configuration
reference
on
the
main
dock?
We
can
point
to
that
reference,
each
time
that
will
limit
the
mess
of
each
plugin
having
a
different
default
version
between
Docker
Cloud,
ec2,
Azure
VMS
as
your
containers,
SSH,
etc,
etc.
So
that's
why?
Having
a
single
change
for
at
least
the
docker
images
is
a
good
start.
A
Sorry,
it
was
just
a
good
idea
at
the
beginning
regarding
the
performance
I
think
you
explained
me
one
day
that
it
was
because
using
it
as
a
volume
gives
some
better
performance
than
just
working
inside
the
machine
without
any
volume
am
I
right.
Okay,
yep.
B
But
still
it
has
to
be
a
volume.
In
the
case
of
Docker
images,
we
have
users
complaining
that
it
creates
empty
volumes
on
Docker.
That
one
is
not
a
problem,
because
that
one
is
absolutely
the
normal
behavior
of
all
Docker
images
that
you
can
discover
on
the
docker
Hub,
it's
a
normal
Docker
process,
so
they
have.
We
can
help
them
on
learning
and
growing
on
Docker
usage,
even
for
development,
but
that's
a
normal
Docker
of
pattern
on
the
other
way
around.
B
A
Thank
you.
Damien,
oh
I,
still
I
still
see
some
references
to
gdk8
I
thought
it
were
about
to
forget
everything
about
gdka.
B
Team
already
and
I
think
Alexa
some
contributors,
usual
maintenors
have
removed
gdk8
from
our
Docker
agent
images.
The
controller
has
been
already
done
month
ago,
however,
with
the
recent
issues
with
the
docker
inbound
agent
and
tagging
and
release
that
were
going
back
in
the
past.
B
Will
be
used
used
in
case
of
security
issue,
though,
and
would
helps
us
to
have
most
of
the
fixes
that
we
already
did
on
gdka
11
that
could
be
done
on
the
gdka
8..
The
volume
agent
is
one
of
these
fixes
that
have
to
be
Cherry
Picked,
so
once
this
element
will
be
done,
we
can
then
continue
forward
with
GDK,
11
and
17
on
the
main
branches.
A
A
A
A
Okay,
documentation,
thank
you,
and
so
the
last
subject
of
Docker
regions
is
the
proposal
to
merge
the
three
repos
into
a
single
one,
the
Eternal.
You
know
the
mono
repo
versus
multi,
repos
I
can
see
some
fights
on
the
web
just
about
every
week.
On
that
subject,
okay.
A
That
way
next
is
container
image:
duplication
for
the
blue
ocean
container
Kevin.
You
made
an
amazing
job,
putting
warnings
just
about
everywhere
on
the
blue
ocean
documentation.
Please
stop
using
that.
I'll
know
that
it's
deprecated
or
won't
be
it's
maintained,
but
you
won't
see
any
new
features
coming
in
the
following
months:
it's
not
dead
but
anyhow,
and
we
still
have
to
do
that's
kind
of
the
same
thing
for
the
containers
of
blue
ocean.
So
maybe
Mark
will
do
that.
A
I,
don't
know
we'll
see
that
later
on,
we
have
to
update
the
page
on
dokarab.
We
have
to
make
a
changelog
a
great
guide
and
so
on,
and
it's
not
just
because
we
should
stop
using
Bluer
shell.
The
container
images
are
pretty
much
outdated.
In
fact,
I
even
don't
know,
somebody
is
taking
care
of
them
so
anyway,
it's
not
a
good
idea
to
use
them
these
days.
So
let
me
know
if
I'm
wrong,
Damian.
B
I
think
that's
a
good
summary.
Blue
ocean
is
still
be
used,
but
not
really
well
maintained,
except
for
security.
There
are
projects,
but
nothing
to
replace
it
as
it
right
now.
However,
maintaining
that
image
was
created
on
a
time
where
Jenkins
configuration
as
code
and
the
Jenkins
plugin
CLI
weren't
a
thing,
so
it
was
easier
for
for
the
community
to
push
pre-built
images
with
version
already
installed.
As
for
today,
if
you
start
a
brand
new
Jenkins,
the
setup,
the
default
setup
propose
you
to
install
version
by
default.
B
You
can
always
install
it
manually
on
your
existing
Jenkins
instance.
Most
of
the
time
it's
already
there.
Third,
you
can
use
Jenkins
sprig
in
CLI,
either
on
the
default
container
installation
or
on
your
own
system.
If
you
don't
use
container,
it's
already
pre-default
installed
on
kubernetes
installations,
so
yeah
we
have
a
lot
of
tools
and
way
of
easily
going
from
zero
to
Blue
Ocean
in
one
command
line.
So
that's
why
it
doesn't
make
any
more
sense
to
maintain
such
image,
because
that
image
is
always
not
up
to
date.
A
Cool
thanks
for
the
details,
so
as
it's
written
not
likely
to
make
progress
until
November,
I
guess
Mark
wanted
to
address
that
when
he
comes
back
from
PTO,
we'll
see
that
later
on
now
container
repository
management
for
Jenkins
agents.
We
already
addressed
some
parts
of
this
subject
because,
yes,
we
may
want
to
unify
the
existing
repositories
for
the
agents,
and
we
also
have
to
work
on
the
release
process,
which
is
not
that
easy.
These
days.
B
Yep,
so
the
main
driver
for
this
merging
repository
is
the
following.
We
have
inbound
agent
that
depends
on
agents
which
mean
for
each
gdka
version.
Then
each
operating
system,
which
has
multiple
variations.
We
have
to
duplicate
the
same
update
of
the
operating
system
and
gdker
version
inbound
as
mapping
101.
B
But
already
we
have
different
naming
and
different
operating
system
between
both
second
Docker
agent
alone
is
a
nice
route
that
we
can
extend
for
the
inbound
agent,
but
we
never
were
able,
as
a
community,
to
do
the
same
with
SSH
agents
that
could
iterate
from
this
one
without
without
having
too
much
duplication
or
unused
item.
So
the
goal
will
be
to
have
that
element.
And
now,
since
we
have
Docker
multi-stage
builds,
we
have
Docker
bake
or
even
just
a
single
Docker
build
for
Windows
machines.
B
So,
thanks
for
this
contributor,
and
now
we
have
everything
in
place
so
to
merge
everywhere.
That
will
not
change
the
name
of
the
docker
images
if
you
are
using
in
bondage
and
today
that
will
keep
the
same
okay.
However,
that
will
change
how
you
see
the
release
and
release
now,
because
they
will
be
all
on
the
same
repository.
So
we
will
change
the
tagging
convention,
for
instance,
one
of
the
proposal.
It's
not
reality,
but
one
of
the
proposal
will
be
to
have
let's
say
a
tag:
name
inbound,
a
dash,
Agent
Dash.
A
I
see
technically
speaking,
that
sounds
really
interesting
and
for
the
maintainers
to
come.
That
should
be
easier
to
maintain
when
the
heavy
lifting
to
convert
everything
to
a
single
repo
will
be
done.
Oh
nice,
thank
you.
Damien.
A
What
else
I
think
we're
done
with
that
sharp
Jack
subject
require
Java
11
on
your
for
jking's
core
I
think
so
the
dropping
Java
8
from
the
docker
agents
has
been
merged
and
you
said
me
earlier:
it
had
been
released,
so
we're
done
with
that.
Pretty
cool
and
plug
in
some
plugins
I.
Don't
have
the
numbers
yet
are
beginning
to
require
Java
11.
So
it's
an
ongoing
process.
A
I
guess
that's
a
good
idea
to
move
the
plugins
to
the
GDK
11.
Do
you
know
Damien?
Why
plug-in
maintainers
shouldn't
move
to
GDK,
11
or
17.?
We
don't
force
them
to
do
so.
Can
we
expect
their
plugins
to
work
and
be
able
to
release
new
releases
in
the
coming
future,
even
if
they're
still
using
gdk8
I
don't
want
to
force
anyone
I
just
want
to
have
the
status
should
we
or
do
we
have
to
move
to
hdk
11
for
the
plugins.
B
So
today,
if
you
are
maintaining
a
plugin,
you
should
test
it
with
both
Java
8
and
available
Java
8,
because
there
are
still
some
people
using
Java
8.
So
you
need
backward
compatibilities
and
Java
11,
because
it's
the
standard
default.
If
you
don't
use
Java
11
today,
that
means
your
plugin
cannot
be
installed
on
the
new
LTS.
B
So
that's
quite
problematic
going
to
Java
17,
it's
not
required
today,
but
you
should
really
start
going
on
that
direction.
If
you
don't
know
how
to
build
and
test
your
plugin
already
today
on
CI
Jenkins
IO
with
the
free
GDK
that
we
provide
don't
hesitate
to
look
at
the
build
plugin
documentation
or
open
the
topic
on
IRC
guitar
or
Community
Jenkins.
But
today
you
can
absolutely
set
your
plugin
to
build
and
test
on
the
free
GDK
on
Linux
and
windows.
B
So
you
can
have
six
build
in
parallel
that
try
all
the
available,
my
bad
sorry
fives,
only
Java
17
on
Windows
is
not
available
yet,
but
it
will
soon.
So
my
recommendation
is,
if
you
are
maintaining
a
plugin
and
he
when
you
are
hearing
this
word,
please
enable
for
the
free.
If
you
already
did
the
work
for
dropping
Java
8,
no
problem,
you
can
remove
the
hate
from
your
CI
process.
However,
communicate
correctly
in
the
readme,
don't
state
to
mention
that
Java
height
has
been
dropped
for
your
plugin.
A
Okay
and
I've
seen
I
know
if
it's
your
urban
legend
or
not,
but
I
think
that
for
Java
19
we
could
have
some
problems
with
Jenkins
core
or
even
Jenkins
plugin,
because
some
things
you
know,
we
always
have
some
warnings
about
either
girls
that
use
exceptions.
Something
like
that
and
I
heard
that
maybe
with
Java
19,
we
will
have
some
problems.
This
will
not
be
a
warning
anymore,
but
growing
into
an
error
so
we'll
see.
Definitely
you
should
upgrade.
A
A
I
know
it's
maybe
a
urban
legend
I
don't
know,
I
should
have
checked
and
yeah.
It's
a
good
idea.
What
I
remember
from
what
to
say
that
it's
just
a
good
idea
to
move
to
GDK
11
and
see
either
Jenkins
Io.
If
you
are
a
plug-in
maintainer
supplies
you
with
build
for
8,
11
and
17,
except
on
Windows,
where
there
is
no
17
yet
pretty
cool,
thank
you
and
regarding
GDK
17
by
the
way
you're
using
it,
maybe
not
everywhere,
but
you're
using
it
on
TI
Dinkins
IO
am
I
right.
A
So
I
don't
have
the
numbers
for
October.
Unfortunately,
there
were
11
000,
GDK
17
install
for
Jenkins
last
month.
I
can
only
help
this
as
grown
as
these
bonds.
I,
don't
know
where
to
find
the
numbers
by
the
way,
I
think
it's
Mark.
Who
can
accept
that
anyhow,
that's
a
good
progression
from
August
months
and
the
Forum
anyway.
A
C
So
I
know
what
you
have
here
on
the
page:
that's
pretty
much!
It
honestly
I
think
that
that
still
has
to
be
developed
and
figured
out
a
little
bit
more
and
at
least
obviously
the
scheduling
still
needs
to
happen
for
sure
so
yeah
more
to
come.