►
From YouTube: 2021 01 25 Docs Office Hours
Description
Jenkins Documentation Office Hours January 25, 2021
A
Okay,
welcome
everyone.
This
is
jenkins
documentation,
office
hours.
It's
the
25th
of
january
2021,
reminder
that
we
live
by
the
jenkins
code
of
conduct,
so
be
nice
to
each
other.
Here's
what
I've
got
for
topics!
Oh,
let's
see
vlad.
We
need
to
note
that
here
jenkins,
contributor
summit
and
how
we
deal
with
the
documentation
track
as
two
probes
as
two
proposed
topics,
and
then
we
had
pull
request,
progress
and
encouraging
new
contributors
from
underserved
communities.
A
B
Well,
related
to
the
latest
item
that
you
added
mark
it's
about
docker
installation.
I
noticed
on
github,
you
have
wonderful
repository
related
to
docker
docker
lfs.
I
guess
it
is
called
it
is
under
your
name,
and
I
noticed
that
some
branches
I
had
of
the
master,
so
they
never
merge
into
master.
So
maybe
you
can
just
well
whatever
you
want,
spend
a
couple
minutes
or
a
couple
seconds
describing
the
process
about
all
this
yeah,
because
usually
I
imagine
into
master.
A
A
A
C
A
A
We've
done
a
contributor
summit
before
where
we
use
the
fact
that
many
jank
or
some
jenkins
contributors,
many
is
probably
too
strong.
20
to
50
jenkins
contributors
commonly
find
themselves
at
fosdem
in
belgium,
each
february,
it's
a
large
open
source
software
conference
and
and
at
that
conference
we
would
gather
together
the
day
before
and
have
a
contributor
summit
where
we
talked
about
the
jenkins
project,
jenkins
development
and
the
jenkins
roadmap.
A
So
we'll
start
with
an
introductory
session
that
we
encourage
everyone
to
join,
who
wants
to
participate
in
any
way
in
the
in
the
summit.
So
all
contributors
are
welcome.
Encouraged
it'll
be
a
90-minute
session
where
we'll
introduce
some
concepts,
give
a
summary
of
how
things
are
going
where
we're
working
and
where
we're
not
working.
A
So
this
is
for
everybody,
but
then
beginning
with
that.
At
that
moment
on
day
one
and
continuing
through
the
closing
session,
we
intend
to
have
separate
sessions
in
small
blocks
of
time
throughout
24
to
24
hour
periods
at
times
that
work
for
the
participants.
So
if
someone
is
in
the
far
east,
like
raihan
shoal,
for
instance,
is
in
singapore
or
we
have
some
contributors
in
japan,
they
are
in
china.
They
can
meet
during
their
working
day
and
have
conversations
about
topics
like
chinese
localization
or
about
the
developer
experience
as
they
see
it.
A
Then
we'll
end
with
a
closing
session,
a
two-hour
block
encourage
everyone
to
attend.
It
on
day
three
and
that
will
include
a
summary
of
all
the
parts
and
pieces
that
were
presented
so
here
are
some
of
the
suggestions
that
have
gone
into
the.
What
should
the
opening
session
look
like
and
we've
got
proposed,
presenters,
etc
notice?
There's
one
topic
right
here
for
us
documentation,
and
so
the
intent
here
is
to
invite
those
of
us
who
are
in
office
hours
to
come
to
this
and
we'll
host
sessions
relative
to
documentation
in
this
three-day
period.
A
A
Actually,
this
is
for
anyone
who's
willing
to
contribute.
It
doesn't
have
to
be.
You
don't
have
to
particularly
be
experienced,
but
you,
the
intent,
is
that
you're
willing
to
continue
contributing
so
you're
coming,
not
just
asking
for
things
you're
coming
saying.
Here's
this
area,
where
I
plan
to
contribute
I'd
like
to
coordinate
my
plans
for
contribution
with
others
who
are
like-minded.
D
A
So
so,
if
they,
if
they
come
in
with
with
no
experience,
they
say,
I've
never
done
this
before
we'll
we'll
rely
on
the
session
leaders
to
keep
it
focused
on.
Where
should
we
be
going
not
on
how
to
introduce
them
to
to
being
part
of
jenkins?
Now
we
do
have
a
topic
around
see.
Where
is
it
called
it's
the
developer
onboarding
track
here
that
may
may
focus
intense.
It's
proposed
that
it
may
focus
intensely
on
what
does
it
take
to
onboard
new
contributors
and
in
the
documentation
track?
D
A
A
A
E
D
E
B
D
B
A
A
D
A
A
A
D
Style
guide
because
the
the
half-assed
I
hear
that
you
and
tammy
have
an
agreement
to
steal
from
each
other
when
you
want
to,
and
you
won't
go
after
each
other
and
you
won't
coordinate,
etc.
Tammy
has
put
together
a
very
good
style
guide
for
our
docs
and
there's
no
reason
why
the
open
source
community
has
to
stick
to
those,
but
there
would
be
advantages
to
us.
It
might
be
worth
us
contributing
this
and
saying.
Does
anybody
have
any
objections?
D
A
D
D
A
B
D
Section
there's
some
out
on
the
wiki
there's
a
bunch
of
stuff,
that's
really
old.
It
should
not
be
showing
as
current
documentation,
but
it's
still
kind
of
fun
to
go
back
and
you
know
when
pipeline
was
brand
new
or
when
these
things
were
brand
new.
What
did
they
say
about
it
and
I
don't
know,
should
we
just
bury
that
or
should
we
have?
A
A
A
As
static
pages
no
longer
editable,
because
it's
already
read-only
right,
should
we
capture
the
static
pages
and
then
turn
off
the
wiki
engine,
so
that
all
we've
got
is
a
bunch
of
static
pages
and
then
we
could
migrate
content
from
the
static
pages
and
leave
the
static
pages
as
the
historical
documents.
You
were
mentioning.
A
A
B
B
A
Their
needs
they.
I
would
hope
that
those
kinds
of
hey
I'm
missing
this
infrastructure
or
mission,
that
ain't
missing-
that
information
we
use
as
input
to
the
documentation,
inventory,
review,
exercise,
review,
questions
and
from
users
as
input
review
comments
in
the
user
feedback
spreadsheet
for
jenkins
dot
io,
I
other
than
the
four
letter
words
that
are
sometimes
spread
in
there
by
people
who
are
really
frustrated.
A
B
A
D
D
A
A
The
beginnings
of
my
docs
outline
and
we'll
talk
about
it
and
try
to
highlight
hey
here's.
What
I've
learned
invite
the
two
of
you
then,
to
help
me
with
making
comments,
improvements,
I'm
assuming
I'll,
just
use
a
google
doc
because
that's
convenient
and
an
easy
way
to
do
to
do
comments
and
corrections.
D
Right
one
other
question:
that's
and
you
guys
can
shut
me
up
anytime.
You
want
to
lurking
in
all
of
this
is
the
question
of
audience:
god,
I'm
going
back
to
old.
I'm
sound
like
an
old
writer,
but
I'm
struggling
with
some
of
that.
We
have.
My
impression
is
that
when
jenkins
was
first
put
together,
whoever
used
jenkins
did
it
all
and
it
was
structured
that
way.
D
But
I
haven't
gotten
into
that
but
stuff
like
notifications
and
credentials
and
there's
a
lot
of
these
things
where
there's
an
administrative
part
and
there's
a
pipeline
part,
and
should
they
be
documented
together
as
the
technology
or
should
that
here's,
how
you
use
credentials
in
your
pipeline
and
here's
how
you
set
up
credentials
as
an
administrator
and
you
can
make
arguments
either
way.
But
I'm
you
know
I'm
wondering
if
it
would
make
sense
for
us
to
consider
and
have
some
sort
of
general
statement
about
where
we
want
to
go
forward.
A
A
A
D
D
Well,
I
think
in
the
in
the
jenkins,
I
I
don't
think
we
have
a
place,
there's
only
like
how
to
use
maven
how
to
use
gradle.
It's
not
our
subject,
but
we
don't
tell
them
if
you've
used
maven
for
your
builds.
Here's
how
you
call
those
scripts,
here's
the
synth,
the
pipeline
syntax
for
calling
those
right.
I
actually
know
where
you
could
steal
some
source
material
for
that.
A
D
I'm
almost
okay
with
anything.
I
just
think
we
need
to
have
some
place
and
agreed
on
strategy,
and-
and
I
you
know-
and
I
yeah
because
I
mean
this-
is
back
in
the
80s
that
was
god:
ieee
tried
to
have
a
a
standards
group
for
documentation
and
they
met
for
months
and
months,
and
I
think
about
all
they
agreed
on
was
that
you
should
know
your
audience.
First,
okay,
you
know,
and
I
I
think,
we've
moved
beyond
that.
D
But
it's
you
know,
but
it
if
some
of
it
is
like
you
know,
and
maybe
and
some
of
it
is
going
to
happen,
there's
going
to
have
to
be
arbitrary
distinctions.
It
may
be
that
right
now
we
say
this
is
how
you
define
a
credential
and
you
must
have
admin
or
you
must
have
not.
You
must
have
permissions
given
to
you
through
whatever
your
security,
your
security
matrix.
D
Your
authorization
is
to
do
this
and
then
in
the
pipeline,
here's
how
you
call
credentials
to
get
to
a
resource,
and
somebody
else
had
to
have
set
this
up
and
we
become
fairly
arbitrary
in
a
small
shop.
You
may
be
the
one
who
goes
boat
if
we
link
back
and
forth
it's
like
it's
some
it
was.
You
know
if,
if
you
were
a
pure
pipeline
developer,
this
should
be
done
for
you
by
somebody
else,
and
you
know
which
is
it's
an
arbitrary.
A
B
Well,
yeah,
I
agree
actually
mark
that
it
is
sometimes
very
hard
to
distinguish
if
the
content
refers
to
the
user
material,
to
developer
material
or
to
administrators,
and
I
guess
right
now
we
have
even
in
january's
dot
io
two
kind
of
us
administrate,
related
sections.
One
is
system
administrator
and
the
other.
I
even
forgot
how
we
call
that
administrator,
not
system,
but
something
else.
B
C
A
B
A
I
I
like
that,
I
think
I
think
that
is
intensely
valuable
and,
and
it
could
use
someone
who
has
a
different
set
of
skill
sets
right.
There,
we've
got
people
who
can
contribute
by
writing
and
describing
what
they've
experienced
the
site
search
thing
is
more
of
a
technology
and
deployment
thing
that
it
is
a
writing
thing,
and
so
I
think
that's
this.
In
fact,
we've
got
another
one.
That's
just
happening
right
now
is
additional
improvements
to
the.
A
So
the
reason
there
is
make
to
your
pipeline
authoring
question
or
the
pipeline
authoring
challenges.
There
are
times
when
I'm
sitting
inside
of
a
pipeline
step.
For
example,
let's
go
to
the
pipeline
steps
reference,
and
let's
pick
one
that
I
know
about
this
one
okay,
so
here
is
a
description
of
a
pipeline
step.
A
However,
if
I
down
at
the
bottom,
oh,
it's
gone
good,
okay,
on
every
other
page
on
jenkins,
documentation
right
here
in
the
bottom
left
corner
there
is
a
is
an
improve.
This
page
link
that
will,
let
me
improve
it.
It's
not
here,
but
this
was
this
page
helpful.
All
it
does
is.
Let
me
complain
about
it,
not
let
them
not
take
them
to
the
place
where
they
can
actually
improve
the
text
that's
written
here,
and
this
is
coming
from
a
source
repository,
so
it
could
be
a
link.
So
that's
that's
one.
A
B
D
A
A
But
what
we've
got
right
now
is:
we
have
improved
this
page
at
the
bottom
bottom
corner
and
one
of
the
suggestions
had
been
okay.
Let's,
let's
take
this.
Let's
take
our
example
here
installing
jenkins,
I'm
in
installing
jenkins
on
docker,
I'm
here
on
this
thing
and
I'd
like
to
improve
some
phrasing.
A
Well,
there
isn't
an
immediately
obvious
way
here
on
the
thing
I'm
seeing
this
hovert
hover
shows
me
a
hyperlink
what
if
there
were
a
hover
pencil
right
next
to
it
right,
oh
yeah,
that
would
take
me
to
to
the
github
page.
Yes,
if
I
scroll
down
so
if
I
scroll
down,
I
can
at
the
bottom
of
the
page,
find
and
prove
this
page,
and
it
will
take
me
to
a
page
that
represents
this.
A
D
A
A
A
A
B
A
A
That's
one
that
I've
got
to
work
with
kristen
whetstone
to
learn
what
I've
done
wrong
and
why
I
didn't
why
it's
the
steps
aren't
quite
working
for
me
and
then
we'll
we'll
merge
it
docker
install
instructions
now
vlad
you
had
asked
about
this.
One
we've
got
about
15
minutes.
Are
there
other
topics,
because
this
one
could
spend
a
long
time
with
me
with
me
droning
on
about
what
the
concept
is
and
why
it's?
Why?
It's
doing
that.
D
A
A
B
A
A
A
A
A
This
is
the
thing
I
manage
as
code
and
it's
got.
Let's
look
first
at
the
agents
that
are
connected,
so
the
agents
include
two
arm
servers
on
amazon,
linux,
a
windows,
computer,
two
freebsd
computers,
centos,
seven
centos,
eight
debian,
10,
w9,
suzy,
15,
ubuntu,
18,
ubuntu,
20.,
debian,
freebsd
windows,
an
ubuntu,
a
powerpc,
a
system,
390
mainframe,
wow
yeah
an
nvidia.
A
What
do
they
call
it?
Nano
which
is
a
is
a
an
arm
processor
with
a
gpu
attached
and
then
oracle
linux,
some
open,
bsd,
open,
susie,
some
raspberry,
pi's,
etc.
So
no
facts,
sorry
novak's
you're
right!
I
missed
not
having
a
bax,
because
I
don't
think
java
runs
out
of
acts,
so
yeah
good
point,
but
but
the
idea
was
okay.
This
thing
is
a
an
intentionally
maintained
environment.
Where
I
can
experiment
with
jenkins
in
all
sorts
of
places
and
ways,
then
the
concept
goes
further
with
okay,
each
of
the
each
of
these.
A
I've
got
jobs
that
build
the
jenkins
plug-ins
that
I
maintain,
or
that
are
important
to
me,
and
these
are
github
organization,
or
these
are
github
multi-branch
pipelines
so
that
the
get
plug-in,
for
instance
here,
are
all
of
its
branches
and
all
of
the
things
that
I
care
about
on
it.
So
I
can
see
code
coverage
reports
on
the
the
git
plugin,
so
that's
been
helpful.
A
B
So
much
no,
I
was
my
intention-
was
initial
intention
was
to
fork
this
repository
and
duplicate
the
work
that
you
were
doing,
because
I
found
well
it's
interesting
concept,
but
now
I
realized
it
is
result
of
many
years
of
research
and
development
that
you
had
done
and
you
put
it
in
this
repository
plus.
You
have
private
repositories
repository
at
least
one.
C
B
A
But
so
I
hope
it
I
hope
it
would
work.
I
originally
created
it
with
the
intent
that
others
could
fork
it
really,
the
more
the
more
I
worked.
Well
yeah.
So
so,
certainly
you
I
won't.
I
won't
grant
anyone
access
to
the
private
stuff
right
because
it's
got
my
credentials
in
it,
but
the
public
things
the
public
things
that
are
here.
A
B
A
A
A
Well
and,
and
that
same
that
same
treating
treating
branches
as
a
stack
on
top
of
something
else
also
happens
in
this
other
repository
in
this
jenkins,
bugs
repository
that
I've
been
tracking
right
in
my
in
my
jenkins,
bugs
repository,
it's
the
same
kind
of
thing,
where
each
attempt
to
verify
a
bug
is
an
independent
branch
that
will
never
merge
to
the
master
right.
They
are,
they
are
and
it's
it's
the
same
thing
it's
like.
A
Oh
branches,
don't
have
to
always
merge
to
to
a
central
location,
and
in
this
case
it's
helpful
and
in
this
one
it's
helpful
that
they
don't
merge,
yeah,
so
you're,
but
you're.
Your
observation
is
correct.
This
this,
a
repository
that
is
or
a
branch
that
is
4
000
commits
by
the
head
of
master,
is
quite
odd.
B
A
Actually,
because
because
this
is
exactly
the
concept
that
this
concept
of
a
patch
stack
is
exactly
what
the
freebsd
people
do
and
what
I
think
openbsd
does
with
their
package
their
package
system
where
they
they
say
you
can,
you
can
rebuild
packages
in
freebsd
and
they
do
it
by
taking
the
original
code
from
somebody
else,
layering
a
little
bit
a
little
bit
of
a
patch
on
top
of
it
and
then
build
it.
So
that's
all
this
is
you
know.
This
is
just
that
same
thing.
A
A
A
Thank
you
mark
yeah.
So
so
again
you
are
welcome
to
fork
the
dr
lfs
repository
and
and
I'm
proud
to
say
that
this
jenkins,
bugs
repository
there
are
other
developers
in
the
community
who
are
using
a
similar
technique.
Now
I
know
of
at
least
one
so
so
it's
not
that
this
is
the
only
place
that
this
is
happening.
Other
people
are
using
similar
things.
A
A
All
right
so
look
forward
to
checking
with
you
vlad.
I
will
also
submit
a
pull
request
within
the
next
few
minutes
to
do
this
one
and
I'm
going
to
submit
the
jenkins
2.2
to
jenkins
2.2
77
change
log
due
today,
because
it
will
release
tomorrow
so
I'll,
submit
that
and
hopefully
you'll
see
it
later
tonight
or
others
can
review
it.
If
you're
not
available.