►
From YouTube: SIG Events Meeting - Feb 8, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
B
B
A
All
right,
sorry
about
the
delay
I'll
check
with
the
schedule
if
there
is
any
conflicts
for
the
future
yeah.
So
today
is
february.
The
eighth
welcome
to
the
working
group
for
the
cadbury
working
group
for
the
seek
events
feel
free
to
sign
yourself
in
in
the
participant
list
just
to
be
chat.
The
link
to
the
agenda
case.
A
A
Okay,
just
a
few
announcements
I
wanted
to
do
the
beginning
with,
as
you
probably
know,
we
have
a
website
now
which
looks
like
this
yeah.
It's
pretty
simple
right
now,
but
we
have
the
documentation
as
well
from
our
spec
website
imported
in.
A
I'll
just
continue
try
to
go
quickly
through
the
announcement
so
that,
if
there
is
any
question,
feel
free
to
stop
me
at
any
time.
I
just
wanted
to
remind
everyone.
We
do
have
a
mailing
list.
I
made
it
open
to
for
everyone
to
join.
I
think
right
now.
It's
last
time
I
checked
was
just
me
and
I
know
on
it.
A
I
think
it's
good
to
have
a
synchronous
channel
for
communication
on
the
project
as
well.
So
if
you're
interested,
please
join
the
meeting
list
and
also
we
have,
as
you
see
it's
like
channel
cd
events
on
the
city
foundation,.
A
A
Yeah
thanks
so
for
issues
specific
to
the
city
events
project.
A
A
I
wanted
to
remind
folks
about
the
contributor
summit
at
city
con.
I
created
a
google
form
to
get
an
idea
of
how
many
would
be
able
to
interested
in
joining
either
in
person
or
remotely
encoding
ideas
for
what
we're
going
to
discuss
about
so
that
we
can
plan
for
it.
So
please
fill
in
the
form-
and
also
last
thing
I
wanted
to
mention-
is
the
planning
project
for
the
v01
of
the
spec
and
it's
a
github
project
I
set
up.
A
C
C
A
All
right
next,
I
had
a
list
of
issues
that
we
could
discuss
about.
Those
discussion
can
take
maybe
some
time.
So
if
there
is
anything
else,
anyone
feels
that
we
should
discuss
first
feel
free
to
bring
it
up.
A
A
So,
basically,
there
is
some
vocabulary
work
going
on
in
the
interoperability.
I
think
that
makes
sense
to
do
some
alignment.
I
think
this
goes
back
to
yeah
staying
in
sync
with
the
work
of
the
interval
ability.
A
D
I
can
yeah
so
this
was
presented
in
a
second
drop
meeting.
It
led
to
quite
a
few
discussions.
I'm
not
sure.
Maybe
I'm
not
sure
who
might
remember
that,
but
I
didn't
understand
quite
if
if
anne-marie
would
come
up
with
an
updated
proposal
or
if
she
was
just
like
happy
with
the
current
version,
I
don't
know
what
this
takeaway
was
there
just
so
we
don't
apply
unfinished
version
so
to
say.
C
I
was
part
of
the
the
meeting
where
she
presented
the
first
time.
I
think
it
was
brought
up
last
week
on
sega
drop
as
well,
and
then
I
was
not
there,
but
my
assumption
was
that
this
is
still
a
living
pr
and
shouldn't
be
considered
the
final
version.
Still
there
are
some
outstanding
comments.
I
believe-
and
I
also
have
some
comments
that
I
haven't
really
added
yet
so
I
should,
I
guess.
E
Gonna
say
I
that's
all
right.
That's
right!
That's
what
I
agree
with
the
issues
are
so
outstanding
and
still
under
discussion.
Last
interoperability,
sig
meeting
this
was
brought
up,
but
anne-marie
wasn't
there.
So
the
discussion
didn't
advance
much
further.
Okay,.
C
Yeah
there
is
a
parallel
pull
request
as
well
on
the
pipeline
stages.
This
is
about
pipeline
steps,
so
I'm
not
sure
which
is
most
relevant
to
us.
Maybe
this
with
steps
is
more
of
yeah
this.
This
is
bill
step
at
a
step
or
whatever,
and
the
stages
are
a
bit
more,
maybe
higher
level,
but
still
the
stages
as
well.
I
would
say,
need
to
be
notified
through
events
or
need
to
be,
but
they
they
should
benefit
from
being
notified
with
three
events
as
well,
so
they
should
also
probably
have
specific
events
for
them.
B
A
Great
yeah,
thanks
for
the
additional
context
yeah,
I
agree.
I
think
we
should
look
into
both,
but
it
sounds
like
I
mean
the
the
work
we
can
do
on
these
right
now
is
maybe
joining
the
sick,
interpretability
and
continuing
to
collaborate
on
the
discussion
there,
but
we
should
wait
for
before
implementing
these
intercity
events.
A
Yeah,
I
don't
know
if
anyone
had
to
look.
This
is
a
comment
from
eric
yeah.
I
I
would
like
to
start
moving
forward
on
this,
adding
some
documentation
in
the
cloud
events
finding
and
possibly
working
with
the
sdk
team
on
getting
this
implemented
into
the
sdk,
but
I
wanted
to
get
a
feeling
if
we
had
an
agreement
or
if
there
was
any
any
concern
about
this.
A
Well,
the
idea
is
that
for
ocd
events,
we
have
a
related
activity
or
an
entity
like
a
task
run
or
an
artifact,
or
something
against
which
the
to
which
the
event
is
related,
and
so
the
idea
is
to
use
the
subject.
That
is,
an
existing
field
in
cloud
events
to
transport,
the
id
for
this
entity.
C
So
so
is
that
more
to
state
the
context
of
in
which
this
this,
which
is
this
event,
happened
or
then
or
is?
Could
you
give
an
example
otherwise
of
what
the
subject
is
really.
A
No
well,
it
depends
on
the
event.
So
if
the
event
is
about
the
pipeline
running
started,
it
would
be
the
idea
of
that
pipeline
run
right
and
that's
would
not
be
then
reused.
In
other
events,
except
when
the
same
pipeline
has
been
be
finished,
and
then
you
would
have
the
same
subject
there
or.
A
So
the
id
in
the
line
below
would
be
an
id
which
is
specific,
is
unique
to
this
event,
specifically,
while.
A
Is
something
that
could
be
reused
across
events
if
you
have
multiple
events
associated
to
that
specific
subject
in
this
case,
it's
about
fast
run,
so
you
would
have
task.
One
started
and
task
run
finished,
probably
sharing
the
same,
the
same
subject
but
having
different.
D
C
A
A
Events,
for
instance,
if
I
want
to
look
for
all
the
events
for
a
specific
subject,
maybe
I
get
an
initial
event
on
the
subject
and
I
want
to
follow
the
continue
filtering
all
the
other
events.
I
can
use
to
do
that
using
using
the
subject,
but
then
we
can
have
the
same
event.
You
can
have
the
same
information
again
within
the
data
part
and
in
that
we
can
have
json
schema
and
we
can
use
the
name
that
we
prefer
so
in
the
example.
A
Yes,
that's
my
understanding.
Let
me
bring
up
the
blood
event.
A
So
in
this
case,
if
the
source-
let's
say
the
source
of
the
event,
is
stacked
on,
you
could
have
sub
entities
within
that
source
like
different
pipeline
runs
and
different
task
runs.
That's
at
least
how
how
I
read
it.
A
Like
in
this
case,
there
is
a
source
which
is
a
certain
container,
and
the
subject
is
the
name
of
the
file
image
file.
C
Just
thinking
about
the
name
there,
I
would
tend
to
interpret
it
as
if
we,
for
example,
would
have
a
test
step
in
our
pipeline.
Then
the
subject
would
maybe
be
the
the
artifact
under
test
for
the
item
on
the
test.
That
sounds
more
like
a
subject
to
me,
but
that
maybe
that's
not
how
cloud
events
would
express
it.
A
I
would
agree
for
events
specific
to
test,
so,
if
you're
sending
an
event
that
the
test
is
started,
I
think
the
subject
there
would
be
something
specific
to
what
is
tested
for
the
core
type
of
event.
In
the
example
there
it
was,
there
was
a
task
run
and
from
a
task
run
perspective.
A
It
doesn't
know
about
what
is
going
on
within
the
task
or
it
doesn't
know
whether
the
tascam
is
running
a
test
or
a
build
or
whatever.
So
for
those
kind
of
events,
I
think
this
subject
being
the
id
of
the
task
run
or
pipeline
run
or
step
would
be
appropriate,
but
I
definitely
agree
that
if
the
event
was
about
a
higher
level,
abstraction
type
of
event
like
we
have
in
this
icd
market,
we
would
have
and
the
ide
of
the.
C
I
think,
that's
all
that
this
is
optional
in
in
cloud
events,
and
I
don't
know,
should
we
we
could,
at
least
in
the
beginning,
make
this
optional
also
in
in
our
silly
lens
spec,
but
we
should,
of
course,
if
it
should
be
used,
it's
a
bit
by
used
in
a
certain
way,
so
we
should
say
how
it
should
be
used
if
we
could
use
it,
I'm
not
sure,
or
do
we
want
this
to
be
mandatory
in
the
city
events
protocol?
C
A
I
think,
from
a
purity
event
point
of
view:
it's
part
of
the
mandatory
bits
on
cd
event
site,
and
so
since
we
have
that
information,
we
could
always
map
it
onto
the
subject
when
we
are
transporting
over
cloud
events,
but
we
don't
have
to
so.
We
could,
if,
let's
say
in
the
sdk
we
could
have
a
flag
will
say,
do
not
set
the
subject.
C
I
think
if
we
would
make
this
a
mandatory
field,
then
I
guess
that
it
would
be
mandatory
in
the
data
part
of
the
event,
since
we
cannot
really
affect
how
it's
done
on
cloud
event
level.
But
we
should
maybe
then
provide
some
guidance
on
how
what
it
should
be
set
to,
depending
on
what
kind
of
step
we
are
working
in
or
whatever
what
kind
of
event
is
sent.
A
Yes,
absolutely,
and
my
idea
would
be
that
we
do
that
for
the
sdk,
because
I
would
expect,
then
it's
kind
of
the
what
people
would
use
to
create
events
so
like.
A
The
subject
so
from
cloud
events
by
this
sorry
from
cd
event,
point
of
view
python.
My
id
is
a
mandatory
field
and
then
it
will
be
as
part
of
the
part
of
the
body,
but
we
can
map
it
onto
the
subject
as
well
and
we
could
say
we
can
leave
it
optional
to
market
on
the
subject
or
not,
I
agree
with
you,
it
doesn't
have
to
be
mandatory
and
we
could,
if
you
think
it's
required,
we
could
set
an
option.
A
C
No,
I
mean
if,
if
we
will
have
it
mandatory
in
the
data
body
or
our
city
event,
of
course,
we
can
say
that
it's
if
you
are
sending
a
cd
events
event,
it
should
also
be
in
the
top
level,
the
cloud
event
heading
level
for
sure
and
our
sdks
should
then
enforce
that
I
mean
there's.
No,
I
don't
see
a
big
reason
to
not
set
it
on
the
top
level
if
we
have
it
mandatory
on
the
data
level
and
we
intend
it
to
be
copied
between
or
duplicate
it.
C
B
C
A
C
C
A
I
I
don't
think
we
should
set
any
requirement
unique
uniqueness,
uniqueness
requirement
on
the
protocol,
but
we
should
say
that
when
set,
it
should
be
used
consistently
to
represent
a
resource,
but
that's
kind
of
up
to
them
to
the
source.
Really.
A
So
I
was
thinking
we
have
this
general
kind
of
context
section
for
the
protocol,
which
is
independent
of
the
events,
and
today
we
have
require
metadata
and
we
have
the
event
type
id
source
and
time
step.
So
we
don't
have
a
subject
here,
so
we
could
also
add
no
optional
metadata
for
city
events
and
try
to.
E
E
A
A
Yeah
I
I
came
to
do
this
issue
by
thinking
about
how
to
write
the
cloud
event
minding
trying
to
find
a
good
way
to
to
set
the
headings
there,
and
I
guess
the
subject.
Is
there
the
first
one
I
made
sense
for
me
to
to
discuss
but
yeah?
Definitely
I
think
it
would
make
sense
to
to
look
at
the
other
optional
fields
as
well.
A
So
right
we
have
the
data
content,
type
and
data
schema,
or
you
know
it's
not
sure,
and
this
is
something
that
we
would
probably
set
based
on
the
discussion
that
we
had
in
the
past
of
having
a
schema.
A
A
I
don't
know
emil,
do
you
want
to
maybe
add
your
comments
to
the
issue,
or
are
you
happy
for
me
to.
C
C
C
Sent
to
a
published
event
right.
C
But
because
in
eiffel
how
we
do
it
there,
we
don't
have
this
general
subject
in
this
way.
We
always
use
the
event
by
these
themselves
as
this
way
to
this
way
to
group
things
together
that
belong
to
the
same
pipeline,
step
or
whatever,
but
I
I
I
wouldn't
say
that
I
dislike
the
idea
of
having
a
subject
as
well,
but
maybe
that's
why
I
also
actually
this
should
maybe
be
optional
because
there
might
be
in
depending
on
the
your
use
case.
C
It
might
be
other
ways
to
that,
make
that
are
superior
to
using
a
subject
like
this,
but
I
wouldn't
say
now
that
it's
the
definitive
it's
definitely
so
that
there
is
a
superior
way.
So
let's
have
it
there
at
least-
and
maybe
one
suggestion
for
me
for
me-
would
be
that
we
could
have
it
optional
still,
even
in
the
in
the
city.
Events
part
before
we,
we
know
that
it's
the
way
to
go
for
this
kind
of
grouping,
but
I
I
guess
that
would
make
it
at
least
backwards
compatible.
C
C
A
A
Good
then,
I
would
move
to
the
next
one
since
you
were
mentioning.
I
know
the
discussion
about
produce
events
to
consumer
defense.
A
Yeah,
so
the
idea
on
this
one
is
so
I'll.
Read
the
future
description.
The
city
event
specifications
should
allow
propagating
identifiers
from
consumed
events
into
produce
events
when
activity
is
directly
started
as
a
consequence
of
a
consumed
event,
and
then
an
identifier
of
the
consumed
event
must
be
included
in
the
produced
event
related
to
the
activity.
A
Right,
I
don't
know
it's,
it
sounds.
Maybe
ml,
like
you,
had
some
thoughts
on
this
specific.
C
This
issue
are
the
events
that
cause
another
event
to
happen,
and
we,
for
that
reason
in
united,
will
call
those
references
course
links.
So
we
we
say
that
in
the
to
the
left,
you
see,
for
example,
that
activity
triggered
this
sorry.
The
what's
called
a
ctt,
which
is
activity
trigger
event,
has
a
course
link
to
the
sts,
which
is
the
solar
shade
submitted,
and
that
means
that
the
activity
which
probably
is
a
pipeline
being
started,
was
caused
by
some
commit
being
emerged
in
the
cm
system.
C
So
that's
the
the
the
produced
event
then
was
the
the
s
the
source
change
event
there
and
the
the
new
event
from
this
was
an
activity
event
and
then,
as
you
see,
there
are
a
lot
of
other
arrows
here
with
other
names
on
them
and
also
then
other
link
types
in
iphone.
C
You
can
reference
multiple
other
events
with
different
types,
so
it
doesn't
need
to
be
the
course
of
an
event,
so
say,
for
example,
that
we
have
sent
an
event
for
an
artifact
being
created
or
yeah
or
published,
and
then
in
some
later
test
step
we
might
test
that
artifact.
C
It
doesn't
mean
that
the
test
step
itself
was
triggered
by
the
artifact
being
created.
It
could
have
been
triggered
manually
somehow,
but
still
we
would
like
to
reference
or
link
to
that
created
artifact
event,
so
we
can
build
this
complete
graph
of
events.
So
in
that
case
it's
not
a
course
link
to
the
artifact.
It's
instead
a
an
element
link.
We
can
see
in
this
picture,
for
example-
and
there
are
also
subject
links,
so
there
are
different
kinds
of
links
for
different
purposes
here.
C
So,
in
your
suggestion,
andrea,
I
think
you
had
a
serialization
proposal
on
how
this
can
be
added
to
the
event,
and
I
would
then
like
to
expand
that
proposal
with
making
it
possible
as
well
to
have
a
kind
of
link
type
within
that
string
as
well,
and
that
is
possible
and
to
reference.
Multiple
events,
that's
upstream
events,
so
to
say.
E
E
Is
it?
Is
it
just
a
one
to
one
so
the
one
link
between
two
events
or
is
it.
C
E
C
That
can
be
multiple
links,
so
so
it's
it's
not
just
to
visualize
how
things
have
executed
in
what
order
and
what's
caused
what
so
to
say,
but
you
can
trace
yeah
any
event.
Any
activity
in
your
cdi
cd
pipeline,
not
just
the
actual
causal
relationships,
but
also
other
kinds
of
relationships
between
items
in
your
pipeline,
which
all
are
represented
by
events.
A
Okay,
but
you
still
need
to
have
hold
all
the
events
and
right
so,
let's
say
starting
from
the
far
from
the
right:
the
art
v
circle.
A
C
Yeah
yeah
so
for
traceability
reasons
I
mean
or
for
to
when,
when
you
are,
if
you
are
the
this
pipeline
step
for
the
process
that
sends
that
artifact
published
event
to
the
far
right,
you
probably
know
what
artifact
you
are
publishing,
so
you
probably
have
some
identifier
of
your
artifact
created
that
you
can
provide
a
link
to,
but
you
might
not
know
in
what
pipeline
step
that
artifact
was
created
or
through
what
composition
or
baseline
it
was
built.
So
to
say,
so.
C
You
can't
really
directly
link
to
even
earlier
events,
but
through
this
chain
of
event
links.
We
could
trace
back
to
everything
that
has
happened
earlier
in
the
same
pipeline
or
even
in
other
pipelines
as
long
as
they
are.
There
are
relationships
between
these
events,
so
we
can
even
reference
things
that
has
happened
in
other
pipelines
and
in
in
upstream
projects
and
and
or
less
whatever,
as
long
as
they
are
notified
through
the
series
and
stuff.
A
C
I
mean,
of
course,
you
cannot
reference
anything
else
than
what
you
have
access
to.
You
need
to
have
some
kind
of
way
to
identify
you.
You
could
either
have
direct
event
ids,
which
you
could
then
use
as
reference
links,
but
you
could
also,
for
example,
have
an
some
kind
of
artifact
identifier
or
some
kind
of
what
else
should
I
take
as
an
example,
some
kind
of
baseline
identifier
or
whatever,
which
you
can
use
to
make
a
lookup
in
some
event,
database
that
has.
C
Stored
events
being
sent-
and
you
can
ask
that
database-
hey
do
you
know
if
there
is
an
event
matching
this
artifact,
because
I
would
like
to
reference
that
from
my
event
and
then
the
database
could
ask
to
could
answer
yeah.
I
know
someone,
someone
sent
me
an
an
artifact
created
event
with
this
id,
so
this
is
probably
the
one
you
should
refer
to
and
then
those
things
can
be
created
already
there
as
well.
So
we
don't
make
the
we
don't
need
to
perform
all
those
book
gaps
on
the
consumer.
C
A
So
if,
as
part
of
our
protocol,
we
define
certain
number
of
objects,
let's
say
we
define
artifacts
defined
test,
suits,
we
define
environments
and
so
forth,
and
all
these
objects.
So
to
say
they
have
a
certain
number
of
fields.
A
Could
we
say,
then
that
when
I'm
sending
an
event
I
could
provide,
I
should
provide
all
the
context
available
for
that
event,
which
might
include
objects
that
are
not
specific
to
the
event.
So,
if
I'm
sending
an
object
about
an
environment
created-
and
I
can,
I
will
provide
the
fields
for
the
environment,
but
I
could
add
an
extra
context
with
other
objects
that
are
related
to
what
I'm
doing,
and
so
this
would
allow
to
create
the
links
right.
C
Yes,
so
so
in
an
example
with
an
environment,
for
example,
there
you
probably
have
some
kind
of
at
least
in
the
in
the
container
space.
You
have
probably
some
docker
image
reference
that
you
want
to
say.
My
environment
is
built
up
of
this
image,
for
example,
but
I
was,
I
created
this
environment
not
triggered
by
that
image
being
built,
but
rather
by
something
else
happened
in
the
pipeline.
Someone
said
I
should
start
test
activities
so
therefore
I
create
an
environment
for
it.
C
So
the
course
the
relationship
would
then
be
to
that
test
activity
being
started
somehow,
but
in
your
environment
itself,
you
could
have
a
reference
to
that
docker
image
being
built,
which
in
itself
then
could
of
course
be
in
that
image
could
be
an
artifact
from
another
pipeline.
Maybe
that
pipeline
could
have
run
several
weeks
ago
in
some
other
project
whatever,
but
still
you
can
reference
this
through
an
event
link,
and
I
think,
that's
quite
powerful
to
have
that
possibility.
C
D
D
C
Yeah,
that's
a
good
point
yeah,
but
also
it's
very
interesting
to
to
know
to
be
able
to
understand
what
upstream
projects
are
included
in
in
this
field
that
I'm
performing
right
now,
for
example,
to
identify
vulnerabilities
in
the
project
or
whatever.
A
Yeah,
I
think
it
makes
more
sense
to
me.
I
understand
better
and
I
think
there
is
a
lot
of
value
I
totally
agree,
so
I
can
try
and
give
it
a
go
again
to
inspect
some
of
this
out
and
then
maybe
we
can
have
further
discussion
on
it.
A
All
right,
yeah
we're
almost
at
time
there
are
seven
minutes
left.
There
is
one
more
issue
that
we
could
discuss,
or
there
is
some
discussion
that
we
could
have
on
the
sdks
or
boots
of
proof
of
concepts
updates
from
the
projects.
Anyone
has
anything
that
I
would
like
to
bring
up.
That
is
more
time
critical
for
the
last
few
minutes,.
D
I
I
guess
when
it
comes
to
the
sdk,
I
think
well
or
I
hope
I
have
a
very
simple
question:
does
anyone
have
any
strong
opinions
on
what
like
project
management
or
dependency
management
solution
we
use
for
the
python
sdk?
So
I
know
there
is
something
called
poetry.
I've
tried
to
like
it,
but
I
still
don't
setup
tools
would
be
my
favorite
it's
old,
but
works
really
well,
but
does
anyone
have
any
strong
opinions
on
it.
D
A
D
A
A
Good
for
the
sdk
still
one
question
that
I
had
in
my
mind
was:
do
we
need
any
kind
of
dedicated
work
stream
for
that
or
any
place
for
people
working
on
the
different
sdks
to
to
sync,
or
or
maybe
not-
I
mean
they're,
there's
going
they're
going
to
be
fairly
independent,
anyways,
but.
B
A
Okay,
then,
just
quickly,
maybe
just
wanted
to
mention
this-
this
issue,
it's
about
the
cd
service
published
event
proposed
by
mauricio
as
part
of
the
canadian
plc.
A
So
I
left
a
comment
there.
I
think
the
new
event
makes
sense,
but
there
is
also
a
possibility
of
having
fewer
events
and
maybe
having
extra
nuances
for
the
event
in
the
extra
field
just
wanted
to
know
what
people
thought
about
it.
A
It
will
be
great,
I
don't
want
to
hold
the
work
that
mauricio
is
doing
on
this,
but
so
maybe
we
can
comment
on
the
issue
and
discuss
it
further
on
slack,
if
needed,.
A
All
right
about
the
pocs,
there
is
an
issue
on
sick
events
that
mauricio
created.
So
if
you're
interested
in
understanding
what
is
going
on
with
the
canadian
plc,
please
have
a
look
in
there
and
for
the
matrix
poc.
So
we,
the
kind
of
the
idea
that
we
use
eric
for
our
submission
to
kubecon
and
to
use
cd
events
to
collect
metrics
across
multiple
platforms.
A
A
So
on
production
side
we
are
working
with
vpaf.
We
are
resuming
work
on
the
experimental
controller,
so
we
set
up
a
roadmap
to
the
project
and
the
plan
we're
setting
up
a
plan
on
how
to
move
the
controller
out
of
experimentals
into
being
a
official
component
of
tecton,
which
would
be
great
because
then
we
would
have
official
support
for
city
events
in
tecton
and
it
would
be
really
nice
place
to
be
yeah.
I
don't
know
if
there
is
any
other
update.
I
think
we
are
at
time
now.