►
From YouTube: GSoC 2021 Git credentials binding 2021 07 06
Description
Google Summer of Code 2021 project mentoring session for the Git Credentials Binding project. Topics included moving the implementation from the git client plugin to the git plugin and how to handle OpenSSH format private keys in Jenkins.
A
A
A
D
A
A
B
A
A
C
A
A
C
D
A
A
A
A
A
B
B
B
So,
at
the
time
when
I
was
investigating
the
get
to
resolution,
actually
harshit
raised
a
a
good
point
yesterday,
which
I
actually
failed
to
notice.
While
I
was
doing
the
investigation
that
there
is
a
there's,
a
principal
difference
between
the
context
of
the
binding
and
what
I
was
saying
in
the
git
plugin.
B
So
at
the
git
plugin
level,
the
git
tool
resolution
depends
upon
a
name,
and
that
is
the
user's
choice
or
the
default
installation.
It
could
be
anything,
but
then
there
is
a
name
which
is
passed
to
the
resolution
and
and
in
harshit's
case,
what
we
have
is
the
run
context.
That
is
the
context
we
have
and
that's
it
right.
We
don't
have
anything
else,
except
that
we
don't
have
the
name
of
the
git
tool.
So
if
we
cannot
so,
I
have
not
have
not
actually
looked
at
the
run.
B
C
B
B
B
B
A
B
A
Well,
well,
you
have
the
option
of
giving
a
get
tool
and
if
you
don't
give
the
get
tool,
it's
assumed
it
will
take
default
or
it's
assumed
it
will
take
the
first
in
your
in
your
selection.
So
if,
if
the
global
configuration
lists
command
line
get
first,
it
will
choose
that
if
the
global
configuration
lists
jgit
first,
it
will
choose
that,
but
was
that.
Was
that
answering
your
question
richard.
B
Yes,
mark
I
just
I
I
was
I
wanted
to
ask
that
question,
because
I
I
was
just
thinking
if
the
you
should
be
place,
that
responsibility
to
a
user
who
knows
but
then
sense
that
that
is
already
something
that
is
an
expectation
from
a
user.
It's
optional,
it
doesn't
it's
not
a
mandatory
requirement,
but
it's
optional,
but
then
we
can
extend
the
same
thing
in
this
binding
context
as
well
right.
B
A
C
A
And
I
think
that
that
should
be
the
default
mode
right.
I
think
we
should
absolutely
make
git
tool
entirely
optional.
So
if
we
were
going
to
add
git
tool,
it
should
be
optional.
I
don't
know
that
we
need
to
add
it,
but
if
we
were
going
to
it
should
for
sure
be
optional,
because
we
don't
want
them
to
think
about
it
in
the
main
case,
where
they've
only
got
command
line
git,
they
say
I'll,
take
command
line,
get
whatever
I've
got.
B
C
C
Yeah,
in
both
the
case,
it's
similar
to
the
git
resolve
on,
but
the
git
resolve
can
traverse
the
whole
list
because
it
is
name
specific
rather
than
type
specific.
So
if
the
name
is
in
the
last
but
yeah
it,
the
difference
come
to
the
same
like
if
the
both
the
tools
are
in
the
logic
tools
are
placed
in
the
last,
so
they
will
have
to
traverse
all
the
lists
since
it.
You
know
it's
a
linear
complexity,
so
the
difference
is
same.
I
think,
in
the
complexity
case
of
both
the
implementations.
B
The
only
problem
I
think
that
would
have
is
that
for
each
installation,
you're
trying
to
find
it's
going
to
in
actually
install
it
for
a
node
which,
which
is
the
problem
which
I
have
seen
with
the
git,
and
so
I
also
had
a
same
similar
situation
in
git
to
choose
a
it's.
It's
a
class
I
created
last
on
my
project
and
I
had
to
decide.
B
B
So
my
question
is
that
so
you
think
that
we
should
not
tell
the
use
we.
The
usual
user
should
not
be
concerned
with
it
and
we
should
be
able
to
get
it,
but
then
let's
say
we
have
the
binding
and
in
a
pipeline
we
are
going
to
do.
We
run
the
risk
of
doing
this
twice
because
at
the
scm
level,
resolved
get
2
will
try
to
find
a
tool,
and
then
we
are
going
to
do
the
same
thing
after
that.
C
C
B
B
C
That
I
have,
in
my
mind,
is
so
if,
in
a
freestyle
job,
we
are
performing
a
git
checkout,
so
it
will
use
the
git
resolve
tool
to
find
the
tool
get
a
good
tool.
Right
and
after
that,
when
we
are
performing
the
using
our
my
binding
in
the
batch
script.
So
we
are
performing
again
that
thing,
but
using
a
type
specific
implementation
of
the
same.
B
C
B
B
B
A
But
but
again
I'm
okay.
If
we
say
no,
we've
decided
against
that
there's.
We
need
to
do
some
more
work
for
me.
I've,
for
instance,
I'm
not
ready
to
release
the
current
username
password
because
freestyle
projects
still
don't
work
for
me,
and
I
I
don't
know,
don't
work
for
mark-
and
I
haven't
had
the
time
yet
to
to
understand
why,
because
they
do
work
for
for
harshit.
A
Yes,
we
do
actually,
at
least
for
I
think
we
have
an
automated
test
case
for
freestyle.
We
don't
have
a
pipeline
automated
test,
but
we
know
how
to
write
one.
There
are
pipeline
automated
tests
that
would
illustrate
it
in
the
git
plugin.
So
we
and
I
I
can't
explain
why
it
fails
in
my
in
my
installation
but
works
in
the
automated
test.
B
Okay,
I
think
we
we
have
some
time.
You
know
explore
that,
explore
the
options,
so
the
user's
option
is,
I
think,
right
now.
What
is
the
most
plausible
direction
we
could
take?
I
just
want
to
also
see
if
the
context
which
is
being
provided
in
the
binding
is
something
which
we
can
use
to
get
it,
because
user
has
already
chosen
the
git
tool
once
can
we
use
that
information?
If
you?
If
not,
then
I
think
the
cleaner
approach
is
to
ask
the
user
only
and
then
have.
D
C
D
A
Yeah
and-
and
I
would
guess
resolving
twice-
is
still
much
much
cheaper
time,
wise
than
any
get
command
line.
Git
operation
right
even
to
the
local
disk,
because
resolving
the
s
resolving
get
tool
is
just
java
code
in
memory,
whereas
as
soon
as
we
call
command
line,
git
we're
forking
a
process
and
talking
to
disk
drives,
and
so
I
I'm
not
I'm
actually
not
overly
worried.
If
we
we
end
up
resolving
the
git
tool
twice,
I
the
performance
impact
will
be
below
our
ability
to
detect
it.
A
Now,
if,
if
if
it
does
do
an
unpack-
and
there
are
many
tools
defined,
that
would
be
different
right
and
reshab.
I
think
that
was
what
you
were
saying
is
that
the
resolve
get
tool
when
we,
when
we
were
working
with
it
last
year,
we
have
a
scenario
where
we
were
actually
installing
the
tool
multiple
times
in
order
to
resolve
it.
A
A
B
A
A
A
C
A
C
A
It
is
get
2.7.
I
think,
on
my
ubuntu
18
with
custom
installation.
It's
get
2.32
on
windows,
it's
get
2.32,
and
so
in
that
case
I
get
version.
I
wouldn't
know
how
to
answer
the
answer
that
value,
because
the
same
job
could
execute
on
any
one
of
these,
and
I
don't
know
which
one
of
them
it's
going
to
execute
on.
A
A
A
C
A
Okay,
so
see,
let
me
get
include
a
link
here
so
that
you
know
how
to
do
that,
so
that
you're
you're
not
blocked
waiting
for
a
release
of
the
get
client
plug-in.
Let
me
find
that
jenkins
use
incrementals
incremental
in
development,
incremental
incrementals,
developing
components
in
parallel.
Here
we
go.
A
A
A
There
we
go
so
that
hyperlink
will
help
you.
The
page
looks
like
this
developing
components
in
parallel,
creating
a
pull
request,
obtaining
the
version,
number
etc
and
then,
instead
of
jenkins.version,
you
would
put
that
version
in
the
get
client
section
of
the
of
the
git
client
dependency
inside
the
git
plugins
palm.xml.
A
A
A
A
A
C
C
C
No,
they
have
not
using
the
bouncy
class
label,
they
have
created
their
own
implementation
from
the
scratch.
I
think
so.
Bouncy
castle
apis
the
class
they
used
in
bouncy
castle
app.
I
have
a
limited
scope
there,
so
they
don't
have
use
that
they
have
created
their
own
implementation
from
scratch.
From
what
I
have
seen.
A
A
C
A
C
A
Because,
because
that
certainly
is
also
very
valuable,
if
we've
got
time
available
and
you
could
submit
to
them
all
the
better,
I
wouldn't
attempt
to
put
it
inside
the
bouncy
castle
api
plug-in.
I
would
rather
just
ask
them
to
include
it
in
bouncy
castle
itself.
If
you've
got
if
it
turns
out,
we
have
capacity
for
you
to
write
that
code.
That
would
be
great.
It
would
be
really
cool
for
a
google
summer
of
code
project
to
submit
something
to
bouncy.