►
From YouTube: ☀️ GSoC CloudEvents plugin mentor meeting 2021.6.14
Description
First week of GSoC coding phase! Shruti demoed an initial implementation of CloudEvents plugin for Jenkins.
Awesome work already! 👑
C
A
So
I
have
like,
I
have
duncan's
running
right
now,
and
these
were
jobs
which,
like
I,
created
just
like
test
jobs.
So
right
now,
what's
you
know
for
the
the
things
what
it's
doing?
This
is
basically
like
jenkins
as
a
source,
so
we
figured
that
we'd
start
working
with
junctions
as
a
source
first
and
then,
once
we
have
a
bit
of
like
more
clear
idea
of
getting
events
and
stuff,
we
can
move
into
configuring.
A
A
I
I
also
have
a
server
running,
which
is
just
a
simple
http
server,
and
this
particular
one
does
not
like
it's
not
parsing
cloud
events
data,
but
we
are
sending
over
cloud
events
data
and
it's
like
able
to
look
into
headers.
I
also
have
a
server
which
is
able
to
like
look
through
cloud
events,
data
and
then
sort
of
send
back
a
response
in
that
format.
But
it's
not
running
right
now
and
the
events
the
last
we
talked.
We
were
we.
A
You
know
we
talked
about
starting
off
with
events
which
are
more
sort
of
used.
So
in
terms
of
like
a
job,
we'd
say
like
a
job
has
started,
a
job
is
completed
and
if
the
next
step
of
the
job
like
the
last,
what's
it
called
the
artifact
is
built.
So
we
can
choose
what
events
we
want
and
maybe
all
of
these
events-
I'm
just
maybe
gonna-
do
job
start
it
and
also
add
another
endpoint.
B
B
B
B
A
A
So
this
is,
you
know
this
is
like
setting
up
setting
up
like
we
want
to
send
a
json
object,
which
is
like
in
in
in
a
byte
like
like
a
byte
array
which
is
being
configured
here.
So
this
is
like
the
cloud
event
which
we
want
to
send
and
going
back
to
job
listener
or
stage
so
we're.
So
this
is
basically
like
an
enum
and
it
has
the
the
three
stages,
which
is
like
a
job.
A
So
this
is
sort
of
the
payload
that
we're
gonna
get,
and
since
this
is
configured
first
started,
that's
why
it's
getting
all
the
started.
I
can
also
go
and
add
another
event,
and
I
want
to
get
events
every
job
failed
job
started.
So
all
of
the
events.
Basically,
so
that's
that's
jenkins,
I'll
I'll
move
into
the
code
and
how
it's
figured
and
it
it
uses.
A
It
uses
listener
implementation
and
right
now
you
know
there's
the
abstraction
that
we
were
talking
about.
I
I
don't
think
I
was
completely
able
to
understand
where
exactly
we
might
need
that
sort
of
that
sort
of
implementation,
because
you
know,
since
all
of
these
are
like,
if
this
is,
for
example,
a
run
listener
which
is
basically
just
notifying
for
run
and
then
there's
item
listener
or
job
listener.
You
know.
So
what
so?
This
is
essentially
like.
A
We
want
them
overwritten
or
maybe
not
whatever
our
circumstance
looks
like,
but
when
we
talk
about
abstraction
the
thing
that
I'm
sort
of
thinking
is,
I
I
don't
feel
that
there's
anything
which
is
really
common
between
these
implementations,
so
we
can
like
pull,
maybe
some
constant
fields
out,
for
example,
job
name
or
and
then
put
that
into
like,
like
like
an
interface
instead
of
like
an
abstract
class
and
then
just
first
figure
out.
What's
common,
what
sort
of
extra
methods
can
we
add?
A
A
So
so
yeah
so
right
now
it's
just
using
a
job
listener
here
and
it's
just
extending
the
listener,
which
is
the
the
enumerations
which
we
were
looking
at
earlier
and
then
there's
a
build
model
and
job
model,
but
just
gets
information.
You
know
url
the
current
id
and
stuff
and
the
cloud
event
message.
Writer
is
what's
needed
for
cloud
event
and
it's
using
one
of
the
cloud
event.
A
I
have
independency
to
write
any
you
know
like
each
and
write
into
http
and
send
it
over
as
an
http
request,
and
then
this
is
the
end
point,
which
is
some
sort
of
some
configuration,
that's
needed
for
the
jelly
file
and
also
some
configuration
that's
needed
to
send,
and
I
need
to
refracted
this
out
like
the
send
to
some
better
class
or
something.
I
don't
think
that
this
is
the
right
place.
To
put
it
and
the
stage
is
the
renaulting.
B
C
D
A
A
F
E
F
D
A
So
like
looking
into
this
like
endpoint
file,
I
like
like
right
now,
I
real
I'm
realizing
that
I
hardcoded
it
there
in
the
endpoint
class,
which
basically
is
configured
for
you
know
it
has
the
sync
url
and
it
has
the
event,
whichever
that
event
is
configured
to
be
received
like
so.
If
I
go
into
the
the
jelly
file.
A
D
D
B
A
D
D
A
A
A
An
item
listener
is
completely
different
and
all
of
them
share
different
information.
So
I
don't
like
there's
not
a
lot
of
common
information.
Besides,
you
know
the
name
of
the
job,
the
description
and
stuff.
So
I
like,
I
want
to
hear
your
guys's
idea
on
how
or
where
can
we
leverage,
just
maybe
using
interfaces
and
like
putting
common
methods
or
just
like
if
there
are
variables
which
other
listener
classes
that
can
improve
functionality
and
other
listener
classes
can
use.
D
D
It
might
be
that
that
it's
not
and
but
I
just
wanted
you
to
be
to
be
thinking
about
it-
I
don't
have
anything
specific,
but
when,
when
I
start
looking
at
the
code,
if
anything
pops
up,
we
can
we
I'll
I'll,
bring
it
up
and
we
can
talk
about
it.
But
yeah.
If
you
don't
see
anything
common,
don't
don't
go
create
abstractions.
Just
just
because,
because
of
that,
that
comment-
and
I
think
like
like
properties,
are
less
interesting
on
on
an
interface.
I
mean
it's
to
me.
D
A
Yeah,
I
think
I
was
just
like
still.
You
know.
I
have
sort
of
figures
on
my
notepad
just
trying
to
understand
where
you
know
where's,
that
commonality
that
we
can
create
and
leverage
abstraction,
because
it
is
a
really
great
idea
to
you
know
like
have
that
implemented
through
an
abstraction
and
have
different
listener.
A
Implementations
like
leverage
that
and
but
I
don't
know
if
I
necessarily
am
able
to
understand
it
yet,
but
I'm
still
working
on
it
and
also
on
extending
other
plug-ins,
though
it
was
something
that
I
was
trying
a
bit
earlier.
But
again,
as
I
said,
you
know
if
I
this,
if
I
am
to
extend
a
plug-in,
that
would
mean
that
I'm
delegating
the
task
of
having
that,
like
that
event,
payload
and
being
sent
over
to
my
or
like
to
this
cloud
event
plugin.
A
So
so
it's
it's
sort
of
tricky
because
you
know
for
if
we
consider
github
on
the
status
plugin.
For
example,
it
has
those
listener
implementations
and
that's
when
it
gets
data
right.
So
if
there's
a
list
location
for
run
listener
and
run
listener
on
start
it,
which
is
already
sort
of
like
a
method
that
it's
overriding
so
as
that
as
the
run
has
started,
and
I'm
like
I'm
again
extending
that
plug-in
and
as
a
running
so
started.
A
I
want
the
github
auto
status,
plug-in
to
send
my
plug-in
that
event
data
and
I
will
send
it
to
the
the
sync.
But
so
do
you
like?
Do
you
kind
of
see
the
it
will
that
con?
This
is
a
sort
of
different
overridden
unstarted
methods,
because
your
plugin
has
an
onstart
which
needs
to
be
implemented
for
to
send
me
the
event
details,
and
then
it's
just
a
bit.
A
So
it's,
I
think
it's
if
that
makes
sense.
I'm
not
I'm
not
really
sure
if
I'm
making
sense
right
now,
but
but
okay,
I
what
I'll
do
is
sort
of
create
a
diagram
of
what
I'm
trying
to
say
and
then
I'll
send
it
over
to
you
as
well.
So
it
makes
it
more
sense,
but
I
just
think
that
it
it.
It
will
over
complicate
this
process,
because
what?
If
what
we
only
need
to
do
is
you
know,
get
implementation
as
soon
as
we
run
as
it
started.
A
D
D
I
I
hate
to
see
you
spending
time
on
something
I
mean.
My
comment
was
more.
You
know
spent
some
time
thinking
about
this
and
then
and
you've
done
that,
and-
and
I
mean
I
I
can
see
that
you-
you
know
you're
capable
and
you're
smart,
and
I
I
trust
you
so
I
I
don't
I
don't.
I
don't
want
you
to
be
spending
time
worrying
about
convincing
me.
I'm
good.
A
No,
I
think
it
was.
It
was
a
good.
It
was
like
a
good
place
for
me
to
think,
because
I
was
just
like
that
can
also
be
a
way
we
can
do
it.
You
know
like
if
I
just
had
it
hand
it
over
to
me,
wouldn't
have
been
as
fun.
I
think,
even
if
it
were
just
like
jelly
files,
as
I
was
talking
about
earlier,
it
wouldn't
have
been
fun.
A
If
you
know
the
jelly
fat
was
just
like
there,
so
it
was
kind
of
fun
to
figure
it
out,
and
I
was
also
trying
to
extend
like
plugins
in
this
particular
plugin
and
seeing
if
or
how
does
particularly
the
ones
with
listener
implementation,
because
that's
sort
of
the
thing
that
we
want
to
do
also.
You
know
the
listener
implementation
on
started,
they're,
basically
like
non-returning
methods,
so
those
methods
don't
return.
Anything
that's
what
we
want
to
do
is
like
as
something
as
a
started.
A
One
and
return
something
to
another
thing
to
you
know
get
basically
an
event
out
of
it.
So
it's
yeah.
I
think
we
might
have
to
go
with
a
single
listener
implementation
and
then,
maybe,
like
you
know,
different
listeners
of
course,
which
well,
which
is
also
like
sort
of
my
another
question
about
listeners
itself
right
now.
A
What
what
I
had
was
a
run
listener
and
it
it'll
be
simply,
I
think,
very
easily
extended
to
an
item
listener
and
queue
listener,
but
kara-
and
I
we
were
talking
last
time
about
having
like
computer
listener,
which
is,
if
a
note
is
online
or
offline.
Oh
also,
it
does
also
work
on
scalable
systems,
so
the
node
that
I
was
talking
about
earlier,
like
that
the
agent
node,
which
was
offline,
I
tested
and
made
sure
that
it
works
on.
A
You
know
if
there's
like
a
distributed
system,
and
so
so
it
was,
it
was
working,
but
in
terms
of
sending
events
like
this
is
this
job
was
completed
by
so
and
so
agent
or
this
job
or
like
this
agent,
is
offline.
So
trigger
this
event,
so
you
know
that's
also
do
we
do
we
want
to
also
have
events
about
computers
or
just
executors
and
agents,
or
do
we
just
stay
through
the
generic,
like
jobs
and
cues
and
files
and
folders?
Maybe
change
of.
B
D
D
So,
whether
I
so
so
I
mean
the
the
the
short
answer
is
that
I
I
think
that
events
about
agents
will
be
useful.
In
fact,
we
were
having
problems
with
some
of
our
agents
at
one
point
and
I
created
a
plug-in
just
to
to
write
the
name
of
the
agent
just
so
we
could
track
because
we
suspected
that
some
of
them
weren't
working,
but
so
the
the
long
answer
is,
does
does
it
fit
within
within
your
project.
And
so
that's
that's
what
we
have
to
decide.
B
E
E
A
D
D
D
E
D
A
So
when,
if
we
are
to
add
more
events
in
terms
of
going
on
to
other
listeners
like
you
and
computer
listener,
I
think
the
list
will
either
just
have
to
grow,
or
maybe
we
can
say
something
like
this
is
a
build
like
over.
Here
we
can
say
something
like
build
endpoint
and
something
like
that
and
then
particular
ones.
B
E
A
D
E
D
I
did
have
a.
I
did,
have
a
thought
about
this
too.
I
want
to
know
what
other
people
think
again.
I
mean
I
don't
want
to
muddy
the
waters
too
much,
but
if
there
ends
up
being
a
lot
of
settings,
you
can
actually
create
your
own
setting
applet
for
the
plugin
so
rather
than
having
it
in
jenkins
system.
D
Yeah,
you
could
have
your
own
settings
app
and-
and
I
mean
like
with
with
the
I
didn't
know
this,
but
with
the
auto
status
plug-in
right.
So
I
just
add
it
to
the
the
config
that
has
like
lots
and
lots
of
settings
and
it's
just
polluted.
You
can
have
like
your
own
separate
settings
applet
and
I
don't
think
it
has
to
be
jelly
either.
A
E
D
A
And
also
completely
gave
up
the
idea
of
using
stapler
because,
as
I
said
last
time,
it's
like
with
the
binding
that
we
like
the
binding
with
url
like
object,
url
binding,
and
I
think
that
we
are
going
to
need
that
here,
it's
more
yeah.
We
we
might
need
it
for
when
we're
configuring
a
sync
since
you
know
we'll
need
a
url
to
to
to
be
configured
to
receive
catalans
and
but
not
not
for
powerful
swords.
E
A
D
E
D
E
A
G
A
G
G
A
E
E
A
Yeah
now
I
think
there
is
a
repeatable
for
the
event
phone
like
itself
to
event
or
no.
It
would
not
event
for
the
end
points,
so
the
endpoint
is
basically
like
a
java
class,
and
I
have
a
repeatable
for
the
java
class
and
event
like
the
end
point
has
the
sync
url
and
the
event
where
it
needs
like
where
a
particular,
wherever,
whatever
event
we
want
to
be
sent
to
the
youth.
So
that's
what
I
have
remember
you're,
suggesting
that.
A
I
kept
it
like
this
or
like
the
reason
like
I
feel
like
this
might
be
more.
You
know,
modular
in
the
sense
that
a
particular
sink
is
only
receiving
the
particular
event
that
it's
configured
for,
and
I
think
that's.
If
we,
if
you're
looking
at
ada
just
patterns
in
general,
you
know
you
you.
You
think
that,
for
example,
if
you're
like
looking
at
terraform
or
just
maybe
something
like
infrastructure
as
code-
and
you
know
as
a
it
receives,
a
single
event
of
a
type
node
has
failed.
A
What
advantage
and
like
with
with
the
statistics,
gather
plugin?
I
think
it
was
like
the
ui
with
school,
but
it
was
sending
all
of
the
events
together
and
for
everything
that's
happening
inside.
A
queue
gets
sent
to
a,
but
I
but
again
it's
it
was
for
a
different
purpose.
The
purpose
here
is
different
than
the
purpose.
It
was
there,
but
I
think
yeah
we
can.
We
can
also
try
how
that
might
work
in
ui
and
also
in
inside
code.
E
I
think
that
makes
sense
I
think,
for
now
we
keep
it
this
way
and
yeah.
It
does
make
sense
like
to
have
a
endpoint
which,
which
might
be
configured
to
receive
certain
kind
of
events
like
in
this
case
you're,
given
like
job
created
or
like
job
or
job
related
events.
So
if
that
endpoint
is
configured
for
that,
then
it
makes
sense
to
kind
of
make
it.
D
E
D
E
G
E
A
So
the
next,
so
the
first
thing
is
obviously
extending
this,
but
that's
not
going
to
be
super
like
troublesome
or
of
you
know
something
that's
going
to
take
a
lot
of
time,
but
the
next
next
big
thing
I'm
looking
at
is
sync
implementation
and
I'm
looking
at
extension,
points
for
like
webhook
like
plugins
and
obviously
start
with.
There's
the
generic
trigger
plugin
and
all
all
or
most,
I
would
say,
are
like
extension
points
for
actions
since
it
gets
tied
to
a
url.
A
So
I
just
have
to
understand
that
better
to
sort
of
just
make
just
see
how
the
entire
infrastructure
and
the
entire
system
is
going
to
work
when
jenkins
is
configured
as
a
sync,
especially
because
the
events
that
we're
receiving
will
not
just
be
specific
to
a
job,
but
they
can
also
be
specific
to
say
a
node
or,
like
you
know,
because
I
think
I
was
looking
at
that
and
node
is
also
an
model
object.
I
think
so.
A
A
But
like
just
events
which
might
tie
into
that
node,
for
example,
some
event
has
been
received
and
we
want
to
scale
up
our
nodes
and
we
want
to
delete
or
do
something
with
our
with
our
current
system
or
agents
and
stuff.
So
that's
sort
of
the
thing
to
just
understand
the
implementation
of
sync
and
how?
A
A
Yes,
I
do,
and
we
were
talking
about
it
earlier
and
jeff
and
rohit
mentioned
that
it
would
be
nice
if
I
like,
if
the
code
is
on
on
github,
so
you
guys
can
look
and
comment.
So
I'm
just
going
to
do
some
cleanup
because
you
know
my
log
right
now:
it's
not
like
a
debugger
log,
it's
a
system
print
and
that's
that's
not
good.
I'm
just
going
to
change
it
to
a
logger
or
something
like
that
and
also
just
clean
up
some
more
places
and
then
put
it
there.
A
E
E
A
E
C
E
C
So
the
coding
phase
runs,
as
rioji
said,
from
june
7th
june
7th
to
july
to
august
16th.
So
it's
quite
it's
a
good.
It's
a
good
period
of
time
we're
one
weekend.
Truth
is
zooming
ahead
being
awesome,
and
this
year
has
reduced
hours.
Actually,
so
we're
gsak
is
requiring
less
hours
from
the
students
to
take
into
account
everything
that
is
going
on
in
the
world
and
and
how
turbulent
this
time
is,
which
gives
us
a
great
deal
of
flexibility.
C
A
Yes,
and
and
again
like
you
know,
thank
you
so
much
for
being
understanding
and
appreciated
and
really
really
important,
and
also
it's
like
so
nice
that
I
have
such
amazing
team
of
mentors.
So
amazing,
and
I
it's
I
think,
it's
like
unless
you
guys
have
like
want
to
change
the
meeting
hours
or
to
like
change.
I
don't
know
the
way
we
are
meeting
right
now.
I
think
it
should
be
funny.
C
So
it's
a
little
bit
of
a
fast
doing
these
conversions,
but
I
think
that's
the
way
it's
said,
and
it's
said
on
the
calendar
that
way,
but
if
anyone
has
an
issue
with
that
and
I'll
double
check
it
with
mauricio,
because
I
just
want
to
make
sure
he
can
it's
the
one
mentor
we
need
feedback
from
and
I
want
to
make
sure
it
works
for
him,
but
yeah.
We
can
be
flexible
on
that,
but
that
that
is
where
it's
currently
set
now.