►
From YouTube: 2020 08 12 GSoC Git Plugin Performance Project
Description
Google Summer of Code git plugin performance project meeting August 12, 2020.
A
What
is
its
name?
I'm
sorry.
I
forgot
the
devops
event
hosted
by
cloudbees
so
to
to
give
meaningful
insight
metrics.
I
would
need
to
profile
an
instance
which
would
have
jobs
which
would
simulate
a
a
near
real-world
use
case
of
the
plug-in,
and
then
I
could
then
we
could
use
the
updated
git
plug-in
and
with
the
updated
git
brand
source
plugin
to
to
see
to
measure
the
differences
in
performance
in
in
a
freestyle
job
in
a
multi-branch
project,
and-
and
in
that
way
we
we
for
ourselves
it
will.
A
It
will
be
a
great
exercise
to
understand
what
kind
of
changes
we
are
expecting.
Once
we
introduce
this
class
inside
git
plugin
this
change
and
for
the
presentation,
I
will
be
able
to
give
some
useful
results,
and
that
would
be
great
for
doing
the
project.
So
so
we
would
have
to
figure
out
how
to
profile
the
the
the
jenkins
instance
running
on
your
machines,
because
I
have
the
access
to
the
localhost
8080
port
directly.
I'm
not
sure
if
I
can
start
the
instances
using.
A
I
don't
have
the
permission,
I'm
not
sure.
How
would
I
start
the
instances
with.
I
know
how
to
start
them
if
I
am
starting
them
using
the
war,
the
jenkins
war,
so
I
can
use
the
java
command
to
run
it,
and
then
I
append
the
jfr
optional
arguments.
The
java
flight
recorder
optional
arguments
it
it
comes
packaged
with
the
jdk
11,
so
we
won't
have
to
add
anything
else
for
it,
but
we
do
need
to
run.
I
only
know
how
to
run
it
from
the
jenkins
work
from
for
a
for
darker
image.
A
I'm
not
sure
how
I
would
do
it,
how
I
would
proceed,
but
that's
something
we
might
need
to
figure
out
because
for
me
personally,
if
I
I
find
profiling
it
for
some
jobs,
I
would
I
can
do
it
for
some
jobs,
but
not
for
so.
As
far
as
I
know,
you
have
a
lot
of
jobs
in
the
in
that
instance,
which
would
automatically
be
be
profiled,
and
we
would,
I
think,
have
a
a
huge
range
of
data
on
how
the
plug-in
is
performing
with
the
changes.
A
B
Then
we
would
just
we
could
enable
time,
stamper
and-
and
I
think
we
could
even
in
that
case
then
rely
on
some
some
repositories.
We
already
have
that
are
of
known
size
like
the
get
client
plug-in
repository,
which
I
think
is
less
than
five
megabytes
still
and
the
git
plug-in
repository,
which
is,
I
suspect,
greater
than
five
meg.
It's
it's.
How
big.
B
Oh
good,
okay,
so
it's
and
then
we
could
take
jenkins.io,
which
I
think
is
about
60
now
and
there
we've
got
three
jenkins.io
is
around
400.
I
think
that's
fine!
Well,
that's
even
worse,
that's
even
even
great
okay.
So
if
jenkins.io
is
that
big,
it's
even
we've
got
those
and
by
choosing
those
those
are
repositories
that
already
have
a
jenkins
file,
and
so
we
could
enable
a
multi-branch
project
on
that
jenkins
instance
for
each
of
those,
some
of
them
already
have
it,
and
therefore
the
cash
will
already
be
available.
A
Okay,
but
but
if
we
are
going
to
do
this
whole
exercise,
wouldn't
we
want
to
do
both
of
the
things
to
run
it
for
a
freestyle
job
if
we
don't
have
a
multi
branch
project
for
all
of
the
cases,
and
this
would
not
just
be
for
the
results,
but
for
the
because
I
have
interactively
tested
this
feature,
but
it
maintains
you
the
mentors
haven't,
so
I
think
it
would
still
be.
It
would
be
better
if,
if
I,
if
I
provide
the
implemented
brand
source
plugin
and
then
we
can
test
yes.
A
Earlier
they
did,
they
did
say
that
we
have
to
do
it
till
friday
and
I
was
notified
about
it
on
monday.
So
I
thought
that
I
possibly
cannot
do
this
till
friday,
but
then
I
asked
oleg,
so
he
said
that
we
will
pro
since
the
gsoc
students
were
notified
at
a
later
stage.
They
would
give
us
later
dates
and
I
I've
been.
I
have
booked
the
recording
session
for
28th
of
august,
so
I
think.
A
A
A
A
The
second
all
the
other
three
prs,
which
we
have.
They
are
open
right
now,
the
biggest
one
is
the
get
tool
chooser
and
the
git
to
choose
a
test.
The
second
one
is
the
unsupported
command
the
the
usage
of
that
class
within
git
plugin.
I
I
have
some
work
on
that
pr.
The
third
one
is
the
extension
implementation
on
github
brand
source
plugin.
A
So
I'm
going
to
start
with
the
the
biggest.
We
are
the
the
major
concern
for
us,
the
git
tool
chooser
and
its
test.
So
so
there
has
been
a
change
in
design
for
that
pr
and-
and
the
reason
for
that
change
in
design
is,
is
a
is
an
observation,
brilliant
observation
by
omkar
and
fran.
They
both
pointed
out
a
huge,
I
would
say,
a
hole,
a
gaping
hole
inside
the
the
get
to
chooser's
implementation,
and
I
will
go
through
what
what
is
the
problem
and
how
have
I
solved
it?
A
I
just,
I
think,
I've
I've
added
the
comments
in
the
comment
message
and
I
would
I
would
just
show
that
and
then
explain
what
the
decision
the
change
is
so
so
currently,
so
we
are
talking
about
git
tool
here.
Git
tool
is
basically
a
class
which
is
encapsulating
the
details
about
the
git
implementation,
which
is
going
to
be
used
to
create
a
client
in
the
git
plugin,
so
currently
a
git
line.
We
know
that
a
client
is
initialized
with
a
git
implementation.
A
Now
there
are
two
decision
factors
which
decide
what
implementation
will
be
used.
The
first
is
the
user.
The
second
is
the
system.
The
user
has
an
option
to
choose,
decide
between
get
jet
or
j
get
apache.
These
are
the
three
options
they
have
and
if
they
do
not
choose,
we
provide
the
default
implementation
as
the
gate
implementation.
A
If
it
is
available,
if
it
is
not
available,
we
will
we
have
the
jget
implementation
ship
within
the
plug-in.
We
would
provide
that
the
second
decision
after
the
user
chooses
its
its
implementation,
its
preferred
implementation.
The
second
decision
is
taken
by
the
system,
that
is
that
it
takes
the
user's
choice
and
then
it
validates
with
the
particular
agent
or
wherever
the
system
is
working
to
check.
If
that
particular
user's
choice
is
available
within
the
system
or
not.
A
Now
what
is
happening
with
the
introduction
of
git
tool
chooser
is
that
we
have
added
another
decision
variable
to
this
whole
process
of
providing
the
implementation
from
the
user
to
the
client
to
to
the
process
of
making
the
client
we've
added.
Another
decision
variable,
which
is
the
get
tool
chooser,
but
the
get
tool
chooser
was
not
considering
what
the
system
is
evaluating
and
then
eva
then
providing
the
implementation.
A
What
the
git
tool
chooser
was
considering
was
that
okay,
I
will
tell
what
the
best
implementation
is,
but
before
telling
that
I
will
check
if
that
implementation
is
installed
or
not,
but
we
are
not
seeing
what
the
system
is
already
provide
has
already
provided
and
and
and
shortly
we
will
see
how
that
will
break
some.
You
use
cases
existing
if
we
do
not,
if
we
do
not
take
into
consider
consideration
what
the
system
is
providing
to
us,
so
so
the
change
in
design
is
basically.
A
What
I'm
doing
is
that
I'm
in
the
constructor
in
the
initialization
of
the
class,
I'm
adding
another
argument,
which
is
the
executable
path
of
the
the
implementation
which
the
user
has
provided,
so
so
how
this
works
within
the
git
plugin
before
the
get
tool
chooser
is
that
the
user
would
provide
for
git
for
get
the
cli
get
user
can
provide
the
name
of
the
implementation
and
provide
the
path
within
the
system.
That
is
how
it
is
installed.
So
the
git
plugin
uses
the
path
provided
by
the
by
the
user.
A
That
is
what
it
uses
to
feed
the
get
client
initializer,
and
then
it
initializes
the
git
client
that
that
is
how
it
works.
So
what
we
need
is
we
need
that
executable
path
and
then
we
can
decide
if
what
we
have
to
preserve
what
how
our
decision
is
not
affecting
the
existing
case
and-
and
I
think
the
best
way
to
to
understand
that
is
I,
let's
just
look
at
the
test
cases-
I've
added
so
that
those
are
the
scenarios
where
we
can
understand
how
this
is
affected,
so
I
will
okay.
A
This
is
the
test.
Yes,
yes,
so
we
have
two
scenarios
here.
The
first
scenario
is
the
size
of
the
repository
is
less
than
5
mb.
The
git
tool
chooser
will
recommend
jkt.
Now
this
is
from
get
to
user
side.
We
have
some
various
decision
variables.
We
have
to
consider
before
that.
Those
are,
let's
say:
the
user
has
installed,
the
installation
is
called
mygate
and
its
path
is
set
has
to
be
user
bin
git
earlier.
A
A
We
are
giving
the
name
for
it,
and
maybe
that
works
here,
because
it
is
linked,
so
git
would
work
in
a
system
where
user,
where
gate
is
installed
in
user
bin
for
a
next
system,
but
it
might
not
work
if
there
is
a
difference.
If
there
is
a
if
it
is
installed
at
a
different
path,
instead
of
the
user
pin,
which
might
be
unlikely,
but
it
still,
it's
still
a
case.
A
I
I
think
please
interrupt
me
if,
if
my
assumptions
are
wrong,
so
so
so
if
this
is
the
case
that
the
user
has
installed
the
git
tool
with
a
different
name
and
a
different
path,
what
we
would
do
is
so
what
we
should
expect
is
in
this
case
we
don't
have
j
get
in
this
system,
although
we
will
always
have
jet
in
the
system,
but
for
this
particular
use
case,
I
have
removed
I.
This
jenkins
instance
all
only
has
the
git
tool,
which
is
the
my
gate
2,
which
is
configured
by
the
user.
A
A
The
second
use
case
is
what
what,
if
we
have
the
same
git
installation
and
we
have
j
gate
within
the
system,
then
I
think
the
expected
behavior
is
that
it
should
provide
jj
as
the
expected
implementation-
and
one
thing
I
am
missing
here-
is
that,
while
writing
the
get
tool
chooser,
I
I
did
not
investigate
the
fact
that
we
do
not.
We
should
not.
We
are
not.
We
should
not
provide
the
implementation
name,
we
are
providing
the
implementation,
the
the
path
where
the
implementation
is
is
installed
for
the
get
client.
A
The
git
client
does
not
take
the
name
of
the
implementation.
It
takes
the
path
of
that
implementation.
That
only
matters
it
is
limited
to
the
scope
forget
for
jet
and
for
jkt
apache
it
doesn't
matter.
The
path
is
same
as
the
name.
That
is
what
is
what
I've
seen
in
the
get
tool
jet
tool
class,
which
is
implemented
on
the
extended
from
the
git
tool
class.
Forget
it
matters
because
the
name
and
the
path
where
it
is
installed
can
be
different.
A
So
this
is
this.
This
awareness,
which
I
did
not
have
earlier
to
the
observation
by
omkar
and
fran,
was
something
I
now
realized,
and
that
is
why
the
get
tool
chooser
is
now
aware
of
that
fact,
and
it
will
provide
the
path
instead
of
the
name
for
jet
and
jj
apache.
It
will
still
be
the
same.
It
is
equivalent
to
the
name,
but
for
git
it
will
provide
the
path
instead
of
the
name,
and
so
I
have
some
more
use
cases
where,
if
js,
I
was
not
cons,
yes,
mark.
B
B
Okay,
so
so
excellent
that
you
wrote
these
tests.
This
is
brilliant,
thank
you
so
much
to
fran
and
to
omkar
for
detecting
the
problem.
The
in
this
case.
Oh,
oh,
no,
okay!
It's
I
see
so
in
this
case.
You've
got
command
line,
git,
jgit
and
jgit
apache
and
it
chooses
jgit.
Do
you
have
a
test
which
has
only
command
line
git
and
jgid
apache.
B
Okay,
okay,
so
so
so
long
as
so,
it
looks
if
you've
got
the
well.
If
you
could
just
safety
check
for
my
comfort
that
if
cli
get
and
jake
and
apache
are
both
available,
but
jake
it
is
not.
J
get
apache
should
be
chosen
because
it
is
a
it
is
a
plug,
compatible
replacement
for
jdit
right.
So
so
you've
got
the
case
at
line
300,
where
you
are
correctly
choosing
j
get
apache.
So
that's
a
big
win.
A
B
A
B
A
B
A
A
And
so
this
was
the
scenario
when
the
git
tool
chooser
has
a
repository
of
size
less
than
5
mb.
Now,
if
the
scenario
is
that
the
repository
size
is
greater
than
5,
mb
cli
git
should
be
recommended,
and
I
think
the
case
is
again.
They
they
show
us
that
if
we
have
no
tool
installed
in
the
jenkins
instance,
I
assume
that
the
git
executable
would
can
be
named.
So
it
would
not.
It
would
be
named
gate
not
since
the
user
has
not
provided
the
path.
A
So
then
the
the
get
to
chooser
would
recommend
get,
and
if
there
is
a
case
where
j
gate
is
installed
and
git
is
not
installed
installed
in
the
system
and
it
has
to
recommend
git,
but
since
the
system
doesn't
have
git,
it
would
provide
jig
it.
It's
just,
I
would
say
an
exhaustive
list
of
the
possible
scenarios
we
could
have
and-
and
maybe
they
do
not
make
sense
in
a
lot
of
cases.
But
it's
a
possible
scenario.
We
could
have.
B
A
In
it
sample
repo
in
it
is
for
the
project
I
am
building,
so
I
for
this,
so
I
need
two
things
for
so
since
we
have
enabled
authentication
now
authentication,
we
provide
credentials
to
the
plugins
who
will
implement
the
extension
point.
We
need
to
send
them
two
things
and
the
first
is
the
context
of
the
job,
and
the
second
is
the
credentials
id
so
to
build
to
to
have
the
context.
A
I
need
to
build
a
project
so
so
that
I
have
a
context,
and
so
that
is
why
I
am
initializing
a
sample
repository
and
then
I'm
building
a
project
and
the
function
is
given
late.
It's
it's
the
later
part
of
the
code
and
the
credentials.
I
I
saw
this
in
one
of
the
tests
already
written
in
git
plugin.
This
is
a
way
to
so.
A
Initially
before
the
test
start,
I
have
added
before
a
method
which
would
initialize
a
a
local
credential
store
and
it
would
have
a
a
credential
called
github
with
the
id
github
and
username
password
sample
and
and
what
would
happen?
What
I
expect
is,
I
actually
expect
since
so
we,
so
our
responsibility
is
to
provide
the
credentials
id
in
the
context.
It's
the
plugins,
the
other
plugins
responsibility
to
use
them
and
to
validate
in
this
particular
test
class.
I
have
test
extensions.
A
Validates
them,
because
that
is
that
would
be
the
responsibility
of
the
of
to
get
a
branch
source
plugin
and
I'm
not
sure
if,
if
there's
a
point
of
validating
them
through
our
logic,
I
am
not
sure
if
we
should
do
that
right
now.
It
just
checks
if
the
current,
if
the
repository
url
contains
github
or
not,
that's
the
it's,
not
the
right
logic
to
check
it,
but
it's
just
for
this
test
class.
A
So
so
that
is
why
I
am
building
a
project
so
that
we
can
have
the
context
and
then
we
have
the
credentials
we
provide
to
the
get
to
chooser.
This
is
the
second
point,
the
change
in
design
I
wanted
to
discuss.
I
discussed
the
implementation
part
first,
the
git
tool
implementation
part,
so
you
can
look
at
the
test
cases
and
and
we
can
see
how
what
cases
I've
missed.
But
this
this
is.
This
is
a
big
change
which
I
missed
while
creating
this
class,
and
I
have
added
it
currently,
it's
pushed.
A
A
Any
concerns
possible
concerns,
I've
missed
or
maybe,
if,
if
you
later
look
at
the
pr
and
review
it,
then
I
think
that's
that's
the
better
way
right,
okay,
so
the
second
thing
is,
the
authentication
is
basically
providing
user
credentials
to
the
plugin.
Now,
with
this
change,
we
have
certain
issues
I
want
to
discuss.
The
first
is
that
there
are
multiple
ways:
multiple
credentials,
multiple
ways.
A
User
can
create
credentials
and
from
git
plugins
perspective,
we
have
I'm
not
just
maybe
more
than
two
or
three
valid
ways
of
creating
user
credentials,
but
when
we
provide
those
credentials
to
the
getup
branch
source
plugin,
the
github
branch
source
plugin
will
only
consume
username
password
type
of
credentials
and
it
would
not
consume
any
other
type
of
credential
we
may
throw.
We
may
provide
to
it
so
that
will
limit
our.
A
I
would
say
it
would
limit
the
cases
we
would
cater
in
terms
of
optimization.
I
could
not
find
a
way
around
to
so.
There
was
one
possibility
suggested
by
mark
that
maybe
the
get
transfers
plugin
maps,
the
url
urls
with
the
credentials.
So
if
I
provide
the
github
branch
shows
up
url
a
valid
repository,
remote
repository
url,
it
could
possibly
look
at
the
credentials
it
might
store.
A
But
again
I
think,
for
that,
a
user.
In
a
jenkins
instance,
the
user
would
have
a
pro
github
organization
project
and
would
have
to
set
up
those
credentials.
That
is
the
assumption
we
we
took,
but
I
cannot
find
any
way
where
only
the
repository
url
is
enough
to
get
the
credentials.
What
I
what
I'm
seeing
is.
We
need
the
context
and
we
need
the
credentials
id
so
so
that
is
a
concern.
A
A
C
A
point
of
reference,
I
think
we
were
putting
the
credentials
in
the
git
plugin
to
support
freestyle
projects
right.
That's
the
primary
reason
why
it's
in
the
git,
plugin
and
so
like
github
branch
source,
would
already
have
its
own
credentials
and
a
project
would
have
been
configured
with
project
credentials
for
that
project.
Right.
A
Get
a
brand
source
plugin
a
project;
yes,
it
would,
but
then
okay.
So
I
have
a
question
related
to
that
to
that
statement.
If
someone
is
configuring,
a
project
using
the
github
plugin
brand
source
plugin
it
will,
it
will
not
be
needing
the
get
get
git
plugin
for
any
for
for
the
branch
source
for
scanning
the
branches
or
for
because,
as
far
as
I've
seen
the
code
it
they
have
implemented
their
own
sem
apis.
A
They
would
not,
but
then
they
would
not
be
able
to.
We
will
not
be
able
to
actually
use
that
use
the
performance
improvement,
because
the
git
plugin
will
not
be
will
will
not
be
used
in
that
case.
If,
if
we
just
have
a
jenkin
in
jenkins
instance,
where
a
user
has
created
a
project
using
the
git
brand
source
plugin,
I
am
not
sure
the
optimizations
we
are
talking
about.
A
C
I
think
for
the
cloning
activities
and
stuff
like
that,
it
still
uses
all
the
get
plug-in
stuff
right
or
the
api
stuff
is
primarily
for
like
hey.
Do
I
have
new
branches
hey
like?
Are
there
other
things
going
on
they're,
also
doing
like
the
reach
out
stuff
that
we're
trying
to
do
with?
Like
the
estimation,
that's
all
the
api
driven
stuff,
but
I
think
all
the
mark
mark
can
go
go
ahead.
He
knows
better
than
me,
probably
yeah.
B
But
when
it
comes
time
to
clone
a
repository,
it
goes
down
to
the
git
plug-in
and
says
clone
the
repository
for
me,
and
but
then
it
provides
the
credential
that
it
has
to
the
git
plug-in.
So
I
think
that
supports
rishabh
your
your
assertion.
The
git
plug-in,
has
to
be
willing
to
provide
the
credential
out
to
to
others
who
may
need
it.
C
B
B
A
Not
those
credentials.
Would
we
be
passing
the
same
credentials?
I'm
actually
not
for
me
to
understand
that.
I
think
I
need
to
understand
the
credentials
api
better.
So
if
so,
the
credential
store,
which
stores
the
credentials
would
it
be
common
for
the
git
plugin
and
the
git
brand
source
plugin.
In
the
same
jenkins
instance,.
C
C
A
Okay,
so
then
I
would
need
to
create
a
function
which
would
check
the
credential
store
for
a
use,
I'm
not
what
I'm
not
able
to
figure
out
right
now.
Maybe
I
need
some
more
time
to
understand
it
is
that
how
would
I
uniquely
identify
those
credentials
from
the
perspective
of
git
plugin?
How
would
git
plugin
have
that
information?
C
Either
that
or
the
github
branch
source
plugin
provides
you
an
answer
based
on
the
results
of
the
query
like
either.
One
of
those
would
work,
but
I
don't
think
git
plugin
would
would
know
that
or
have
have
a
way
and
probably
shouldn't
reach
back
in
to
get
github
brand
source
to
try
and
figure
out,
like
mappings
of
things.
A
A
Branches,
so
the
problem
is
that
if
we
need
to
send
when
the
x
the
extension
we
we
are
implementing
it's
it's
in
a
static
con,
it's
a
static
class.
We
need
to
initialize
a
github
object,
which
is
basically
it
encapsulates
the
apis.
We
have
for
github
java
apis,
so
it
needs
the
credential.
So
at
that
point
of
time
it
needs
the
credentials
and
I
cannot
take
those
credentials
within
the
github
branch
source
plugin,
because
that
would
mean
that
I
have
to
provide
a
non-static
object
to
a
stack
static
class.
A
So
what
I
understand
what
my
understanding
is
that
the
extensions
if
they
are
static
classes
we
are
not
meant
to
take.
I
don't
know
information
from
the
object.
Individual
objects
of
that
particular
instance
instantiation
or
maybe
there's
something
I'm
missing
here.
My
my
my
question
is,
I
thought
about
using
if
the
github
brand
source.
Initially,
I
thought
that
if
the
github
brand
source
plugin
has
the
credentials,
why
not
use
them
for
the
extension,
but
how
I
was
limited
there
was
that
the
extension
is
in
when
I
implement
an
extension
point.
A
A
Plugin
is
what
I
could
not
figure
out
at
that
point
of
time,
and
the
second
thing
my
confusion
was
the
context,
so
I,
what
makes
sense
is
that
the
gate
plugin
should
provide
the
context
where
the
the
brand
source
plugin
should
scan,
with
which
the
brand
source
plugin
should
scan
the
credentials,
because
that
is
the
git
plugin
is
using
those
functionalities,
and
the
job
which
is
it
is
which
it
is
running,
should
be
the
context
it
is
providing
to
the
brand
source.
Plugin
is
what
I
understand
for
scanning
the
credentials
correctly.
A
A
C
A
So
justin,
you
are
right
here,
but
my
issue
is
that
I
I
want
to
show
you
the
issue
through
code,
so
the
estimator,
so
I
have
created
this
extension
inside
the
grid
brand
source
plugin
now
this
is
this
is
a
static
class.
How
do
I
access
the
context
of
the
current
branch
source
plugin
and
its
credential
id
and
provide
it
here
where
I
am
trying
to
connect
with
github
the
github
apis
and
then
retrieve
the
size
of
the
repository?
A
What
what
information
the
context?
So,
if
you're
talking
about
using
the
context
provided
by
the
github
brand
source,
plugin
and
the
credentials
id
of
that
plugin
only
then
we
need
to
provide
those
in
for
those
two
two
parameters
to
this
extension,
where
it
is
trying
to
query
the
size
of
the
repository.
A
A
That
is
how
this
is
working,
but
if
we
are
thinking
of
use,
if
we
know
that,
if
there
is
a
project
created
by
the
getup
branch
source
plugin,
then
we
would
have
the
credentials
within
the
plugin.
Then
how
would
I
use
its
credential
id
and
the
context
for
this
extension
is
something
I
I
am
not
able
to
understand.
Currently.
C
B
A
A
A
So
there
was
a
possibility
discussed
by
justin
that
what
if
we
use
the
credentials
in
the
context
within
the
brand
source
plugin,
that
would
make
us
less
dependent
on
what
the
git
plugin
is
providing
and
because
we
know
that
the
gear
brand
source
plugin
would
definitely
have
the
credentials
if
it
is
being
used
in
the
jenkins
instance.
The
git
plug-in
might
have
it
or
might
not.
Even
if
it
does
have
the
credentials,
it
might
have
the
type
of
credentials
which
are
not
supported
by
the
github
branch
source
plugin.
A
A
We
are
limited
to
the
user's
choice
of
using
username
and
password
credentials
in
the
git
plugin,
so
the
problem,
what
the
problem
is
that
the
user
might
they
will
not
know
about
this
performance
improvement
will
not
know
that
using
the
username
password
credentials
would
actually
enable
something
which
the
user
doesn't
even
know.
So
the
point
is
that
if
the
user
is
using
the
git
branch
source,
the
github
branch
source
plugin,
the
the
user
will
be
forced
to
use
username
password
credentials
and
would
add
that
in
the
jenkins
instance.
A
But
if
the
user
is,
if
we're
looking
at
this
problem
from
the
git
plugins
perspective
from
a
user,
who
is
only
using
the
git
plugin
and
not
aware
of
the
git
branch
hit
a
brand
source
plugin
for
that
user,
he
he
will
use
what
whatever
way
of
credentials
whatever
type
of
credentials
they
use
and
it
may
be
username
password
it
may
might
not
be
for
us.
It
will
only
help
if
it's
username
password
credential.
C
That's
a
primary
challenge:
yeah.
I
think
the
primary
challenge
is
going
to
be
usability
for
getting
a
branch
source
like
if
you
think
about
how
you
would
maybe
need
to
set
that,
because
if-
and
maybe
I'm
not
understanding
this
correctly
on
how
you
set
this
up
for
git
plug-in
and
how
this
would
look.
But
I
think,
if
I'm
understanding
this
correctly,
if
you're
setting
up
a
multi-branch
project
or
something
like
that,
you
would
select
your
credential
for
your
multi-branch
project
and
then
you
also
have
to
like.
A
It
is
but
then
that's
and
that's
an
added
responsibility
to
the
user
of
git
plug-in
who
doesn't
who
is
not
aware
of
the
performance
improvement.
It's
supposedly
a
hidden
feature.
The
user
is
not
aware
of
something
wouldn't
the
user
think
about.
Why
is
it
happening?
Why
would
it
I'm
not
sure,
I'm
not
sure
from
the
perspective
of
user
how
it
would
go,
but
but
then,
if
we
have
a
multi-branch
project,
we
wouldn't
even
need
the
credentials.
We
wouldn't
need
this
api.
We
would
have
the
cache.
A
So
I
I
think
this
this
needs
more
thinking
and
probably
to
clarify
to
have
a
clear,
a
clearer
discussion,
and
maybe
I
could
make
a
diagram
with
the
current
flow
of
authentication,
how
the
git
plugin
is
expecting
how
the
size,
how
is
it
working
so
that
then
maybe
the
mentors
can
review
the
diagram
and
the
current
implementation
the
way
it's
working,
because
the
pr
has
had,
I
think
it's
greater
than
60
messages.
It's
a
long
conversation.
A
It
might
be
difficult
for
people
who
haven't
reviewed
it
yet
so
I
I
would
add
a
diagram
to
it,
attach
a
diagram
with
the
current
flow
of
authentication
and
in
meanwhile
I'll
think
more
about
how
so
so.
Currently
it's
it's
a
non-blocking.
This
discussion
is
non-blocking
to
the
get
tool
choosers
release,
if,
if
you're
talking
about
that,
because
because
the
so
the
git
tool
user
expects
the
size
of
a
repository
from
the
rest,
apis,
it
is
able
to
do.
A
A
Yes,
so
mark's
thinking
so
this
so
so
currently
after
this
discussion
and
the
prs
the
changes
I've
done,
the
status
of
git
to
chooser
is
interactively.
I
have
the
current
changes.
I've
done.
I've
tested
the
gate
tool
chooser
with
with
multiple
implementations
and
in
the
case
of
a
cache,
cache
repos.
If
we
have
that,
then
it
should
use
that
to
estimate
the
size-
and
I
have
also
used
a
modified
version
of
the
getup
brand
source
plugin,
which
is
local
in
my
instance
and
I've.
A
I've
used
that
to
interactively
test
that
the
get
to
chooser
is
able
to
recommend
the
optimal
implementation.
While
we
are
checking
out
a
repository
using
the
git
plugin.
So
so
I
have
been
able
to
done
that.
The
next
step
after
the
review
we
have
for
the
current
changes
is
for
me
to
instantiate
to
to
add
the
git
to
chooser
everywhere.
A
The
client
is
being
created
within
the
git
plugin,
so
I
I
haven't
done
that,
and
the
reason
was
that
I
wanted
git
to
choose
it
to
be
a
functionally
working
class
before
we,
we
decided
to
add
it
at
places.
It
should
work
how
it's
supposed
to
and
after
I
think
what
justin
and
omkar
have
pointed
out.
I
I
assume
that
we're
and
one
case
I
missed
which
mark
has
pointed
out.
I
will
add
that
I
assume
we
are.
A
Code,
wise,
we
are
done
with
kit
tool
chooser,
but
again,
I
think
the
mentors
need
to
review
it
first.
There
might
be
things
I've
missed.
There
are
some
more.
There
are
more
test
cases
I
have
to
add,
and
those
are
related
to
unsupported
extensions
when
we're
using
that
in
the
environment.
The
unit
test
cases
do
not
cover
those
cases
where
we
are
using
unsupported
extensions
and
it
should
not
be
recommended
for
those
cases.
So
I
I
have
to
add
those
test
cases
test
cases
wise.
A
That
is
what
I
haven't
added
for
the
current
change,
which
is
using
the
existing
the
system
provided
path,
yet
executable
path
and
then
deciding
to
implement
to
recommend
the
implementation.
I've
I've
added
those
cases.
I've
just
shown
you
the
cases,
that's
the
latest
commit
in
the
in
rpr
number
931.
A
Apart
from
all
of
this,
I
have
one
more
thing
I
needed
to
discuss
was
the
extension
work.
So
that
is
something
something
I
am
doing
parallelly
and
I
have
been.
I
have
been
contact.
I
have
been
working
with
liam
on
on
merging
the
pr
for
the
github
branch
source
plugin.
I
was
stuck
at
creating
unit
test
cases
for
that,
because
so
it
was,
I
think
it's
it's
really.
A
A
I
have
one
more
issue
I
haven't
discussed
with
the
mentors
is
that
so
for
the
github
brand
source,
plugin
git
plugin
is
is
added
within
that
plugin
via
the
github
plugin,
so
the
gate
plugins
get
plugins
dependency
is
not
directly
exposed
in
the
form
of
the
github
branch
source.
Plugin.
The
github
brand
source
plugin
contains
the
get
plugin
using
the
github
plugin
to
get
it.
It
comes
with
the
github
plugin
dependencies.
I
I
checked
the
dependency
graph
for
the
github
branch
source
plugin,
and
that
is
how
I
got
to
do
that
so
now.
A
My
problem
is
that
I
want
to
use
a
class
of
the
git
plugin,
which
is
not
available,
which
is
which
the
github
plugin
does
not
have,
because
it
is
depending
on
a
4.2.2
version
of
the
plugin,
and
so
my
my
concern
is
that
if
I
directly
add
the
git
plug-in
the
latest
version,
the
snapshot
version
I
have
to
the
pom.
It
creates
the
enforcer
issues,
upper
bound
dependency
issues,
and
so
I
was
not
able
to
solve
it
at
that
point.
For
so
I
did
a
very
bad
hack.
A
B
There
is
a
trick
used
inside
the
git
plug-in
where
it
has
an
optional
dependency.
On
some
other
plug-in
I
forget,
which
which
plug-in
it
is
that's
optional,
matrix,
matrix
plug-in,
maybe
and
inside
the
source
code.
It
does
a
dynamic
check
to
ask
if
an
api
is
available,
you
you
that
might
be
an
option
here,
at
least
short
term
that
you
can
use
reflection
to
ask.
Is
this
api
even
available?
B
A
C
Yeah,
what
I
suggested
is
is
probably
your
your
next
pr
you'll
have
to
change
it.
Anyways,
so
you'll
have
to
send
them
a
pr,
so
that
might
actually
work
out
well
for
your
local
testing
and
you'll
also
be
kind
of
like
testing
out
that
pr
as
well.
If
that
works
for
you,
perhaps
you
need
what
what
mark's
suggesting
to
you,
but
but
you'll
have
to
do
that
at
some
point.
A
A
A
B
I
would,
I
would
guess
personally,
that
the
gitlab
branch
source
plugin
is
probably
more
popular,
but
you
could
check
stats.jenkins.org
or
plugins.jenkins.io
to
see
here.
Actually,
I'm
just
going
to
do
it.
It's
easy
to
easy
to
ask
the
question:
how
many
installations
are.
There
are
there
of
the
giddy
plugin
okay,
there
are
1700.
B
A
A
C
A
Yes
agreed
a
great
justin,
that's
a
great
advice
and
I'll
do
that,
because
I
think
it's
it's
it's
best.
If
we
resolve
the
authentication
discussion
before
moving
on
to
other
brand
source
plugins,
because
if
we
do
not
and
then
we
have
to
change
the
get
tool
chooser
for
some
reason,
then
we
would
have
to
change
all
of
those
brand
source,
plugin
extension
implementations
as
well.
So
yes,
that's
that's
a
valid
point.