►
From YouTube: CDEvents Working Group, 2022-07-20
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
C
B
B
B
Okay,
yeah,
let's
get
started
so
welcome
everyone
yourself
to
the
to
this
participant
list,
so
today
July
the
20th.
This
is
the
City
events
working
group
and
yeah.
The
meeting
is
recorded
so
that
you
know
so
I
added
a
few
updates
on
the
agenda
for
today.
So
let's
go
quickly
through
those
oh
hi
breath.
B
C
B
C
B
C
C
This
Library
will
be
the
main
main
goal
of
it,
but
we're
starting
with
just
one-to-one
parity
to
get
a
good
starting
point
for
it.
Yeah
work
is
going
to
continue
actively
for,
for
some
time,
at
least
so,
depending
on
exactly
what
we
set
as
the
goal
for
the
python
SDK
I
think
it
should
still
be
be
done
in
before
the
work
well
in
time
for
the
0.1
release.
C
C
Yeah
I
think
Tariq.
My
colleague
just
wanted
to
have
some
little
program
to
start
with.
He
had
some
things
he
wanted
to
to
clean
up
like
some
defense
issues
and
things
like
that,
but
I
think
once
it
works
properly,
then
I
think
we
should
definitely
go
back
to
the
and
the
CD
events
product
and
work
from
there.
C
B
Thanks
all
right
next
on
the
spinner
curves
POC,
the
pr
is
merged
on
the
second
site
and
also
they
turn
under
implemented
the
ability
to
to
use
a
variable
image,
shot
and
Spinnaker's
side.
So
it's
great
on
the
website.
I
just
wanted
to.
Let
folks
know
that
I
set
up
like
a
nightly
job
that
picks
up
this
pack,
the
latest
pack
and
publish
it
on
the
website.
So
that's
all
automatically
updated.
Now.
B
B
In
terms
of
their
formatting
work
on
the
spec
that
are
enjoying
with
the
plates
to
lower
camel
case
and
so
forth,
and
currently
working
at
the
CI
packet,
that
will
work
in
progress
bi
there
and
I
just
continue
to
go
through
the
dock,
so
this
is
mostly
look
and
feel
type
of
change,
so
I
hope
it
should
be
pretty
set
for
what,
but
in
doing
this,
I
realized
that
there
are
a
lot
of
missing
Partners
in
the
model
out
of
events
they
get
pretty
bare.
They
have
nothing
defined
in
there
and
so
yeah.
B
B
B
Okay
cool,
so
the
first
one
is
about
the
data
model
for
the
build
event,
so
that
the
reason
I
opened
this
issue,
while
I
was
looking
into
the
metrics
PLC.
So
this
is
about
producing
dollar
metrics
or
LCD
events,
and
so
what
we
need
to
do
there
is
to
be
able
to
correlate
events
from
different
stages
in
the
code
builds
deploy
process
in
the
city
process
to
extract
those
Dora
metrics
and
know
what
information
like.
B
How
often
are
we
deploying
and
how
long
it
takes
for
a
change
from
when
it's
developed
to
when
it
gets
into
production
and
and
so
forth,
and
in
trying
to
to
build
this
model?
I
realized
that
yeah,
the
the
build
event,
don't
really
contain
anything.
Apart
from
the
build
artifact
ID
right
now
and
I
was
suggesting
that
we
could
add
the
Repository
to
them
and
also
the
last
change
or
some
kind
of
ID
that
represent
what
is
the
state
of
that
repository
when
the
build
was
made
yeah.
A
So
yeah
it
feels
a
bit
strange
to
actually
have
a
repository
information
if
you
have,
if
you
all,
have
a
change
of
Entry,
have
someone
where
you
have
the
cluster
information
to
actually
have
it
that
in
the
build
of
it,
whereas
yeah.
So
that
was
the
kind
of
like
this
the
start
of
the
discussion,
but
you
had
some
some
questions
and
opinions
there.
B
C
There's
a
question
there
I
don't
remember
exactly
but
I
think
typically,
when
we
talk
about
a
change
we're
talking
about
or
we
have
two
things,
we
have
a
change
proposal
which
would
be
like
a
put
a
request
or
a
merch
request
or
a
review,
and
then
we
have
the
actual
change,
which
will
be
something
like
a
commit
or
a
set
of
commits,
getting
merged,
or
something
like
that.
We
are
not
talking
about
a
merge
request
here.
Right,
we're
talking
about
an
actual
commit
or
something
like
that
is
that
great.
C
A
C
You
know
there
could
be
some
some
verification
or
something
like
that-
absolutely
but
then
at
least
every
code
review
system
that
I
know
of
it
does
boil
down
to
there
being
some
comment
you
can
point
to,
and
that
would
be
the
in
in
GitHub
or
in
gitlab.
It
would
be
the
latest
commit
in
a
branch
I
think
and
in
Garrett
it
would
be
one
commit
but
yeah.
Yes,.
C
C
D
A
good
point,
I
I
know
that's.
We
had
this
similar
challenge
internally
and
we're
currently
capturing
the
the
the
repo
push
events
effectively,
as
well
as
the
any
of
the
key
pure
related
change
events
and
our
mechanism.
How
we're
correlating
these
together
is,
is
in
the
build,
not
necessarily
captioning
in
the
in
the
in
the
the
compilation
are
built.
That
might
happen.
It's
really
the
Clone,
the
Clone
event
that
comes
down.
C
Because,
on
a
general
in
a
general
sense,
I
think
I
I
would
say
it
makes
sense
that
if
we
are
sending
all
the
change
events
that
we
need
to
be
able
to
to
link
to
them,
then
it
might
be
better
to
link
to
those
change
events
rather
than
repeating
repository
and
what
we
want
to
call
your
last
change
or
or
something
like
that.
But
we
should
also,
of
course,
allow
for
not
having
to
chain
send
change
events,
because
you
might
want
to
start
sending
events
at
the
build
stage.
C
I
think
that
should
be
okay
as
well,
and
then
perhaps
especially
if,
if
you're
talking
about
things
like
yeah,
GitHub
or
gitlab,
or
things
like
that,
where
you
have
the
source
code
externally
to
your
own
team
or
to
your
own
organization.
But
you
do
the
builds
and
things
in
terms.
You
know
that
happens
in
world
of
course,
a
lot
that
we
have
source
code
in
GitHub,
but
it
gets
built
by
Azul
internally
in
in
world
of
course.
So
the
first
thing
that
would
happen
is
a
build
so
and
I
think.
C
Maybe
something
like
what
Andrea
proposed
is.
There
are
some
use
cases
for
that
as
well,
but
it's,
of
course,
always
tricky
like
what
what
is
mandatory
and
what
is
not
mandatory.
And
if
it's
not
mandatory,
then
the
system
that
wants
to
to
correlate
that
information
would
have
to
support
both
I
guess,
both
looking
for
a
previously
sent
change
event
or
reading
out
the
the
repository
and
commit
information
from
the
actual
build
events.
C
C
So
the
idea
I
think
for
the
mattress
perspective
is
to
be
able
to
say
what
commits
are
included
in
this
build
that
wasn't
included
in
the
other,
build
like
what
are
the
new
comments
that
are
included
in
this
build,
because
that
will
help
us
calculate
this
lead
time
for
changes.
So
so,
if
there
is
a
change
like
someone
has,
has
created
a
commits,
how
long
does
it
take
until
it's
included
in
a
build
that
is
then
eventually
deployed
or
sort
of
put
into
production?
That
is
the
metric
that
we
want
to
to
grab.
C
A
C
Need
to
go
and
ask
the
The
Source
controls
system
like
what
are
the
yeah,
for
instance,
by
doing
some
sort
of
History
diff,
like
what
other
commits
that
are
included
in
in
this
thing,
that
I'm
building
now
versus
the
last
thing
I
built.
So
it
definitely
gets
a
bit
tricky.
If
you
want
to
look
at
the
information
up
afterwards,.
C
C
A
C
To
figure
it
out,
I
would
say.
Probably
we
do
want
events,
but
what
I'm
I'm
probably
getting
at
here
is
that
I
don't
think
it
should
be
required
to
send
events
for
every
commit
to
get
this
lead
time
for
changes
working,
because
if
we
do
allow
the
build
event
to
say
here
is
what
I
have
built.
Then
we
have
enough
information
to
be
able
to
look
that
up,
not
just
by
looking
at
the
event
store.
Of
course,
you
would
have
to
go
and
contact
the
source
control
system
to
ask
additional
questions.
B
Yeah
yeah,
unfortunately,
as
you
said,
I
mean
the
the
apis
are
different.
So
that's
something
that
maybe
in
future
we
we
can
try
to
to
drive
getting
like
a
common
way
to
ask
this
question
to
different
gate
hosting
system
but
yeah
for
now,
it's
I
think
the
best
we
we
can
do
is
to
at
least
have
that
information.
B
So
that
we
don't
require
anyone
who
wants
to
implement
CD
events
to
must
have
like
a
repository
with
all
the
events
stored
in,
so
that
would
be
an
optional
feature
of
the
of
the
protocol.
So
that's
that's
the
current
status
in
my
mind,
so
I
I
when
I
think
about
fields
that
we
we
that
we
need
not
necessarily
mandatory,
but
that
we
may
need
for
building
this
POC
I
make
the
assumption
that
we
may
or
may
not
have
that
Repository.
B
A
I
guess
the
risk
of
going
down
that
route
is
that
you
will.
You
might
have
unlimited
amount
of
these
information
that
you
want
to
have
in
the
routing,
because
at
some
point
you
might
be
looking
for
well.
I
want
this
I'm,
the
only
interested
in
the
bills
on
this
branch,
which
you
can
be
detailed,
and
then
you
start
you
want
to
include
those
ones
in
the
build
funds.
A
B
Okay,
yeah
I'm,
not
saying
that
this
should
be
mandatory
and
just
saying
that
I
think
it.
It
would
be
good
to
to
have
it
covered
by
our
data
model
so
that,
if
we
want
to
send
this
information,
then
we
have
a
common
way
of
sending
it
otherwise
yeah
we
can
pretty
consume
it
in
a
standard
way.
This
information
is
provided
by
different
system
in
different
formats.
Then
it's
hard
to
consume.
A
A
Because
it
can
be
that
you
build
yeah
when
you
build
a
binary
with
other
binaries,
for
example
like
I,
guess
that
if
you're,
if
you're
building
a
languages
has
compiled
Libs-
and
you
say,
Okay
I
want
to
kind
of
like
statically
link
this
so
I,
don't
dynamically
link
it.
Then
you
will
include
this
Library,
which
the
none
is
is
a
binary
and
that
binary
might
not
be
stored
in
in
your
get
source
code.
It
might
be
stored
in
like
a
j
for
your
repository
or
something
else.
A
B
I
I
don't
think
we
are
limiting
this.
The
scope
I
mean
at
least
in
in
my
experience.
When
you
have
this
kind
of
dependencies
you
you
will
have
in
your
in
your
repository
or
you
will
document
what
is
the
list
of
your
dependencies
and
that
that
list
of
your
dependencies
with
a
version
is
versioned
along
with
your
source
code.
B
B
A
A
It
might
not
be
defined
inside
a
file,
it
might
be.
It
might
have
been
defined
as
at
in
some
other
process
that
you
you're,
saying.
Okay,
we
want
to
have.
We
have
to
talk
about
baselines
before
we
wanted
to
find
a
baseline.
So
we
have
a
tool
that
says:
Okay
I
want
to
have
these
versions
and
the
Baseline
tool
that
has
the
idea
of
what
you've
built
and
then
in
order
to
track
what
versions
are
put
together?
C
C
If
that
is
like
how
we
want
to
deal
with
that,
if
we
want
to
consider
the
action
like
when
you're
doing
you're
producing
or
transforming
source
code,
if
we
see
that
as
something
other
than
combining
already
transformed
source
code
I'm,
not
saying
they
should
be
different,
I'm
just
saying
we
need
to
take
a
decision.
I
think
whether
we
see
those
as
is
like,
it's
build
and
packaging
the
same
thing
or
are
they
different
things?
Maybe
that's
what
I
mean.
B
A
A
C
C
You
want
to
include
that
new
binary
version
in
whatever
compositions
it
should
be
part
of
to
be
be
able
to
be
tested,
and
then
we
build
a
lot
of
things
that
we
would
then
call
baselines
and
then
Baseline
can
contain
other
baselines,
etc,
etc.
So
the
path
from
an
initial
code
change
up
to
something
actually
being
considered
released,
which
would
be
what
we're
talking
about
here
early
time
for
changes.
It
does
include
multiple
steps,
typically
of
just
packing
things
together
in
more
and
more
complex
combinations
and
then
verifying
that.
C
C
But
somehow
the
way
we've
thought
about
it,
a
little
bit
is
so
we
have
a
concept
in
something
I
presented
a
long
time
ago,
where
we
say
that
when
we,
when
we
build
something
which,
in
our
our
flow,
is
called
creating
a
component
which
is
roughly
the
same
as
smart
effects,
then
we
say
that
a
components
is
created
from
things
in
different
repositories
of
different
versions.
And
then
we
don't
say
that
the
repository
version
is
necessarily
A
commit
or
even
a
source
code
management
system
like
revision.
C
It
could
also
be
like
an
inversion
index
in
some
database,
or
it
can
be
a
document
version
or
whatever,
but
something
that
has
a
version
so
that
when
we
go
look
for
it,
we
can
extract
the
exact
same
version
again.
It
could
be
a
composition
version
as
well,
so
I
think
what
Andrea
is
proposing
would
still
be
quite
generally
useful
to
say
that.
Okay,
when
we
built
this
thing,
we
went
over
here
and
got
this
version,
and
that
is
what
we
included.
C
So
that
is
what
we
have
and
then
just
say
that
the
version
doesn't
have
to
be
a
commit.
It
can
be
anything
that
is
version
handled,
because
that
I
think
is
a
reasonable
requirement.
We
can't
just
say
we
went
over
here
and
took
the
latest
thing,
because
we
don't
know
what
the
latest
thing
was
when
we
did
it.
C
We
are
connecting
it
to
not
really
to
the
buildings,
we're
connecting
it
more
to
the
artifact.
We
haven't
really
thought
about
events
that
much.
But
when
you
go
look
at
the
yeah
I
guess,
for
us,
an
artifact
is
a
file
and
a
file
can
exist
in
many
different
places,
so
a
single
component
as
we
would
call
it
and
a
multiple
artifacts.
But
if
we
talk
about
the
component,
that's
not
in
fact
like.
C
This
is
the
thing
that
was
actually
built,
and
that
is
the
thing
that
we
have
a
reference
to
multiple
repositories
and
multiple
versions
yeah.
So
it
would
be
the
the
final
result
of
the
build
step
or
the
transform
step
or
whatever
you
want
to
call
it.
I
guess
yeah
connecting
into
the
artifact,
would
be
more
more
true.
A
C
A
Yeah
now
you
have
to
stop
and
if
I'm
I'm
going
too
deep
or
if
you
don't
follow
me,
but
the
question
is:
if
you're,
if
you
want
to
in
your
metrics,
want
to
trace,
for
example,
this
is
a
deployment
here
and
I
want
to
see
what
commits
were
part
of
it.
Do
you
actually
want
to
need
to
Traverse
and
look
at
at
build
jobs?
Then?
A
A
A
A
B
A
B
B
I'm
not
sure
if
it
will
be
more
logical
or
not,
but
yeah
it's
I,
I,
yeah
I
think
I
tend
to
agree
that
what
we
need
is
information
thought
specifically
for
the
for
the
POC.
We
need
information
more
about
artifact
being
produced
rather
than
Fields
being
executed,
and
it's
probably
a
good
degree
of
overlap
between
the
builds
and
the
artifact
events,
but
I
guess
different
events
might
be
more
interesting
for
different
use
cases.
B
D
Okay,
just
just
from
my
point
of
view
here
are:
we
are
we
assuming
that
artifacts
could
be
built
outside
of
the
build
pipeline?
To
your
point.
Is
that
because,
for
me,
the
way
we'd
be
looking
at
this
is
there's
a
deep
correlation
between
the
SCM
events
to
the
to
the
Clone
events
that
are
happening
within
the
pipeline
to
tie
that
lineage,
which
would
then
be
tied
to
the
artifact
share
being
produced
in
the
pipeline
to
help
us
with
this
correlation.
D
D
No,
it's
because
I
sort
of
tend
to
agree
with
Andrea
on
this.
The
simple
use
case
at
the
end
of
the
day,
if
multiple
multiple
binaries
could
theoretically
be
built,
it
like
the
artifact
that's
been
built,
could
be
consumed
of
multiple
things
are
a
simple
thing
right,
and
if
we
it's
just
really
how
that
composition
model,
we
want
to
look
at
it.
D
I
was
like
Andrea
made
before
the
simple
use
case,
going
that
everything
would
be
coming
from
the
it's,
assuming
that
that
micro
views
in
place
that
any
artifact
would
be
tied
back
to
the
build
process
that
we
could
easily
correlate
to
the
SCM.
It's
just
it
just
that
makes
sense
to
me,
because
otherwise,
where
the
infinite
number
of
possibilities
that
gets
hard.
A
I
guess
what
me
and
Eric
talked
on
on,
lastly,
was
that
we
do
want
to
correlate
kind
of
like
clone
events,
or
maybe
the
sem
and
so
on,
but
we
we
don't
know
if
we
want
to
involve
the
actually
the
pipeline,
so
he
found
if
you're
looking
for
deployment.
Are
you
actually
interested
in
what
pipeline
this
was
running,
or
are
you
more
interested
in
what
SCM
events
or
SCM
git
commit
was
contained
to
that
one?
So
that
was
a
discussion.
D
A
Just
want
to
spend
a
couple
of
seconds
here,
so
this
is.
This
is
an
angel
image
where
we
have
the
SAS.
That's
the
source
change
and
the
seed
of
the
green
CD
is
done.
The
composition
I
talked
about.
We
don't
need
to
deal.
Rc
stands
for
artifact
trade,
it
which
is
artifact
packaged
and
then
RP
is
notified.
A
Published
here
so
I
want
to
hear
is
my
idea
that
I
want
to
be
able
to
link
the
published
events
back
to
the
source
change
without
going
through
all
the
blue
ones,
which
are
can
be
in
the
pipelines
which
can
be
test
and
so
on.
So
that's
why
I
wanted
to
have
a
quick
password-
and
that
was
my
my
reason
or
idea
behind-
maybe
not
including
this
in
the
building,
but
have
good
artificial
package
and
study.
B
B
Then
you
will
need
that
information
in
there
as
well
right.
So
it
depends
okay,
which
route
you
go
through,
but
I
mean,
and
it's
it's
fine.
It
makes
sense
to
to
have
that
information
in
in
the
artifact
as
well,
but
I
don't
see
why
it
shouldn't
be
in
the
build
event
too,
but
yeah
I,
don't
know
I
don't
want
to.
B
A
I
mean
I
I
get
your
point
from
from.
If
if
we
only
have
a
build,
that
would
be
if
the
build
of
Anton
represents
builds
but
and
then
it
might
be,
the
all
the
other
things
that
you
might
do
and
if
it's
my
own
building,
but
in
this
Anne
Maurice
PR,
will
all
the
the
steps
there
were
a
bunch
of
other
things
that
you
might
do
that
I
guess
would
be
also
maybe
build
these
Santos
build
events
we
put
on
trade
extra,
but
for
those
ones,
of
course,
so
yeah.
B
B
What
do
we
want
to
track
and
yeah
all
the
possible
composition
models
and
so
forth,
but
I
would
like
to
at
least
have
a
simple
model
to
begin
with
that
we
can
experiment
with
in
the
POC
and
then
yeah
as
we
make
the
application
that
we
use
in
the
POC
more
complex
and
made.
Maybe
yeah
depend
on
multiple
repositories
or
use
external,
more
external
dependencies
or
yeah.
We
can
build
and
this
various
we
can
adapt
the
the
model
to
to
fit
that.
A
B
A
B
A
B
B
D
B
B
B
The
advantage
of
the
binary
mode
is
especially
for
places
where
there
is
a
radio
format
like
even
in
terms
of
projects.
If
you
look
at
captain
or
tactone
or
Jenkins,
they
already
have
some
Cloud
events
with
their
own
format.
So
in
binary
mode
it
would
be
possible
to
have
the
CD
event
information
added
in
the
city
in
HTTP
headers
format
and
preserve
the
original
payload,
which
means
that,
on
the
receiving
side,
like
clients
that
do
support,
Cloud
events
will
be
able
to
benefit
from
the
cloud
event.
So
City
events,
information.
A
So
one
one
question
here
now:
Maybe
I'm
Wrong
here,
but
isn't
the
isn't
the
idea
of
using
the
cloud
events
that
you
you
don't
have
to
care
about
the
account
of
the
transport
layer
thing
because
it
struck
me
now
when
we
were
talking
about
HTTP,
but
maybe
someone
prefers
Kafka
or
amqp
yeah.
She
would
really
talk
about
each
of
those
modes
and
and
talk
about
this
in
our
respect.
A
B
Yes,
yes,
so
this
is
not
something
that
changes:
the
kind
of
data
model
of
City
events
or
anything,
but
it's
even
if
you're
agnostic
in
the
spec
agnostic
of
the
transport,
you
need.
You
still
need
to
Define
a
binding
to
that
transport
right.
So
I
think
you
still
need
to
say:
okay,
when
you're
signing
a
CD
event
on
top
of
Cloud
events.
How
do
you
do
that?
B
Because
you
actually
need
to
send
these
events,
so
you
need
to
define
those
formats
and
even
Cloud
event
supports
multiple
modes,
so
we
need
to
kind
of
Define
LCD
events
mapped
onto
those,
and
when
we
do
that,
I
mean
we
can
do
that
in
a
way.
That
is
more
useful
for
like
a
transitioning
into
City
events
and
that's
what
this
is
about.
B
Yeah,
if
I'm
trying
to
implement
CD
events
in
in
tectum,
for
instance,
where
we
try
to
use
existing
events
from
Captain
when
doing
the
the
POC
I'm
having
this
this
approach,
I
think
it's
very
much
useful
and
in
fact
it's
it's
it's.
What
the
go.
Sdk
does
right
now:
kind
of
it
stores
all
the
CD
events
and
information
as
Cloud
events,
extensions,
but
I.
B
Think
if
we
pick
it
to
formalize
that
and
have
these
two
two
options
or
I
mean
we
could
say
we
just
do
the
binary
version
of
if
you
think
that
this
structured
version
there's
no
value
in
that
I.
Think
that
in
in
my
opinion,
the
binary
version
is
a
very
time
and
it's
it's
good
for
transition.
The
the
structure
version
gives
more
flexibility
in
the
data
that
we
can
transport
and
also
it's
more
probably
more
readable
but
yeah
anyway.