►
From YouTube: 2023 05 26 GitLab Plugin Modernization
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
Okay,
and-
and
so
so,
let's
look
at
so
what
I
saw
was
this
declaration?
That's
using
the
Jenkins,
API
wrapper
plug-in
and
it's
5.2.0.
It
will
remain
and
I
think
that's
actually
the
one
we
want
until
the
wrapper
is
ready
to
do
6.0.
That
was.
That
was
a
piece
that
that
I
was
ultimately
I
may
be
able
to
agree
that
we
will
eventually
get
to
6.0,
but
for
right
now.
A
C
Yeah
so
you're
right
on
this
point,
that
the
problem
is
the
the
pr
that
I
made
is
for
6.0.0.
So
when
the
release
will
be
cut,
then
we'll
be
using
the
6.0.0
version,
so
the
gitlab
API
has
to
be
updated
to
6.0.0.
So
that's
what
I
was
talking
about.
A
A
A
C
B
A
C
B
As
has
a
release,
candidate
been
published
from
gitlab
for
Jay,
or
are
you
still
waiting
for
them
to
publish
something
that
contains
your
changes?.
C
No,
it
has
not
been
published,
I
have
pin
pinged
the
maintain
it
over
there
and
I
hope
for
the
response.
It
will
take
time.
I
know
for
sure.
B
Okay,
as
soon
as
as
soon
as
as
soon
as
they
publish
something,
then
you
could
start
adapting
it
from
Jenkins
side
and
the
wrapper
plug-in,
but
if
it
takes
them
more
than
a
week
or
so
then
there's
an
alternative
which
is
for
you
to
deploy
a
snapshot
build
to
the
Jenkins,
artifactory
server
and
I
would
I
would
want
to
check
up
on
this.
The
next
time
we
meet
to
see,
if
there's
any
progress
or
not
so
there's
no
progress.
B
Upstream,
then
you
can
run
Maven,
deploy
with
some
special
arguments,
which
I
would
need
to
look
up
to
deploy
gitlab
for
Jay
against
our
Jenkins
artifactory
in
a
special
snapshot
area,
and
then
what
you
could
do
from
there
is
file
a
draft
pull
request
in
the
wrapper
plugin
to
consume
that
snapshot
and
then
that
that
draft
will
request
would
generate
an
incremental
build
because
all
Jenkins
plug-in
pull
requests,
create
incremental,
builds,
and
then
you
could
consume
that
incremental
build
from
the
gitlab
plugin.
B
So
there's
there's
a
way
for
there's
a
way
for
us
to
do
this
internally,
but
it's
a
lot
more
complicated.
So
if
we
can
just
wait
a
week
and
if
Upstream
is
responsive,
that
would
be
the
easier
method,
but
if
they
aren't
responsive,
then
we
shouldn't
block
ourselves
based
on
that.
A
No
but
harsh
in
terms
of
the
timing,
I
thought
that
there
were
an
awful
lot
of
other
things
that
you
could
be
doing,
that
don't
require
that
API
Edition.
You
did
for
6.0,
so
even
even
buzzles,
I
I
love,
basel's
energy,
that's
great
in
terms
of
a
week
or
two,
but
my
assumption
was
you
could
go
as
much
as
a
month
and
still
make
really
good
progress
without
requiring
the
6.0
release
of
gitlab
for
J
API.
B
I
mean
I
I
I
it
may.
We
may
have
other
things
to
do,
but
if
we
don't
start
testing
this
sooner
rather
than
later,
we
might
not
discover
problems
with
it
either.
That's
so.
B
B
Sooner
we
start
using
basically
the
sooner
we
start
eating
our
own
dog
food,
the
the
more
feedback
we're
gonna
get
so
yeah
I
mean
we
could
we
could
wait
a
month,
but
I
I
would
personally
not
wait
that
long,
but
either
way
it's
fine
with
me.
B
D
Yeah
guys
it's
like
kenosh,
do
it
or
do
we
have
to
do
a
Time
by
Snapchat.
B
Anyone
who
can
anyone
who
can
do
releases
of
Jenkins
plugins
can
publish
to
actually
no
now
that
I
think
about
it.
All
you
need
is
a
login
to
artifactory,
which
I
think
everyone
has
but
I.
Think
if
you
have
an
ldap
account,
whichever
one
with
anyone
with
a
jenkins.io
ldap
account
can
can
log
into
artifactory
and
after
you
log
in
for
the
first
time,
you'll
have
an
artifactory
account
and
once
you
have
an
artifactory
account,
you
can
publish
to
the
snapshots
area.
You
don't
need
any
specific
permissions
in
the
repository
permissions
updater.
B
It's
we
essentially
give
anyone
in
the
project
permissions
to
publish
to
that
snapshot
area
and
it's
it's
safe,
because
it's
not
consumed
by
any
production
builds
in
fact,
there's
a
lot
of
Maven
logic
to
prevent
snapshots
from
ever
being
used
in
a
production
build.
So
that's
why
everyone
has.
C
That's
all
about
the
test
that
you
were
talking
about.
You
can
actually
skip
that.
The
commit
status,
I
added
one
comment,
status
called
skipped
and
we
can
skip
that
test.
Instead,
that's
a
very
small
test
that
I'll
be
adding
so
I,
don't
think
so.
It
will
be
that
much
of
a
major
issue,
because
it's
the
small
part
of
a
course
it's
not
that
big.
A
Great
well
and
I
think
I
think
I
understand
basel's
point.
It
was
a
point
that
I
had
missed.
It's
the
sooner
we're
on
to
what
your,
what
you
believe,
your
final
destination
or
your
final
destination
is
a
version
6.0,
the
better
it
will
be
for
for
everybody,
so
that
that
also
has
the
benefit
that
you
become
the
the
leading
Tester.
The
leading
check
that
6.0
could
be
consumed
by
other
things
like
the
gitlab
branch
Source
or
the
gitlab
logo
plug-in.
So
so
it's
it's
a
benefit
to
the
project
as
a
whole.
C
So,
let's
get
to
the
second
thing
that
I
wanted
to
wanted
to
discuss
so
battle
suggested
that
we
implement
the
end
to
end
implementation
of
the
getla
plugin
first,
but
when
I
tried
doing
that,
the
plugin
is
the
plugins
code
is
so
tightly
bounded.
That
I
cannot
let
it
loose
like
when
I
try
to
implement
the
web
hook
listener,
then
I
have
to
change
all
others
other
than
push.
Also
like
merge
request,
also-
and
it
has
come,
it
is
getting
into
the
complete
migration.
So
I
cannot
really
establish
an
end-to-end
connection
like
vassal
set.
C
So
we
have
to
get
into
some
other
approach
for
this
that
I
discussed
with
Chris
like
how
are
you?
What
is
your
opinion
on
that,
because
we
wanted
to
like
we?
What
we
wanted
to
do
is
we
wanted
to
First
Implement
the
to
migrate
from
the
rest,
easy
to
gitlab4j,
while
taking
the
web
hook
thing
implemented
as
it
is
now
when
the
web
hook
thing
is
implemented
as
it
is
and
we
are
using
gitlab
4J
for
the
calls
the
plugins
the
plugins
should
still
work
now
after
that,
as
a
second
milestone.
C
B
C
B
Yeah
I
mean
that
that
sounds
fine
to
me.
The
proxy
thing
should
definitely
be
at
the
very
end,
because
that's.
D
C
This
order,
because
I
could
test
this
in
order
like
once
the
gitla
4J
resource
calls
are
being
used.
I
don't
need
to
Tender
account
with
the
web
hook
thing
and
I
can
test
all
of
that
after
then,
after
migrating,
the
webhoop
thing
also
I
can
test
the
complete
plugin
after
after
migrating.
The
proxy
settings
also
I
can
test
the
complete
plugin,
so
it
will
be
in
a
correct
order.
So
that's
why
I
chose
this
order.
A
C
C
And
the
first
two
things
we
won't
be
implementing
the
processing
I'll,
remove
them
and
at
the
last
I'll
explain
when
the
processing
and
we
can
test
the
complete
plugin
after
that.
Also
because,
if
I
implement
the
end-to-end
thing,
it
is
very
hard
to
test
it.
It's
really
hard.
I
cannot
test
that
so
I
am
trying
to
test
it
step
by
step.
C
A
C
A
So
my
usual
technique
is
I
run
the
code.
Look
at
it
in
a
debugger
watch
that
the
break
points
in
the
debugger
that
I
think
should
be
hit
or
hit
and
then
I
test
it
interactively
now.
I'm,
not
sure
any
of
those
things
are
dependent
on
how
how
you
submit
the
pull
request
did
I
did
I
answer
your
question,
hard
yeah.
C
A
That's
a
great
way
of
reviewing
actually
run
the
tests
in
a
debugger
with
break
points
and
watch
that
that
the
tests
are
hitting
the
code
where
I
think
it
should
Etc.
So
those
are
those
are
my
kind
of
techniques
and
check
interactively
so
others
may
have
better
techniques
and
I'm
happy
to
learn
from
other
people's
techniques.
B
Have
you
posted
anything
so
far,
or
is
it
just
what
you're
planning
to
do.
D
C
B
C
B
Concern
either
way,
yeah
and
you're
right,
I
mean
I.
Think
the
main
thing
that
I
would
want
to
see
as
a
Reviewer
is
some
sort
of
written
guidance
on
how
to
how
to
read
the
change
like
what
what
parts
this
is
going
to
be
a
huge
pull
request,
yeah
and
I.
You
know
I
assume
that
at
the
by
the
by
the
end
of
the
project,
we'll
find
things
that
we
could
split
off
and
merge
earlier.
B
B
So
if
you
can,
if
you
can
talk
about,
if
you
can
talk
about
the
the
major
parts
of
the
the
major
parts
of
the
change,
for
example,
you
know
start
by
reading
this
file,
which
is
the
first
part
of
the
execution
path.
And
then,
when
you're
done
reading
that
read
this
second
file,
which
is
you
know
the
next
thing,
because
you
know
when
you're
scrolling,
through,
like
dozens
of
files
and
hundreds
of
lines,
just
even
just
knowing
the
order
of
operations
to
read
the
code.
B
Changes
is
a
huge
help
but
yeah.
But
even
beyond
that,
the
you
know
the
reasoning
behind
each
one.
The
more
detail,
the
better
but
yeah
I
I
do
this
very
often
when
I,
when
I
submit
large
changes
for
others
to
review.
I'll
write
a
notes
for
reviewers
section
and
basically
just
tell
them.
You
know
what
order
to
to
read
everything
and
for.
C
C
What
can
I
do
is
I
can
comment
out
the
understanding
that
why
am
I
doing
this
instead
of
what
am
I
doing
like
when
I'm,
when
I'm
going
to
migrate
from
rest,
easy
to
gitlab
project
I
can
comment
out.
Let's
refer
these
links,
this
is
how
am
I
doing.
This
is
where
the
method
is
being
called.
This
is
where
the
method
is
being
written.
So
I
think
this
would
help
you
guys
a
lot
and
that's
a
really
great
idea,
because
yeah
I
understand
it.
It
is
difficult
to
actually
understand
the
code
base.
B
B
Harder
than
writing
it,
and
and
extrapolating
reasoning
after
the
fact
is
as
low
as
more
difficult
than
coming
up
with
the
reasoning
after
noticing,
a
problem.
A
Now
now,
in
terms
of
whether
or
not
the
pull
request
should
be
draft
I,
don't
for
me,
I
typically
treat
draft
pull
requests
as
though
probably
I
shouldn't
review,
but
I'm
perfectly
okay.
If
we
agree
as
a
group
that
we're
going
to
review
your
draft
pull
requests
and
you're.
Okay
with
that
I
I,
assume
you're.
Okay,
that
we
can
give
you
review
comments
anytime
and
you
you
won't
be
irritated
or
frustrated
at
us,
giving
review
comments.
B
Problem,
okay:
well,
if
there
are,
if
there
are
pieces
that
are
intentionally
admitted
or
incomplete,
you
could
just
mention
that
in
the
notes
and
say
you
know,
don't
bother
reviewing
this
file
right,
I
haven't
even
I,
haven't
even
really
thought
about
it.
Yet
and
it's
you
know
so,
there's
there's
nothing
wrong
with
posting
a
complete
change,
but
it
would
be
good
to
point
that
out.
So
we
don't
spend
too
much
time
scrutinizing
the
parts
that
are
incomplete.
C
D
D
C
So
one
of
the
action
items
that
I
also
have
is
to
create
a
uml
uml
schematic
diagram
for
the
webhook
implementation.
That
Chris
asked
so
I'll
have
a
session
with
frame
since
on
Saturday
when
he'll
be
teaching
me
about
this
because
I
don't
really
know
human
syntax
and
stuff
so
I'll
also
be
adding
it
in
the
project
plan
for
easier
understanding.
A
Great,
thank
you
yeah
now,
I
am
not
a
I,
am
not
a
unified
modeling
language
user,
so
I
apologize
if,
if
I
fail
to
use
the
correct
terminology
Etc,
but
the
the
act
of
diagramming
and
the
effort
to
draw
those
pictures,
oftentimes
is
the
thing
that
helps
you
think
most
clearly
about
what
you're
trying
to
do.
So
it's
not
that
the
diagram
is
so
important.
It's
rather
that
you're
doing
the
effort
to
get
to
the
diagram
is
the
thing
that's
so
valuable.
C
B
Yep
we
do.
We
want
to
create
a
a
project
Branch
for
this
to
get
the
basically
to
get
the
Prototype
to
get
to
get
the
prototype
in
a
state
where
it
can
be.
You
know,
tested
by
other
people
easily
or
do
we
want
to
use?
B
A
It's
a
good
question,
so
harsh
what
what
Basel
is
pointing
to
is
that
we
could.
If
we
were
to
create
a
separate
branch,
we
could
then
have
you
submit
pull
requests
to
that
separate
branch
and
CI
will
build
that
separate,
Branch
independent
of
Master,
so
we're
not
disturbing
the
master
branch
and
and
we've
then
got
incremental
artifacts
that
we
can.
Then
you
run
for
to
run
tests
against.
We
can
experiment
with
it
gives
us
a
staging
area
before
emerge
to
master.
C
C
B
Yeah
I
mean
I
think
the
advantage
to
doing
project
branches
that
you
can
then
open
up,
multiple
or
quests
into
that
project,
Branch
to
describe
different
different
work
that
you're
doing
that
may
not
be
ready
to
commit
to
the
main
branch.
B
Don't
have
a
project
range,
then
your
single
Mega,
pull
request
would
basically
become
the
project
branch
and
any
changes
that
you
make
would
have
to
be
discussed
in
a
single
pull
request
rather
than
in
multiple
pull
requests.
B
So
yeah
yeah
when
I
wrote
the
point
that
the
pull
request
becomes
the
project
Branch
I'm,
using
project
grants
in
in.
B
B
B
It
compiles,
you
know
we
wouldn't
we
wouldn't
need.
You
know
any
guarantees
like
we
do
on
the
main
branch
that
it
actually
works,
or
that
it's
releasable
or
anything
like
that
or
that
the
tests
are
passing
it
just
says.
Simply
you
know
we
could
even
we
could
even
turn
off
the
tests
on
the
project
Branch
by
setting
you
know,
Maven
configuration
so
that
it
it
doesn't.
Even
you
know,
bother
running
them.
B
You
know
and
then
that
you
know
that
project
Branch
with
the
tests
disabled
could
be.
You
know
something
that
we
slowly
get
to
a
state
where
it
works,
not
just
compiles
but
actually
works,
and
that
can
be
done
in
separate
pull
requests
as
you,
you.
B
C
B
I
mean
I
think
we
could.
We
could
re-enable
the
tests
on
the
project
range
after
the
main
code
is
working
end
to
end
yeah,
and
at
that
point,
when
we
see
when
we
see
failures,
we'll
know
for
sure
that
they're
because
of
test
issues
rather
than
because
of
production
issues
right
now,
either
way.
But
we
would
suspect
that
the
test
test
issues
and
production
issues.
C
B
So
yeah
yeah
I
would
just
whoever
creates
the
project
Branch
if
they
could,
if
they
could
also
push
a
push.
A
first
commit
to
it
to
turn
off
the
test
or
I
could
even
do
that
if
needed.
B
Know
Skip
tests
as
a
maven
property,
okay,
and
that
would
that
would
mean
that
our
our
standard
for
integration
to
this
branch
is
just
that
it
compiles
so
pretty
low
standard,
but
at
the
same
time
that
would
allow
us
to
file
smaller
pull
requests
against
that
project
branch
and
as
long
as
they
compile
you
know,
we
could
approve
them
and
go
through
a
relatively
normal
code
review
process
rather
than
just
having
this
very
long-lived.
Mega
pull
request.
A
That'd
be
great
thanks,
Chris
for
your
willingness,
so
I
assume
one
of
the
one
of
the
responsibilities
will
have
during
this
project,
then,
is
when
changes
merge
to
the
master
Branch.
We
want
to
keep
the
project
Branch
current
with
it.
So
we'll
merge
outward
to
the
project,
branch
and
harsh
I
assume
you
do
that
or
Chris
or
I
can
do
that
anybody
who's
a
maintainer
can
do
it,
but
you
can
even
submit
pull
requests
proposing
it.
B
Okay,
I
could
create
a
GitHub
action
to
automatically
create
PRS
to
do
merges.
Okay,.