►
From YouTube: CDEvents / SIG Events Vocabulary - Aug 23, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
A
A
B
A
B
B
D
D
D
D
Cool
thanks
the
first
item
I
had
in
the
agenda.
I
put
it
first,
but
the
three
ml2
movies,
if
you'd
like,
prefer
it's
about
my
great
content
from
sig
events
to
cd
events.
So
we
have
some
content
today
under
the
sig
events,
repo
in
the
cdf
org.
And
then
we
see
the
events
org
and
there
are
still
things
to
be
moved
across
and
ml
has
been
working
on
that.
So
I
was
wondering
if
you
would
like
to
give
an
update
on.
E
Yeah
I
could,
but
maybe
I'm
not
sure,
if
that's
really
the
highest
important
thing
to
talk
about
today
on
this
meeting,
I
think
we
should
focus
on
the
vocabulary
issues
here
now.
If
there
is
time
in
the
end,
we
can
look
into
that
because
it's
mostly
admin,
stuff
and
moving
things
around
okay.
So
let's
keep
that
on
the
sig
meeting
or
if
we
have
time
on
this
meeting
in
the
end
we
can
go
into
it.
D
D
It's
matching
the
spec
and
I
also
added
all
the
other
events,
but
I'm
working
on
getting
them
up
to
date
with
the
specs,
so
adding
any
extra
feel
that
they
might
have
a
lot
of
them.
Don't
have
extra
fills.
So
probably
it's
going
to
be
not
so
much
work
to
finish,
but
still
there's
some
something
to
be.
A
D
A
D
D
D
C
So
I
have
a
curiosity
with
the
schema
right
like
this
seems
like
it'd,
be
useful
across
all
the
sdks
I'm
assuming
like
that
is
probably
gonna,
be
something
in
the
future,
mostly
because,
when
I
think
of
validation
right,
the
biggest
issue
is
when
you
have
multiple
sdks
and
you
know
a
required
field
gets
added
or
removed
right.
How
do
you
update
all
sdks
easily
right
and-
and
I
think
the
schema
would
probably
do
it,
so
is
that
kind
of
the
idea
here.
D
Yeah
absolutely
so,
I
actually
kind
of
use
the
sdk
to
generate
the
schemas
to
get
started
on
those,
but
I
have
a
pr
up,
which
is
the
next
update
to
to
put
those
schemas
in
the
spec
repo,
so
that
then
every
sdk
can
use
them.
It
was
just
convenient
from
from
the
goal
structs
to
generate
the
schema,
rather
than
forging
them
by
hand
or
writing
in
their
hand,
but
yeah.
D
C
D
D
E
D
D
D
D
Yeah,
just
other
updates
on
the
specification
itself,
the
the
the
pr
with
the
formatting
changes
are
merged
and
live
now,
so
just
to
show
how
it
looks
now
for
all
the
events,
and
we
have
an
initial
description
for
the
kind
of
the
stage
with
the
packet.
Then
the
list
of
the
subjects
with
some
details
about
possible
fields,
and
then
we
have
the
list
of
events.
So
events,
one
by
one
and
each
event,
has
the
list
of
the
fills
that
are
either
mandatory
or
optional.
D
D
E
B
A
A
B
D
D
D
Let
me
see
if
it
loads,
it
is
need
to
fix
this
rendering,
but
which
we
have
where
we
have
a
context
and
subject
root
elements,
and
then
the
other
elements
are
distributed
like
like
this
I
mean
the
actual
content
is
the
same.
I
don't
think
we
have
added
or
removed
any
specific
field
from
the
different
events,
but
we
have
kind
of
changed
defined,
at
least
the
structure
before
it
wasn't
defined
at
all.
D
D
But
the
new
sdk
will
generate
this
exaggeration
as
I'm
showing
here,
and
that
should
be
the
format
for
always
the
case
eventually,
but
because
the
the
new
go
sdk
did
not
exist
at
the
time.
I
think
I
understand
that
the
new
the
java
and
the
python
sdk
have
been
created
following
what
was
in
the
original
go
sdk
as
a
starting
point,
but
we
should
converge
on
what
is
in
the
spec.
D
For
the
sdk,
so
this
change
events
pipeline,
run
event
and
task
run
events,
and
I
I
plan
to
continue
producing
the
other
ones
as
a
radius
and
then
adding
them
to
the
spec.
If
this
works,
the
id
that
I've
been
using
is
the
domain
that
we
own
slash.
Draft,
slash,
schema,
slash
change,
abandoned
event,
so
the
name
of
the
event
and
eventually
we'll
need
a
way
to
to
publish
those
schemas
to
that
domain,
so
that
we
so
that
this
url
is
actually
can
be
pulled.
D
But
that's
not
the
case
yet
yeah.
So
that's,
that's
it.
I
think
we
need
to
add
eventually
also
to
the
sdk
the
ability
to
to
fill
in
the
cloud
events,
data
shima
field,
but
yeah.
So
let
me
know
what
you
think
about
adding
the
schemas
here
in
the
in
this
pack.
If
you
have
any
concern
or
if
I
can
continue
to
produce
them
and
add
them
in
here.
E
A
E
E
B
B
D
E
I
think
it
kind
of
does
I
mean
if
you
would
move
this
out,
as
you
said,
to
somewhere
else,
to
a
schema
registry,
for
example,
but
actually
would
use
for
validation
or
whatever
purpose.
Then
you
would
need
somehow
to
see
within
the
schema
what
version
it
belongs
to.
I
think
that
could
be
improved
later
on,
so
we
don't
need
to.
I
don't
think
we
need
to
edit
today,
but
but
you
should
be
aware
of
it.
A
C
C
Yeah,
I
don't
know
how
they
how
they
handle
that,
to
be
honest
and
that's
why
I
was
thinking
we
might
not
need
it,
but,
like
it
just
depends.
Maybe
oh
wait.
Maybe
they're
release
pages.
Okay,
so
that's
how
it
works.
Okay,
they
do
have
a
version.
So
if
you
go
to
the
releases,
they
actually
have
like
the
version
there,
but
whatever
you
see
on
the
website
is
always
the
latest.
Basically.
C
E
D
A
A
E
E
A
E
A
E
A
D
D
D
D
A
D
D
So
the
the
work
that
was
in
scope
for
this
initial
issue,
jalander
said:
okay,
we
can
close
this
one,
that's
okay,
the
initial
work
that
was
planned
for
this
issue
is
finished
and
with
track
extra
work
and
in
a
separate
issue.
It's
just
that.
Not
it's
not
saying
that
the
java
sdk
is
fully
complete
or
there's
no
more
work
to
be
done.
It's
just.
E
E
D
D
D
A
Will
discuss
so
basically,
I'm
not
saying
so
much,
but
first
of
all
we're
creating.
We
created
a
world
request
with
what
we
have
achieved
and
we
added
a
little
bit
step
for
not
just
sending
also
start
receiving,
so
we
optimized
our
object
to
be
able
to
read
from
html
http
http
or
send
an
object.
So
the
comment,
the
current.
A
B
I
think
when
it
comes
to
adopting
this
the
context
and
subject
type
things
I
think
me
and
tariq
and
the
rest
of
you
what
me
and
I
can
start,
we
need
to
think
a
little
bit
about
like
what
values
makes
sense
to
set
for
every
event.
You
send
what
values
make
sense
to
set
somewhere
in
the
sdk,
so
that
every
event
that
you
send
gets
that
value,
for
instance,
maybe
something
related
to
source.
B
We
could
provide
a
method
in
the
sdk
for
setting
a
default
value
for
source
like
it
would
be
the
application
or
some
context
related
stuff,
so
that
we
don't
need
to
repeat
that
in
every
event,
and
that
would
simplify
things
for
users.
I
think
if
say
that
you
have
a
rather
complicated
application
that,
like
can
set
some
of
the
context
in
some
sort
of
startup
or
whatever,
so
that
individual
pieces
of
code
further
inside
the
application
does
not
need
to
know
what
the
context
is,
because
that
is
made
part
of
all
the
events
by
themselves.
B
B
E
E
I
think
that
the
context
object
that
we
have
on
top
level
is
the
syntax
of
it
is
the
same
for
all
event
types.
As
far
as
I
understand
right
now,
so
there
could
be
a
common
function
at
this
common
method
to
create
the
context
object,
you
might
need
some
input
there.
Of
course,
the
the
events
type
as
an
input
or
something
like
that.
B
E
D
Basically-
and
I
think
this
is
similar
to
what
you're
saying
ml
and
yeah
so
for
the
go
sdk,
what
I'm
doing,
I'm
setting
the
id
and
setting
the
timestamp
by
default
unless
they
are
already
set
or
but
of
course
they
can
be
overwritten
with
other
values
but
yeah.
I
agree
we,
it
would
be
nice
to
have
a
way
to
kind
of
give
a
context
and
say:
okay.
This
is
this
application
context,
and
this.
A
D
C
Yeah
so
me
and
my
team,
as
well
as
a
few
teams
here
at
apple,
have
been
talking
about
cd
events
in
general
and
one
thing
that
we
notice
is
because
right
now,
you
guys
kind
of
have
this
idea
of
point
to
point
like
services
talking
to
services.
You
know
with
these
like
cd
events,
and
we
don't
know
if
that
is
going
to
work
kind
of
like
at
a
at
a
good.
C
So
I
was
wondering
if
that
has
been
considered
what
has
been
kind
of
like
talked
about
there,
because
it
seems
like
in
in
the
spec
and
from
all
the
you
know,
meetings
past
things
I've
been
into.
It's
only
been
this
point
to
point
from
service
to
service
passing
these
events,
and
I
wonder
if,
if
this
has
been
thought
about
at
all.
B
Was
going
to
say,
I
think
it's
something
that
we
don't
discuss
very
often,
but
for
me
it
it's
definitely
part
of
the
spec
that
it
or,
I
guess
the
main
use
case
for
me
for
the
spec.
Is
that
a
a
event
producer
sends
it
to
some
sort
of
message,
bus
or
broker
or
whatever
you
want
to
call
it
and
then
don't
care
about
whether
anyone
wants
to
receive
it
or
not,
which
I
think
ben
is
in
line
with
what
you're
talking
about
so
producers
sent
to
the
bus.
B
E
Yeah
it
was
me
yes,
just
a
comment.
I
think
it
could
add
to
the
confusion.
If
you
look
at
the
proof
of
concept,
for
example,
because
there
it
it
really
looks
like
there
is
one
to
point
to
point
communication
going
on,
but
the
actual
events
that
is
passed
between
these
services
are
intended
for
for
general
consumption.
It's
just
that
in
the
box
there
is
a
point-to-point
communication
set
up
where
those
events
are
are
forwarded
just
for
convenience
reasons,
for
the
proof
of
concept,
more
or
less,
I
would
say:
okay,.
C
Cool
because
that's
what
I
was
getting
like,
it
was
just
kind
of
like
this
general
consumption,
and
you
know
and
like,
like
you
said,
based
off
the
examples
it
seemed
like.
It
was
kind
of
point
to
point
and
that's
why
I
was
like
wondering
you
know
whether
or
not
we
can
kind
of
like
illustrate
in
the
spec
because,
like
like
you
were
saying
eric.
I
I
believe
this
is
going
to
be.
The
main
use
case
right
is:
is
he
having
like
the
subscriber?
C
A
A
A
D
A
D
In
the
in
the
cd
events,
some
meth
yeah
actually
in
austin,
because
there
are
some
use
cases
that
were
brought
up
where
it
could
make
sense
to
to
have
more
like
imperative
type
of
events.
So
all
the
events
that
that
we
haven't
expected
today,
they're
meant
to
be
like
declarative
events,
so
events
that
are
sent
to
a
bus,
basically
for
anyone
who
wants
to
listen
to
them
and
react
to
them.
D
C
Yeah
yeah,
I
don't
know
if
we
need
that
point-to-point
use
case.
In
my
opinion,
I
would
try
to
get
rid
of
that
in
the
dos,
because
that's
how
I
read
it-
and
I
didn't
even
know
you
guys-
even
considered
this
publisher
scriber
model
as
the
main
use
case,
but
I'm
glad
I'm
glad
that
this
is
the
main
use
case,
but
I
I
think
we
need
to
do
a
better
illustration
like
having
this
diagram.
Like
would
have
been
perfect
in
the
spec.
C
You
know
saying:
oh,
this
is
kind
of
how
we
envision
this
working
because
like
if
I
saw
this,
I
would
be
like
oh
perfect.
You
know,
then
you
know
we
don't
have
to.
We
don't
have
to
like
discuss
this
at
all
right.
You
guys
are
already
thinking
about
it,
which
you
guys
are
right
so
which
which
is
really
good
to
hear.
But
what
do
you
guys
think
about
that?
Like
maybe
making
spec
a
little
bit
more
or
you
know,
indicative
indicative
of
of
this
model?
B
Yeah,
I
think
that
would
be
good
there
is
I've
been
glancing
at
the
spec.
Let's
say
in
the
background
here
there
is
a
a
small
chapter
in
the
primer
called.
Basically
why
we
don't
want
to
have
point-to-point
communication,
but
I
I
think,
having
something
earlier
on,
as
you
say,
that
sort
of
describes
the
the
intended
or
major
use
case
with
an
event
broker
and
that
stuff
would.
C
Yeah
yeah
definitely,
and-
and-
and
I
agree-
I
I
think
I
think
you
know
having
that
section
saying
you
know
we
don't
we
don't
want
this
to
be
a
point
to
point
should
be
a
huge
bold.
You
know
inbred
in
my
opinion,
but
yeah
yeah.
I
I
I
think
having
that
in
there,
because
you
know
like
having
this
as
point
to
point.
I
think
really
doesn't
make
too
much
sense
and
andre.
I
don't
know
who
he
talked
to
to
ask
for
this
imperative,
but,
like
I,
I
really
feel
like
this
message.
C
Bus
like,
if
you
just
have
like
a
scriber
model
like
would
solve
all
the
like.
Even
the
you
know,
starting
pipeline,
you
know
and
like
I
said
they
still
can
have
their
own
apis
right
like
where
they
can
just
like.
Send
you
can
just
start
the
pipeline.
You
know
so
I
I
really
don't
know
if
and
you
know
if
they
want,
if
they
want
they
can
they
can,
you
know,
make
their
apo
apis.
Look
exactly
like.
C
D
D
D
D
E
Yeah,
I
just
added
that
question
there.
I'm
not
sure
if
it's
a
valid
topic,
but
I
think
we
meant
we
brought
it
up
as
well.
On
the
sig
meeting
last
time
or
sometime
I
mean
how
should
we
do
with
our
current
box
and
should
we
instead
call
something
a
reference
implementation
that
will
go
along
with
each
version
coming
version
of
the
spec,
I
mean
I
mean
we
need
to
provide
some
kind
of
proof
of
concept
or
reference
implementation.
I
believe
together
with
0.1,
or
we
should
at
least
aim
for
having
something
there.
E
That
is
up
to
date
with
the
001
version.
So
is
it
so
that
we
should
try
to
migrate
one
of
the
props
that
we
have
towards
zeroth
one,
or
should
we
create
some
other
reference,
implementation
that
say
a
simple
publish,
subscribe
utility
then
that
could
publish
events
and
subscribes
as
well,
maybe
through
some
ci
and
whatever
just
to
have
something
there
more
than
an
sdk.
D
E
E
E
D
E
Maybe
we
actually
discussed
that
in
the
context
of
the
sdks,
where
we
said
what
what
requirements
do
we
have
on
the
sdks?
What
did
they
need
to
contain
and
we
talked
about
if
they
need
a
cli
or
not?
I
think
so
this
might
be
in
in
that
area,
then
I'm
not
sure
if
all
sdks
well,
of
course,
it
would
be
good
if
all
sdks
had
this
possibility
to
to
showcase
themselves,
with
a
very
simple
cli
producing
and
consuming
events.
D
D
I
think,
ultimately
I
would
I
would
like
to
see
like
all
the
sdks
and
maybe
have
a
cli
repo
and
the
cli
repo
behind
the
scene.
It
would
probably
use
one
of
the
sdks,
but
then
you
could
have
the
the
cli
published
on
the
you
know,
built
for
the
different
platforms
and
distributed
on
cocoa
brew
or
whatever
beep.
Whatever
system
is
relevant.