►
Description
Google Summer of Code (GSoC) is a global, online program focused on bringing new contributors into open source software development. GSoC Contributors work with an open source organization on a 12+ week programming project under the guidance of mentors.
As we are at the end of another successful season of Jenkins in GSoC, GSoC Contributors will be presenting the final status for their projects. Join them on this call as they present their final achievements, improvements they've made to the Jenkins project and lessons learned on this journey:
Plugin Health Scoring System by Dheeraj Singh Jodha
Jenkinsfile Runner Action for GitHub Actions by Yiming Gong
Automatic git cache maintenance on the controller by Hrushikesh Rao
Pipeline Step Documentation Generator Improvements by Vihaan Thora
Link to all projects: https://www.jenkins.io/projects/gsoc/
A
The
recording
should
be
on
right
now,
so,
okay,
so
we'll
get
started.
Hi
everybody
Welcome
to
the
Jenkins
online
Meetup.
This
is
Wednesday
October,
5th
2022..
This
is
Jenkins
Google
summer
of
code
2022,
and
this
is
the
Final
Phase,
where
our
gsoc
contributors
will
show
or
demo
what
they've
done
in
this
past
season
and
what
they've
learned
from
it.
A
Sorry
about
that,
okay,
so
the
Jenkins
online
Meetup
is
a
Community
Driven
virtual
meetup
group.
We
discuss
all
things
and
everything
Jenkins
from
case
studies,
success
stories,
Lessons,
Learned
Etc,
and
it
is
a
channel
for
Jenkins
developers.
So
we're
always
looking
for
speakers.
So
if
you
have
a
story
to
share
with
us,
please
submit
a
an
application
through
the
LA,
the
links
there,
some
housekeeping
notes
for
Q
a
please
put
your
questions
in
the
zoom
chat
or
the
Q
a
window.
One
of
us
will
respond
to
it
as
soon
as
we
can.
B
Okay,
thank
you
Elisa,
so
my
name
is
Jean
Mark
Mason,
located
in
Brussels
here
and
on
behalf
of
the
Google
summer
of
code
org
admin
team,
which
is
here
represented,
so
we
had
Alyssa
christern
and
myself.
Here.
We
are
very
happy
to
present
this
last
online
Meetup,
where
the
this
year's
country,
g-soc
contributors,
will
share
the
results
of
their
work
during
this
summer.
B
B
If
you
want
to
have
more
technical,
in-depth
details
about
all
these
projects
have
a
look
to
the
URL
at
the
end
of
this.
This
slide,
where
you
can
read
and
have
the
links
to
the
various
things
that
were
produced
by
the
projects
next
slide.
So
these
are
the
the
participants
to
this
Edition
very
happy
to
have
spent
this
summer
together
with
them.
Hoshikash
had
it's
something
that
it
was
not
available
today
and
he's
very
sad
of
that
and
he
will
be
represented
by
his
mentor.
C
So
this
is
how
we
are
going
to
be
spending
the
next
15-ish
minutes
and
I'll,
be
starting
up
by
telling
briefly
about
the
project,
then
we'll
be
going
through
a
very
short,
quick
demo,
then
we'll
be
seeing
the
achievements
of
this
project
and
I'll
be
sharing
the
next
steps
that
we
have
for
us
and
then
I'll
be
sharing
my
learnings,
which
will
be
followed
by
q
and
A's.
So
please
keep
your
questions
ready
so
about
the
project.
C
What
we
are
trying
to
do
here
is
to
calculate
health
score
for
the
plugins,
and
we
try
to
do
that
by
taking
the
composite
scores
of
two
things.
First,
one
is:
we
want
to
find
out
how
well
a
plugin
performs
on
set
of
predetermined
probes,
and
second,
we
want
to
use
this
data
to
and
combine
it
with
the
weights
for
each
of
those
probes.
C
So
when
I
say
set
of
predetermined
probes,
I
mean
anything
from
let's
say,
for
example,
number
of
open
issues
a
plugin
has
in
its
repository
or
something
like
whether
the
given
plug-in
repository
has
a
Jenkins
file
or
not,
or
it
can
be,
like
latest
release
date
of
a
plugin.
So
these
are
the
probes
that
you
can
have
and
by
weight
the
weight
of
a
probe
signifies.
How
strongly
does
a
probe
wants
to
affect
the
health
score
of
a
plugin?
C
So
when
we
think
of
evaluating
a
plugin,
what
we
mean
by
that
is
view,
you
would
need
to
set
aside
at
least
one
R
and
go
through
the
manual
steps
of
looking
at
the
plugins
repository
and
all
the
files
and
seeing
the
form
XML
file,
checking
out
the
values.
So
it's
a
very
manual
task
so
and
you
have
to
multiply
that
by
1800
plus
plugins.
C
In
the
Jenkins
ecosystem-
and
that's
the
amount
of
time
that
you
would
need
to
set
aside
in
order
to
evaluate
all
the
plugins
in
the
Jenkins
ecosystem,
so
I
think
it's
safe
to
say
that
no
one
would
want
to
voluntarily
take
up
this
task
of
manually
evaluating
this,
the
state
of
plugins.
But
there
might
be
some
one,
some
group
of
people
who
would
want
to
automate
this
manual
process
and
that
group
of
people
is
us.
C
So
it's
time
for
a
quick
demo,
and
so
I've
started
my
project
already
and
if
you
want
to
know
how
to
do
that,
you
can
refer
the
readme
file
of
the
repository
and
on
localhost
8080,
slash
probes.
You
can
see
this
list
of
probes
that
we
have
currently
live
as
running
in
the
project,
so
we
made
this
page
to
to
give
anyone
a
peek
into
what's
the
state
of
this
project,
so
you
can
see
the
first
probe
is
deprecated
plugin
Pro,
which
tells
you
if
a
given
product
plugin
is
deprecated
or
not.
C
C
So
if
you
want
to
view
the
same
page,
the
on
your
local
machine
I
mean-
or
you
can
say
that
if
you
want
to
view
the
deployed
version
of
this
page,
you
need
to
visit
this
link.
Plugin
Dash
health.jenkins.io
props,
so
you
can
see
there's
only
two
of
them,
two
of
the
plug-in
probes
listed
here.
So
we
need
to
update
that,
but
this
is
where
you
can
see
it.
This
is
the
deployed
version
of
the
project.
C
So
now
that
we
know
the
list
of
probes
currently
running
live
in
this
project,
so
let's
see
the
magic
of
probe
engine
which
runs
these
probes
and
populates
the
database
with
its
observations,
and
for
that
I
would
take
you
to
my
IDE
screen
and
on
my
database.
I'll
run
this
simple
query
of
Select
star
from
plugins,
and
you
would
see
these
records
in
this
format.
C
So
in
let's
say
in
record
this
first
record
you
can
see-
let's
just
only
focus
on
this
details
object.
So
these
are
key
value.
Pairs.
Scm
probe
has
a
status
of
success,
because
the
plugin
SCM
link
is
valid.
Duplication
probe
is
also
success,
because
this
plugin
is
not
deprecated.
Up
for
adoption
is
a
success
because
it's,
the
plugin
is
not
up
for
adoption
and
last
commit
date,
gives
you
its
last
commit
date
as
promised,
and
it
stated
this
success.
C
C
Now
let
me
take
you
back
to
the
slides,
and
so
let
me
share
with
you
our
achievements
at
as
part
of
this
project
that
we
were
able
to
do
so.
First
of
all,
we
have
this
probe
engine
running,
live
in
our
project
and
I
like
to
refer
it
as
the
heart
of
this
project,
because
it's
the
single
most
most
important
thing,
because
due
to
this,
all
the
probes
are
running
and
the
database
is
getting
populated
in
everything.
So
this
was
designed
and
developed
by
Adrian.
C
So
let
me
talk
to
you
about
the
next
steps
like
what
do
we
have
next
for
this
project
if
you're
interested
to
know
so,
if
you,
if
you're
curious
or
interested,
so
we
want
to
extend
the
probe
engine
and
by
extent
and
mean
that
we
want
to
make
it
more.
We
want
to
improve
it
more
because
there's
always
room
for
improvement
and
you
want
to
make
it
compatible
with
different
kinds
of
probes,
because
people
can
get
very
creative
in
future.
So
that's
that's.
C
So
to
your
to
the
right
side
of
this
screen,
you
can
see
this
prototype
shared
with
me
by
Jake,
so
on
the
left
side
of
this
image,
you
can
see
these
filters
that
you
can
have
to.
You
know,
filter
all
these
Health
score.
So
it's
a
prototype,
and
this
is
how
the
Jenkins
plugin
site
is
going
to
look
like
and
on
the
right
side.
You
can
see
all
these
plug-in
cards
and
93
by
100
is
the
sample
mock
data
for
a
health
score.
C
So
this
is
how
the
UI
is
going
to
look
like
with
the
health
score
on
the
plugin
site.
So
if
you
click
on
any
of
those
cards
of
a
plugin,
you
would
be
redirected
to
similar
kind
of
page.
So,
for
example,
for
kubernetes
plugin,
you
are
seeing
a
health
score
of
93,
so
someone
would
get
curious.
Why
do
I?
Why
does
this
plugin
has
93
percent
score,
so
we
would
be
displaying
a
detailed
breakdown
of
why
it
has
93
percent.
C
So
these
are
the
list
of
probes
that
contributed
to
this
score
and
if
you
click
on
so
this
is
the
plan
that,
if
you
click
on
any
of
these
products,
you
will
be
redirected
to
a
very
helpful
how-to
guide,
which
will
tell
you
that
how
can
you
improve
a
score
for
this
given
probe
right?
So
this
is
the
imagined
end
result
on
the
UI
of
the
Whole
Health
course.
C
So
I
wanted
to
take
a
moment
and
share
with
all
of
you,
my
learnings,
because
part
of
this
program
has
been
very,
very
varying
interesting
for
me,
and
it
was
a
great
learning
experience
because,
due
to
this,
I
got
to
learn
and
improve
my
interpersonal
skills,
because
this
is
an
environment.
It's
an
open
environment
and
being
part
of
an
open
source
project.
It's
different
from
any
kind
of
you
know
closed
Source,
like
corporate
environment,
so
and
we
work
remotely
so
this.
C
This
was
an
opportunity
for
me
to
improve
on
my
asynchronous
communication
as
well,
so
there
were
lots
of
weekly
meeting
plannings
and
discussing
the
next
PR,
and
you
know
working
on
it.
Asking
doubts
and
I
mean
moving
once
one
PR
at
a
time.
So
this
was
extremely
interesting
and
great
thing
to
learn
and
then,
as
part
of
the
whole
journey,
I
also
get
to
increase
my
knowledge
on
the
system.
C
Designing
aspect
as
well,
because
my
mentor
Adrian,
especially
he
worked
on
lots
of
interesting
PR
and
I,
got
to
review
them
and
I
asked
him.
So
many
questions
and
that's
how
I
got
to
learn
like
hey?
How
that's,
how
you
design
something
and
that's
how
it
comes
to
reality,
so
most
of
them
were
related
to
Java,
so
that
eventually
led
to
that
I
started
to
increase
on
my
Java
knowledge
as
well,
by
using
the
development
best
practices.
C
So
a
big
big
shout
out
to
Adrian
for
helping
me
out
here
now,
if
you're
interested
to
know
what's
next
for
this
project-
and
you
want
to
you
know,
just
ask
us
any
questions
like
hey:
how
does
this
work
I
want
to
contribute
it
or
anything?
So
these
are
the
links
that
you
can
refer
in
order
to
get
more
context
about
this
project,
and
that's
the
gator
channel
here-
and
this
is
the
project
repository
that
you
can
take
a
look
at.
B
D
C
Yes,
so
that's
a
good
question
thanks
for
that,
so
about
the
scalability
concerns
when
we
were
running
some
specific
kind
of
probes
which
which
we're
dealing
with
hitting
the
GitHub
server.
So
those
kinds
of
probes
were
communicating
with
the
GitHub
server
via
those
apis
and
since,
as
you
said,
there
are
1800
plus
plugins,
and
when
we
run
this
engine
there
are
going
to
be
lots
of
requests
to
the
GitHub
API
server
so
that
that
easily
shoots
a
past
the
limit
set
by
GitHub.
C
B
B
Okay,
so
thank
you
very
much
duraj
and
thank
you
very
much
for
sharing
your
experience.
What
you,
what
you
learned
about
with
that
project
was
indeed
a
very
large
one,
and
thank
you
for
the
mentors
that
did
tremendous
in
very
substantial
work
on
that
just
by
the
sheer
size
of
the
project.
So
thank
you
to
all.
B
B
B
E
So
let
me
start
so
hello,
everyone,
my
name
is
Simi
and
I'm.
The
Jenkins
Json
contributor
of
Jenkins
file
Runner
as
GitHub
actions
this
summer
I'm
happy
to
give
the
final
presentation
today
about
this
project,
I'd
like
to
give
a
brief
introduction
about
myself.
First
so
now
I'm
a
graduate
student
from
Carnegie
Mellon
University,
my
major
is
electrical
and
computer
and
Engineering
in
this
project.
My
mentors
are
Chris
and
abiadaya.
E
So
so
our
functional
interface
is
pretty
simple
in
this
project.
You
only
need
to
point
out
the
rounding
options
and
the
relative
path
of
Chinese
file,
jcscm
file
and
plugin
installation
based
file
in
your
repository,
as
some
people
might
not
familiar
with
the
tool
in
our
actions.
I
listed
some
basic
comments
about
them.
E
Basically,
we
use
the
plugin
installation
manager
to
install
the
plugins
specified
by
plugins
installation
list
file
and
the
Jenkins
file
Runner
to
run
the
Jenkins
pipeline,
so
Chinese
fire
rounder
action
for
GitHub
actions
provides
the
customized
containerized
environment
and
the
useful
GitHub
actions
for
users
to
run
the
Jenkins
pipeline
inside
the
GitHub
actions
in
more
detail
using
some.
If
using
these
actions,
any
GitHub
project
with
which
has
a
Jenkins
file
can
execute
its
workflow
in
the
GitHub
actions
Runner.
It
aims
at
applying
Jenkins
in
the
GitHub
actions
in
a
functional
as
a
service
contacts.
E
This
feature
is
based
on
the
Jenkins
file
Runner,
which
is
a
command
line
tool
for
the
Jenkins
pipeline
execution.
Engine
here
is
a
basic
architecture
of
these
actions,
so
I
combine
the
Jenkins
score,
a
minimum
required
set
of
plugins
to
run
the
pipeline
and
the
plugin
installation
manager
and
the
janking
spell
rounder
into
a
base
image.
Then
I
set
up
the
entry
point,
shell
scripts
to
start
up
the
container
workflow.
E
So
in
the
second
phase
of
the
of
this
coding
project,
I
developed
the
GitHub
actions
which
don't
require
the
container
runtime,
so
users
can
directly
run
the
pipeline
in
the
host
machine
and
all
the
dependencies
are
downloaded
for
each
run.
So
the
coolest
part
of
this
runtime
action
is
that
users
can
run
them
in
all
of
the
runners
provided
by
GitHub
action,
which
are
Linux,
Mac,
OS
and
windows
runners.
E
E
So,
as
you
can
see,
there
are
some
differences
in
our
current
actions,
but
the
root
cause
of
these
differences
is
the
starting
time
of
Jenkins
container
in
jfi
coordinator
container
action.
The
Jenkins
container
starts
up
before
all
GitHub
actions
and
execution
and
ends
after
all,
GitHub
actions
and
have
results,
so
all
GitHub
actions
will
have
influences
on
the
container.
E
E
So
in
this
case
the
Jenkins
working
container
has
strong
isolation
with
the
host
machine,
so
users
cannot
use
other
actions
to
set
up
the
container
environment
except
the
actions
checkout.
When
it
comes
to
the
wrong
time
actions,
it
doesn't
require
container
contacts,
so
it
doesn't
have
the
related
problems.
I
described
it
before
you
can
use
them
with
other
actions
in
the
marketplace.
E
So
how
can
you
use
our
actions?
I
provide
five
Jenkins
for
around
reactions
in
my
project.
Now
they
are
called
jfi,
plugin
installation
action,
they
have
a
runtime
action,
JFR
setup
action,
Jeff
are
container
action
and
the
JFR
static
image
image
action.
You
can
use
this
action
URLs
in
the
PBT
or
in
your
workflow
definitions
directly.
E
So,
besides
the
repositories
of
this
Jenkins
field,
GitHub
actions
I
also
provide
the
central
documentation,
so
the
central
documentation
includes
a
user
guide
and
the
developer
guide
and
I
also
provide
the
demo
repository.
The
demo
repository
tells
the
users
how
to
use
these
actions
to
compile
a
different
programming
languages
projects
what's
more.
It
also
includes
how
to
use
the
Jenkins
Secrets
environment
variables
and
how
to
play
with
other
plugins
with
with
jcsc.
E
E
E
E
So,
firstly,
you
can,
as
we
use
the
runtime
actions,
we
can
run
it
in
different
kind
of
Runners,
provided
by
GitHub
actions.
There
are
Ubuntu
or
Mac
OS
and
windows.
So,
and
so
firstly,
you
need
to
call
the
actions
checkout
to
set
up
your
Works
play
workplace
and,
secondly,
you
need
to
call
JFR
set
of
action
or
to
set
up
the
Jenkins
file,
Runner
action
environment.
E
So
if
you
want
to
install
extra
plugins,
you
need
to
provide
a
plug
plugins
text
file
list
file
and
you
need
to
point
out.
You
need
to
use
the
JFR
plugin
installation
action
to
download
the
extra
plugins.
So
finally,
you
don't
need
to.
You
only
need
to
use
the
jfront
action
to
launch
your
exact
pipeline
and
don't
forget
to
provide
the
relative
path
to
your
Jenkins
file
and
your
jcsc
file.
E
E
E
E
E
E
E
E
E
E
So,
in
the
end,
I
really
appreciate
the
help
from
the
Jenkins
Community.
My
mentor
Chris
and
Avada
always
give
me
a
valuable
advice.
Jane
Mark
always
likes
to
hear
my
personal
feelings
or
opinions
during
the
project
development
phase.
Also,
all
that
helped
me
find
the
correct
path
in
this
project.
At
the
beginning
of
the
coding
period,
and
also
finally,
thanks
Alisa
for
coordinating
so
many
online
meetings,
because
I
don't
think
it's
a
easy
job,
and
so
thanks
for
listening.
D
So
for
me,
GitHub
GitHub
actions
have
been
Complicated
by
working
with
when
working
with
credentials.
Jimming
have
there
been
any
things
that
you
learned
in
operating
in
a
credentialed
environment
in
GitHub
that
you
want
to
share
with
others
or
were
there
insights
you
gained
when
you
were
dealing
with
credentials
in
GitHub.
E
So,
usually,
what
I?
What
I
did
is,
for
example,
you
can
go
to
the
so.
This
is
my
this
is
my
let's
see
this
is
my
personal
project
and
you
need
to
go
to
the
settings
page
here
and,
let's
see,
there's
a
secret
Secrets
here
and
you
can
click
it
and
you
can
update
or
set
new
repository
cities
decrease
over
here.
E
So
if
you,
for
example,
if
you
want
to
use
use
or
use
any
extra
secrets,
you
need
to
set
up
here
and
call
it
in
your
workflow
definition
by
using
the
by
using
the
environmental
variables
provided
by
GitHub
actions
or
if
you
want
to
use
it
in
your
Jenkins.
If
you
want
to
use
it
in
your
Jenkins
pipeline,
you
need
to
map
it
map
this
secrets
into
your
Jenkins
running
environment,
yeah,.
E
B
Very
good,
okay,
we're
running
out
of
time
or
I
I
just
give
30
more
seconds.
If
somebody
wants
to
ask
a
question,
meanwhile,
I'm
going
to
thank
himing
for
the
very
interesting
work
done
on
that
and
for
this,
this
very
powerful
demo
on
your
work
and
I'd,
like
also
to
thank
the
mentors
Chris
Stern,
who
made
that,
together
with
being
an
org
admin
during
this
summer.
So
thank
you
very
much
Chris
in
ABIA,
I
I
can't
pronounce
his
name
completely
Chris.
You
wanted
to
add
something.
B
F
F
F
The
sum
the
beginning
of
the
project
was
more
UI
oriented
and
my
task
was
to
make
using
the
documentation
more
handy,
so
for
that
I
worked
on
improving
the
sidebar
scrolling
behavior
of
teaching
kids
documentation,
which
I
can
perhaps
demo
over
here.
So
this
is
an
older
deployment
of
the
site,
which
shows
the
condition
about
everything
before
the
Google
summative
core
project
was
done.
So
this
is
one
of
the
pages
in
these
steps.
F
F
Secondly,
the
change
was
to
add
a
search
filter
and
as
a
name
for
this,
this
is
very
trivial
and
what
it
does
is.
Basically,
it
compensates
the
browser
search
feature
in
a
separately,
dedicated
search
bar
and
what
this
provides
over
the
browser
search.
Is
it
filters
out
the
content
on
the
page
itself,
so
the
content
you
see
here
is
dynamic
and
if
I
enter
some
string,
maybe
that
matches
it
so
SCM.
F
The
third
task
was
to
separate
the
declarative,
Steps
From,
the
main
class,
so
pipeline
steps
are
of
two
types:
declarative
and
scripted,
and
the
cells
are
dedicated
towards
declarative
pipeline
steps
are
generated
using
separate
functions,
not
the
regular
functions
and
those
functions.
We
thought
that
it's
better
to
separate
them
from
the
main
class,
which
is
the
patents
that
extractor
class
and
hence
making
the
main
class
more
readable
and
bringing
some
more
modularity
to
our
code.
F
The
four
change
was
to
shifter
parameter
data
types
on
our
main
website.
I'll
just
show
a
quick
example
of
what
I
mean
by
that.
So
here,
as
you
can
see
for
each
of
the
parameters,
for
example
for
clear
case
SCM.
This
is
a
parameter
class
under
the
SCM
check
out
SCM
step,
and
this
gives
us
some
parameters
such
as
Branch
label,
extract
config
and
all
of
them
have
some
particular
data
types
that
a
user
needs
to
know
when
they
want
to
write
the
python
script,
and
this
was
this.
F
Data
was
present
in
a
new
line
after
the
help
text.
So
here,
as
you
can
see,
there
is
no
help
text
available.
But
if
you
scroll
down
a
little
bit-
and
you
see
some
things
such
as
a
name
here
for
the
data
type
of
the
name-
you
just
scroll
through
the
head
text
and
after
that,
when
the
text
ends,
you
see
the
data
type
over
here,
and
this
has
been
resolved
using
a
very
simple
fix
is
that
is
to
move
the
data
type
within
the
in
line
with
the
name
of
the
parameter
itself.
F
So
here,
as
you
can
see,
the
the
parameter
names
are
in
line,
and
this
also
reduce
the
overall
scrolling
length
of
the
website,
thus
reducing
the
content
that
we
have
moving
on
the
last
thing,
but
not
the
least,
was
the
release
pipeline
metadata
utils.
This
was
a
tool
that
was
under
development
and
what
it
does.
It
provides
users,
a
plugin
manager
which
they
can
use
to
query
their
plugins.
F
What
it
does
is
basically,
for
example,
one
to
my
project
I
have
to
extract
data
about
the
steps,
so
there
is
a
file
which
is
known
as
a
plugin
help
text
and
for
every
plugin.
We
query
that
we
form
our
data
structure,
a
map,
a
descriptor,
and
we
store
data
for
that
using
a
hyper
local
plugin
managers.
F
F
I'll
link.
All
these
things
in
on
my
project,
page
and
I'm-
also
writing
a
Blog
which
will
be
released
after
the
meter,
which
will
contain
all
the
important
links
so
moving
on
towards
coding
phase
two.
What
the
things
are
indeed
coding:
phase
two
was
a
more
specif
specific.
You
know,
focused
coding,
phase,
part
of
the
project
and
the
main
task
was
to
make
the
pages
more
lightweight.
You
know
reduce
the
content
on
those
pages.
F
That
was
the
main
goal
of
the
project,
so
that
was
a
thing
that
I
was
searching
for
the
solutions
for
that
and
before
that
there
was
a
small
change
in
which
we
had
to
label
the
deprecated
plugins
on
the
pipelines.
As
a
reference
page-
and
this
was
done
because
earlier
there
was
no
way
to
identify
if
a
pipeline
steps
mentioned
by
a
plugin,
the
plugin
itself
is
deprecated
or
not,
and
for
example,
you
want
to
use
that
step
and
then,
after
that,
you
realize
the
plugin
is
deprecated.
F
I
have
a
map
of
that
and
I
can
simply
iterate
through
the
keys
of
those
that
map
and
see
whether
that
has
an
entry
as
a
deprecation
to
true.
In
our
upgrade
Center
file-
and
if
that
is
the
case,
then
we'll
add
a
deprecated
text
label
near
that
plugin's
name
itself.
So
this
this
is
a
very
helpful
when
you
want
to
basically
see
all
the
deprecated
plugins,
so
if
I
simply
type
deprecated,
MF
search
filter,
you
can
see
that
yeah.
F
These
four
are
the
plugins
that
are
directed
and
also
provide
pipeline
steps
to
us
and
if
we
simply
type
deprecated
over
here,
we'll
also
get
the
steps
that
the
steps
that
have
the
text
deprecated
associated
with
them.
So
both
these
things
are
possible.
This
is
basically
a
superset
of
the
previous
query,
okay,
so
moving
on
towards
the
main
idea
of
the
project
that
was
to
separate
the
configured
parameters
to
a
new
ASCII
doc.
F
The
project
was
about
separating
some
of
the
larger
sections
of
these
steps,
documentation
towards
a
place
such
that
a
user
is
not
bombarded
with
a
large
amount
of
information
on
a
single
page.
What
it
does
is
it
it
makes
a
page
very
hard
to
navigate
through
and
it
basically
the
content
Becomes
of
little
use
when
the
information
is
not
organized
very
well.
F
So
this
was
a
task
to
accomplish
in
this
project.
So
some
of
the
observations
that
I
did
before
I
started
coding
were
that
there
are
around
eight
big
plug-in
pages
that
contribute
to
about
85
percent
of
the
total
size
of
the
ASCII
docs.
The
total
size
before
the
project
was
done
was
around
16.7
MBS.
This
is
basically
all
the
ASCII
talks
that
we
see
on
Pipeline
steps
reference
all
the
ASCII
docs
that
come
within
that-
and
here
here
are
some
of
the
examples
of
those
ASCII
docs.
F
F
But
what
was
the
issue
behind
that?
Here
are
some
problems
that
we
are
facing
because
of
these
larger
Pages.
We
have
a
JavaScript
that
runs
that
collapses,
these
documentation
lines
so,
for
example,
if
you're
seeing
these
collab
sections
over
here,
this
is
happening
dynamically
after
the
ASCII
dock
is
loaded
and
a
JavaScript
function
collapses.
This
lists
into
these
sections,
and
that
was
taking
a
huge
amount
of
time
when
it
is
running
on
the
page
of
the
size
and
yeah.
F
For
example,
the
multi-trans
plugin
page
took
around
20
seconds
on
my
browser
to
load
and
become
stable
and
even
after
it
was
loaded,
it
was
crashing
the
browser
many
times
and
the
experience
overall
was
not
very
smooth.
It
was
a
very
laggy
experience,
I
should
say,
and
yeah
here
are
some
of
the
useful
investigations.
A
lot
of
the
documentation
that
we
saw
was
redundant.
F
That
is
many
other
texts
present
within
a
same
plugin,
page
or
across
multiple
plugin
pages,
had
the
exact
same
content,
and
we
know
that
redundancy
is
not
good
in
any
kind
of
documentation,
so
this
was
something
that
was
needing
some
kind
of
a
remedy
from
our
side.
Secondly,
we
realized
that
if
we
separate
every
parameter
and
necessary
choice
to
a
new
page,
it
won't
help
a
redundancy
issue
much
because
we
are
anyways
just
shifting
one
one.
F
F
Okay,
here
it
is
so,
as
you
can
see,
multi
SCM
the
list
it
contained
had
the
exact
same
SCM
classes
as
we
have
on
the
main
page
itself.
So
it's
basically
a
recursive
list
that
is
present
in
itself,
so
multi-scm
has
multi-scm
again
in
itself,
but
it
ends
because
it
has
been
set
like
that
the
threshold,
so
the
other
depth,
is
not
increased
by
more
than
one,
but
basically
we
have
every
single
parameter,
such
as
the
git
scn.
F
Everything
is
present
again,
so
this
is
one
of
the
examples
of
redundancy
present
in
the
same
page
itself,
so
this
needed
some
sort
of
sort
of
a
solution.
So
the
idea
that
we
thought
could
be
done
was
one
approach
could
be
to
deal
with
it
using
in
the
two
asciate
generation
process
itself.
So
when
we
are
converting
those
Java
maps
to
ASCII
docs,
can
we
maybe
identify
those
parameter
blocks
and
see
if
that
content
is
redundant
or
not
and
see?
F
So
this
is
the
approach
that
we
thought
would
be
feasible,
and
this
is
what
we
went
through
with,
and
here
are
some
implementation
details
of
what
we
did
process.
Ascii
doc
was
designed
to
be
a
middle
layer
between
generating
and
exporting
the
ASCII
docs.
So
before
the
project
writes
it
up,
writes
its
output
like
an
all
ascii.zip
file.
This
layer
reduces
the
content.
You
know
abstracts
the
whole
thing
out
and
then
writes
it
onto
the
final
thing
and
for
every
configured
class
we
have
and
for
every
configured
class.
F
In
our
configuration
file,
we
iterate
through
the
entire
documentation
to
find
its
occurrences
and
then
localize
it
to
one
specific
place
which
is
in
a
folder
named
as
parents.
So
all
those
new
occurrences
have
been
assigned
to
the
folder
named
params,
and
this
is
just
a
single
file
now
and
all
those
other
files
will
reference
to
the
single
file
on
this
location.
So
in
that
way
we
have
cleared
all
the
redundancy
completely
okay.
F
Okay,
so
basically,
this
is
just
a
flowchart
of
what
I
mentioned
right
now,
and
here
are
some
results
that
I
would
like
to
share.
Finally,
so
the
size
of
the
final
ASCII
docs
has
been
reduced
by
more
than
two
MBS,
and
this
is
all
the
redundancy
that
we
are
getting
rid
of,
and
these
specific
pages
on
their
own
have
been
reduced
a
lot
in
size.
So
earlier,
if
you
remember
this,
filamente
Branch
was
five
MPS
in
size.
F
It's
now
just
0.7
MBS
and
all
of
these
things
can
be
seen
on
the
main
website
itself.
It's
all
in
deployment,
and
you
can
see
the
new
example.
So,
for
example,
I
was
looking
for
multi-scm
before,
as
you
can
see,
it's
just
a
new
link
now
and
we
can
click
through
this
link
and
the
whole
documentation
will
be
localized
in
a
single
place
and
get
SCM
over.
There
would
be
same
as
a
guitar
Sim
over
here.
F
Currently
we
have
around
36
parameters
configured
and
as
and
when
we
increase
it,
the
project
will
become
the
effect
of
the
project
will
become
more
and
more
evident
so
yeah.
These
are
some
some
future
scope
for
improvements
and
which
you
can
go
through.
My
slides
and
my
project
page
as
well,
I
would
say
the
main
goal
for
the
future.
G-Shock
could
be
to
integrate
the
snippet
generator
with
chain
key
set
IO.
F
This
was
something
this
was
something
that
we
went
over
multiple
times,
trying
to
find
implementations
for,
but
due
to
the
lack
of
time
we
weren't
able
to
but
I'm
sure
this
would
be
a
very,
very
valuable
addition
in
the
future.
For
us,
okay,
so
I'd
just
like
to
acknowledge
all
the
people
who
helped
me
throughout
Christian
John,
Mark
Kevin
Alyssa
to
the
entire
community
of
Jenkins
talks
thanks
a
lot
and
please
let
me
know
if
you
have
any
questions
regarding
this.
B
D
I
did
actually
so
vihan.
There
were
some
analytical
things
that
you
did
there.
Any
guidance
you'd
give
us
the
the
things
about
page
load
time
and
about
about
expansion.
Time
were
there
techniques
you
use
to
to
identify
the
hot
problems
there
that
others
of
us
should
know
about
it.
Taking
a
page,
10x
reduction
in
size
of
a
page
is
pretty
amazing.
Well
done,
were
there
things
you
use
to
find
those
pages
in
the
initial?
What
anything
you
wanted
to
share
there.
F
Yes,
so
most
of
the
configuration
that
I
did
was
a
manual
process,
and
hence
this
was
also
kind
of
a
drawback
of
the
project
that
I
wrote
in
the
scope
of
environment,
so
I
had
to
manually
figure
out
sections
that
were
having
ASCII
docs
more
than
a
thousand
ten
thousand
lines
and
configuring.
Those
parameters
is
what
I
did
right
now,
but
in
the
future,
what
we
can
do
is
we
can
set
a
threshold
that,
if
you
have
any
parameter
block
that
exceeds
maybe
10
000
lines
of
block,
maybe
move
them
to
a
new
page.
B
B
D
D
The
task
that's
challenging
here,
that's
hiding
in
all
this
is:
how
do
we
deal
with
things
that
are
sort
of
contrary
to
the
nature
of
git,
so
git,
as
envisioned
by
Lana,
starvald
and
maintained
by
a
great
team
of
maintainers,
focuses
on
Fast
immediate
operations
and
is
willing
to
sacrifice
larger
operations
or
long-term
operations
to
the
benefit
of
short-term
operations.
For
instance,
it
shows
it
chooses
intentionally
not
to
garbage
collect
on
every
operation
that
a
user
does.
D
Therefore,
we
can
collect
things
over
time
when
we
have
long-living
historic
caches
that
need
tidying
prusikesh,
as
our
contributor
provided
a
great
start
on
this
to
allow
git
to
help.
Allow
us
to
have
Jenkins
automatically
maintain
its
caches
and
the
challenges
are
hiding
in
the
fact
that
get
by
its
nature
focuses
on
Fast
operations
for
developers
not
on
long-term
storage
of
fast
access
for
big
bulky
processes
like
a
Jenkins
process.
D
So
the
cash
is
in
Jenkins,
sit
behind
the
controller
and
they
remember
things
about
particularly
large
repositories.
If
you
can
imagine
the
Linux
kernel
as
one
example
is
over
two
gigabytes
as
a
repository,
we
certainly
do
not
want
to
copy
two
gigabytes
every
time.
We
need
to
ask
a
question
of
it,
so
we
cache
it
that
caching
helps,
but
those
caches
may
become
dirty
or
they
may
become
untidy.
D
So
when
you
install
the
get
plug-in
after
this
is
released,
you'll
have
a
git
maintenance
button
here
in
manage
Jenkins
and
here's.
The
configuration
page
tells
you
what
Git
Version
you're
running
and
here
the
the
cache
operations
that
you
can
do.
I've
said
to
do
this
one
once
a
day.
Oh,
this
is
another
way
of
saying
once
a
day
and
and
all
of
the
syntaxes
that
are
used
for
git
cash
operations
are
available
or
that
are
used
for
Jenkins
cron
jobs
and
Jenkins
jobs
in
general
are
available
here.
D
The
results
we
see
are
in
a
nicely
presented
table,
so
here's
a
good
example
of
a
160
megabyte
repository
that
I
use
and
on
which
I
depend,
and
we
see
when
I
expand
all
sorts
of
results
here,
hey
here's.
The
cleanup
that
ran
to
garbage
collect
this
thing
in
seven
seconds
that
garbage
collection
means
that
I
waste
much
less
time
later,
when
I
access
that
repository,
those
kinds
of
operations
are
exactly
what
automated
cash
maintenance
does
for
users.
D
Now,
there's
a
bunch
to
be
gained
from
this
users
will
Define
the
schedule
on
which
maintenance
is
performed,
the
maintenance
get
executed
and
they
get
benefits.
On
the
flip
side,
there
were
some
real
challenges
for
first
Rakesh.
He
was
learning
things
that
were
outside
our
expertise
as
mentors
I,
don't
know
how
to
do
really
good
Jenkins,
uis,
rishab
I
think
felt.
Similarly,
he
was
doing
things
with
a
wide
range
of
git
versions,
an
ancient
Git
Version
as
installed
on
Centos
and
red
hat
7.
D
All
the
way
up
to
the
most
modern
git
versions
installed
on
Windows
or
on
bsds
all
have
to
be
handled
by
this
one
set
of
code.
We're
really
grateful
for
what
rushikesh
did
he
did
a
great
job
handling
the
challenges.
We
look
forward
to
it
to
merging
that
and
having
it
delivered
in
an
upcoming
release
of
the
git
plugin
John
Mark.
That's
really
all
I
had.
B
But
you
you
really
impressed
me
in
doing
a
very
condensed
Rich
presentation
of
the
work
on
her
cash,
so
thank
you
very
much
for
jumping
in
and
congratulations
to
hoshikash
the
mentor
team,
as
well
as
all
the
other
participants
that
that
presented
their
work
here.
It
was
really
a
great
summer
of
code,
so
I
want
to
thank
on
behalf
of
the
org
admin
team
here.
Thank
you
to
the
very
impressive
and
formidable
gsoc
contributors,
the
mentors.
Without
the
mentors
help
this
would
not
have
been
possible.
B
It
was
a
learning
process
and,
like
Mark
said
we
all
learned
from
it
working
together.
That
was
really
really
great
next
slide,
so
we're
getting
prepared
for
the
next
session.
Google
did
not
disclosed
exactly
if
when
how
the
next
session,
but
it
will,
it
will
happen
so
we
as
a
project
will
apply.
This
is
a
decision
made
by
this,
the
the
Outreach
Sig.
That
means
that
we
need
mentors.
B
We
need
project
ideas.
There
will
be
announcement
for
that.
If
you
want
to
join
the
org
admin
team,
let
us
know
I
think
that
Chris
will
join
again
for
next
year,
so
where
the
team
is
nearly
complete.
Thank
you
for
Chris,
for
for
joining
Alyssa
is
on
board.
Two
I
need
her
help,
because
she's
she's
been
key
in
the
startup
part
and
I
will
also
continue.
But
if
somebody
wants
to
to
join
the
effort,
is
org
admin
I'll
send
a
message
for
that.
B
We
don't
want
to
work
as
a
closed
Club.
Everybody
can
join
so
I'm
calling
to
the
community
through
this
discussion
or
this
online
Meetup,
and
there
will
other
announcement.
We
need
mentors.
We
need
project
ideas,
it's
a
very
interesting
experience
for
the
contributors,
but
also
for
the
mentors
and
has
a
big
impact
on
the
Jenkins
project.
Here
are
some
resources.
B
B
A
A
Was
a
bit
fun
so
devops
world
was
canceled,
so
we
they
will
schedule
an
online
virtual
event,
so
that
is
TBD
at
the
moment
and
then,
of
course,
fostom
is
our
another
annual
open
source
event
that
we
go
to
every
year.
So
that
is
going
to
be
in
person
next
year.
That
is
going
to
take
place
in
February,
the
4th
and
the
5th,
and
we
are
planning
to
be
there.
B
And
it
takes
place
in
Brussels,
so
I
can
go
with
my
bicycle
up
to
the
conference.
It
will
be
at
the
main
University
of
Brussels,
a
small
small
details
here.
I
was
ready
to
start
the
conference,
but
was
not
blown
away
by
the
wind
so
and
came
back
home
in
one
piece,
so
it
was
for
a
reason.
The
devops
was
canceled.
The
hurricane
was
here
again,
you've
seen
it
on
the
on
the
news.