►
From YouTube: ☀️ GSoC CloudEvents plugin mentor meeting 2021.6.21
Description
Second week of GSoC coding phase!
Shruti Chaturvedi has pushed her implementation of a CloudEvents plugin for Jenkins here: https://github.com/jenkinsci/cloudevents-plugin
During this session we reviewed her work, especially from the point of view of a user -- what features do they need? how should this be configured in the Jenkins UI?
A
A
You
know
like
moving
things
or
removing
things
in
terms
of
you
know,
moving
a
code
to
a
function
in
itself
and
renaming
the
function,
but
there
was
one
interesting,
a
bit
which
I
really
liked,
and
it
was
about
this
public
class
endpoint,
so
one
endpoint
is
basically
do.
Oh,
it
was
doing
previously
was
I'll
switch.
A
Over
so
what
if
previously
was
doing,
is
it's
just
a
collection
of
you
know
the
sync
url,
where
the
event
will
be
sent
and
the
type
of
event,
which
is
you
know,
job
started
or
job
ended
and
queue
started
and
stuff
like
that,
and
then
it
had
the
send
method
in
here,
which
you
know.
I
remember
last
time
I
mentioned
the
meeting
that
this
is
not.
This
is
not
the
right
place
to
put
that
code,
and
I
do
want
to
move
it.
I
was
thinking
about
where
what
class
can
we
implement?
A
A
So
I
will
go
to
so
what
I
sort
of
thought
of
doing
was.
I
moved
endpoint
to
just
represent
the
sync
url
and
the
event,
because
the
endpoint
is
going
to
be
a
collection
of
you
know
the
sync
where
an
event
will
be
sent
to
and
the
event
type
itself,
so
a
user
can
go
into
the
ui
and
select
the
type
of
the
event
and
then
also
select
the
the
url
where
that
will
be
sent
to,
and
I
moved
where
is
it?
A
Okay?
Oh,
yes,
so
there's
this
sync
class
right
here
inside
of
http
sync,
which
is
so
there's
this
abstract
class
of
cloud
event.
Sync
and
this
basically,
what
it
can
do
is
allow
users
to
configure
different
kinds
of
sync
other
than
just
http
sync.
So
I
moved
the
method
of
sending
the
event
itself
to
this
http
sync
class.
A
A
I
think-
and
I
I
kind
of
want
to
change
it,
but
I
think
it
might
look
unclean
on
the
on
the
user
side.
So
right
now
it's
just
over
here.
You
know
so
a
person
can
choose
one
sync,
and
within
that
sync,
they
can
choose
the
the
end
points
and
the
events
that
they
want
to
send
to.
So
you
know
they
can
either
click
all
events
and
they
can
have
this
deleted
or
they
can
choose
a
specific
events
to
be
sent
to
specific
endpoints.
A
B
From
my
side,
I
think
that
this
looks
good
in
general.
What
I
tend
to
see
happening
is
that
people
will
want
to
send
multiple
events
to
the
same
sync
right,
so
it
should
be
easier
to
select
multiple
events
there.
When
you
have
event,
I
would
make
that
events
and
basically
an
array
of
events
that
are
going
to
be
sent
to
that
sync.
A
What
I
feel
is
that
it
will
allow
users
to
sort
of
have
modularity
over
the
kind
of
events
that
each
sync
receives,
so
that
particular
sync
is
just
configured
to
receive
like
job
created
events,
so
as
soon
as
it
receives
an
event
from
jenkins,
it
knows
that
it's
a
job
created
event,
so
it
knows
what
to
do
and
go
ahead
without
really
like
parsing
through
the
either
the
headers,
if
it's
a
binary,
structured
cloud
event
or
parsing
through
the
body.
If
it's
like
a
structured.
B
But
that's
the
thing
about
events
right
like
usually
you
what
you're
going
to
do
is
you're
going
to
send
it
to
a
broker
that
doesn't
know
exactly
who
is
going
to
consume
that
right
and
here
you're,
assuming
that
you
know
you're,
sending
it
to
an
end
point.
That
knows
what
event
is
supposed
to
receive
right.
So
I
think
that's
kinda,
like
the
difference
in
general,
I
would
say
you
are
sending
it
somewhere.
B
A
C
I
I
see
so
so.
Yes,
I
mean
the
the
I
I
agree
with
the
the
overall,
the
the
overall
feedback
that
this
could
to
to
do
add,
endpoint
and
then,
and
then
you
know,
enter
your
sync
url
and
then
select
the
event
if
you're,
if
you're
doing
lots
of
them,
that
would
get
kind
of
cumbersome.
I've
done
a
jelly
ui
like
that
before
and
it's
it's
not
fun
to
set
up.
C
C
I
mean
it
would
make
each
thing
kind
of
kind
of
kind
of
long,
but
you
could
then
you
could
see.
You
know.
You'd
have
a
check
box
for
all
events
that
you'd
have
a
checkbox
for,
in
fact,
in
fact,
you
could
have
have
a
checkbox
for
all
events,
that's
checked
initially
and
then,
when
you
uncheck
it,
then
you
see
the
other
ones
and
you
can
individually
check
them
and
then
so
you
see
them
all
right
there
you
can
see
which
ones
are
checked.
A
Yeah,
I
think
that's
a
really
good
idea.
I
think
that
might
be
a
better
configuration
and
mauricio.
Do
you
think
that,
having
like,
if
we
like
all
difference
between
that
all
events
and
sort
of
giving
the
users
the
ability
to
select
multiple
events,
you
know
for
the
the
configured
sync
like
you
know
what
you
were
saying
earlier,
that
it
should
be
the
job
of
the
sink,
to
sort
of
figure
out
what
they
want
to
do
with
the
events.
So
when
we
send
them
all
events,
they
have
complete.
B
Yeah
yeah
yeah
in
general.
I
would
say
that
the
sync
is
the
one
responsible
for
dealing
with
all
the
events
that
you
are
sending
right
like
and
even
to
reject
the
events
that
you're
sending
right
like
the
sync
can
be
configured
like
the
broker
can
be
confused
to
say
you
know.
I
want
to
filter
these
types
because
I'm
not
interested
in
in
some
of
those
types,
but
I
think
that,
like
my
point,
was
more
about
like
to
make
like
the
the.
C
C
I
I
do
think
that
there
could
be
value
in
in
being
able
to
to
select
which
events
you
you
send
to
the
sink
like,
for
instance,
I
might
only
be
interested
in
job
completed
and
job
failed,
and
my
sync
is
running
on
aws,
so
I
I
have
to
pay
more
money.
If,
if
I
process
a
lot
of
stuff-
and
I
I
maybe
maybe
don't
want
to
send
stuff-
I'm
not
going
to
process
so
that
that
that
does
seem
interesting.
Although
I
mean,
if
we
didn't
have
it,
people
would
probably
still
use
it.
C
B
A
Yeah,
I
can
actually
show
around
the
the
event
body
as
well,
and
also,
I
think
you
know
the
the
conversation
about
structured
versus
binary.
I
think,
for
you
know,
because
it's
being
sent
to
external
systems,
I
think
it's
a
better
idea
to
have
it
constructed
in
a
binary
manner,
because
that
way,
you
know
the
external
system
is
much
easier
to
figure
out
with
the
headers
what
they
want
to
do
going
through
the
body.
A
A
A
Oh,
oh,
yes,
it
might
have
not
received
the
job
field,
I'll
look
into
it,
but
this
is
sort
of
you
know
what
happens
when
all
the
events
are
going
to
go.
So
I
am
thinking
of
increasing
the
payload
in
terms
of
adding
more
information.
So
there's
also
going
to
be
information
about
the
user,
since
I'm
not
logged
in
right
now
and
seriously,
the
user
is
no,
but
but
yes,
the
payload
might
increase
when
there
are
artifacts
involved
when
there
are
parameters
inside
of
the
job.
A
B
So
something
something
maybe
not
for
now
but
to
to
keep
in
mind,
is
the
idea
that
maybe,
when
you're
sending
cloud
events
you
want
to
configure
you
know
these
things
and
the
events
kind
of
you
want
to
probably
decorate
the
events
with
some
extra
metadata
right.
Sometimes
you
want
to
add
something
to
the
cloud
event
as
an
extension
or
an
extra
field,
or
something
for,
for
example,
in
the
in
the
headers,
so
the
sync
can
do
filtering
based
on
that
right.
B
A
Do
you
see
my
yes
and
you
two
like
what
headers
are
the
other
ones,
so
yeah
the
id
is
using
uuid
right
now
so
yeah?
I
think
we
can
also
send
name,
but
I
I
what
I
the
reason.
I
think
I
didn't
do
it
because,
when
you're
sending
multiple
events
and
receiving
like
the
id
there's
several
events
with
the
same
id,
I
think
there
I
think
cloud
events.
B
I
think
that
the
id
is
fine
right,
like
the
id
needs
to
be
there
right,
like
you
need
to
have
an
id
for
the
event,
so
that's
perfect,
but
what
I
would
like
to
see,
for
example,
is
then,
if
you
can
get
the
job
name
from
collect
the
job
in
jenkins
and
then
send
that
because
then,
then
you
have
a
way
to
say
from
the
sync
side,
I
I'm
really
interested
in
the
you
know.
Job
builds
for
this
specific
job
name
and
not
for
all
the
jobs
that
you
can
have
in
jenkins.
A
Wow,
yes,
yes,
I
think
yeah
this.
That
makes
sense-
and
that's
also
you
know
one
of
the
benefit
of
using
just
like
a
binary
format
easier
to
look
for
information
here.
So
yes,
I
think,
that's
that's
a
really
good
idea
and
I'll
move
the
critical
information
which
identifies
that
particular
object
outside
from
the
body.
I
I
mean
in
the
body
as
well,
but
also
inside
of
others.
A
A
Yes,
like
sync
type
so
like
someone
has
to
be
the
tcp
sync
and
then
maybe
some
other
kinds
of
sync
and
they
wanted
to
so
at
once.
I
just
want
to
configure
all
those
three
things
like
I'm,
just
I'm,
maybe
just
thinking
of
would
the
user
need
to
configure
three
different
or
two
different
thing
types
at
the
same
time,
because
right
now
the
easier
option
on
like
for
jelly
to
me
was
just
having
a
simple
drop
down
and
I
can
choose
either
either
an
issue
to
be
saying
for
others.
Think
at
one
time,
like.
B
I
feel
that's
all
right,
yeah
yeah,
you
usually
want
to
configure
like,
but
because
the
syncs
are
going
to
have
all
different
configuration
parameters.
I
think
that
it's
good,
like
as
it
is
right
now
right
so,
depending
on
the
scene
type
you
are
going
to
be
able
you
need,
you
will
need
to
show
kind
of
like
different.
B
You
know
configurations
parameters
and
that's
what
I
think
that
at
the
end
of
the
day,
you
will
need
to
have
that
kind
of
like
structure
that
you
have
now,
okay
type
and
then
based
on
the
type
you
choose.
The
parameters
that
you
need
to
configure
right
like
let's
say
that
it's
a
message,
queue
or
something
like
that.
B
A
You
know
a
job
started
and
that's
sort
of
like
a
one
run
or
one
build.
I
think
I
should
name
it
maybe
handle
run,
but
I
then
because
at
that
time
build
made
more
sense
to
me
and
then
there's
handle
queue,
there's
handle
item
and
all
of
them
are
basically
in
the
same
class
and
they
also
are
using.
You
know
the
the
payload
inside
of
this
same,
like
class,
so
the
build
job
model
which
is
which
the
item
listener.
A
A
Oh-
and
this
is
okay,
well,
the
same
methods
but
with
different
parameters,
because
both
are
something
sort
of
different
and
then
there's
the
q
model,
which
is
basically
building
like
the
q
model,
and
I
I'm
going
to
be
adding
you
know
more
feels
to
it.
So
I
was
maybe
thinking
that
is.
Is
this
single
class?
A
The
you
know
should
instead
of
having
this
single
class,
maybe
if
I
can
move
into
you
know,
build
stage
for
cube,
will
stage
four
job,
like
you
know,
into
different
numerations,
and
that
way,
maybe
we
can
have
more
flexibility
in
in
terms
of
you
know
this.
This
particular,
for
example,
function.
It's
just
sort
of
it's
not
the
best
function
right
now.
A
But
if
I,
if
it
does
make
sense
to
you
guys,
do
you
think
that
instead
of
having
like
a
single
stage,
which
is
just
doing
the
work
for
all
the
listeners
of
sending
events-
and
you
know-
should
send
that
event
and
then
building
the
model
should
it
be
divided
into?
Maybe
you
know
different
stages
for
different
objects.
B
A
Yes,
this
is
so
I'm
just
having
like
a
different
enums
for,
like
you
know,
entered
waiting
and
it
left
is
basically
functionalities
for
a
queue
and
created
and
updated
our
functionalities
for
a
particular
like
job
itself
and
started
completed
and
finalizer
functionalities
for
a
run
of
a
job.
So
I'm
thinking
of
moving
this
to
a
different
email
and
then
this
to
a
different
enum
and
inside
of
the
listener
classes.
A
So
I
think
it's
simply
like
using
an
enum
is
simplifying
some
things,
but
I
still
want
to
split
this
enum
into
maybe
two
or
three
or
four
or
however
many
enums,
which,
however
many
different
listeners
but
another
another
implementation
would
be
just
putting
you
know,
more
sort
of
you
know.
Maybe
computer
added
you
know
and
then
I
would
have
another
sort
of
listener,
which
would
be
a
computer
listener
and
it
would
just
call
something
like
staged.
Computer
added
or
whatever
the
function
which
is
going
to
handle
that
I'm
just
going
to.
B
It
does
that.
Does
that
make
sense,
it
does
make
sense
to
me
yeah.
It
does
make
sense,
but
again
try
not
to
over
optimize
before
having
code.
I
think
that,
like,
like
you
mentioned
before
right,
like
when
you
see
like
that,
the
glass
and
the
enum
is
getting
too
big.
Then
it's
very
definitely
like
a
you
know
the
point
to
split
it
up
do
not
split
up
just
because
you
know
you,
you
think
that
it's
going
to
be
nicer.
A
A
Yeah,
yes,
that's
yeah,
maybe
I
was
basically
thinking
of
like
keeping
items
together.
You
know
so
items
in
terms
of
like
job
like
job
created,
updated
and
queue.
I
think
that
might
be
a
good
implementation,
since
there
is
some
similarity
between
the
event.
You
know,
parameters
and
stuff
like
that.
So
I
think
that's
what
I'm
going
to
probably
do.
A
Yeah,
so
in
in
terms
of
behavior,
it's
more
what
what
her
so,
okay
I'll
show
around
the
listener
classes,
and
just
so
here's
the
job
list
there,
which
is
over
like
three
different
parameters,
and
then
it
has
this
handle,
build
method.
So
the
and
then
there's
the
item,
listener,
which
is
sending
item
of
class
of
like
type
item
listener
from
listeners
and
then
there's
the
queue
listener,
which
is
basically
sending
item,
which
is
a
different
kind
of
item.
So
this
item
is
basically
like
a
queue
item.
A
So
when
I
go
on
to
the
edam
class,
you
know
I
have
these
methods.
So
there's
the
handle
item
and
this
one
is
for
a
job
created
in
java,
updated
and
then
there's
a
handle
queue
which
is
using
an
item.
But
it's
a
different
kind
of
item
and
what
this
is
basically
most
of
the
functionality
is
same
as
you
can
see
it's
just
going
through
all
the
like
the
for
loop
and
the.
A
If
and
the
try
straight
from
the
try
statement,
but
the
one
thing
is
like
that
building
of
the
payload
and
what
needs
to
be
put
inside
that
payload
is
also
you
know,
it's
different.
It's
all
happening
inside
of
this
particular
enum
and,
as
I
said,
it's
also
going
to
see
whether
or
not
a
particular
sink
is
configured
to
receive
that
kind
of
event.
A
A
A
So
I'm
just
thinking
because,
yes,
this
particular
element
does
have
its
benefit,
that
you
know
it
does
it's.
It's
like
pretty
similar
for
some
things
like
this
method
and
I
can
use
into
another
listener,
which
is
like
the
computer
listener
as
well.
I
had
looked
into
it,
but,
yes,
it
might
sort
of
make
the
class
really
big
and
might
complicate
the
process
because
then
I
have
to
if
I
go
back
to
jobless,
are
not
jobless.
A
A
C
So
one
thing
that
comes
to
mind-
and
this
is
just
a
suggestion-
and
it
I
haven't-
looked
at
the
code,
so
it
may
not
even
make
sense,
but
if,
if,
if,
if
you
had
an
like
an
interface
that
all
of
the
models
had
to
implement
and
one
of
the
methods
on
the
interface
was
something
like
get
get
type,
then
every
model
would
have
its
own
implementation
of
get
type
that
could
return
like
whatever
is
appropriate.
So
for
a
job.
It's
either
the
phase
or
the
status.
C
Where
for
a
queue,
it's
the
status
and
you
might.
If
you
did
something
like
that,
you
you
might
be
able
to
get
rid
of
some
of
these
if
checks
and
and
let
the
fact
that
it's
that
each
model
implements
the
get
type
function
handle
it.
I
I
don't
know
if
it
like
makes
the
code
simpler
or
or
more
difficult,
but
it's
just
just
something
to
consider.
A
Yeah,
no,
I
think
that's
a
really
good
idea
and
I
think
yeah,
that's
that's!
Maybe
what
I'm
going
to
do,
because,
even
with
you
know
all
of
these
sort
of
models,
yeah
like
like
there's,
also
some
sort
of
like
common
listeners
which
are
using
like
the
job
model
they're.
I
think
two
listeners
which
are
using
the
same
job
model.
So
just
having
that
you
know
so
one
of
them
has
like
a
created
update
and
the
other
one
is
using
updatedly.
A
A
A
So
right
now
I
have
two
tests
basically,
and
I'm
actually
not
sure
about
this
first
do
check
global
config.
I
I'm
not
sure
if
this
is
the
right
way
to
go,
but
but
I
read
earlier
now,
it's
like
okay,
I'm
going
to
check
if
it
works,
so
it
does
work
but
again.
So
this
is
what
this
is
doing
is
basically
checking
all
the
global
config
parameters
and
if
they're
setting
all
right
and
what
this
check
sync
url
is
doing-
is
basically
running
a
form
validation
on
the
sync
url.
A
So
you
know
it
shouldn't
be.
It
should
only
be
http
it
should.
It
should
not
be
like
no
for,
like
the
http
kind,
and
this
is
doing
the
checking,
for
you,
know
the
parameters
and
just
null
or
equal
and
stuff,
I'm
not
sure
again.
If
this
is
the
right
way
to
go,
but
I've
been
looking
into
other,
like
google
config
tests
and
seeing
how
they
have
implemented
it.
A
So
maybe
in
the
future
there
this
will
probably
would
have
changed,
but
this
would
have
probably
changed
and
then
there's
the
stage
test,
and
this
test
is
basically
checking
that
for
each
event
type,
I'm
only
sending
that
particular
event
and
no
other
event.
So
you
know,
as
I
was
showing
the
should
send.
Bolin
should
send
item
methods.
So
these
are
the
methods
which
sort
of
define
whether
or
not
that
particular
endpoint
is
configured
to
receive
that
sync.
A
A
Basically,
going
to
take
that
endpoint
is
going
to
take
that
that
stage,
which
is
the
enum
right
now
so,
for
example,
these
stages
left
and
I'm
only
requesting
entered
waiting.
So
this
is
going
to
be
false,
so
moving
back
here,
it's
not
going
to
send
that
method.
It's
just
going
to
resume
false.
This
also
works
and
again,
as
I
said,
I
need
to
make
it
more
simplified
in
terms
of
like
moving
it
into
its
different
tests.
A
Rather
than
like
one
big
test
and
right
now,
I
was
also
not
sure
what
other
tests
I
can
write
because
there's
not
like
there's
a
lot
of
functionality
in
terms
of
it's
all
combined
into
like
one
one
sort
of
thing:
there's
not
a
lot
of
like
different
things
that
are
happening.
There's
a
lot
of
one
kind
of
different
things.
That's
happening,
I'm
not
sure
what
other
events
I
can
or
should
or
like
tests
I
can
or
should
create,
and
if
you
guys
have
any
suggestions
or
comments,
I
would
love
to.
C
So
one
one
thing
that
I
often
do
is
is
enable
code
coverage
and
and
then
look
at
the
code
coverage
report
to
see
just
to
see
if
there's
any
any
areas
of
the
code
that
aren't
even
aren't
being
hit
at
all.
You
know
the
goal
is
maybe
not
to
have
some
x
percentage
of
code
coverage,
but
just
to
look
for
things
that
that
maybe
aren't
covered.
So
that's
one
idea.
A
A
C
Yeah
that
that
that's
exactly
right,
it's
for
the
user,
so
so
the
I
mean.
I
think
the
guidance
is
just
to
to
make
sure
that
it
works
with
with
configuration
as
code,
because
people
might
might
want
to
use
that
to
configure
it
and
most
plug-ins
do
out
of
the
box,
but
occasionally
you
you
may
have
to
do
something.
A
Right,
okay,
so
that's
okay!
That
was
another
question.
I
went
to
that
weird.
Yes,
this
one's
a
stupid
question,
but
I
tend
to
like
commit
or
send
like
full
requests
when
I
feel
that
this
code
is
working-
and
you
know
so
last
what
happened?
The
last
time
when
I
sent
the
pull
request
and
like
without
like
mentioned
some
changes,
and
then
I
went
into
those
changes
and
then
I
did
more
changes
and
that
led
to
me
waiting
until
you
know
it
was
working
sort
of
perfectly
for
the
code.
A
C
B
B
B
A
B
C
Yeah,
I
I
small
small
changes
are
easier
to
review
so
that
that
that
makes
sense
to
me.
I
I
I
would
like
now
that
you
have
kind
of
the
the
base
code,
too,
maybe
be
thinking
about
about
small
changes,
so
so
you're
pushing
a
small
change
for
us
to
review,
but
it's
working,
the
tests
are
passing,
but
when,
when
it's
approved,
you're
planning
on
on
merging
the
pull
requests,
so
there's
there's
kind
of
kind
of
two
to
two
times.
C
When
I
push
code
one
one
is
I
I
want
to
merge
it,
and
I
want
people
to
comment
on
it
but
but
but
as
as
I
said,
some
sometimes
you,
you
specifically
want
feedback,
and
it's
like
hey.
I'm
I'm
doing
this
approach,
curious.
What
people
think
about
it
and
then
so
I
might
push
that
and
make
it
a
draft
pull
request
and
just
kind
of
make
it
clear
in
the
comments.
I'm
I'm
looking
for
feedback,
maybe
even
on
a
specific
section
of
the
code,
so
people
can
target
that.
A
Yeah,
that's
a
really
good
idea.
I
think
the
you
know
the
draft
pr.
I
think
that
I
think
that
might
work
better,
because
right
now
there
are
kind
of
not
really
not
a
lot
of
changes,
but
the
last
pr
did
not
have
a
test
to
it
and
I
was
working
on
it,
but
now
it
does
so
this
pr
is
shouldn't,
be
a
draft
pier
but
I'll
push
it
just
so
you
guys
can
take
a
look
and
send
comments
and
any
if
anything
needs.
B
That's
looking
really
good,
I'm
super
happy
with
the
progress
so
yeah
keep
us
posted,
I
mean
if
you,
if
you
move
forward,
I
will
sing
with
biba
as
well
offline
to
see
you
know
if
he,
if
he
needs
help,
and
I
I
just
want
to
check
with
him
like
how
a
line
are
we
on
on
on
the
work
but
yeah.
I
think
it's
looking
really
really
good
and
can
you
please
send
me
yes
luck
or
yeah.
If
you
can
send
me
the
slack,
that
would
be
great
the
url.
A
B
D
A
Yes,
I
think,
and
so
the
jenkins
contributor
summit
is
coming
up
and
I
think
I
will
be
presenting
the
cloud
events
plug-in.
So
I
think
I
this
is
the
right
time
to
start
the
implementation
of
jenkins
as
a
sync.
So
I
think
the
next
three
to
four
days
is
going
to
be
looking
into
methods
and
modes
of
doing
that.
So
I
think
I'm
pretty
set
on
the
task
for
the
next
few
days.
For
the
week.