►
From YouTube: CDEvents / SIG Events Vocabulary - Nov 1, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
C
B
F
C
B
A
A
A
B
Yeah,
okay,
so
I
guess
we
shouldn't
wait
for
anyone
else
now.
I
could
bring
up
the
agenda.
So
we
all
know
what
we're
talking
about
here.
B
B
But
okay,
so
yeah
we're
here.
The
fourth
agenda
for
today
is
that
we
should
have
some
discussions
on
GitHub
actions.
Github
has
spent
some
time
thinking
about
that
and
probably
doing
some
some
work
with
it.
Let's
see
what
that
is
soon
and
then
this
SDK
status
updates
see
Eric.
You
have
added
already
for
the
python
SDK
and
then
we
should
look
into
the
plans
for
the
coming
City
events
release
0.2,
which
we
haven't
well.
G
G
Yes,
so
I
don't
have
a
demo,
but
I
don't
have
a
demo,
mostly
because
over
the
last
few
days,
all
the
conversations
we've
had
on
the
channel
regarding
you
know
the
implementation
for
for
an
adapter
for
GitHub.
It
didn't
make
sense
for
me
to
like
just
go
ahead
and
demo
it
because
it
it
makes
more
sense
to
make
a
more
like
a
like
a
good
solution
instead
of
just
pocing
it.
So
what
I
want
to
focus
on
is
mostly
how
to
implement
this
adapter
on
this
call.
B
G
Yeah,
so
so
this
is
how
I
was
initially
thinking
of
like
the
action
to
look
like,
we
basically
say,
uses
CD
events
and
send
a
CD
event
like
this
would
be
one
action
and
we
give
the
sync
URL
with
the
with
like
we
just
give
the
sync
URL
we
give
the
URL
for
the
sync
like.
This
is
the
very
basic
example
if
I
was
thinking
of
and
now
think
of,
implementing
this
in
dash
initially
and
just
giving
a
payload
like
using
call
but
we'll
go
on
to
the
actual
implementation.
G
What
would
be
implementation
later?
I
wanted
to
discuss
and
see
what
you
guys
think
about
the
mapping
that
I've
done
here
for
the
get
GitHub
PR
event
type
to
the
CD
event.
G
G
G
So
for
the
when
a
PR
is
opened
on
GitHub
I
expect
a
workflow
to
run
and
run
the
run
this
job
and
then
see,
and
then
once
the
pr
is
open,
it
will
basically
say
that
the
pr
sorry
change
created
event
should
be
sent
ideally
to
the
sync
then
same
upon
like
when
a
PR
is
edited.
As
in
like
the
comment
has
changed,
we
send
a
updated
event
if
the
pr
is
closed,
send
an
abandoned
event.
If
the
pr
is
reopened.
G
I
would
think
like
create,
like
sender,
created
event
again,
because
there
is
no
reopening
as
such,
then
for
synchronize.
Again,
I
was
thinking
of
updated
and
there
is
contention
upon
like
how
the
review,
like
what
event
should
be
sent
on
reviewed
for
a
change.
So
that's
something
I
want
to
discuss
further
and
what
is
something
if
we
should
add
a
field
or
if
there
are
new
events.
We
need
to
add
for
that.
But
these
are
the
events.
I
was
thinking
of
implementing
initially.
G
B
B
There
I
guess
what
changed
updated,
for
example:
I
guess
that
could
be
different
kinds
of
updates,
doesn't
need
to
just
be
the
edited
action.
Maybe
I
I
guess
speculating
now,
I
guess
so
it
says
what
that
event
contains.
There
is
actually
doesn't
contain
any
additional
properties
right
now
in
the
spec,
but
I
guess
it
could
State
just
that.
Well,
just
inform
that
now
this
change
has
been
updated
and
the
consumer
of
the
event
could
of
course,
go
to
GitHub
to
see
what
has
happened.
E
B
Is
the
current
status
of
this
change?
It
was
apparently
updated
about
this
current
status,
but
exactly
what
to
include
and
if
we
should
also
provide
some
data
in
that
updated
events.
That
would
then
reflect
that
now
there
is
a
new
review
requested
or
a
review
puts
or
whatever
but
I
think
anyway,
the
updated
reticulate
is
the
used
initially
for
any
kind
of
updates.
B
G
So
so
you're
suggesting
that
we
could
actually
add
information
regarding
reviews
in
the
update,
probably
I.
B
D
And
just
real,
quick
with
GitHub
right,
there's
like
two
concepts
like
there's
the
pr
and
then
there's
like
the
files
changed
right.
So
when
we
say
edited,
we
just
care
about
the
files
change
and
not
necessary,
like
for
instance,
if
someone
changes
the
pr
title,
are
we
also
capturing
that
in
edited
or
like
what?
What
I
guess?
What
is
the
scope
of
edited.
F
Yeah
I
was
actually
going
to
guess
that
edit.
That
means
that
you
opened
the
the
pr
in
GitHub
and
you
sort
of
like
change
the
title
or
change
the
description,
or
did
something
else
like
that,
whereas
not
the
only
purpose
of
the
change
updated
but
I
think
the
main
purpose
somehow
is
to
say
that
the
code
has
changed,
which
would
typically
be
a
signal
to
maybe
some
build
system
or
some
verification
system
that
okay
now
the
code
has
changed
so
so
now
we
should
retrigger
a
builder
or
something
like
that.
F
But
of
course,
as
you
say,
email
updated
could
mean
any
form
of
update,
and
some
other
updates
might
be
interesting
too,
to
announce
as
well.
But
if
you
look
at
the
spec,
then
the
example
that
is
given
is
that
the
code
has
changed
and
I
think
looking
at
this
list.
This
edited
thing
would
not
fire
when
the
code
has
changed.
That
would
be
my
guess
at
least
because
I
think
or
I
would
guess
that
GitHub
would
probably
send
events
related
to
the
branch
that
is
backing
the
the
review
rather
than
the
review
itself.
G
B
G
G
Yeah,
so
there
is
a
web
payload
object
and
one
of
the
fields
is
changes.
The
changes
is
basically
the
changes
to
the.
If
the
action
was
edited,
the
changes
to
the
rule-
I,
don't
know
what
rule
means.
Yeah.
B
B
B
G
G
B
D
D
Actual
changes,
then,
through
the
commits
URL,
okay,
that
that
makes
sense,
but
it
still
doesn't
answer
what
edited.
If
edited
also
includes
things
like
you
know,
PR
title,
you
know
comments
to
the
pr.
B
C
B
D
In
the
comments,
though,
right
like
on
the
on
the
pr
itself,
not
the
like
the
code,
but
you
know
like
on
GitHub,
you
can
just
have
like
comments
just
like
on
the
parent
like
level
that
that
would
be
important
to
include
right,
even
though
it's
like,
outside
of
the
code
per
se,.
F
G
Oh
sorry,
I'm
guessing
would
that
count
as
a
review,
then
there's
a
okay.
There
might
be
like
another
events
itself
for
that,
like
okay,
let's
see,
okay,
they
have
pull
requests,
pull
request,
review.
F
I
was
going
to
say
there
are
some
interesting
use
cases
here
related
to
what
Ben
said
like.
If
you
announce
a
comment,
because
I
know
in
zul,
which
we
use
like
one
way
of
retriggering,
is
to
just
write
the
trigger
in
a
comment
and
that
gets
sent
out
on
the
event
bus
and
soon
picks
that
up
and
retrigues
the
job.
A
F
We
do
have
an
event
that
is
called
change
reviewed.
F
If
we
want
to
use
an
existing
event,
then
that
would
be
the
one
I
think,
because
that
one
doesn't
say
that
you
actually
have
to
have
given
a
verdict.
It
just
says
that
you,
you
have
yeah
you've
done
something
that
related
to
reviewing
of
this.
F
Actually,
it
says
that
the
review
event
has
to
include
if
the
change
is
approved,
so
then
we
would
need
a
separate
event
or
to
change
the
definition.
It.
G
So
while
we
are
on
this,
I
I
have
more
like
questions
around
the
reviewed
aspect.
So
this
what
the
states
is
basically
change
has
been
reviewed
and
it's
like
the
review
has
been
done.
But
at
no
point
is
there
like
a
event
which
says
there
is
a
change.
Sorry,
the
change
needs,
a
review
like
a
review
is
requested
or
a
review
is
deleted.
So
this
one
is
basically
saying
a
review
has
been
created
on
the
change,
but
there
is
nothing
saying
that
a
review
needs
to
be
done
so
yeah.
F
G
Is
like
there's
a
communication
gap
like
no
one
is
just
going
to
come
and
tell
me
to
like
review
my
peer,
sorry,
I'm,
not
just
gonna
go
and
like
review.
Some
sphere
like
I
need
to
know
what
to
review
so
I
I
feel
like
there's
a
need
for
changed.
Change
review
created
sorry
Change
review
requested
as
like
on
other
events.
Subject
event
maybe,
but.
F
I
think
this
this
I
mean
this
relates
to
discussion
that
we've
had,
which
is
about
a
prescriptive
versus
descriptive
events
that
it's
not
we've
tried
thus
far
to
avoid
pre-scripted
events.
So
it's
not
that
the
purpose
of
see
the
events
to
to
announce
that
something
needs
to
be
done.
B
It
is
more
saying
that
the
pull
request
now
has
the
state
of
we
having
requested
a
review
for
it.
I
mean
it's
something
that
has
happened,
and
someone
has
requested
a
review
on
this
pull
request,
and
we
just
want
to
announce
that
that
has
happened.
So
I
mean
it's,
it's
not
that
we
more.
Let's
replace
the
GitHub
request
for
review
thing
with
the
seed
events,
but
rather
seeing
now
that
this
GitHub
system
has
requested
someone
to
review
this.
Okay.
B
F
F
B
F
Way
this
works
in
in
zul
is
that
you
don't
request
a
review.
Zul
picks
up
the
like
change,
created
and
change
update
in
those
other
events
and
then
just
automatically,
thus
its
its
tasks.
So,
there's
no
state
where
you
you
ask
Zoot
review
just
picks
up
on
this,
the
other
signals
and
does
the
review
automatically
that's.
G
F
G
F
B
Would
be
more,
do
you
see
a
use
case
where,
where
people
would
like
to
have
City
events
for
such
use
cases,
for
example,
that
there
might
be
some
use
GitHub
some
use,
bitbucket
or
whatever,
and
they
would
like
to
have
one
common
way
of
seeing
that
they
have
been
requested
to
review
changes
from
whatever
system?
Is
that
your
use
case
that
you're
looking
for
or
is.
G
D
There
there
is
a
use
case
where
I
could
have
an
email,
microservice,
that's
running,
and
then
you
know
anyone
that
adds
like
whether
it's
from
bitbucket
or
GitHub
or
whatnot
adds
a
new
reviewer
like
it
would
send
all
these
CD
bits
and
then
I
could
have
this
one
service
do
all
the
emailing
right.
So
that
might
be
useful.
D
You
know
it
just
really
depends
like
how
people
want
to
use
use
the
CD
events,
but
that
that
could
be
a
potential
use
case.
Yeah.
E
So
you
know
if,
if
something
has
moved
into
a
review
state
everything's
going
to
hang
until
some
external
activity
is
completed
now
it
depends
whether
or
not
you
want
the
system
to
be
aware
of
that
and
to
understand
potential
sources
of
you
know
things
not
happening
in,
in
which
case
how
telling
the
system
that
responsibility
has
moved
outside
its
domain.
G
There
could
be
like
Dora
metrics
accordingly,
I
guess
where
you
can
see
like
how
many
reviews
were
requested
for
like
a
PR
and
how
many
changes
like
we
could
see
like
a
review
requested
and
like
review
requested
and
the
change
edited
or
like
change,
updated
ratio
to
see
how
many
reviews
did
a
PR
actually
took
yeah.
B
B
So
we
can
calculate
such
metrics
based
on
the
events,
and
that
would
actually
make
sense
to
have
a
common
way
of
describing
that
through
the
dumpster
that's
now,
this
change
has
got
a
review
requested
from
someone,
and
now
it
was
approved,
and
now
it
was
reacted.
So
we
can
calculate
the
the
duration
of
such
video
activities.
E
From
a
chain
of
custody
and
audit
perspective,
you,
you
might
want
to
be
aware
internally
of
you
know
who
specifically
has
been
tasked
to
review,
and
you
may
want
to
manage
situations
where
you
you
want
to
enforce
specific
reviewers
at
a
platform
level,
which
you
can't
control
necessarily
on
external
systems.
So
you
might
need
to
actually
intercept
this
and
say:
okay,
a
review
has
been
requested,
but
it
actually
we've
requested
it
from
the
wrong
person.
So
then,
the
platform
would
want
to
take
action
to
to
redirect
those
those
reviews,
foreign.
B
Requests
withdrawn
and
and
all
other
kinds
of
the
edge
cases
I
guess
on
these
kinds
of
things.
So
it's
hard
to
to
maybe
map
that
to
all
sem
systems
as
well
and
make
it
work.
Well,
if.
D
B
Want
to
know,
that's
I
mean
actually
because
then
you
might
not
want
to
run
your
Ci
or
pre-emerge
Pipeline
on
the
draft
payer,
but
you
would
like
to
run
it
on
a
non-draft
fear,
for
example,
so
that
actually
makes
sense
to
have
a
distinguished
out
in
the
events.
If
it's
the
drafts
or
not
or
is
it
called
preliminary?
No,
it's
called
router
I
think
it
is
draft.
A
B
G
It's
so
for
this
specific
event.
Maybe
it
makes
sense
to
do
kind
of
a
like
check,
get
Club,
GitHub
and
maybe
other
other
get
get
Technologies
or
GitHub
git
providers
to
see.
If
so,
this
makes
sense.
B
Yeah
I
think
that
that's
a
good
way
to
go
and
also
before
before,
settling
on
on
terms
for
these
things.
We
ideally
should
go
through,
seek
interoperability
or
I'm,
not
sure
if
it
will
end
up
in
sixth
best
practice
now,
maybe
Terry.
If
you
know
that
better
about
the
normal
categories
used
or
the
terms
to
use
for
different
actions
in
the
cicd
systems,
we
have
the
vocabulary
document
there
today.
So.
E
E
You
know
you
can
look
at
it
at
the
the
engineering
level
of
a
pipeline
as
just
a
mechanism
for
for
delivering
software
in,
in
which
case
you
might
say
that
this,
this
type
of
feature
sits
outside
of
that,
but
from
a
best
practices
perspective,
we're
thinking
much
more
about
the
overall
product
governance
perspective
that
people
want
from
their
pipelines,
and
in
that
case
you
you
need
to
think
much
more
about
what
are
the
the
security
aspects
of
this
one
of
the
software
supply
chain
aspects
of
of
this,
and
in
that
case
the
review
mechanism
is
actually
another
Potential
Threat
Vector.
E
E
So
there's
a
there's,
an
audit
part
to
this
and
a
security
part
to
it,
which
is
almost
independent
from
the
software
delivery.
Part
right
and.
B
That
could
maybe
be
notified
by
I
mean
the
input
data
that
could
come
from
students
if
that's
suitable
for
some
of
those
I
think
yeah
I
guess
so,
but
talking
again
about
the
vocabulary,
maybe
the
best
practices,
ideas
or
the
work.
There
is
more
now
related
to
the
security
parts
and
the
the
processes
always
are
working
around
the
cicd
pipelines,
not
exactly
the
vocabulary.
The
the
terms
used
themselves,
I
guess.
E
Yeah
so
I
think
this
there's,
if
you
like,
the
best
practices
piece
is
going
to
paint
the
picture
of.
What's
the
overarching
need,
what
are
the?
What
are
the
user
stories
for
for
continuous
delivery
and
then,
as
you
work
your
way
through
the
the
different
levels,
we're
starting
to
to
say?
Well,
you
know:
are
we
including
these
capabilities
at
this
level
of
definition,
we're
so
yeah
you?
You
could
certainly
make
the
argument
that
it.
E
It
would
be
important
to
include
these
factors
within
our
terminology
and
within
the
events
level,
because
then
it
gives
us
a
standard
way
of
doing
that
and
therefore
tooling
is
likely
to
adopt
that
and
and
that
will
encourage
the
implementation
of
best
practice
at
a
tilling
level.
B
G
B
F
Full
of
course,
uses
Garrett
extensively
okay
paper.
If
it's
okay,
could
you
share
the
Google
Doc
just
on
the
screen
for
a
few
more
seconds,
I
had
to
do
some,
some
understanding
on
the
site.
So
we
had
a
question
before
like
what
is
the?
F
What
is
the
event
that
actually
signals
that
a
the
code
has
changed
and
apparently
that
is
which
you
have
already
identified.
It's
a
synchronize
so
synchronize
it
will
be
sent
whenever
the
code
is
changed,
like
you
have
done
a
rebase
or
added
a
new
commit
or
something
I
find
that
naming
to
be
very
confusing,
but
now
I
know
so
edited
would
be
for
like
when
you
change
the
title
or
some
other
things
like
that,
synchronizes
what
it
gets
triggered
when
the
code
has
changed.
F
F
Merch
change,
merge,
yeah
change
version,
yeah
yeah,
so
so
that
closed
event
will
be
triggered
both
when
the
change
is
abandoned
and
when
the
change
is
merged,
so
yeah,
but
this
looks
really
good
I'm
I'm
happy
that
someone
is
slipping
into
this
and
I
can
see
a
lot
of
views
for
it.
Yeah.
B
So
do
we
have
some
I
know
that
we
internally
in
our
example,
we
have
actually
events
or
where
no
not
actually
that,
but
we
have
states
where
we
look
when
they
change.
A
pull
request
in
this
case
has
been
approved.
So
it's
reviewed
enough
so
to
say
so
there
there
has
been
enough
amount
of
reviews
and
in
some
scenarios
we
would
then
like
to
run
a
separate
Pipeline
on
some
code.
That
we
knew
know
has
at
least
passed
the
manual
human
review,
and
we
don't
want
to
run
that
before
the
review
has
been
approved.
B
B
F
But
I
think
here
it
is
submitted
so
I
submitted
here
would
be
that
someone
has
made
a
review
which
was
either
approved
or
not
not
approved,
so
it's
not
actually
submitting
the
merge
or
a
pull
request.
It's
submitting
the
review
yeah.
B
B
F
F
B
G
Either
do
I,
but
but
that
seems
like
a.
G
B
It
it
means
more
or
less
that
the
submit
button
is
oh,
it
doesn't
actually
need
to
be
the
submit
button.
It's
is
available
yet
because
it
could
still
be
some
automatic
pipeline
still
ongoing,
but
and
I
know
that
in
gitlab
there
is
a
concept
of
approved,
so
emerge
requesting
GitHub
could
be
approved
or
not
yet
approved
and
approving
their
as
far
as
I.
Remember
now
at
least
means
that
manual
reviewers
has
approved
the
merge
requests,
even
though
there
might
still
be
some
automatic
Pipeline
on
going
for
it.
B
So
there
in
in
GitHub
I'm
pretty
sure
there
is
such
a
concept.
And
if
you
look
into
it's
a
different
sem
providers,
you
can
see
that
for
gitlab
I
assume
that
there
might
be
some
kind
of
is
it
called
not
git
love
action,
but
whatever
the
Web
book
for
notifying
it
loud.
G
G
I,
don't
know
how
at
what
point
we'll
be
getting
this
event,
like
I,
don't
know
the
life
cycle
like
a
point
in
the
life
cycle
where
we
see
this
see
this
event,
but
it
seems
like
there
is
a
this
event
called
require
required.
Approving
review
count.
C
G
This
might
this
might
be
the
point
where,
after
enough
people
have
approved,
you
can
see
in
the
GitHub
UI,
where
you
know
like
enough.
People
have
approved
this
pull
request.
This
must
be
part
of
that.
B
So,
of
course,
we
don't
need
to
have
that
in
the
first
version
of
this,
but
but
yesterday
there
they
will
will
possibly
come
extensions
to
this
need,
anyway,
to
add
more
maybe
more
predicates
or
events
or
add
even
more
event
types
later
on.
That's
it
as
well,
of
course,.
E
E
E
B
Exactly
yeah,
that's
what
I'm
thinking
as
well
I
mean
we
will
not
be
I,
mean
I.
Don't
think
that
City
events
will
be
duplicating
what
we
are,
what
already
exists
in
the
open
Telemetry
world
or
the
tracing
world
of
systems,
so
to
say,
I
mean
making
sure
that
all
CI
series,
system
tools
or
subsystems
are
up
and
running,
but
instead
we
should
have
references
between
these
different
notifications
in
some
way,
either
from
City
events
to
the
whatever
open
tracing
items
or
vice
versa,
or
maybe
both
ways.
So
we
can
track.
B
E
Yeah
so
I'm,
just
thinking
back
to
you
know
a
fairly
common
issue
with
Jenkins
EX
that
occurred
specifically
with
GitHub
was
that
we
would
quite
frequently
hit
rate
limits
on
the
GitHub
end,
which
would
cause
you
to
have
a
backlog
of
activity
in
your
cicd
system,
which
would
then
keep
trying
to
poll
the
the
end
system,
which
would
just
reject
you
even
more
because
you
were
creating
more
load
on
it,
that
it
was
exceeding
your
rate
limits.
B
Sure
and
of
course,
that's
true
I
guess
for
any
kind
of
performance
related
issues,
I
mean
it
could
be
CPU
load
or
external
storage
load
or
whatever
in
your
system
as
well,
that
you
need
to
be
aware
of
in
inside
your
system,
somehow
the
but
still
I
don't
really
see,
because,
of
course,
those
skit.
We
don't
get
the
Gate
of
action
when
when
to
get
notified
by
get
directions
when
when
git
love,
this
get
sorry
GitHub
is
is
a
big
has
decreased
performance
or
whatever
so
I.
B
F
B
F
Do
have
I'm
not
sure
how
related
it
is,
but
we
do
have
the
incident
events
that
we've
discussed.
So
if
we
consider
that
an
incident
that
okay,
our
we
have
a
service
that
we
would
like
to
talk
to,
but
that
Services
is
not
talking
to
us,
we
could
choose
to
send
an
incident
event
which
other
parts
of
our
cic
system
could
pick
up
and
say.
F
B
C
C
D
And
and
for
me
like,
if
I
am
adjusting
an
event,
that
system
would
then
make
the
call
to
this
system
that's
down,
and
then
that
would
do
the
rate
limiting
and
the
throttling
right
like
we
don't
need
that
to
be
propagated
throughout
CD
events.
You
know
and
I
think
you
know
with
tracing
you
know
you
can
you
can
visit
that
that
there's
already
a
good
measurement
for
that
so
I
I,
really
don't
think
CD
events
is,
is
the
is
the
right
place
for
it,
at
least
from
from
what
I
can
see
foreign.
E
E
It's
Overkill,
but
I've
certainly
looked
at
system
implementations
where
you're
trying
to
build
a
a
very
resilient
platform,
agnostic,
CI
CD
system,
where
you
actually
are
trying
to
build
something
that
spans
across
multiple
Cloud
vendors
and
potentially,
would
even
want
to
try
and
have
a
a
fallback
Repository
to
stop
the
the
the
fact
that
if
you've
got
a
single
point
of
failure
and
that
goes
down,
you
then
can't
build
and
release
anything,
because
that
becomes
a
big
weakness.
E
Because
if
someone
can
interrupt
your
service
provision
from
an
external
vendor,
then
you
can't
react
to
them,
because
you
can't
deploy
any
new
code.
So
you
would
want
to
know
if
you
couldn't
access
part
of
your
system
so
that
you
could
fail
over
your
your
process
onto
an
alternative
path
to
work
around
that.
E
C
B
Any
subsystem
would
anyway
need
other
means
of
monitoring
some
parts
of
its
environment,
even
though
we
could
of
course
succeed
events
for
certain
such
status,
reporting
notifications,
but
I,
I
I,
don't
know
if
we
can
have
it
for
everything.
Of
course
it
could
I
guess
it's
a
bit
stretched,
but.
G
B
D
Right,
like
you,
should
have
other
Technologies
to
you,
know
like
canaries,
and
you
know,
and
then
the
correct
load
balancers
in
front
of
those
things
or
you
know
what
have
you
you
know
to
hit
the
correct,
pods
or
services
or
whatnot,
so
I
think
CD
events,
especially
since
you
know
we're
in
the
early
stages
of
it
I
think
we
should
focus
on
more
of
the
the
code
part
of
it
rather
than
the
the
infrastructure
part
of
it,
keeping
the
scope
lower
for
now
and
then
maybe
in
the
future
like.
C
E
Yeah
I
I
I,
don't
I
don't
disagree
with
that
from
the
best
practices
perspective,
we
would
probably
take
the
opposite
approach,
which
is
to
say,
what's
actually
the
overarching
set
of
requirements
that
that
is
the
end
goal
for
this,
and
and
therefore
what
things
should
be
on
the
roadmap
and
then
you
might
then
set
the
implementation
order,
but
you,
you
wouldn't
exclude
things.
You
would
say
right.
That
goes
on
the
roadmap,
but
it's
in
X
version,
rather
than
this
version.
B
B
Yeah,
it's
great
that
that
work
is
done
in
best
practices,
so
we
can
somehow
see
that
we
are
at
least
converging
eventually
towards
a
common
or
we
reach
some
kind
of
completeness
in
in
both
monitoring
and
traceability
and
every
aspect
of
the
system
and
parts
of
it
through
sediments
I'm,
not
sure
if
all
those
aspects
are
to
be
covered
by
citizens,
so
I
try
to
I
think
I
tend
to
agree
with
them
there.
They
must
might
not
be
the
best
fit.
B
E
I
think
some
of
it
comes
down
to
whether
we
see
the
future
of
CD
events
as
a
kind
of
abstraction
layer
in,
in
which
case
there
there
will
be
a
minimum
set
of
functionality
that
you
need
to
have
a
viable
extra
abstraction
layer.
B
G
Also
wanted
to
discuss
the
implementation
aspect
for
this
for
the
book,
so
on
slack
we
discussed
if
JavaScript
would
be
a
good
idea
initially
to
do
it
because
reading
GitHub
events
from
JavaScript
was
pretty
easy
and
I
and
GitHub
actions
is
an
easy
way
to
do
this.
By
giving
a
script
and
running
that
script.
Writing
the
script
in
JavaScript
and
reading
GitHub
event,
event
payloads
from
there
and
then
doing
whatever
we
we
need
to.
So
it
was
considering.
There
was
no
JavaScript
SDK
for
CD
events.
G
The
way
we
would
get
to
do
this
with
golang
is,
after
giving
a
little
thought,
might
become
a
kind
of
a
CLI
for
like
a
CD
events,
generator
CLR,
where
you
will
be
able
to
like,
provide
a
sync
and
pass
the
payload
requirements
and
like
whatever's,
required,
whatever
we
need
to
given
the
extra
extra
Fields,
the
custom
Fields,
so
it
seems
like
it
might
become
a
CLI
which
we
would
then
be
running
in
GitHub
actions.
B
Yeah
there
are
discussions
on
providing
a
CLI
to
interact
with
City
events,
whether
that
CLI
should
be
based
on
top
of
the
goal
SDK
or
maybe
the
python
SDK,
which
is
almost
there
as
well
for
the
Java
SDK,
which
is
ongoing
or
something
else
I.
Don't
know
it
remains
to
be
to
be
decider,
I
guess,
but
I
agree
that
they
would
be
beneficial
to
have
the
CLI
to
to
emit
the
events.
Do
you
think.
G
Yeah
that
that
CLA
would
be
like
initially
I
would
it
would
be
specifically
for
like
if
go
is
the
way
we
are
going
for
the
Spock,
then
sailor
would
be
the
best
way
to
like.
If
we
have
to
do
it
and
go,
then
then
making
a
CLI
makes
sense
for
generating
these
events.
B
B
G
I
mean
considering
that
and
considering
like
the
testing
aspect
of
this,
maybe
go
makes
a
lot
more
sense,
because
then,
if,
if
I
create
a
CD
events,
generator
using
go
so
it's
something
I
I
found
a
cloud
Advanced
generator
a
second.
C
A
G
Yeah
I
found
this
loud
image
generator.
You
could.
Probably
you
like,
get
some
inspiration
from
initially
to
create
a
CD
events.
Generator
is
is
what
I
was
is
the
path
I
was
thinking
of
taking.
G
If,
if
you
guys
don't
like
mind
it
like
I
will
just
go
ahead
with
this
done
and
basically
either
like
fourth
person
creator
CD
events
run
data,
make
some
changes,
create
a
CD
management
data
else.
If
you
guys
have
any
other
ideas,
I'll
go
ahead.
I
can
consider
that
as
well.
A
D
D
You
know,
and-
and
if
you
feel
like
go
is
the
best
approach,
just
you
know,
I
think
you
know
just
choose
it.
You
know
if
you
like
python,
just
go
python,
I
I
think
you
know
like
what
a
meal
will
say:
it's
just
you're,
not
you
don't
have
to
go
with
go
right
and
I.
Think
if
you
want
to
use
this
generator,
you
know,
but
that's
completely
fine,
because
I
think
we're
kind
of
getting
into
the
implementation,
details
and
and
yeah.
So
I
think
you
know
whatever
gets
the
job
done.
A
G
Okay,
okay
I'll.
Do
that
one
question
I
had
was:
is
there
a
cloud
events
sync
which
is
kind
of
owned
by
a
CD
events
like
a
okay?
Our
better
question
would
be.
Is
there
a
cluster
where
I
can
test
this
one
like
an
endpoint
where
I
can
just
send
CD
events.
B
No,
not
that
I'm,
aware
of
is
there
I,
don't
think
we
have
requested
on
the
infrastructure
for
City
events
itself.
B
A
B
F
Sdk,
no
other
than
what
I've
added
in
the
notes.
There
is
a
PR
with
which
compliant
events
can
be
created,
but
it
doesn't
give
a
very
good
user
experience
yet,
and
it
cannot
course
events
so
there's
still
a
better
work
left
to
do,
but
I
will
keep
working
at
it.
Yeah.
B
I
think
we
had
a
very
fruitful
discussion
today
and
I'm
very
happy
to
see
that
I'll
try
to
have
some
some
notes
somewhere
and
maybe
some
issues,
so
you
can.
So
we
don't
forget
about
things.
B
Thank
you
all
for
joining
and
for
the
great
discussions
talk
to
you
next
time.
Thank.