►
From YouTube: 2020 12 14 Docs Office Hours
Description
Jenkins documentation special interest group office hours Dec 14, 2020. Topics include LTS release line, Docker images, release workflow, and tutorial alternatives for plugin installation manager.
A
Welcome
to
season
or
two
to
the
doc's
office
hours,
it's
the
14th
of
december
and
I've
extended
this
particular
document
to
cover
both
monday
and
thursday
office
hours
so
monday,
office
hours.
We
do
for
the
benefit
of
those
of
us
in
the
u.s
west
and
thursday
office
hours.
We
do
for
more
more
for
those
in
europe,
okay
and
in
africa.
A
A
A
I
am
proud
to
say
that
I've
started
detailed
review
of
pr
3979
scaling
jenkins
on
kubernetes,
and
there
are
a
number
of
challenges
there,
so
vlad
this
may
be
one
where
you
can
guide
me
so
running,
jenkins
and
mini
cube
is
complicated
right.
You
know
you
have
to
deal
with
ingress.
You
have
to
deal
with
installation
with
what
else
with
oh
docker
image
repositories.
A
A
We
are
actually
down
slightly
from
the
number
of
open
pull
requests
we
had
before.
So
that's
a
plus
and
so
right
now
we've
got
29
open
with
two
or
three
of
those
two
of
those
having
just
arrived
within
the
last
24
hours.
So
we're
we're
down
from
the
35
that
we
had
reached
before
making
progress,
but
more
work
to
be
done.
A
A
B
A
A
A
A
B
B
B
Yes,
this
one
and
it
defines
which
are
stable
release
in
our
like
on
github,
and
it
sells
that
packaging
and
there
is
releases-
I
guess
somewhere
yeah
releases,
yeah
stable
releases,
stable
releases
is
a
manually
triggered
release
that
happens
around
once
a
month.
So
it
duplicates
the
same
kind
of
statement
that
it
is
once
a
month
and
it
is
manual
triggered
release
at
the
same
time
in
our
documentation,
specifically
in
download
page
on
jenkins.io.
B
B
Yeah
and
we
can
see
that
there
are
like
a
little
bit
up-
there
are
different
lts
releases
and
those
lts
releases
like
31
minutes
ago,
36
minutes
ago,
and
so
on.
So
in
spite
of
the
fact
that
lts
release
was
well
delivered,
I
guess
we
have
blog
on
that
some
time
ago.
It
happens
like
in
automatic
fashion.
I
guess
versus
what
is
documented.
It
happens
manually
and
it
happens
once
a
time
so
I've
found
it
is
kind
of
inconsistent.
A
A
A
A
D
A
A
C
C
B
A
Image
right
right,
so
the
way
the
way
a
jenkins
lts
is
constructed
is
by
adding
a
relatively
small
number
of
so
the
2.263.2
its
release
candidate
is
being
developed
right
now.
The
proposed
pull
request
has
been
submitted
by
tim
jacom,
the
release
officer,
and
in
that
pull
request
he
proposed
a
set
of
five
or,
as
maybe
as
many
as
eight
or
nine
changes
that
he
thinks
should
be
brought
in
from
other
streams
into
236
263.2.
B
D
A
C
A
C
A
C
A
The
docker
image,
so
the
docker
image
based
on
alpine
3.9,
was
outdated
for
operating
system
security
fixes
because
they'd
stopped
patching
it
because
the
docker
pro
the
alpine
project
stopped
patching
it
applying
security
fixes,
and
so
what
we
did,
then,
is
the
jenkins
project.
Thankfully,
oleg
nanashov
upgraded
from
alpine
3.9
as
the
opera
as
an
operating
system
base
to
alpine
3.12,
and
we
will
do
something
similar.
A
C
A
A
B
A
D
D
A
B
A
Yeah
and
and
that's
a
good
point
vlad
it's
the
process,
documentation
we
generally
put
other
places
because
the
outcome
outcome-based
documentation,
the
results
documentation
is,
we
think,
mostly
what
the
users
want.
They
want
to
know.
Where
do
they
find
an
lts?
How
do
they
know
what
changed
in
the
lts
there
to
them?
It's
largely
and
don't
care
how
we
created
the
lts.
They
they
trust
us
and
we've
got
though
I
guess
this
one
is
a
good
one,
and
a
good
example
of
this
is
very
much
a
process
document.
D
A
A
C
B
A
B
B
Well,
we're
using
inside
actually
inside
our
documentation
when
describing
how
to
create
a
docker
ins,
jenkins,
docker
installation,
by
using
a
plugin
installation
manager
as
the
tool
to
build
our
customized
documentary,
docker
release
and
this
plugin
installation
manager
it.
I
guess,
fits
into
category
of
the
tools,
not
plugins,
it's
the
tool
which
manages
installing
plugins
and
so
on,
and
we
have
the
section
in
our
recommendation
describing
tools.
B
A
A
D
But
but
we
don't
go,
you
know
there's
a
lot.
Some
of
those
commands
are,
you
know,
abandon,
hope
all
who
enter
here
and
others
are
very
nice
useful.
You
know
and
we
have
no
place
to
reel
where
that's
never
really
documented
or
just
something
you
know
some
sample
scripts
and
and
then
I
wrote
this
beautiful
sample
script,
and
now
I
can't
run
it
because
I
don't
have
the
permissions
or
or
it's
waiting
for
you
know
the
the
system.
God
to
give
me
permissions,
or
you
know
something
that
puts
together
all
those
pieces.
A
Yeah
and
those
are
the
those
I
think,
that's
a
very
good
insight-
the
if
we
had
something
for
the
jenkins
command
line
interface
as
a
tutorial.
So
how
do
you
use
the?
How
do
you
use
the
tutorial
how
to
use
the
cli
with
the
cli
jar
file
with
ssh
connections
with
websocket,
I
mean
there
are
some
cool
things
there.
Likewise,
the
rest
api,
yeah
good,
now
vlad
you
had.
You
had
started
the
question
with.
Should
we
have
a
tutorial
that
describes
the
plug-in
installation
manager?
A
B
A
D
D
A
A
C
A
Yeah
so
and
and
their
administration
tutorials,
it's
yeah
any
one
of
these
seem
certainly
this
one,
for
example,
jenkins
job
dsl.
I
don't
understand
how
to
use
it
and
I'm
aching
to
learn
how
to
use
it.
So
this
one
that
one
configurations
code,
I'm
very
comfortable
with
I've,
used
it
a
lot
and
love
it.
So
so
each
of
these
has
has
compelling
value
in
certain
portions
of
the
jenkins
use
experience.
B
And
I
guess
mark,
we
also
need
to
address
the
question
about
the
difference
between
tutorial
and
just
general
chapter
in
our
documentation
because
for
siegment
administration
we
have,
I
guess
chapter
it
was
called
the
right,
but
maybe
not
enough
jenkins,
documentation
yeah
in
fact
good
point
right,
okay,
now!
Well,
I
guess
we
need
maybe
for
ourselves
to
clarify
what
is
the
difference
between
user
handbook
and
tutorial
and
is
there
any
difference.
A
A
Let's
create
a
cli
tutorial
when
we
we
don't
yet
or
even
better
cli
rest
ap,
a
rest
api
tutorial
when
we
don't
yet
have
a
good
tutorial
in
the
developer,
docs
or
elsewhere,
or
not
a
good,
a
good
reference
set
for
for
that
topic.
So
managing
plugins
feels
like
a
great
topic
for
managing
jenkins.
Doesn't
it
and
and
we've
got
a
page
and
it's
I'm
pretty
sure,
woefully
inadequate
right?
I
mean
the
the
many
different
ways
that
you
can
manage.
D
D
You
know
a
back
assumption
that
the
people
who
do
this
power
stuff
are
going
to
be
powerful
people
and
they'll
figure
it
out,
which
is
not
necessary,
which
means,
I
think,
that
a
lot
of
people
are
missing
out
on
a
lot
of
really
good
functionality
or
they're
finding
out
about
it.
Only
in
you
know,
side
places,
but,
like
I
don't
see
the
user
guide
as
being
reference
material,
I
guess
I
would
love
to
see.
D
D
D
A
D
Yeah,
but
it's
you
know,
I
would
almost
I
would
like
the
user
guide
to
almost
be
more
tutorial.
You
know
this
is
an
example
of
how
you
use
it
and
then
go
here
to
find
all
of
the
all
the
cli
commands,
all
the
syntax
or
whatever,
and
have
that
broken
out
into
separate
reference
material
that,
even
if
it's
not
man
pages
you
know
be
it
separated,
because
that
also,
if
I'm
trying
to
get
the
basic
big
picture,
then
having
all
the
details
of
every
last
little
jot,
twiddle
and
option
is
intrusive.
D
D
D
A
Oh
right,
I
think
so
yeah
I
think
that's
the.
I
think
what
we've
really
said
here
is
here.
Earth
here
are
topics
we
already
know
would
be
interesting
for
people,
and
then
the
question
is:
do
we
already
have
places
for
for
these,
and
I
think
we
do
for
this
one,
or
at
least
for
several
of
these
we
could
identify,
which
section
they
might
logically
add
be
added
to
as
reference
material,
because
if
I
look
at
this
one,
for
instance,
jenkins
cli
is
there's
reference
material
for
it
and.
A
A
D
I'm
toying
with
the
idea
that
we're
still
that
what
we
really
need
to
do
is
re-architect.
I
re-architect
the
administration
documentation
that
some
of
what
they're.
Well
I
see
it
there
there's
there's
tutorial
generally,
I
think
of
tutorials
as
getting
started
for
for
novice
users
exactly,
but
then
there's
another
level
of
guy.
Let's
call
it
guide
type
information
for
power,
users
or
people
who
are
trying
to
become
power,
users
and
they're
separate,
and
there
is
the
question
of
the
fact
that
we
have
the
reference
and
the
guide
all
jumbled
together
and
inconsistently.
D
A
Well,
so,
for
me,
tutorials
are
step
by
step,
whereas
the
handbook
content
is
so
the
tutorials
talk.
Take
us
through
a
step
at
a
time.
Do
this
do
this?
Do
this,
whereas
the
the
handbook
material
takes
us
through
concepts
like
here,
are
here's
what
shared
libraries
are
in
pipeline?
Here's
how
you
deal
with
branches
and
pull
requests.
D
D
C
D
A
Yeah,
I
I
would
think
if
it
were,
if
we
were
trying
to
do
a
tutorial
with
this,
we
would
likely
start
with
a
problem
statement
and
take
the
user
through
how
with
how
this
tutorial
will
solve
their
problems.
So
the
problem
statement
might
be.
I
want
to
use
blue
ocean
or
it
might
be.
I
want
to
use
blue
ocean
and
I
want
to
use
declarative
pipeline
or
some
story
like
that,
and
then
we
would.
The
tutorial
would
solve
that
that
that
hypothetical
problem
we've
presented
to
them.
D
Is
that
a
complicated
enough
thing
I
mean
so
you
end
up
potentially
with
the
tutorial,
for
I
want
to
use
get
or
I
want
to
use.
Is
that
worth
all
of
those
tutorial
I
mean:
do
things
change
or
aren't
the
things
you
do
to
manage
plugins
pretty
much
the
same
for
all
of
the
plugins?
Am
I
missing
something.
A
C
B
C
D
D
A
D
D
A
It
isn't
right,
and
so
this.
For
me,
this
is
missing
so
where,
where
is
it
describes
two
techniques
to
install
plug-ins?
There
are
at
least
two
or
three
others
right
there's
I
can
install
plug-ins
with
plug-in
installation
manager
tool.
I
can
install
plugins
with
the
deprecated
install
plugins.sh
script,
yeah.
D
C
D
Yeah
it's
like
I
mean
I
can
also
see
like
a
lot
of
what's
here
going
away
and
you
sort
of
say
you
can
manage
them
these.
You
know.
Theoretically,
if
we
had
all
this
stuff,
this
could
be
a
fairly
short.
What
are
plugins,
and
what
do
you
mean
by
managing
them
that
you
got
to
install
them
and
you've
got
to
configure
them
and
you've
got
to
upgrade.
C
D
B
D
But
it
is
there's
a
lot
of
I'm
seeing
like
script
console
and
groovy
hook,
scripts,
which
I
haven't
looked
at
for
a
while,
but
there's
a
lot
of
subjects
that
are
out
there
that,
but
there
isn't
something
that
sort
of
puts
it
together.
Does
that
make
sense?
Give
you
the
big
picture
to
know
what
all
this
is.
A
A
D
I
think
there's
probably
many
paths
what
we
lack
is
sort
of
an
architecture
about
how
we're
doing
this
is
that
each
piece
you
know
got
written
by
somebody
who,
with
some
competence,
has
got
some
information.
You
know,
and
maybe
that
maybe
if
there
were
a
single
issue
yeah,
it's
that
it's
hard
to
see
the
big
picture.
A
D
I'm
talking
to
tammy
way
too
often
these
days,
you
might
notice,
but
there's
an
argument
for
an
information
architecture
of
what.
How
do
we
do
this
and
because
well
another
thing
that
we
didn't
there
are
things
like
in
this
case:
I'm
not
actually
sure
that
the
catacota,
if
you
know,
given
that
it's
gonna,
be
an
expense
that
we
can't
do
for
everything.
D
D
B
A
C
D
D
I'm
not
sure
that
I
mean
those
there's
everything's
merging
together,
because
everything
is
remote
and
online
and
I
don't
buy
books
anymore,
and
what
does
it
mean
that
I'm
going
to
take
I'm
going
to
go
over
and
take
this
training
module
or
I'm
going
to
take
a
tutorial?
Or
you
know
that
that
all
we're
sort
of
trying
to
play
with
old
categories
that
are
no
longer
relevant.
But
I
don't
know
how
far
to
go
in
merging
them.
Do
we
just
say
it's
one
information
set,
that's
not
sure.
D
It
is,
we
are
gonna,
we
are
gonna,
throw
out
everything
and
we're
not
gonna
have
a
revolution
whatever
we
do.
We're
gonna
have
to
start
moving
towards
it
incrementally
and
putting
the
areas
that
are
the
most
egregious
difficulties
right
now
and
pulling
those
out
and
re-architecting
them.
But
it
would
be
nice
if
we
started
working
towards
some
sort
of
common
definition
or
something
of
the,
and
I
don't
know
you
know
it's
it's
something
that
doesn't
exist
because.
C
B
I
had
some
trouble
actually
running
the
tests
on
my
mac
and
I
figured
out
that.
Well,
it
was
the
version
of
maven
because,
like
I
was
able
to
do
this
using
google
cloud
shell,
where
was
the
latest
maven
version,
but
on
my
mac
it
was
not
the
latest
but
version
35,
something
and
with
this
previous
version
of
maven
there
were
some
errors
as
well,
so
yeah.
D
C
A
B
A
D
A
A
C
A
Yeah
now
december
28th
I'm
back
available.
We
could
we
can
meet
december
28th.
Most
most
of
the
of
my
colleagues
at
the
in
the
company
will
be
off
and
I'll
be
off,
but
I'm
happy
to
talk
office
hours
anyway.
So
would
you
like
to
meet?
Do
we
want
to
meet
the
21st?
I
propose
to
cancel,
but
I'm
okay
with
meeting
the
28th.
D
A
A
C
A
A
I
have
no
idea
yet
I've
got
to
think
about
that.
The
most
crucial
thing
is
the
day
prior
will
be
our
large,
our
family
gathering,
where
we
get
all
the
the
grandkids
that
live
in
colorado
together
for
for
fun
time
and
so,
and
you
can
and
you're
going
to
do
that.
We
we
are,
we
we,
we
know
we're
all
covered,
not
non-coveted
positive,
and
we
are
going
to
very
boldly
do
that
because
we
we
like
getting
together
and
even
the
even
the
son-in-law
with
leukemia
is
likely
to
be
there
and
just
rejoice
with
us.