►
From YouTube: 2021 08 13 Platform SIG
Description
Jenkins platform special interest group August 13, 2021 with topics including Docker, Java 11, and our Docker image support strategy
A
A
A
B
A
B
A
A
Okay,
so
that
that
we've
got
to
change
great
all
right,
any
other
topics
before
we
get
into
walking
working
through
the
agenda
nope.
Okay,
so
I
had
the
oak
action
item
to
open
the
jet
pull
request.
It's
been
opened
and
requesting
comments,
we're
actually
executing
on
this
plan
right
now,
even
without
it
having
been
accepted,
as
a
draft
comments
have
been
received
from
tim,
jacom
and
from
and
from
one
other
contributor,
and
I
think
the
proposal
is
currently
up
to
date.
With
those
comments.
A
I've
still
got
the
task
to
open
a
jeb
for
docker
operating
system
support,
and
this
is
but
we've
got
a
code
owner's
file
now
already
it's.
The
jet
is
basically
used
code
owners
and
the
concept
we
have
one
in
the
controller
repository,
but
it's
not
yet
fully
expanded
to
cover
all
the
all
of
the
images
that
we
have.
A
A
Next
topic,
then,
is
the
hot
one.
For
me,
at
least
java
11
is
default
in
all
our
docker
images,
so
the
the
story
there
is
2.306
has
added
jdk8
tags.
So
there
is
a
latest
jd
latest
jdk8
so
that
people
could
switch
to
use
it.
It
happens
to
be
the
same
right
now.
It's
an
alias
for
latest
next
week.
It
will
be
an
alias,
for
it
will
be
separate
from
latest
and
because
latest
will
become
java.
17.
A
A
A
B
Yeah
we
could.
The
the
old
scripts
are
very
hard
to
understand,
at
least
for
me
not
knowing
them,
and
it's
there's
probably
no
just
well.
I
don't
think
there'll
be
any
point
in
not
doing
it
because
the
old
ones
unless,
unless
you've
got
docker,
auto
builds
working.
So
the
only
reason
not
to
use
bike
would
be.
If,
if
you
got
the
auto,
builds
working
again
and
stayed
with
that,
because
there's
no
scripts
for
those
reapers,
I
would
assume.
A
Great
okay,
thank
you
all
right!
Then,
we've
got
2.303.1
august,
25th,
we'll
add
a
jdk8
suffix
tag
and
we'll
switch
to
java
11
as
the
as
the
default
in
the
docker
image,
any
red
flags
there
or
concerns
from
anyone
of
oh
something
that
we
we
should
not
go
forward
with
this
right
now.
My
plan
is
to
go
forward.
C
A
Right
very
good
point
and
I've
attempted
to
already
put
it
into
the
upgrade
guide
and
the
the
change
log.
So
so
that's
out
for
review
and
would
love
to
have
more
voices
checking
it.
Let
me
put
a
link
to
that
into
the
meeting
notes.
So
it's
I
didn't
well.
No,
I
take
it
back.
I
didn't
put
it
in
the
change
log.
I
wasn't
sure
quite
where
to
put
it
in
the
changelog
so
daniel,
maybe
you
can
give
me
some
hints
there,
but
I
definitely
did
put
it
as
the
first
entry
in
the
upgrade
guide.
C
A
A
A
A
B
Sure
so
there
was
on
the
docker
agents.
There
was
one
thing
that
damien
suggested
was
that
maybe
we
think
about
merging
some
of
the
repositories,
because
we've
got
quite
a
lot
of
repos
and
with
docker
bake
we
can
kind
of
build
them
all
together,
especially
the
ones
that
build
off
of
agent
base.
So
we
can
build
the
agent
first
and
once
that's
built,
we
can
build
the
other
ones
on
top.
I
think
it's
I
think
inbound
agent
is
the
one
that
builds
off
it
or
ssh
put
it
inbound
agent.
I
think.
C
So
because
so
I
saw
the
meeting
note
beating
invitation
earlier,
and
I
thought
well
that's
a
good
opportunity
for
me
to
join
and
thank
you
for
making
the
docker
build
faster,
because
waiting
for
that
is
always
really
painful.
While
I'm
trying
to
deliver
security
fixes.
This
hasn't
really
been
relevant
in
the
last
one
or
two
months,
but
it
will
surely
come
up
again
soon.
So
thank
you
very
much.
B
Yeah,
I
mean
so
they
well.
The
main
waiting
time
is
just
on
that
is
on
the
windows
publishing
and
that's
because
the
windows
based
image
is
very,
it's
one.
Large
and
windows.
Docker
is
small
to
pull.
I
removed
the
prone
on
the
controller,
publish
which
means
that
it.
That
goes
a
lot
quicker
now,
if
the
agent
it
runs
on,
has
it
cached?
B
So,
if
you're,
if
you,
if,
for
whatever
reason,
you're
running
multiple
builds,
it's
a
lot
quicker,
we
were
seeing
all
the
scheduled
builds
that
were
just
kicking
off
where
every
single
one
of
those
was
taking
20
minutes
and
we're
wasting
quite
a
lot
of
compute,
and
that
went
down
to
three
seconds.
If
the
agent
was
still
around.
B
C
B
A
And-
and
it
did,
we
had
a
daniel
thanks
for
highlighting
it
actually
last
week
or
two
weeks
ago,
damien
shared
a
an
overview
for
us
and
we
captured
some
of
the
choices
in
terms
of
why
why
bake
is
using
hcl
and
why?
How
that
helps
and
how?
How
the
parallel
testing
helps
and
parallel
image
building
helps,
and
this
was
this
is
quite
an
amazing
contribution
from
tim
and
from
damien
thanks
tim,
very
much
for
what
you
did
and
thanks
to
damian
as
well.
A
B
And
the
scripts
are
massively
simplified.
Now
I've
ripped
out
most
of
the
code
from
the
scripts
as
part
of
bake,
because
all
of
that
is
encoded
in
declarative
file
now,
rather
than
shell
scripting,
especially
that
was
nice
and
docker
agent,
because
I
I
couldn't
read
that
shell
script,
it
was
insane.
B
The
other
fix
that
we
did
was
I
found
that
the
tests
weren't
actually
running
on
ci
on
the
agent
repository
it
had
been.
There
were
tests
in
the
repo,
but
they
weren't
run
and
the
tests
actually
failed
when
there
was
a
arch
linux.
Image
was
added
recently
and
the
tests
weren't
running
and
the
tests
were
now
failing
since
then
so
damien
and
I
had
the
fun
of
fixing
those.
D
B
C
It
is
and
tell
people
well.
If
you
want
to
do
something
else,
you
can
always
build
your
own
images
that
are
custom
made.
Just
for
you
and
from
my
point
of
view,
this
would
make
it
much
easier
for
us
to
stay
up
to
date
with
base
images
and
various
package
related
security
fixes,
and
all
of
that,
rather
than
having
to
adjust
a
dozen
different
variants,
all
the
time
and
keeping
them
updated.
A
C
Agree
right-
and
I
mean
those
are
kind
of
low-hanging
fruit.
The
problem
is,
there
are
so
many
linux
distributions
that
are
actually
actively
maintained
and
are
reasonable
choices,
and
everyone
has
their
favorite
linux
distro,
and
so
they
submit
a
new
variant
for
jenkins,
because
that's
the
one
destroyer
they're
using
and.
C
I
don't
really
see
the
point
of
doing
that
again.
I
am
very
biased
because
I'm
the
one
that
receives
the
report
says
your
package
is
outdated
and
then
there
are
security
vulnerabilities
in
the
package
nobody's
even
using
yeah,
but
it
would
make
the
image
maintenance
easier,
especially
given
that
we're
historically
at
least
not
been
great,
with
con
continued
maintenance
without
interruptions,
because
you
know
people
lose
interest,
move
on
to
a
different
project
and
then
suddenly
you
know
something
that
should
be
maintained,
isn't
and
you
cannot
fault
the
people
for
losing
interest.
B
C
That's
basically
it
and-
and
I
mean
the
my
favorite
distribution-
there
is
one
way
to
phrase
it
that
almost
seems
reasonable,
and
that
is
it's.
My
information
security
team's
requirement,
which
is
just
business
speak
for
this
is
my
favorite
distribution.
But
why
make
this
a
problem
of
the
project
right?
Because
everything
they
upstream
suddenly
becomes
our
problem?
C
And
so
maybe
maybe
it
makes
sense
for
us
to
consider
a
more
opinionated
approach.
There
saying
we
provide
the
image
that
we
feel
is
the
correct
one
and
if
you
prefer
a
different
one,
you're
free
to
roll
your
own
again,
just
my
perspective
as
someone
who,
admittedly
doesn't
care
at
all
about
the
underlying
system,
because
it
really
doesn't
matter
to
me,
but
perhaps
something
to
consider.
A
That's
I
I
think
that
makes
sense
in
terms
of
if
we
were
to
take
that
approach.
It
seems
like
we
would
need
to
do
a
at
least
an
announcement
saying:
hey
we're
intentionally
so
conceptually.
Let's,
let's
take
this,
what
if
we
said
all
right,
we're
going
to
stop
supporting
alpine
and
stop
supporting
centos
7
and
stop
supporting
debian
10,
switching
only
to
debian
11
or
some
some
mix
of
those
there
are.
Certainly
there
will
certainly
be
noise
in
the
community.
A
C
I
think
it's
too
early
to
talk
about
implementation
detail
when
so
far
it's
been
the
three
of
us.
It
was
just
you
know,
something
that
my
mind
when
I
don't
even
know
what
it
was
think
at
the
time
I
was
thinking
about
bill
times.
I
also
saw
a
twitter
thread
about
what
it
means
for
someone
to
do
a
poll
request
or
request
a
feature
be
added,
because
that
implicitly
says
yeah.
C
B
B
B
C
C
Yeah
the
problem
is,
I
think,
that
a
lot
of
people
actually
build
on
the
controller,
which
is
a
horrifyingly
bad
idea,
but
you
know
the
default
way.
We
deliver
jenkins
makes
this
too
easy
to
do,
and
if
you
look
at
the
usage
stats,
the
vast
majority
of
jenkins
instances
in
executive
executives,
which
are
very
likely
the
ones
configured
by
default
for
the
built-in
node.
C
So
obviously,
we've
done
things
like
the
admin
monitor
to
recommend
doing
this.
Otherwise,
and
we've
updated
the
documentation
to
explain
exactly
why
this
is
a
bad
idea,
but
this
might
be
just
you
know,
people
actually
building
on
the
controller,
and
I
cannot
think
of
a
different
reason
to
install
git
lfs
by
default
on
the
controller
which
we
do
so.
That
would
also
be
one
of
those
things.
If
do,
we
actually
need
git
lfs
installed
by
the
default
and
the
controller
if
you
actually
implement
our
best
practices
and
do
all
of
the
actual
building
on
agents?
B
A
C
Right,
that's
that's
what
I'm
saying
if
it!
If,
if
you
implement
the
best
practices-
and
you
don't
need
it,
we
should
not
deliver
it
because
that
sends
the
signal
yeah,
just
you
know,
do
whatever
and
while
we're
added,
I
think
some
of
the
packages
grant.
Other
user
accounts
read
access
on
the
jenkins
home
directory,
because
that's
a
convenient
way
for
people
to
do
something
like
copy
artifact,
plugin
does,
which
is
also
not
a
great
default
choice
I,
but
I
don't
want
to
completely
hijack
this
meeting
so.
B
C
A
Right
good
good
point:
that's
that
could
be
presented
as
the
logical
extension
of
yes,
we're
warning
you
not
to
have
not
to
run
agents
or
not
to
run
builds
on
the
controller.
Now
we're
going
to
remove
tools
from
the
controller
because
they're
not
needed
for
the
controller
itself,
and
if
you
say
you
need
maven,
we
say.
No,
you
don't
not.
On
the
controller
you
say:
oh,
I
need
and
your
example
get
lfs.