►
From YouTube: 2021 02 01 Docs Office Hours
Description
Jenkins Docs office hours Feb 1, 2021
A
C
A
Very,
very
good,
all
right
so
topic,
so
we've
got,
we've
got
jonathan.
This
is
one
that's
a
great
one
for
you,
because
we're
coming
we're
approaching
a
an
event
that
we
would
love
to
have
you
and
vlad
and
and
meg
all
involved
in
it's
the
jenkins
contributor
summit,
every
two
every
year
as
part
of
the
free
and
open
source
conference
in
belgium,
we
would
hold
the
jenkins
contributor
summit
and
we
would
do
it
in
person
there
at
the
at
the
event
so
that
everyone
could
get
together
in
a
room,
but
this
year.
A
A
A
A
So
what
what
this
one
is
is
a
a
proposal
that
here
we'll
go
back
here
to
this
document
to
look
at
it.
It's
a
proposal
we
discussed
last
week
with
with
megan
with
with
actually
with
meg
and
then
with
christian
whetstone
and
zinab
abubakar,
that
what
we'd
like
to
do
is
look
at
the
current
content
on
www.jenkins.io
and
wiki.jenkins.io,
and
use
that
to
assemble
a
list
of
topics
that
are
available
and
try
to
slot
the
topics
into
places
in
the
books.
A
So
it's
basically
do
more
of
what
you
had
done
for
us
for
hacktoberfest
that
kind
of
technique
where
we
say,
let's
look
at
every
page,
that's
out
there.
We
we
may
not
have
a
capacity
yet
to
to
publish
that
page
to
to
do
the
rework
for
it,
but
that
page,
if
we
publish
it,
would
be
long
here,
it
would
be
long
here
and
the
idea
is,
as
a
group
we
agree.
Oh
these
are
the
sort
of
sort
of
sections
that
belong
in
this
document.
A
These
are
the
the
general
ideas
that
might
be
inside
that
section
we
discuss
and
and
sort
of
disagree
as
necessary
dispute
with
each
other.
I
think
it
should
be
this.
I
think
it
should
be
that
so
that
we
get
a
good
framework
into
which,
in
which
we
all
agree.
Oh
these
topics
belong
here,
but
these
belong
over
here
and
and
that
way
we
get
okay.
Now
we've
got
a
plan
that
says
when
the
material
arrives
for
this,
we
put
it
here
when
it
arrives
for
this.
A
It
goes
here
and-
and
so
this
was
a
an
exercise
that
that
the
parties
that
were
we
were
discussing
with
seemed
very
interested
in
hey.
Yes,
we
could,
we
could
do
that
and
that
would
give
us
a
chance
to,
for
instance,
correct
what
I
had
initially
thought:
the
original
creators
of
the
documentation.
That
said,
let's
do
one
book
like
the
free
freebsd
handbook
and
about
two
years
ago
I
started
thinking.
Oh,
we
should
change
it
to
two
books,
user
and
admin,
but
now
I'm
back
to
no.
A
A
A
And
then
we'll
use,
then
we'll
use
discussion
and
and
think
about
it
to
decide
how
to
change
that
document.
How
to
change
the
location
now
is
it
actually
document
probably
is
the
wrong
way.
Maybe
we
really
do
want
a
google
sheet
here,
because
we
need
to
know
where
it
came
from
and
where
it's
going
so
there's
more
data
about
this
than
just
would
fit
into
okay,
so
yeah,
I'm
already
saying
it
should
be.
C
B
A
Converted
but
gives
us
gives
us
a
destination
and
and
gives
us
a
a
chance
to,
because
we
then
have
a
tabular.
We
have
a
chance
to
prioritize
which
things
we
think
are
more
useful
topics
based
on
user
interest,
so
as
an
example
to
go
back
to
meg's
meg's
point
about
the
pipeline
authoring
pipeline
authoring.
Examples
continue
to
be
a
major
request
from
users.
A
A
At
least
in
the
way
things
are
currently
done
right
now,
so
when
we
look
at
the
online
feedback
form,
let's,
let's
let
me
grab
the
doc's
feedback
just
because
you,
I
think
you
need
to
see
this
the
the
times
when
I
I
shake
my
head.
Some
of
the
words
that
are
said
here
are
really
kind
of
kind
of
harsh,
so
don't
don't
be
offended
by
the
harshness
of
some
of
the
things
people
say
here
about
hey
you're,
you're,
a
terrible
human
being
for
not
having
written
this
documentation.
A
A
D
A
A
A
A
C
A
It's
it's
not
even
that
we
duplicate
it
in
in
the
case
of
plugins,
we
actually
have
to
write
the
we
don't
write
the
instructions
in
the
in
the
jenkins
I
o
site
at
all.
We
write
them
in
the
plugin
site
in
the
plug-in
github
repositories
and
then
there's
a
program
that
extracts
that
documentation
and.
C
C
A
Just
tags,
I
think
those
would
continue.
I
would
I
think
we
would
retain
the
tutorials
and
keep
them,
because
we've
recently
had
more
additions
to
the
tutorials.
We
just
recently
had
ibm
submitted
a
thing
on
how
to
do
jenkins
on
ibm
cloud.
Vlad
submitted
how
to
do
jenkins
on
google
cloud
and
and
so
we've
we've
had
new
tutorials.
So
I
would
suspect
we'll
keep
tutorials
as
a
topic.
B
And
then
comes
the
ugly
question
of
the
structure
of
the
pipeline
reference
pages
and
like
that
one
you
looked
at
adding
examples
is
going
to
make.
I
mean
it's
already
ugly,
it's
hard
to
find
stuff
in
when
that's
a
good
one
to
look
at
because
it's
got
a
whole
lot
of
stuff.
We
start
adding
examples.
That's
going
to
become
even
harder
to
read,
but
the
basic
pipeline
reference
page.
These
things
need
to
be
broken
out
into
real
reference
pages
or
formatted
in
some
way
that
I
can
find
stuff.
A
Good
point
so
let
there
was,
I
made
a
a
feeble
attempt
to
create
something
for
here.
Let's,
let's
look
at,
let's
look
at
a
different
page
and
and
I'll
show
you,
the
feeble
attempt
I
made
for
one
keyword
trying
to
trying
to
give
more
more
opening
material
on
the
thing
before
getting
into
examples.
So
so
the
git
plug-in
actually
has
a
whole
bunch
of
okay.
B
It's
a
logical
place
to
do
it.
I
mean
from
a
pure
writing
standpoint:
it'd
be
nice
to
pull
it
off
in
a
tutorial,
but
this
is
where,
because
the
normal
thing
is
you're
going
to
read
a
tutorial
once
or
twice
to
get
the
big
picture
and
then
you're
going
to
be
in
the
reference
materials
all
the
time
now
does
git
just
have
the
one
step
for
it.
It.
A
If
we
look
at
the
checkout
step
on
these
pages,
you're
going
to
have
to
wait
patiently,
while
the
page
loads,
because
it
is
so
large
just
a
minute,
I've
got
to
show
it
to
you,
because
it
highlights
just
all
right.
So
pipeline
scm
step
has
one
step,
I'm
going
to
click
it.
Now
we're
going
to
wait
all
right.
It
has
loaded
the
page
notice
how
many
different
implementations
of
checkout
there
are,
and
each
of
them
is
a
valid
implementation.
A
A
B
At
the
top,
and
then
there's
no
discussion
that
they
had,
that
says,
find
the
sem
that
you
you
know
and
look
on
and
click
on
that.
That's
not
there,
because
what
I
was
going
to
say
back
to
yours
was
like
I
mean
what
you've
got.
There
is
not
it's
actually
not
bad,
I
kind
of
like
it,
but
what
I'm
thinking
of
is,
if
you
had
four
steps
for
that
plug-in,
you'd
get
buried
in
the
first
one
and
it's
like
but
you're.
Looking
for
one
of
the
other
three.
B
A
A
That's
proposing
to
write
the
program
to
do
extraction
of
the
jenkins
rest
api,
oh,
but
but
the
student.
That's
that's
preparing
for
to
submit
a
proposal
for
that
has
had
questions
and
and
bumps
and
bruises
along
the
way,
because,
right
now
we
have
no
document.
We
have
only
the
online
documentation,
that's
inside
jenkins
itself,
no
separate
documentation
on
the
rest.
Api,
oh,
is
that
true
for
cli.
A
B
A
A
A
Another
suggestion
yeah
and
that's
that's
another
right-
administering
jenkins
as
code
right
right
without
the
ui
as
code,
and
there
are
things
like
configuration-
is
code
plug-in
right.
There's
the
job
esl
plug-in
there
are
stored,
xml
files
in
in
a
actually.
We
should
put
it
this
way.
The
jenkins
rest
api,
all
right,
jenkins,
cli
tool,
all
right
and
stored,
xml
files.
C
Mark
in
all
these
years,
work
with
jenkins
and
you
already
have
or
or
get
the
information
about
what
is
the
most
common
cases
in
using
jenks,
for
example,
to
with
that,
with
that
information,
we
can
just
work
samples
by
that
on
the
user
experience.
So,
for
example,
we
can
use
suitcase
for
just
write
about
it
and
give
instructions
about
the
most
common
uses
in
jenkins,
good
question
yeah.
So
we
have
that
information
in
some
studio
or
forums,
or
something
like
that.
We.
A
C
Not
pages
users,
because
we
are
writing
for
them.
So,
for
example,
we
we,
we
know
the
most
important,
for
example
it's
pipelines
but
which
part
of
pipelines
are
more
important.
We
can
use
paste.
We
can
use
page
as
reference,
because
it's
missing
content
there
or
it's
just
pulverize
inside
the
week,
so
we
need
some
user
feedback.
C
Only
just
saying
look,
this
part
is
important
or,
for
example,
we
have
partners
and
some
events
and
some
places
then
just
can
share
the
case
of
use
for
jenkins.
So,
for
example,
our
pipeline
here
just
work,
running
sonar,
plug-in
running
testis
and
integrations
and
access
github
and
pull
and
push
everything
go
from
there
into
there.
So,
with
that
information
we
can
just
put
our
focus
to
construct
that
more
available
user
experience.
B
Definitely,
but
we
need
to
be
careful
because,
for
instance,
we
know
that
last
I
heard
something
like
54
of
the
jobs
running
in
the
jenkins
world
were
freestyle,
but
we
don't
get
called
on,
but
I
think
they're
old
stuff
from
people
who've
been
doing
them
forever.
They're,
not
looking
for
documentation
on
how
to
do
freestyle
jobs,
whereas
pipelines
are
new.
B
So
so
we
go
for
that,
and
we
also
there's,
there's
always
going
to
be
a
split.
I'm
going
to
think
that
novices
most
novices
in
a
small
installation
are
going
to
do
most
of
their
admin
initially
from
the
gui,
but
as
the
installation
gets
bigger
and
they
get
more
sophisticated
and
if
they
aren't
some
people
are
just
love
a
gui
and
will
put
up
with
anything
but
they're
going
to
want
to
get
into
the
command
line
and
they're
going
to
want
to
automate
and
script
it.
B
So
there's
some,
and
for
some
of
these
there
is
a
split
I
mean
within
that
there's
prioritization
too,
you
know
different,
but
but
it
would
be
good
to
take
a
slice
at
some
of
that.
It's
not.
I
don't
think
we
can
come
up
yet
with
an
algorithm
that
makes
it
obvious
that
okay
for
this
data,
this
is
higher
priority
than
that,
but.
A
C
In
example,
for
example,
if
I'm
just
using
jenkins
the
first
time,
so
I
will
just
build
small
process
using
freestyle
pipelines,
but
what
kind
of
process
so,
for
example,
the
first
time
we
just
arrived
in
jenkins
wiki,
where
you
go.
If
you
are
office
user,
you
are
first
company
user
about
jenkins,
so
just
for
example,
you
can
offer
them.
Eight
suggestions.
C
Look
if
your
company
are
using
jenks
after
first
time
start
to
just
merging
your
brains,
for
example,
or
just
check
out
your
brains,
okay,
so
step
by
step,
going,
involve
your
process
moving
your
manual
manually
process
to
automatic
side
process
with
jenkins,
so
first
integrate
your
github
second
integrate
to
your
development
server.
Then
your
station
server,
then
you
less
time
less
step
of
your
integration,
just
integration,
your
production
server,
for
example.
So
we
can
create
a
hold
map
for
guiding
through
the
way.
B
B
A
C
A
B
A
A
A
A
C
C
Okay,
because
if
you,
if
we
can
define
a
template
to
guide
the
writer,
we
can
use
that
template
for
other
language.
So
we
just
put
there
some
difference
between
them
technologies
present,
because
the
same
example
you
you
give
us,
for
example,
you
have
compiling
program
language
program
and
other
are
just
interpreted,
but,
for
example,
if
you
I'm
just
check
out
for
github
it's
one
process,
if
I'm
checked
out
from
svn
it's
another
process,
but
it's
the
same
activity.
A
Yeah,
I
think
I
see
your
point,
so
the
idea
is
that,
if,
if
we
have
a
concept
of
hey
here's
a
language,
we
if
we
have
a
framework
that
is
language
independent
or
at
least
somewhat
language
independent
as
the
as
the
structure
and
then
when
we
implement
for
a
specific
language.
We
just
follow
that
structure.
Is
that
sort
of
what
you're
saying.
C
B
A
A
B
B
And
then
there's
another
direction
where
you
start
out.
This
is
declarative
pipeline
and
you
go
into
blue
ocean
and
you
have
a
step
that
echo
says
here:
we're
going
to
build
our
code
and
here
we're
going
to
do
unit
tests,
and
here
we're
going
to
you
know
et
cetera
and
that,
but
that's
I
mean
it's
like
there's
this.
You
know
multi-faceted
matrix
of
where
you
get
started.
That's
another
piece.
They
have
to
get
right.
A
Good
point
right-
it's
it's
this
is
pipeline
pipeline
authoring
is,
is
a
is
a
different
kind
of
thing
than
these
right
here
here
there
are
probably
many
many
people
who
know
the
language
in
a
team.
The
pipeline,
not
learning
path,
is
not
as
commonly
not
as
well
known,
yeah,
so
steps
pipeline,
authoring,
learning
path.
B
Theoretically,
when
they
come
to
jenkins,
they
already
know
how
to
build
test
and
deploy
their
c
app
or
ruby
app
or
python
app.
Theoretically,
the
problem
is,
of
course
they
don't
always
so
then
we
then
it
gets
nasty
but
but
yeah.
The
current
documentation
does
just
assume
that
you
know
all
that
and
then
here's
how
you
put
it
into
pipeline,
I
mean
actually
for
tools.
You
have
to
think
about
shell
script
and
bat
too.
B
A
B
Good
but
then
for
prioritization
too,
when
we're
looking
at
the
reference
materials
that
need
to
be
fixed,
I
mean
what
are
there
like?
1700
pipelines,
and
god
knows
how
many
steps
that
results
in
some
of
them
are
clearly
more
popular
than
others,
and
some
of
them
are
have
probably
been
dead
for
five
years.
A
That
so
that's
a
that's
a
another.
That's
I
think
of
that
as
a
different
topic
on
a
different
sort
of
question,
because
I
think
you're
right
there
are
there's
so
much
work
that
could
be
done
in
in
reference
material
in
general,
right
so
pipeline.
Steps,
for
instance,
are
the
most
frequent
most
frequent
requested
most
most
frequent
ask
for
for
examples.
B
B
A
But
it
is
is,
is
one
the
other
we
could.
We
could
ask
for-
and
I
suspect
it's
in
the
log
somewhere
ask
for
the
hit
counts
or
other
page
statistics
for
jenkins
for
jenkins.io
pages
to
see
hey,
which
one
are
they
looking
at.
If
we
get
lots
of
hits
on
the
github
solutions
page,
we
should
strengthen
it.
If
we
get
very
few
and
we
get
a
lot
on
installing
on
kubernetes,
we
should
improve
that.
B
B
There
is
something
I
mean
once
I
you
know
for
anything
I
work
with
that.
I
get
to
know
this.
Reference
page
is
pretty
good,
so
I
go
there
all
the
time,
but
I
go
there
because
it's
good
there's
something
else
that
I
really
don't
understand,
but
I've
looked
there's
nothing
written
about
it,
so
I
have
nothing
to
hit
to
for
our
statistics.
D
And
we
have
somewhere,
I
guess,
related
to
declarative
syntax
inside
our
documentation,
but
not
much
allowing
a
user
the
reader
of
our
documentation
to
try
on
their
own
how
it
will
be
implemented.
So
I
guess
it's
requires
some
thinking
about
how
to
organize,
and
this
would
be
ideal.
Of
course,
I'm
not
sure
if
it
is
achievable
at
all,
but
allowing
user,
for
instance,
talking
about
about
pipelines,
create
their
own
pipeline
a
freestyle
job
and
go
and
see
what
happens
yeah.
Well,
just
just
the
thought.
C
Yeah,
for
example,
we
talked
about
this
in
the
past,
but
I
just
given
bring
back
the
topic
again.
There
isn't
any
chance.
We
just
start
to
use,
for
example,
algolia
for
our
page
just
for
improve
our
our
user
experience
when
church
searching
about
the
topics
so,
for
example,
algolia
use
a
e.
I
a
I
intelligence
just
to
map
all
your
documentation
of
all
three
projects
around
the
world
are
used
in
algorithm
in
this
moment.
So,
for
example,
I
put
the
link
in
the
chat,
so
you
can
just
access
there.
C
C
C
C
Yeah,
because
to
us
is
simple,
because
we
already
know
our
own
documentation,
so
we
just
use
cultural
f
and
just
shares
for
things,
but
the
users,
their
company
when
they
arrive
in
our
site.
They
have
no
idea.
Where
is
jenkins
pipeline.
Where
is
that
tutorial
about
php
or
about
java?
Where
is
that
tutorial
about
maving?
They
have
no
idea,
so
we
need
a
search
engine.
A
A
A
A
A
So
I
would
rather
not
have
the
jenkins
documentation
page
having
something
that
suggests
circle.
Ci
is
a
good
choice
for
instead
of
jenkins,
you
know
they've
been
very
actively
attacking.
Oh,
you
should
up
replace
your
jenkins
with
circle,
and
I
have
no
interest
in
our
search
results.
Giving
any
hint
is.
A
That
so
so,
this
the
site
search
engine
feels
like
another,
very
good
topic
for
discussion
at.
In
fact,
I
think
I
mean
yeah
so
for
as
a
as
part
of
that
the
government
governance
the
contributor
summit,
because
I
think
I
think
it's
this
is
a
someone
may
say
hey.
I
would
like
to
contribute,
but
I
don't
want
to
write
documentation.
A
C
C
A
Yeah
yeah:
it's
something
like
that
right,
where
it's
it's
a
how
somebody
would
have
to
do
a
prototype
and
and
see
how
how
the
documentation
would
feel
if
we're
using
algolia
as
the
search
engine
could.
Could
our
pages
still
continue
to
be
the
static
site
that
it
is
or
does
something
else
have
to
change?
I
think
it's
an
interesting
experiment.
C
A
B
B
A
B
So
that
I
mean,
I
think
it's
just
an
administrative
one.
Now,
what
I
don't
know
at
the
other
end
is
what
the
ramifications
are
for
cdf
or
jenkins,
being
officially
a
non-profit
for
companies
that
are
then
using
that
as
the
base
and
making
a
profit
off
it.
I
don't
think
that
the
open
source
stuff
has
been
registered
and
maybe
that
we
need
to
have
a
separate
category,
which
you
know
don't
even
think
about
getting
that
to
washington
dc
right
now,
but.
B
B
A
B
Very
good,
well,
there's
a
couple
ways
too:
I
mean
they
could
say,
we'll
give
you
the
song
we'll
give
you
the
you
know
commercial
software
will
give
you
the
professional
software,
but
you
got
to
find
your
own
servers
and
google's
our
best
place
to
go
for
those,
but
I'm
not
sure
google's
going
to
want
to
sponsor
something,
that's
not
using
their
their
search.
So
right,
right,
your
mind,
boggles.