►
From YouTube: 2021 05 07 Platform SIG
Description
Jenkins platform SIG discussed Java 11 as default for Docker images, Docker image generation improvements, and progress on pending pull requests
A
Okay,
did
I
get
welcome
to
the
jenkins
platform
special
interest
group
meeting?
It's
the
7th
of
may
2021
reminder
that
we
abide
by
the
jenkins
contributor
code
of
conduct,
so
thanks
very
much
for
being
here,
topics
that
I
had
on
the
list
open
action
items
securing
the
jenkins
delivery
pipeline
java
11
as
default
in
all
our
images
proposed
docker
changes,
security
scanning
status;
anything
else
that
we
should
add
to
the
agenda
alex
or
gareth
anything
that
you
have.
That
needs
to
be
included.
A
A
A
A
C
Actually,
I
thought
his
concern
was
on
the
other
versioning
scheme.
Oh
oh,
oh
it
was.
It
was
hard
to
read
because
it's
a
slack
thread,
but
it's
it's
difficult
to
read,
but
I
took
it
as
when
I
put
the
example
as
807.
some
random
char.
I
think
his
concern
was
with
that
because
that
won't
work
with
major
versioning
semantics.
A
Okay,
all
right
so
to
so.
I
just
need
to
let
me
take
the
action
to
discuss
with
him
to
confirm
that
the
the
technique
we're
using
in
elastic
access
is
not
going
to
be
a
problem
for
maven,
because,
as
far
as
I
understood,
what
we
did,
there
looks
exactly
like
semantic
versioning
right.
It's
exactly
three
components
and
applies
the
semantics
of
okay
patches
increment.
The
rightmost
component
features
increment
the
middle
and
breaking
changes
increment.
The.
C
A
C
A
B
C
A
A
C
Yeah
the
report
version
pipeline.
We
added
as
a
sort
of
a
method
of
debugging
what
jake's
release
version
was
going
to
determine
as
the
next
version,
because,
because
it
can
be
run
on
workflow
dispatch,
you
can
select
a
branch
to
run
it
against.
So
it's
just
it's
just
a
useful
debug
tool.
It
just
prints
out
to
see
what
the
version
is.
So
it's
quite
handy.
A
A
A
All
right
now,
I'm
still
I'm
still
not
fully
personally
through
the
transition
yet
to
using
cement.
Using
can
what
oh
there
it's
conventional
commits
is
is
still
a
learning
curve
for
me
right.
I
haven't
yet
trained
myself
to
always
use
a
conventional,
commit
marker
text
and-
and
that's
just
needs
practice.
C
Pipeline
I
mean
as
something
in
the
future
that
you
could
do.
You
could
determine
the
next
version
number
based
on
the
release:
drafter
config
we're
not
so
much
the
releaser
after
conflict,
but
with
the
release.
Drafter
content,
that
if
we
say
it's
a
major
release
or
breaking
change,
we
would
use
that
to
bump
the
next
version.
A
C
C
Yeah
so
you're
so
you're
like
if
you
have
a
new
features
and
improvements
for
ins,
for
instance,
that
would
be
that's
a
feature.
You
know.
That's
a
minor
release
there.
If,
if
it
comes
up
as
major
changes,
then
we
know
to
bump
it
from
that.
So
if
you,
if
you
don't
want
to
use
the
conventional
commits
as
a
as
a
process
or
as
a
way
of
determining
this
stuff,
that
may
be
an
easy
way
of
doing
it.
A
C
Yeah
something
other
than
jx
release
version,
but
I
think
I
mean
you:
could
it
wouldn't
be
too
difficult
to
do,
because
I
think
the
difficulty
would
be
like
if
you
have
to
make
a
multiple
get
out
calls.
If
you
have
api
calls
to
be
able
to
determine
that,
then
it's
going
to
be
difficult
and
you
probably
need
to
write
something
to
be
able
to
do
that
and
handle
that
with
this
you
should
be
able
to
do
it.
C
C
A
A
And
yeah
that,
I
think,
was
the
two
comments
anything
the
two
of
you
want
to
guide
there
in
terms
of
where
we
should
go
with
that.
I
think
I'm
prone
to
this
maintain
java
8
for
a
limited
period
after
that,
because
because
it's
we
don't
have
enough
java
11
adoption
yet
in
the
in
in
the
jenkins
installed
base
that
I
can
see.
B
Yeah,
I
think
we
probably
have
to
maintain
java
for
a
period
of
time
just
based
on
the
feedback
that
was
on
the
mailing
list
about
java
11,
and
that
was
just
for
that
wasn't
even
for
the
docker
images,
necessarily
that
was
just
in
general
for
updating
the
source
level
to
11.,
but
it
seems
like
there's
still
a
lot
of
people
who
use
java
8,
so
we
can't
really
just
drop
it
right.
Okay,
although
for
docker
containers
to
me,
it
seems
kind
of
weird
that
it
would
matter
that
much.
B
A
B
C
A
A
A
A
A
A
A
C
A
Good
all
right,
thank
you
and
announcing
those
changes.
We're
not
ready
to
merge
them.
Nothing
to
announce
yet
security
scanning,
so
oleg
is,
has
made
further
progress
with
linux
foundation,
security
and
sneak
and
is,
is
actively
starting
a
co-working
thing
with
them
to
help
adapt,
sneak
to
better
understand
or
adapt
what
we
need
in
sneak
so
that
it
will
better
understand,
jenkins,
use
of
maven
and
not
incorrectly
flag
things
as
a
dependency
that
are
that
are
included
as
a
dependency
by
the
maven
hp
by
our
our
hpi
process.
A
The
there's
there's
work
going
on
there,
so
very
glad
for
the
progress
only
it's
making.
He
regularly
reports
on
that
in
the
governance
meeting
and
elsewhere
code
ql
scanning
I'm.
I
think
this
is
where
we're
now
in
discussions
of
how
do
we
deploy
it
more
broadly
and
hosting
requests
so
oops
so
alex
in
terms
of
hosting
requests.
I
assume
it's
still
being
used
there
is
that
correct.