►
From YouTube: CDEvents / SIG Events Vocabulary - Sept 6, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
B
B
A
A
So
we
were
just
about
to
start
and
yeah,
so
a
couple
of
things
on
the
agenda
for
today
and
if
you
have
more
things
just
let
me
know
or
add
them
to
the
agenda.
Please
yeah
so
action
item.
From
last
time,
eden
json
schema
to
the
spec.
The
pr
is
still
working
progress.
A
B
It's
fine
to
me
has
anyone
else
commented?
No,
no
one
else
has
commented
right
yeah,
but
I
guess
we
can
live
with
it
as
assassins.
B
A
A
A
Yeah
I
will
regenerate
the
schemas
as
well
and
also
yeah.
I
fixed
the
the
id
here
to
point
to
the
url
that
you
want
to
have
schema
includes
the
new
fields
in
there
and
also
it's
nice
to
see
the
jobs,
the
ci
jobs
that
brad
hadley
added
they're
working
now.
So
we
have
linter
and
unique
test
running.
B
A
I
don't
know
if
this
job
covers.
It
shows
the
coverage.
A
But
most
of
it
I
mean
I
tried
to
to
be
zero
with
a
unit
test.
B
A
A
The
code
got
the
binding
test
and
what
I'm
doing
it's
basically
got
one
test
for
each
event,
type
to
make
sure
we
cover
all
of
them,
so
starting
from
the
json
we're
starting
from
the
events.
So
that's.
B
A
Yes,
you
can,
you
can
have
test
files
for
each
go
module
but
because
most
of
the
code
for
all
these
modules
is
basically
identical.
Okay,
yeah
just
copy
paste
it.
So
I
decided
to
kind
of
aggregate
all
the
tests
in
in
a
single
go
module
for
them,
and
I'm
looking
into
options
for
maybe
generating
this
or
being
able
to
regenerate
this
automatically.
A
Okay,
because
all
these
they
have
most
most.
What
they
have
is
this
kind
of
getters
and
setters
yeah.
It
is,
and
they
all
look
identical,
and
the
only
exception
is
when
you
have
some.
Let's
take
the
pipeline.
A
B
C
A
A
B
A
B
B
A
B
C
I
think
we
made
some
notes
in
that
in
a
previous
meeting.
I
will
see
if
I
can
go
back
and
find
them.
B
A
A
We
should
probably
have
the
sdk
run
against
those
schemas
or
maybe
have
a
set
of
tests
like
end-to-end
tests
somewhere.
That
can
be
used
against
all
dst
as
the
case,
so
that
we
have
like
the
unit
test
internals
to
the
sdk,
but
also
like
a
set
of
conformance
tests
that
the
sdk
can
be
tested
against
to
make
sure
that
they
all
producing
yeah
a
content
that
is
conformed
with
the
spec
and
maybe
the
test
there
could
be
based
on
out
of
the
json
schemas
in
the
spec
or
some
example.
B
B
B
A
A
So
like
in
the
go
sdk
at
least,
I
think
it
is
hardcoded
today,
but
then
when
we
make
new
versions.
A
A
A
A
A
All
right
and
yeah
for
the
custom
data
in
the
sdk,
I
will
finish:
writing
the
tests
and
then
hopefully
that
can
be
merged
as
well.
A
Right
other
actions
we
had
for
from
last
time
I
think
subscriber
mode,
the
consideration
and
I
granted
spec.
I
did
not
have
time
to
get
to
that
this
time
yet
and
saying
for
the
next
items,
so
document
decision
about
prescriptive
events
in
the
spec
and
create
an
issue
for
the
poc
demo
implementation.
So
these
are
still
outstanding,
so
I
just
reported
them
here,
so
we
don't
forget
about
them.
A
Okay,
next
thing
I
wanted
to
bring
up
is
the
the
versioning
discussion.
I
think
we
had
some
good
discussion
on
on
this
issue.
I
know
and
just
to
summarize
it
if
and
correct
me
if
I'm
wrong.
A
A
So
in
this
example,
there
is
no
semantic
version
here,
so
that
needs
to
be
fixed,
but
we
could
have
spec
one
zero,
one
where
we
have
event
a
on
version,
one
similar
for
b
and
c
and
then
in
the
second
version
of
the
spec
event.
C
only
is
changed
and
event
d
is
added
and
we
could
use
semantic
versioning
for
the
event
version
as
well,
and
the
idea
would
be
that
if
the
event
has
a
new
field
in
a
way
it
is
backward
compatible.
A
Right,
the
last
thing
we
were
discussing
was
how
to
how
to
handle
the
the
spec
version.
While
we
are
working
on
new
version
of
the
awesome
events,
and
my
proposal
here
is
that,
okay,
if
we
we
tag
the
list,
0.1,
then
on
the
main
branch
we
could
have.
The
events
tagged
onto
0.2
work
in
progress,
for
instance,
and
then
change
that
to
0.2
once
this
fact
0.2
is
stacked
is
released
basically
and
each
event
in
the
sec.
A
In
the
version
the
spec
version
area,
they
could
have
a
list
that
lists
all
the
specification
versions
where
this
event
exists.
So
like
going
back
to
the
example
before,
for
instance,
event,
ae
in
v1
is
available
in
spec,
0,
2
and
spec
01.
So
when
we
are
building
an
event,
a
in
b1,
the
value
for
the
spec
can
be
either
0.2
or
0.1.
B
So
so
that
means
then,
that
the
json
schema
for
event
a
would
be
updated
in
0.2,
even
though
the
event
itself
is
not
changed,
it's
just
the
enum
that
is
changed
in
for
the
spec
version
right,
so
that
is
actually
a
change
in
the
event
schema.
Even
though
this
event,
the
rest
of
the
event
content,
is
not
changed
at
all.
B
Yes,
it
will
actually
change.
I
will
update
the
json
file.
There
is
some
scheme
and
maybe
the
documentation
for
the
event,
even
saying.
What's
what
specs
it's,
what
spec
versions
it's
applicable
for,
but
doesn't
that
also
make
it
a
new
version
of
the
event
itself,
of
course,
not
the
major
version,
but
maybe
we
should
just
update
it.
The
patch
part
of
it,
though,
if
we
would
have
some
antiversions
for
the
events
individually.
B
Which
one
is
to
me,
the
spec
is
more
a
collection
of
events
that
we
used
to
contain
within
some
version
of
the
spec,
but
if
the
the
events
themselves
should
know
which
spec
they
are
part
of,
then
we
need
to
yeah.
We
need
to
update
in
both
ways
you
see.
B
B
It's
quite
intriguing
or
interesting
anyway,
to
have
the
spec
version.
I
think
in
the
scheme
as
well
for
the
event,
but
it's
a
bit
hard
to
see
the
consequences
of
it
might
be
fine,
but
I
think
we
should
show
in
some
way
that
there's
a
new
patch
level
or
something
of
the
event
anyway.
A
A
Yeah
I
mean
the
alternative
would
be
to
all
again
like
yours
to
exclude
the
spec
version
from
the
event
itself.
A
The
version
of
the
spec
to
the
context
and
the
version
of
the
events
only
to
everything
which
is
not
the
to
the
subject.
Basically,
because
the
context
is
a
shared
part
and
if
the
context
change
changes,
then
we
would
need
to
to
change
all
the
event
versions,
which
also
is
fine.
It's
just
just
an
idea
came
to
me.
A
A
B
C
That
you
would
assume
that
there
can
be
multiple
artifact,
artifact
packaged
versions
inside
the
same
spec
version,
which
is
true.
I
guess
I
didn't
have
a
related
thought.
I'm
not
sure
if
this
is
a
good
idea.
It
just
feels
good
that
the
events
are
individually
versioned
with
exactly
the
same
version
number
as
the
spec
version
in
which
they
were
last
changed.
C
So
we
do
clearly
indicate
they
are
not
the
same
events,
but
we
also
clearly
indicate
which
spec
version
was
it
last
changed
in.
So
if,
if
I'm
looking
at
spec
version
0.5,
I
can
look
at
all
the
messages
and
if
all
the
messages
I
recognize
say
0.4-
and
I
know
I'm
compatible
with
0.4,
then
I
don't
have
to
worry
it's
yeah.
It's
just.
I
thought
I
had
it.
It
feels
good
somehow.
C
B
B
B
And
multiple
versions
of
the
spec
from
the
producer
and
and
consumer,
and
so
I
couldn't
really
say
that
we
have
the
perfect
solution
there
yet,
but
what
we
have
there
is
is
individually
versioned
events,
and
then
we
have
this
spec
version.
We
call
it
editions,
but
anyway
and
those
are
not
those
don't
have
a
semantic
version.
It's
just
a
consecutive
line
of
names
without
any
version
numbers
in
them
at
all.
B
So
that's
what
I
was
referring
to
just
as
grouping
events
within
a
bag
that
we
call
an
edition,
but.
A
A
So
we
would
have
this
version
as
a
free
string
and
the
event
version.
A
What
it
would
be
you
you
would
see
it
more
in
the
context
or
as
part
of
the
of
the
type,
I
think
both
have
pros
and
cons.
I
mean,
if
you
have
it
on
the
type.
A
I
think
you
can
do
the
filtering
just
using
a
single
field
if
you're
looking
for
a
specific
version,
but
on
the
on
the
other
side,
if
you
want
to
yeah
look
for
all
the
events
of
certain
type,
regardless
of
the
version,
then
you
need
to
kind
of
do
a
partial
match.
B
It
might
be
a
bit
quicker,
of
course,
to
match
full
strings
and
not
just
part
of
strings,
but
I
don't
know
I
can't
really
say
if
there
are
any
major
drawbacks
with
including
it
in
the
event
type
itself.
We
don't
even
do
it
in
eiffel,
but
that
doesn't
say
it's
not
possible
or
not
not
recommended.
I
can't
say
that.
A
B
B
C
B
C
C
My
initial
idea
would
be
that
we
have
asymmetric
sending
and
receiving
if
you
want
to
call
it
that
so.
C
For
for
users,
I
think
it's
helpful
to
be
able
to
say
cd
events
and
then
a
spec
version
and
then
some
event
type
and
then
in
the
sdk
internally
we
will
figure
out
what
event
version.
We
should
send
to
correspond
to
that
spec
version,
because
users
will
most
likely
not
want
to
worry
about
sending
a
specific
version
of
event.
But
following
a
specific
version
of
the
spec,
that
would.
B
C
One
assumption,
but
when
it
comes
in
then
the
only
thing
we
would
need
to
know
is
the
version
of
the
event
itself.
It
doesn't
matter
what
spec
version
the
sender
wanted
to
use
as
long
as
we
can
decode
it
properly,
and
for
that
we
just
need
the
event
type
itself.
We
don't
care
about
the
spec
version.
B
C
C
A
A
But
this
is
yeah,
so
this
is
from
the
it's
kind
of
the
how
the
sdk
is
implemented,
yeah
but
yeah.
I
think
it
doesn't
impact
really
format
that
we
want
to
use
then
in
the
json
yeah.
My
proposal
would
be
to
keep
for
now
the
the
context,
one
as
the
spec
version,
and
to
have
the
semantic
version
for
the
event
on
the
on
the
event
type.
A
Okay,
yeah
I'll
I'll,
make
some
pr
to
reflect
this
when
I
get
to
but
good
thanks
good
discussion
on
this.
A
Right,
I
I
have
some
small
tool
called
city
inventor
that
I
was
thinking.
Maybe
we
could
demo,
but
I
don't
know
if
there
is
any
other
urgent
or
thing
that
people
would
like
to
discuss.
First.
A
A
Looks
like
this:
okay,
apart
from
the
metadata,
there
are
some
parameters
and
the
parameters
correspond
to
what
needs
to
be
put
in
the
context
and
what
needs
to
be
put
in
the
subject,
and
then
the
status
reflects
what
happened
with
this,
so
whether
the
event
was
successfully
sent
or
not,
or
maybe
there
was
some
invalid
format
or
invalid
city
event.
A
Right
so
cd
event
itself
is
a
kubernetes
controller
that
watches
this
runs
and
when
there
is
a
new
run
submitted
in
the
cluster,
it
will
basically
look
at
the
parameters
and
send.
A
A
Victim
dashboard
here
and
here
you
can
see
the
event
that
was
sent,
and
this
is
a
service
deployed
v1
and
the
id
is
generated
time
step
is
set,
the
version
is
draft,
and
here
is
the
event
that
was
sent
so
basically
the
way
it
works.
My
cd
inventor
is
configured
to
send
this
event.
Cd,
then,
to
a
text
on
event,
listener
which
then
triggers
a
task
run
that
logs
the
event
here
so-
and
this
is
the
the
first
step-
is
there
any
question
on
this,
or
does
it
make
sense?
B
Yeah,
I
think
it
does
yeah.
So
will
the
resource
stay
there
in
the
cluster
or
is
it
just
a
one-time,
one-shot
sending
or
it's.
A
A
B
A
A
A
A
A
So
the
event
type
in
this
case
is
hard
coded,
because
I
want
to
have
a
change
merged
when
a
pr
is
merged.
The
event
data
can
be
the
original
event.
Data
from
the
web
book
thesaurus.
A
A
B
A
Yeah,
so
the
idea
is,
I
don't
know
if
you
understand
what
I
was
saying
that
if
you
could
understand,
but
basically
the
idea
is
that
you
then
can
have
a
generic
source
of
event
like
cloud
event
or
web
book
pointing
to
this
and
then
for
this
yaml.
You
can
map
it
to
a
run
and
the
run
will
send
a
cd
event
and
so
just
to
to
end
to
end
demo.
This
is
my.
A
A
A
And
then,
if
I
merge
the
pull
request
and
I
go
to
my
tekton
dashboard-
I
will
see
okay,
so
this
task
run
basically
logs
the
original
content
of
the
webhook
from
gt.
A
So
there
was
a
source
event
id
and
then
it
tells
me
similar
to
github
so
the
shop
before
the
show
after
the
details
about
the
pr,
the
owner,
the
pr
the
repository,
etc,
etc,
etc.
A
A
B
A
Possibly
yeah
I
mean
I
I'm
running
this.
I
have
got
a
cluster
and
ibm
cloud,
but
after
I'm
satisfied
with
the
overall
poc
setup,
I
will
try
to
to
check
if
it
fits
in
a
maybe
kind
or
a
mini
cube
cluster
that
you
can
run.
A
B
A
All
right,
yeah-
and
I
have
this
on
my
personal
github
for
now,
but
eventually,
if
folks
are
interested
and
I'd,
be
happy
to
to
put
it
in
the
city,
then
org,
so
it
kind
of
remains
as
a
tool
for
building
pocs.
C
B
Be
the
whole
week
there
I
will
not
be
on
the
summit,
though,
on
the
wednesday
but
thursday
friday.
I
would
be
there.
B
I'm
jealous
yeah,
I
will
be
there
first
three
days
monday,
tuesday
and
wednesday.