►
Description
Part 1 of the GSoC project demos in the Jenkins organization. At this meeting GSoC students in the Jenkins will present their projects. Every student will do a quick project overview and a live demo of the current project status. Agenda:
* Martin d'Anjou - GSoC 2020 introduction
* Zixuan Liu - Jenkins X: Apps/Addons consolidation
* Sladyn Nunes - Custom Jenkins distribution build service
* Rishabh Budhouliya - Git Plugin Performance Improvements
* Kezhi Xiong - GitHub Checks API for Jenkins Plugins
Full presentation abstracts and links can be found here: https://docs.google.com/document/d/1F9JVUEQyTL_JI8-_WPV-vMbuX94ZENjffsVlPOptPKE/edit#heading=h.3bn29jza54ej
During the first part we focus on projects happening under the umbrella of the Jenkins Platform SIG (except the Windows Services Project which will be presented during the second part).
A
A
Alright,
so
welcome
everyone.
In
this
difficult
year,
we
have
decided
to
get
together
and
help
each
other
right,
better
code
for
the
Jenkins,
open
source,
CI
CD
platform
and
this
year
were
participating
in
Summer
of
Code.
So
the
agenda
for
today
is
a
short
introduction
to
Jenkins
in
Summer
of
Code.
We're
gonna
have
demos
by
our
students
for
the
phase
coding
phase.
A
One
and
we're
gonna
have
questions
and
answers
for
at
the
end
of
each
presentation
and
at
the
end
of
this
presentation
so
which
google
Summer
of
Code
organization
are,
we,
we
are
the
Jenkins
project
organization,
so
this
is
where
the
Jenkins
and
the
Jenkins
X
projects
are
being
mentored
this
year
for
the
other
CI
CD
projects.
Please
look
under
the
CD
foundation
website,
where
you're
going
to
find
those
other
projects.
We
are
the
Jenkins
one.
A
This
is
our
fourth
year
in
Summer
of
Code,
and
this
year
we
have
proximate.
We
have
had
20
project
ideas
that
were
submitted
and
we
accepted
seven
students.
This
is
a
great
year
for
us.
We
have
two
to
four
mentors
per
project,
and
this
is
you
know
one
of
greatest
participation,
so
we've
grown
slowly
but
surely
every
year
we're
hosting
Jenkins
and
Jenkins
X
Summer
of
Code
projects
this
year.
And
if
you
want
to
know
more
about
Jenkins
in
Summer
of
Code,
please
visit
our
website
Jenkins
that
IO
slash
projects,
slash
JSOC,.
A
Communication
channels
to
reach
out
to
us,
we
have
a
mailing
list
on
the
Google
Groups.
We
have
a
git
er
chat
under
Jenkins
CI
/
JSOC,
sig
sig
stands
for
special
interest
group.
We
have
regular
office
hours
on
Wednesdays,
we
are
holding
them
online
and
via
video
call,
whenever
needed,
there's
project,
specific
channels
that
you
can
reach.
If
you
are
interested
in
one
of
our
specific
Summer
of
Code
projects
and
the
Jenkins
X
slack
channel
is
also
open
for
questions
and
participation.
A
During
this
presentation,
we're
gonna
take
questions
via
the
zoom
chat
or
on
the
jsoc
guitar
chat.
So
here
there's
the
link
after
the
presentations.
You
can
ask
your
questions
on
guitar
or
on
the
mailing
list
for
participation.
We
have
a
code
of
conduct
and
essentially
please
be
nice
to
one
another,
and
if
you
want
details
regarding.
B
A
Code
of
conduct,
there
is
the
link
for
you,
the
links
for
these
slides,
here's,
the
short
URL
down
at
the
bottom
and
where
so
before
we
get
into
the
part
1
demo
I
just
like
to
remind
everyone
that
we're
at
the
end
of
the
coding
phase.
One
word
during
the
we
are
in
the
evaluation
period.
So
if
there
are
mentors
who
have
not
submitted
yet
their
evaluation,
just
like
to
remind
you
that
we
have
approximately
one
day,
5
hours,
48
minutes
and
24
seconds
left
to
complete
those
evaluations
all
right
before
we
start.
C
A
Thank
you
all
a
guy.
Thank
you.
Thank
you
for
reminding
us
that
you
know.
Everybody's
contribution
is
super
welcome
and
we're
very
grateful
to
have
all
of
you
participating
in
this
project.
So
thank
you,
okay.
So,
let's
go
to
our
first
presentation
of
this
part.
One
of
the
demos
just
a
reminder,
we're
gonna,
have
part
two
part.
Two
of
the
demos
gonna
have
three
other
demos
in
a
couple
in
an
hour
and
a
half
two
hours
from
now.
Okay,
so
Jenkins
X
applications
and
add-ons
consolidation
by
X,
wand,
Lu
and
Cara.
A
D
About
his
work,
but
I
just
wanted
to
say
quickly
on
behalf
of
Jenkins
X,
thank
you
to
the
Dickens
org
for
having
us
as
part
of
your
JSOC
umbrella.
This
year,
we've
had
a
really
good
experience
and
been
really
well
supported,
and
we
really
appreciate
it.
So
one
has
done
amazing
work.
So
I
will
let
him
now
speak
about
what
he
has
done
for
us.
E
E
D
A
B
F
F
Yeah
so
yeah,
so
I
just
wanted
to
introduce
first
of
all
so
I'm
stealin
and
I'm,
a
student
in
the
Jenkins
google
Summer
of
Code
for
the
year
2020
and
as
my
mentors
I
have
16
Rick
and,
of
course,
for
each
eye
has
been
added,
so
apologies
for
not
actually
having
an
India
so
as
well
as
the
Oleg
as
a
technical
advisor,
so
yeah,
so
I
think
I
can
begin.
My
presentation.
F
So,
first
of
all,
I
started
up
what
the
project
is
about,
so
the
initial
idea
of
the
project
was
to
make
you
know
to
have
our
Jenkins
out
of
the
box
custom
distribution.
So
whenever
you
install
or
you
get
a
Jenkins
instance,
you
have
to
go
to
the
entire
process
of
actually
configuring
every
single
instance.
You
know
you
need
to
download
the
plugins.
You
know
you
need
to
write
the
you
know,
select
put
in
a
bunch
of
numbers
and
so
on
and
so
forth,
and
that
takes
that
be
time-consuming.
F
It
can
be
a
lot
of
time
and,
to
you
know,
speed
up
that
process
or
make
it
easier
for
a
new
user
to
actually
use
the
Jenkins
distribution
or
probably,
if
he
has
a
use
case.
That
is
very,
very
common
in
the
industry,
for
example,
you
find
AWS
distributions
or
you
find
distribution
on
kubernetes
and
stuff
and
which
makes
it
you
know
which
makes
sense
to
have
custom
distributions
just
like
on
top
of
the
Linux
kernel,
you
have
a
bun.
Do
you
have
viewer
videos
of
the
flavors
just
like
that?
F
So
what
we
aim
to
do
is
to
have
an
out-of-the-box
Jenkins
distribution
with
a
very
simple
user
interface
and
actually
that's
the
kind
of
USP
of
the
entire.
You
know
the
project.
It
needs
to
be
very,
very
simple
to
use
and
you
know
very
easy
to
interact
with
so
that
you
are
able
to
configure
it
in
a
very,
very
simple
way,
the
third
and
fourth
on
putting
forth
points
of
the
project.
What
the
project
is
about,
the
community
shared
configuration,
so
you
know
Jenkins
is
all
about
the
community.
F
We
have
a
huge
community
and
in
order
to
leverage
of
the
contributions
made
by
the
entire
community,
we
have
community
shared
configurations.
That
is
that,
if
you
make
us
a
configuration-
and
you
want
to
share
it
with
the
world-
probably
we
will
have
us.
You
know
we'll
have
a
feature
where
you
can
share
your
configurations
with
with
Jenkins
users
around
the
world,
which
makes
it
very
very
easy.
F
You
know,
because
there
is
a
person
out
there
who
might
have
the
same
configuration
as
you
have,
and
you
know
why
would
you
want
to
reinvent
the
wheel
so
yeah?
That's
that's
about
it.
For
shared
community
configurations
and
easy
access
around
the
world,
so
sometimes
you
know
you
have
problems
with
the
Jenkins
server
like
pulling
in
plugins,
maybe
you're
running
it
behind
a
proxy
and
so
on
and
so
forth.
We
plan
to
make
this
service
easily
accessible.
That
is
one
of
the
deliverables
and
goals
for
the
project
and
we
hope
to
achieve
that.
F
So
that's
it
for
this
slide.
Moving
on
to
the
next
slide,
so
what's
the
current
problem
yeah
so
as
I
explained
in
detail
in
the
previous
actually,
so
this
should
in
the
previous
our
description,
the
entire
problem
is
up
a
downlo
Jenkins
first
select,
some
plugins
configure
them
take
a
lot
of
time
yeah,
and
so
we
want
to
get
a
perfect
Jenkins
distribution
right
out
of
the
box,
so
it
contains
all
that
you
need
and
save
over
that
time.
F
F
Okay,
what's
the
project
motivation,
we
work
hard,
so
you
don't
have
to
that's
a
pretty
character
line,
so
we
will
be
doing
all
the
hard
work
behind
the
scene
and
we
will
be
leveraging
of
certain
packages
that
are
already
present
and
do
all
the
hard
work
so
that
you
just
have
to
sit
back
and
just
use
the
sort.
You
know
right,
it's
simple
and
plain
English,
whatever
you
want,
it
needs
to
happen,
so
features
implemented
in
phase
one.
So
this
is
a
phase
one
demo
and
so
I'll
talking
just
the
features
implemented
in
phase
one.
F
So
we
have
four
of
them
currently
the
package,
config
generation,
the
War
generation,
the
ability
to
configure
custom
packages
and
the
ability
to
I
plug
into
the
package.
Now
this
might
seem
a
bit
of
jargon
at
the
end,
but
what
it
essentially
does
is
you
know
package
configuration
just.
Let
me
see
if
I
can
get
the
point.
Oh
yeah,
this
so
yeah,
so
the
package
configuration
essentially
generate
the
package
of
config.
Why
minute?
So,
if
you
see
how
the
custom
package
or
wha
package
of
works,
you
need
to
provide
it
a
configuration
file.
F
F
These
two
go
hand-in-hand
because
you
need
a
watt
to
directly
just
run
it
out
of
the
box,
so
this
is
stage
one
generating
the
configuration
file
and
putting
that
configuration
file
into
the
wall
generator
so
that
we
have
a
word
at
the
end
that
stays
yeah
so
phase
one
has
two
complimenting
teachers
supported
to
it,
so
you
need
to
have
the
ability
to
our
plugins
to
it.
So
we
are
providing
you
with
all
of
the
1700
bucks
thanks
to
the
update
Center
and
you
will
be
have
the
ability
to
configure
the
package
once
it's
ready.
F
So
once
you
have
the
yml
file,
you
will
have
the
ability,
as
in
you
know,
as
a
engineer,
to
be
able
to
change
certain
aspects
like
if
you
realize
that
hey
you
now
own
a
different
version
of
changing.
You
can
do
that
at
the
end,
once
the
package
has
been
generated
so
making
me
Jenkins
initial
setup
simple.
So
this
is
the
workflow
actually
of
the
entire
service,
and
this
is
the
high
level
workflow.
So
you
select
your
favorite
plugins
that
you
want
into
your
video
Jenkins
distribution.
F
You
would
be
asking
him
a
question
that
hey
the
setup
wizard
already
installed
certain
plugins
yeah.
We
will
be
providing
an
option.
You
know
to
select
where
you
want
the
setup
visit
to
run
when
you
run
your
voice,
all
together,
customizing
the
configuration
obviously
having
the
chance
to
you
know
change
the
configuration
to
your
whims
and
fancies.
You
wanna
drop
the
container.
F
You
don't
want
to
talk
of
container,
that's
up
to
you
and
when
you
relax
so
once
you
relax
so
you're
either
ready
to
use
engine
power
and
you
just
need
to
download
and
run
so
after
you
generate
the
wall,
we
will
provide
with
the
option
to
download
it
and
you
can
just
go
ahead
and
run
it.
So
that's
the
entire
workflow,
it's
an
eye
level
below
it,
so
that
you
understand
in
the
coming
phases.
I
will
be
giving
the
slide
on
always
so
that
you
can.
F
You
know
the
overall
for
the
project
is
so
that's
about
it
for
that
yeah
there's
more.
Actually,
so
after
you
download
the
plugins,
you
can
share
it
in
the
community.
That's
the
most
important
part
is
the
community.
So
you
will
have
the
ability
to
share
those
configurations
with
the
wall.
It
might
be
an
AWS
configuration
a
kubernetes
configuration.
You
know,
basically,
whatever
you
have
it
right
out
of
the
box.
F
So
it
is
an
example
here,
I'm
not
gonna,
be
going
it
outside
links
for
now
just
want
the
slide
deck,
but
there
are
examples
such
as
the
Jenkins
formulas
page.
That
rake
has
very,
very
developed
for
us,
so
you
know
that
can
be
used
for
jenkees
distributions.
It
gives
you
an
example
of
what
the
entire
project
looks
like,
but
yeah.
That's
that's
about
it
for
all
of
the
pictures
that
we
plant
about
for
this
project.
Okay
time
for
some
demo
harm.
Let
me
just
exit
my
screen
and
yeah
cool
I.
F
Yeah
so
yeah,
so,
as
you
can
see,
this
is
the
user
interface
for
the
plugin
for
the
distribution.
We
have
all
of
the
things
that
we
wanna,
so
as
you
can
see,
you
can
scroll
to
pages.
This
might
seem
familiar
to
the
to
the
plugins
page
of
that
of
Jenkins.
We
even
search
for
all
of
the
plugins,
so
you
can
scroll
around
to
all
the
way
to
the
end,
but
you
can,
if
you
want
to,
and
that
would
give
you
the
list
of
all
of
the
1072
plugins
into
evolve
into
our
collection.
F
So
yeah
not
all,
is
supported
so
neat
and
fancy
features.
So
what
I'm
doing
here
is
I'm
going
to
follow
a
pretty
simple
procedure,
I'm
going
to
add
a
list
of
four
plugins
right
on
the
screen:
I'm,
not
gonna,
search
for
anyone,
especially
so
what
happens
are
listed
here
are
the
latest
versions.
We
haven't
included
the
ability
to
version
them
because
of
certain
compatibility
changes.
So
these
are
just
the
latest
versions.
We
might
have
the
ability
to
configure
it
later.
F
F
So
essentially,
these
are
the
details
for
your
Junkers
wha,
so
it
might
be
your
title
so
for
now
I'm
just
putting
taken
later
whatever
was,
and
so
for
now
you
can
choose
whatever
version
you
want,
that
isn't
any
restriction,
so
you
can
enter
your
ID,
the
fact
ID
for
the
package.
So
all
of
these
fields
that
are
being
provided
here
are
there
are
pretty
much
self-explanatory.
So
you
can
get
an
example
and
the
description,
obviously
blah
blah
so.
F
You,
okay,
you
also
have
the
option
to
add
Jacob.
If
you
don't
want
to
use
yes,
but
yes,
if
you
have
a
Jake
a
spine
into
your
voice
object,
so
I
really
want
to
insert
it.
You
do
have
the
ability
to
include
it.
Don't
just
omit
the
docker
build
so
yeah
Jenkins
experiment,
you
can
click
Casa
bills.
This
is
of
been
setting.
So
if
you
want
to
configure
it,
you
have
the
freedom
to
configure
it.
The
way
you
want,
so
you
can
choose
a
darker
base.
F
You
can
choose
your
dog
up
in
all
sorts
of
options
here
and
once
you
generate
package,
it
is
going
to
go
ahead
and
generate,
and
this
might
take
a
minute
because
it
needs
to
pull
in
all
of
the
plugins
and
stuff
all
of
the
data.
So
once
your
generate
plugin
package
configuration
there's
going
to
be
a
generation
of
plugins.
So
why
did
this
package
in
rate
I'm
going
to
take
you
I'm,
not
gonna.
You
know,
have
a
staring
at
a
screen
for
that
that
for
a
minute
or
so
45
seconds
to
be
precise,
I'll.
F
You
to
the
way
you
can
you
don't
fail,
this
repositories
hosted
and
stuff.
So
just
coming
back
to
this,
you
have
the
general
distribution
service.
Of
course
you
don't
get
up
and
we've
used
Springwood
and
react,
as
a
combination
of
you
know,
services
so
that
to
make
this
project
successful,
so
react
is
used
for
the
front
end
and
spring
wait
for
the
bus,
oh
that
too
shorter
than
expected,
so
I'm
going
to
be
screening
out
yeah.
So,
as
you
can
see
you,
this
is
the
package
of
config
wireman.
F
This
is
your
configuration
that
goes
into
generating
the
watch.
So,
as
you
can
see,
I
selected
the
four
plugins
auto
status,
the
auto
status,
the
CCM
is
your
storage
media
version
number.
So
you
have
all
of
your
place
that
you
selected
to
move
the
plug-in
the
maybe
I.
Remember
Jake
asked
so
you
can
your
configuration
Xcode
as
well
in
your
directory.
Obviously
you
can
change
directory
paths
now.
One
good
feature
about
this
is
yeah.
Just
before
I
move
to
that
you
have
the
bill
settings.
You
have
the
bundles
and
stuff.
F
I
entered
to
point
107.3,
so
that's
there
as
well,
and
these
are
default
properties,
so
we
were
debating
on
whether
to
include
them
as
defaults,
but
we'll
just
select
it
to
use
them
metaphor,
and
this
also
editor
as
well.
So
if
you
realize
that
hey
I'm
a
stake
in
the
versioning
and
I
want
to
change
this
version,
I
can
you
know,
go
with,
you
know
say,
doesn't
look
like.
F
F
Okay,
apart
from
this,
what
another
cool
thing
that
you
can
do
is:
if
you
want
to
use
this
in
conjunction
with
your
custom
wall
packaging,
you
have
the
option
to
download
this
separation,
so
download
custom
package
I
can
see
if
here
and
I
might
just
click
it
and
it
might
take
some
times
opening
to
demo
but
yeah
you
can
download
the
package
text.
Finally,
you
can
use
it
for
generating
your
wall
package
so,
as
you
can
see
the
system,
apart
from
that,
that's
all
about
it.
For
the
demo,
the
download
wha
file
option.
F
Now
you
may
be
wondering
why
is
that
button
there,
so
that
button
is
actually
there
for
it's
a
phase
to
deliver
so
for
the
next
phase,
probably
you'll
see
that
button
working
that
button,
the
wall
generation
has
already
been
implemented,
but
you
just
can't
download
it
from
there
right
now.
So
that's
a
phase
2
you'll
be
able
to
down
to
the
box
island.
Probably
I
can
show
you
in
the
next
phase.
Oh,
you
can
run
it
out
of
the
box.
That's
for
phase
2!
So
coming
back,
that's
that's
about
it!
F
F
The
Ridgid
service,
it's
pretty
simple,
to
just
spin
it
up
and
run
so
we
provided
all
the
containers,
a
few
commands
and
you're
off
and
running.
Apart
from
this,
you
have
a
get
a
channel
or
the
customer
needs
to
be
serviced.
So
you
can,
you
can
have
a
here.
You
can
feel
free
to
ping
the
chat
or,
if
you
just
want
to
say,
hi,
it's
just
completely:
okay,
yeah
and
there's
a
project
link
as
well.
So
you
can
find
the
project
links
in
the
description.
These
slides
will
be
made
public
later.
F
Okay,
what's
next,
that's
interesting!
So
what's
next
is
you
saw
phase
two
we're
done
with
phase
one,
and
it
was
absolutely
amazing
what
we
and
to
do
for
Phase
two
is
focus
on
improving
the
user
experience.
I
know
I'm,
not
very
good
at
you,
I
put
butter
yeah,
that's
something
that
we
aim
to
improve
over
the
next
phase,
so
that
it's
pretty
easier
to
use,
maybe
less
for
scrolling
and
stuff
implementing
the
wire
generation
and
downloads.
F
So
that's,
okay,
too
again,
so
then
you
can
download
the
war
file
and
use
it
later
to
the
book
and
milestones
so
I
have
set
up
some
of
the
milestones
for
Phase
two,
so
that
I
could
take
you
through
just
a
just
a
few
of
them,
not
deep,
diving
into
code.
That's
not
for
the
demo
is
for
but
yeah.
If
you
want
to
have
a
look
at
the
milestones,
I'm,
just
showing
you,
these
are
some
of
them
geez
of
Phase
two.
F
Apart
from
that
yeah,
that's
about
it
just
before
I
hand
over
the
bike
mic
back.
I
would
like
to
thank
my
mentors.
Christian
Christian
great
apologize
have
been
absolutely
wonderful
and
I've
enjoyed
working
with
them.
A
lot
I'm
hoping
to
you
know,
work
with
them
for
the
next
two
months
to
make
this
project
so
you're
handing
over
the
mic
back
thanks
a
lot.
A
G
I'm
no
questions,
but
I
would
like
to
say
that
Slayton
has
done
a
great
job.
This
first
I
guess
milestone.
You
saw
like
that
incredible
demo
and
I
know
that
he
said
his
UI
skills
are
not
that
great,
but
I
think
it
looks
amazing,
like
it's
really
cool,
to
be
able
to
click
all
the
different
cards
and
be
able
to
add
the
plugin.
So
I
think
he
did
a
great
job
and
I'm
really
looking
forward
to
milestone
two
and
seeing
what
they
can
accomplish.
The
congratulations
I
think
he
did
a
great
job.
I.
H
A
C
Yeah
I
have
a
quick
question
yeah
most
about
the
front-end
part.
So
right
now
we
have
at
least
three
places
where
we
have
a
listing
for
plugins.
One
is
a
plug-in
side
which
is
basically
written
in
red
as
well.
This
Java
not
clean
but
Java
as
a
back-end,
then
we
have
plugin
manager
inside
the
Jenkins
core,
and
now
we
have
the
custom.
Mr.
F
You
think
about
that.
Yeah
sounds
really
interesting,
because
we
have
three
different
places,
and
rightly
so,
actually
having
a
unified
place
to
pick
up,
you
know
plugins
from
a
central
place.
That's
that's
really
amazing
yeah
taking
into
consideration
that
could
be
done
for
the
future
you
know
to
have,
but
then
that
would
make
it
indicate
coming
back
to
the
service
tree
in
order
to
generate
the
list,
because
for
the
custom
distribution
service
you
would
need
to
have
those
plugins
I
mean
pulled
or
something
so
it
would.
It
would
make
it
difficult
to
come
back.
H
So
I
think
I
know
the
end
points
are
getting.
The
plug-in
list
is
only
serving
the
entire
list
of
plugins.
We
could
have
a
paginated
query
sort
of
the
thing
implemented
so
that
we
only
get
chunk
of
the
plug-in
list
that
we
want
to
show
in
the
front-end
and
then
likewise
end
user
searches
or
user.
Go
to
the
next
page.
Then,
based
on
that
further
plug-in
list
would
be
test
so
I
mean
that's
a
thing
for
phase
two.
J
C
C
H
C
A
K
I'm
going
to
talk
about
my
project,
which
is
the
gate,
plug-in
performance
improvement,
my
name
is
Vishal
and
Martin
has
introduced.
Me
I
would
first
like
to
thank
my
mentor
before
I
move
on
Marc,
Fran,
justin,
parish
and
omeka.
Their
constant
guidance
helped
me
a
lot
during
the
development
of
this
project
during
phase
one
so
about
me.
I
mostly
put
in
Java
I,
have
some
interesting
machine
learning
as
well
during
college
I
research
papers
on
the
application
of
convolutional
neural
networks,
which
I
commissioned
a
Content.
K
That's
it
now
the
project.
The
aim
of
the
project
is
simple:
it's
to
improve
the
performance
of
the
gate
plugin
now
before
we
move
on
to
how
we
are
going
to
do
that,
we
first
need
to
know
that
the
get
plug-in
essentially
provides
the
gift
functionalities,
jenkin
and,
and
it
does
that
by
providing
two
implementations
internally.
K
The
first
one
is
the
command
line
jet
and
the
second
is
a
pure
Java
implementation
called
Jacob,
so
by
default,
CLI
get
is,
if
included
in
the
plug-in,
but
if
I
use
the
user
wishes
to,
they
can
use
Jacob
as
an
implementation
as
well
in
our
infrastructure.
In
I
see
a
dent
in
what
I
owe
we
use
Jacob
as
the
default
implementation,
so
what
we
want
to
do,
how
are
we
going
to
improve?
The
function?
Get
begin
the
first,
so
there
are
two
stages
to
the
project
and
both
can
work
family.
K
The
first
stage
is
to
apply
a
micro
benchmarking
frame
framework
to
to
study
the
two
to
Gailey
comparative
analysis
between
the
execution
time
of
the
grid
operations
implemented
in
both
of
these
implementations.
So
what
we
want
to
do
is
is
we
want
to.
We
want
to
basically
isolate
the
gate
operation
and
then
ideally
find
out
which
implementation
is
performing
better
than
the
other
or
particular
parameters
like
repository
size
or
the
number
of
branches
or
the
history,
the
commit
history
and
or
maybe
the
different
platforms
like
Windows
or
Mac
or
Linux
other
distributions.
K
So
so
that
is
the
first
stage.
The
second
stage
is
to
use
the
insights
we
get
from
that
analysis
and
to
you
and
to
encode
and
decode
those
and
the
insides
inside
the
plugin.
For
an
example,
if
we
find
out
that
the
performance
of
J
gate
is
affected
by
the
size
of
the
increasing
size
of
the
repository,
we
can
either
switch
inside
the
plug-in.
When
we
see
that
we
have
a
large
size
depository,
we
can
switch,
we
can
switch
from
yet
and
and
basically
stop
the
degradation
of
performance.
K
So
so
what
we
have
done
in
three
is
one
what
we
were
supposed
to
do
and
we've
done.
The
first
was
to
integrate
the
gmh
benchmarks
inside
the
gate.
Banks
again
and
I-
did
that
you.
So
it
was
pretty
simple,
because
in
a
previous
edition
of
project,
jmh
is
basically
providing
I-I-I
had
to
do
nothing
if
not
in
the
external
dependencies.
It's
it's
provided
in
the
Jenkins
unit
test
harness
so
I
just
have
to
I
I
wrote
a
bit
of
I
wrote
to
get
operations
benchmarks.
The
first
is
the
expression.
K
The
second
is
get
LS
remote
and
then
the
second
step
is
to
validate
those
benchmark
results.
So
how
do
we
do
that?
The
first
is
that
I
create
some
baseline
experiment
like
using
system
dot,
nano
time
or
timing
those
operations.
The
second
is
to
profile
the
junk
Jenkins
instant
instance
with
Java
flight
recorder,
and
the
third
is
to
ask
for
expert
opinion
from
the
mentors
I
have
the
maintenance
of
the
mechanism.
So
these
three
ways
I
validate
the
results.
K
I
again,
the
second
deliverable
was
to
fix
an
existing
performance
issue
inside
the
game
plugin,
which
is
called
the
gift.
The
issue
is
that
we
call
git
fetch
twice
while
we
are
checking
out
the
repository,
so
we
have
to
fix
that.
The
second
was.
The
third
was
to
possibly
design
a
strategy
to
implement
two
strategy
to
implement
the
improvements
we
are
going
to
find
out
from
the
benchmarking
strategy
inside
the
plugin.
So
why?
Why
do
we
want
to
performance,
benchmark
I?
K
K
We
would
like
to
find
out
the
bottlenecks
and
then
possibly
fix
them
so
for
an
example,
through
benchmarking,
I
found
out
that
for
a
large
size
repository
like
Ruby,
it
is
going
to
be
too
many
percent
faster
than
Jacob
forming
official
operation.
That's
I
think
big
enough
motivation
to
do
this
project.
K
Okay.
So
how
am
I?
How
am
I
creating
a
comparative
study
between
those
operations?
It's
done
using
the
jmh,
which
is
the
java
micro
benchmark,
hardness.
It's
it's
provided
within
the
Jenkins
unit
test
harness
so
I,
don't
have
to
add
anything
in
the
integrated
it
inside
the
gate.
Clanks
I
mean
you
have
to
plug
in
and
get
flying
again,
so
the
steps
be
performed
to
writing
it
to
analyzing
the
result
we
put
a
benchmark,
we
don't
run
it
on
the
infrastructure
and
then
we
visualize
the
benchmark
so
I'm
going
to
show
you
other
steps.
K
The
first
is
that
I
have
added
a
module
inside
the
deep
line
plugging
in
under
the
test
module.
This
is
where
the
benchmark
slave
or
each
operation
I
create
another
benchmark.
I
have
some
utilities
as
well
to
sort
the
benchmarks,
then
the
second
step,
which
is
to
run
it
on
the
infrastructure.
We
just
have
to
add
another
step,
called
run
benchmark,
which
is
provided
by
the
previous
G
Shock
project.
It's
very
convenient
where
it
will
be
infrastructure.
The
third
process
is
to
visualize
it.
K
So
what
you've
done
is
right
now,
I
will
hopefully
added
so
there's
a
plugin
called
gh
report,
visualizer
which
what
it
does
is
it
ingests
the
benchmark
results
from
the
from
the
frame?
Oh,
can
it
visualizes
those
results?
So
once
we
repaid
that
plug-in
inside
the
Jenkins
instance,
you
once
you
build
your
project
and
run
the
benchmarks.
You
have
a
new
tab
or
GMs
report,
you
click
it
and
you
can
see
the
benchmarks
visualized
and
you
can
add
an
IV
stem.
So
this
is
how
we
we
have.
K
This
is
our
benchmarking
strategy
for
the
plugin
now
git
fetch,
so
with
first
get
patch
I'd
like
to
show
my
results
and
the
analysis
we
have
done
with
it.
So
we
get
fetch.
Let's
just
concentrate
on
the
first
graph
in
the
first
block
is
the
first
graph
I.
Have
the
x-axis
is
the
repository
size?
The
y-axis
is
the
average
time
execution
many
seconds
per
operation
so
for
an
increasing
size
of
all
the
trees
you
can
see
or
get
ortho
jacott.
That
time
is
going
to
increase.
K
That's
an
obvious
fact,
but
one
interesting
thing
which
you
might
see
here
is
that
there
is
a
change
in
the
nature
of
Forman's
of
Jacob
as
the
repository
size
increases,
and
how
is
that
happening?
If
you,
if
you,
if
you
consider
at
this
part
of
the
graph
for
a
suppository
size
less
than
let's
say
5
MB
jagged,
is
performing
better
than
yet
feel
idea
and
once
me
once
we
move
on
from
a
certain
point,
then
jagged
is
exponentially
the
forms
of
J.
K
It
is
degraded,
and
this
might
this
might
look
like
the
graph
might
look
like
they're
going
to
converge
them
at
some
point.
But
this
is
this
graph
has
been
taken
on
a
log
scale.
So
then
I'm
saying
the
degradation
explanation.
It
is
actually
it's
not
going
to
converge
here
and
quantitatively.
If
we
see
the
results
for
Ruby
I
benchmark
the
gate
fetch
from
the
gate,
fetch
operation
or
what
are
the
both
of
the
implementations,
there
is
a
2
minutes,
20
seconds,
difference
between
gate
and
jagged
when
we
fetch
Ruby.
K
So
that's
that's
a
huge
difference
and
we
on
the
second
graph.
You
can
see
it's
the
nature
of
jagged
performance,
extreme,
the
intersection
point
where
the
nature
changes
or
the
inflection
point.
It's
it's
a
little
different
from
what
we've
seen
in
the
first
graph.
But
but
the
main
point
to
the
emphasis
point
is
that
there
is
a
change
and
for
large
repository
now
size
reported
repository
is
jagged.
K
I
would
say
it
degraded
and
it
adds
a
lot
of
overhead
if
you
using
fell
outside
of
all
the
trees,
so
in
sites
the
first
time,
they've
got
it's
that
execution
time
is,
of
course,
going
to
increases
the
quality
increases.
The
second
is
that
there
is
an
infection
point
on
the
scale
of
the
repositories
ie,
where
the
nature
of
the
DAK
becomes
changes.
Now
the
important
part
is
that
we
can
use
this
in
insight
to
implement
a
feature
which
would
avoid
jagged
when
we
are
using
large
repositories
and
the
quantitative
act.
K
Now
benchmarking
get
a
less
remote,
the
experiment
was
pretty
simple:
I
am
my
benchmark
is
interacting
with
the
five
repositories
there
and
how
the
repository
is
the
size
increases
and
the
number
of
references
increases
as
well.
These
are
the
number
of
returns,
the
references.
When
we
see
the
pencil
there
is
a
Blanche's
tags
and
pull
requests
all
of
those
references
total.
So
so
what
you
see
here
is
the
exact
visualization
which
we
get
from
the
plugin
so
or
let's
just
concentrate
on
get.
So
what
get?
K
For
those
five
repository,
the
performance
as
the
size
of
the
repository
increases,
the
GLS
mode
is
going
to
take
more
time
and
that
I
think
I
know
this
fact.
But
the
main
question
is:
when
the
compare
gate
in
Jake
it
is
there
a
difference
in
performance,
and
there
is
none
according
to
the
benchmarks,
it's
actually
not
very
much
it's
less
than
a
second
less
than
a
half
of
a
half
of
a
second.
K
So,
even
if
you
see
for
the
for
kubernetes,
which
a
large
size
repository
there,
there
is
a
difference
when
we
look
at
gate
and
Jake
it,
but
there
is
a
pretty
big
error
in
measurement
or
these
calculations,
and
that
is
happening
because
of
this
benchmark.
They're
involving
network
for
the
gate
will
fetch
when
I
don't
use.
I
use
a
local
git
repository
to
fetch
to
to
benchmark
the
fetch
operation,
but
for
this
operation
they
directly
using
the
Internet.
K
K
One
yeah,
so
the
issue
is
pretty
simple:
when
you're
in
the
during
the
checkout
step,
the
plugin
is
going
to
fetch
the
repository
once
and
again
going
to
do
that.
So
this
is
the
issue
the
solution.
The
solution
was
that
I
provided
a
function
which
determines
if
we
want
to
avoid
the
second
patch
or
not,
which
ones
which
are
related
to
reference
impact
of
the
fix
on
the
gate,
again
performance.
K
So
before
the
project
marked
the
maintenance
of
the
plugin
mark
and
and
David,
they
used
to
get
reports
that
the
redundant
such
as
adding
considerable
performance
overhead
in
their
setup.
So
so
that
that's
what
we're
you,
what
we're
basically
fixing
when
you're
saying
that
we're
avoiding
the
second
patch
at
all
the
head
for
the
Phase
two.
What
do
you
want
to
do
so
as
you've
seen
that
we've
gained
some
result
is
where
we're
seeing
that
the
performance
of
dick
edge,
the
implementations
is
directly
correlated
to
the
size
of
the
repository.
K
We
would
like
to
create
a
class
or
git
repository
size,
estimator,
which
ideally
would
like
to
estimate
the
size
of
the
repository
without
cloning.
The
repository
and
we
have
discussed
some
heuristics-
we
are
going
to
use
to
do
that.
We
don't
have
a
definite
way
to
do
it,
but
we
have
some
heuristics
three
new
istic.
Actually
to
do
it.
It's
still
under
discussion.
Proof
of
contact
is
still
to
be
made.
So
that's
what
we
want
to
do,
and
that
is
how
we're
going
to
move
forward
with
implementing
the
n-side
we've
gained
from
the
benchmarks.
K
The
second
thing
we
want
we
would
like
to
do
is
to
move
out
from,
and
the
analysis
area
right
now
was
get
SEM.
Checkout
I
focus
too
much
on
profiling
and
then
shucking
it.
The
operations
involved
in
the
SCM
check
out
now
I
want
to
go
to
I'll,
be
branching
multi
branch
pipe
length
and
organization
holders.
Third,
is
to
validate
benchmarks
with
more
confidence.
K
That
is
when
I'm
benchmarking,
git
fetch
I
should
validate
that
it's
bringing
the
right
amount,
the
right
size,
the
repository
the
size
of
the
objects,
it's
correct,
so
that
I
don't
get
results
where
I
don't
analyze.
The
results,
which
are
the
operation
is
not
even
working
correctly.
The
last
thing
is
gardening,
the
bench
benchmarking
parameter.
K
So
if
you
see
that
not
only
the
size
of
the
repository
but
the
structure,
that
is
the
number
of
branches,
the
commit
history
and
the
tags,
all
of
that
can
also
have
can
have
a
an
impact
on
the
performance
and
we
need
to
almost
sensitivity.
Analysis
on
that
part
is
well
to
to
gain
decadent
things.
So
this
is
there
any
question
and
answer
questions
I.
C
Have
one
question
so
you
benchmark
different
guild
communications,
but
I,
wonder
whether
you
benchmarked
the
plugins
themselves,
because
we
have
the
client
plugin
plugin.
We
have
a
number
of
other
plugins.
They
depend
on
example,
for
credentials,
etc
and
I
wonder
whether
the
existing
which
are
cover
this
part
of
the
code
base
and
whether
it's
considered
to
be
a
potential
problem
for
performance.
I
C
But,
for
example,
even
if
we
take
a
common
geek
operations
like
get
to
check
out
the
CM
steps,
there
is
a
lot
of
additional
steps
involved,
for
example,
parsing
the
commit
history,
appropriate
visualization
actions
and
other
things
which
can
be
significant
overhead
for
performance.
Oh,
maybe
not
like.
We.
C
Because
games
just
a
common
problem
and
usually
when
you
work
on
performance,
is
better
to
have
some
metrics
on
the
top
level,
because
well
I
believe
that
it's
not
a
kiss
Fergie
plug-in.
But
sometimes
when
you
start
optimizing
low
level
logic,
you
may
realize
that
it's
actually
not
a
concern
on
a
higher
level,
because
there
are
problems
with
elderly
etcetera
in
your
business
logic,
which
basically
cause
a
lot
of
performance.
Depredation
again,
I,
don't
think
that
it's
the
keys
for
get
plugin.
I
K
The
heuristics
will
not
stay
independent
of
the
platform's.
There
is
a
there
might
be
differences
when
we
considered
in
Windows,
but
what
you
see
here
might
not
be
the
actual
representation
of
the
point
we
are
talking
about.
There's
the
nature
of
jagged
changes,
because
quantitatively,
when
I
see
the
results
from
the
benchmarks,
what
I
see
is.
C
I
K
A
B
B
B
So
how
everyone
Cartesian
today
I'm
going
to
present
my
face
1
progress
on
the
jaeseok
project.
You
have
checks,
API,
plugin
for
Jenkins
and
up
to
Quitman.
Hers
is
fully
empty,
so
first
I
want
to
introduce
a
little
bit
about
the
you,
have
checks,
API
and
so
basically,
it's
just
a
highly
customized
way
to
integrate
set
rules
like
Jenkins,
Travis
or
courtesy
to
make
reports
for
PR.
So
it
has
some
parameters
like
the
status
which
is
used
to
indicate
this
kind
of
stage.
B
You
have
to
say
a
job
like
the
jinkies
Butte,
and
then
we
have
a
conclusions
and
the
third
one
is
is
one
of
the
most
look.
Maybe
is
the
biggest
reason
why
we
have
this
plugin
here
this
annotation
and
with
annotations
we
can
make
worries
and
notices
on
specific
lines
of
a
code.
You
can
see
the
annotations
here.
It's
just
like
the
comment
you
made
where
you
are
reviewing
other
people's
PR,
the
next.
B
B
So
back
to
our
project.
I
want
to
first
talk
about
how
Jenkins
is
counting
integrated
is
through
the
github
say
this
API
that
the
status
API
is
very
limited
in
its
function.
It
can
only
support
the
status
and
a
short
message,
and
if
you
want
to
see
more
about
this
job,
you
have
to
click
this
email
link
here
and
normally
the
well
direct
you
to
the
blue
ocean
page.
B
But
we
all
know
that
Jenkins
can
do
more
than
just
the
status
and
a
short
message
and,
for
example,
we
have
the
wardens
plugin.
You
can
see
here.
We
have
many
warnings
from
different
clothes
like
PMD
and
Czech
style,
and
we
can
even
have
this
trendy
charts
to
help.
You
control
your
code
quality
during
your
development
and
also
for
the
code
coverage.
Api
I.
Have
this
gif
hear
from
Jeff
slide.
It
shows
the
file
filtering
feature
of
the
coverage
API.
B
So
what
we
are
thinking
is
maybe
wish
you
the
integrate,
based
functions
to
github,
and
so
we
can
make
the
kink
in.
Maybe
they
think
is
more
convenient
to
the
github
users
so
like
for
the
source
code
view
from
the
Warrens
plugin
you
can
see
here.
It
here
is
a
spot
back
wording
here.
Maybe
we
could
migrate
it
to
the
you
know:
chicken
half
as
chakra
notations,
so
for
this
one
we
have
the
Batman,
the
general
a
child.
B
B
We
have
the
supports
the
actions
whistling
casually
and
we
are
well
do
that
later
in
in
second
or
third
phases-
and
here
is
the
summary,
simple
summary
and
I
I
post
the
image
here
fun
dinner:
you
might,
you
can
imagine
that
they
here
is
something
more
useful
charts
like
the
code
coverage
charts.
The
the
word
is
trend,
but
anything
that's
more
useful
and
for
details.
It's
just
this
video
supports.
My
council
is
very
flexible
and
I
have
also
had
to
add
patience.
B
You
can
even
see
the
annotations
while,
like
you,
are
reviewing
the
PR
yeah,
so
the
next
part
is
within
first
demo
is
basically
simple.
Just
whatever
triggers
the
King
has
filled
here
for
now,
I
just
click
the
view
Now
button
and
it
will
start
building,
has
done
the
job
and
they
here
wait.
A
second
yeah
see
here
the
fist.
B
One
demo
is
cute
and
cute
as
well,
so
so
it's
in
progress
in
now
they're
out
there
help
we
haven't,
provided
any
output
for
this
in
progress
for
the
users,
the
consumers,
our
API,
can't
feel
free
to
to
make
any
output
here.
Well,
the
the
checks
is
steering
progressing.
It
depends
how
the
users
use
our
API,
so
when
in
winds
down
it's
just
the
same
as
I
showed
earlier.
B
Unify
changes
are
also
saying,
and
back
to
here
is.
Another
thing
is
about
the
details.
Url
here
I
just
provide
a
URL
URL
for
the
ICEA
dodging
history,
open,
maybe
the
users
or
developers
customers
about
API
could
provide.
You
are
a
alexis
field,
subfield
page
or
other
lotion
pages.
It
depends
how
to
use
our
API.
C
B
C
B
Sorry,
the
deploy
guys
not
owning
our
current
plan.
Our
plan
for
the
next
phase
is
to
to
use
to
let
what
is
blocking
and
the
code
coverage
and
plug
into
country
market,
pursuing
our
API
to
publish
Sheila's
warnings
and
for
the
third
base
material
support
the
pipeline
and
also
forces.
We
want
actions
and
some
other
our
works.
J
I
Case
you
have,
there
been
any
particular
problems.
You've
detected
that
that
might
be
relevant
to
the
audience.
That's
listening,
I
it
looks
brilliant
to
me.
I'm
excited
to
use
what
you're
doing
and
thrilled
are
the
things
you've
learned
in
the
process
that
oh
hey.
This
was
much
more
difficult
than
I
expected,
or
this
was
easier
I.
B
M
M
B
You
mean
for
the
pipeline
support,
yeah,
I,
guess
well
well
as
the
pipeline's
for
in
the
third
phase
and
about
in
the
next
phase,
and
because
we're
we're
letting
the
Warrens
plug
in
and
customer
API
in
the
next
phase,
so
for
the
warnings
fucking's
users
they
can
just
but
the
morning
clogging
supports
the
pipeline
support
support
of
the
pipeline.
So
when
the
users
use
the
earth
plugin
and
our
API
is
just
called
by
the
waters
plugin.
So
thank
you.
A
Later
today,
we're
going
to
have
part
two
demos,
that's
in
about
two
hours
from
now,
so
I
invite
everyone
interested
to
participate
in
that
next
session
and
if
you're,
looking
for
more
resources
on
Jenkins
google
Summer
of
Code
project,
please
visit
our
website.
We
have
recordings
on
YouTube
in
a
special
Summer
of
Code
playlist.
A
You
can
find
blog
posts
on
our
website
as
well,
and
here's
a
super
long
list
super
long
link
to
these
slides.
So
I
would
like
to
thank
all
our
students
again
for
their
work.
I
want
to
thank
our
mentors
for
making
all
of
this
possible
and
our
organs
for
all
the
work.
That's
happening
behind
the
scenes,
all
right.
So
thank
you
very
much.
Everyone.