►
From YouTube: CDEvents Working Group (EMEA/APAC) - Jan 30, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
C
B
C
All
right
now,
let's
get
started
and
welcome
everyone
to
the
city.
We're
in
working
group
today
is
January
the
30th
already
well
2023.
C
My
name
is
Andrea
Frito
I
work
for
IBM
I'm
in
UTC,
and
please
I
have
to
treat
that
yourself.
The
participant
list
for
today's
meeting.
C
That's
briefly
action
points.
From
last
week
we
had
one
action
to
actually
properly
archive
the
seek
events
notes
which
hopefully
did
right
this
time.
C
B
C
C
Okay-
and
there
was
one
discussion
about
versioning
last
time
and
I
promised
to
create
an
issue,
possibly
a
VR,
about
documenting
better.
Why
we
took
the
decision.
We
talked
about
versioning
and
I
created
the
issue
at
least
I'm,
not
great,
with
API.
Yet.
C
Would
you
like
to
go
through
the
comments
of
the
state
of
is
any
General
update
that
you
would
like
to
provide.
D
No
I,
as
so
thank
you
so
much
for
commenting,
Andrea
and
I've,
dug
in
I
guess
for
really.
First,
this.
A
D
And
there's
I
did
there
were
some
offbeat
comments
last
week,
I
think
so.
I
think
maybe
the
biggest
most
interesting
discussion
coming
out
of
that
is
is
if
we
should
rename
the
the
subjects
to
test
case
run
and
test
Suite
run
simple
similar
to
we
have
like
pipeline
run
and
task
run
in
the
core
events
or
a
core
bucket,
because,
as
you
pointed
out,
these
events
are
really
related
to
runs
of
a
test
case
and
I.
Guess
that's
a
misunderstanding.
D
On
my
end,
sorry,
thanks
for
pointing
that
out,
I,
don't
know
if
you
have.
If
you
wanna
comment
on
that
now
or
think
about
it
to
me,
it
makes
sense
to
model
it
like
that
versus
modeling.
The
actual
test
case
or
test
Suite
subjects,
I
think
it's
more
clear
about
what
we're
actually
notifying
about
on
these
events.
D
So
I've
yeah
I've
made
that
change
I
just
haven't
I
just
didn't
have
time
to
to
push
it
because
I
think
yeah,
it's
those
Ripple
effects,
I
have
to
update
the
schema
and
all
the
links
and
blah
blah
blah.
So
it
kind
of
takes
a
little
while,
but
I
think
that
was
a
good
idea.
At
least
I.
A
I
think
it's
good
that
we
have
the
same
way
of
naming
things
that
that's
fine
I
wasn't
maybe
from
the
beginning
particularly
found
out
the
name
where
we
killed
Rand
in
the
name
but
but
I
see
the
I,
see
the
reason
to
distinguish
it
from
the
to
say
the
definition
of
an
activity
or
so
stating
that
this
is
the
actual
execution
or.
B
A
A
D
A
C
D
So
that's
fine
and
I,
also
renamed
I.
Think
we
had
this
discussion
about
result,
I
renamed
it
to
Output
test
output
last
last
week,
which
I
think
was
also
a
good
idea
to
kind
of
clarify,
and
then
there
were
some.
There
was
a
question
about
severity
versus
priority.
Bruno
was
going
to
answer
that
one
apart
from
that
yeah
I'll
make
the
corresponding
changes
and
I'll
update
the
pr
and
I'll.
D
Let
you
know,
and
then
we
can
yeah
refund,
that
there
I
guess
one
one
thing
which
was
maybe
slightly
tangential
was
when
I
wrote
the
schema.
It
seems
to
me
like
the
schemas
for
the
all
the
sub
events
are
more
or
less
the
same.
It's
it's
just
the
content,
part
which
differs
between
all
of
them
is
that
correct,
correctly
understood
and
then
the
enum
for
the
type
of
the
scheme
or
the
event,
but
then
kind
of
the
wrapping
of
of
the
actual
object
is
always
the
same.
C
Yeah
I
think
that
that's
correct,
so
the
the
subject
is
the
same:
Earth
everyone,
the
the
schema
there
so
and
a
part
of
the
con
x.
Sorry,
the
context
is
the
same
paragraphy
one
and
or
the
initial
part
of
the
subject,
as
well:
I
think
I
initial
setup,
where
we
try
and
split
out
that
common
part
and
then
reference
like
schema
with
reference.
C
C
I
I,
don't
think
it's
necessarily
too
early
I
think
it
wasn't
just
arrogant
enough
for
us
to,
but
we
have
limited
resources.
So
that's
we.
We
didn't
it
didn't
end
up
in
high
in
the
priority
enough
to
do
it
already,
but
that's
something
that
you're
keen
on
helping
out
with
for
sure
by
any
means
that.
D
With
the
hobby
weekend
kind
of
thing,
so,
okay
I
can
once
we
get
this
PR
through
the
works
and
merged
happy
to
look
as
if
that
can
be
optimized
somehow,
because
just
to
kind
of
avoid
inconsistencies,
I
guess
it's
easy
to
yeah.
B
D
Yeah
so
so
renaming
I'll
rename
the
subjects
and
then
yeah
I,
don't
know
if
you
want
to
in
detail,
go
through
the
proposal
or
if,
if
we
should
wait
until
we've
changed
it
from
a
draft
PR
to
a
real
PRN,
maybe
on
the
next
call,
I
can
walk
through
kind
of
what
we've
actually
landed
on
in
regards
to
everything.
A
I
think
if
we
have
time
we
could
take
it
now
as
well.
Maybe
we
should
leave
enough
room
for
incident
event
discussion,
because
that's
something
that
we
intend
to
put
in
the
next
release
at
least
and
test
events
might
come
there,
but
we
don't
know
that
yet
yeah,
but
so
it's
a
clear
time.
Of
course
we
can
come
back
to
the
students
in
the
end
of
this
week,
yeah
I.
C
Inside
okay,.
C
C
All
right,
thank
you
thanks
for
that,
so
we
we
have
an
agreement
at
least
that
we
we
will
go
with
the
renaming
right,
yeah.
A
D
I
think
it's
a
good
point.
I
mean
I,
obviously
missed
it
when
creating
this
proposal.
So
maybe
calling
out
that
it's
important
to
distinguish
between
the
execution
of
an
object
and
the
object
itself
and
or
the
Run
of
an
object
and
and
then
that
we
tried
to
maybe
model
the
actual
runs
as
and
then
referring
to
the
I
can
add
some
blurb
about
that
somewhere.
A
But
it's
also
a
noun.
It's
both.
D
A
C
Maybe
we
can
never
also
says
that
the
term
should
refer
to
an
execution.
C
And
in
the
case
of
build,
it
does
because
it's
a
verb
as
well.
Well,
in
the
case
of
pipeline
or
test
case,
it
would
be.
The
name
refers
to
the
study
definition,
so
we
need
to
have
an
alternative.
A
B
C
So
if
you
would
create
an
issue
ml
or
yeah,.
A
C
Right,
okay,
all
right
so
for
the.
C
So
what
I
did
in
that?
Pr
I
I
updated
the
predicate
to
be
detected
as
opposed
to
report
it
so
that
we
now
have
I.
B
C
That
back,
yes,
I,
was
getting
impressed
with
the
severity
that
we
said.
We
shouldn't.
A
Yeah,
so
so
for
all
this
information
I
think
you
weren't
there
in
the
meeting
we
we
headed
meeting
last
Tuesday
and
give
us
and
then
was
there.
So
we
discussed
this
about
the
incidents
when
something
happens
in
a
running
system.
A
C
Yep
so
question
that
would
be
or
incident
reported,
but
then
a
ticket
reference.
C
C
D
Uri
seems
more
actionable,
I
guess,
or
at
least
like.
If
someone
receives
this
event,
then
there's
a
new
ride,
that's
something
they
can
act.
I
can
click
on
it.
It's
hard,
maybe
hard
to
do
something
with
an
ID.
Apart
from.
A
Well,
I,
don't
know
if
there
are
still
ticketing
systems
which
don't
have
any
URI
possibilities.
I
mean
manual,
archives
of
some
sort,
but
I
don't
know.
If
we
should
support
that,
or
in
that
case
we
could
have
URI
as
an
optional
property
and
then
an
ID
as
another
optional.
And
then
you
would
say
that
you
would
need
either
of
those
at
least.
A
D
A
D
A
No
but
I
think
that
that's
good
actually,
but
it's
not
I
mean
if,
if
it
contains
some
sensitive
data
or
if
it's
not
accessible
by
anyone,
then
it's
it's
good
that
we
don't
include
the
actual
information
here,
but
yesterday
right,
so
that
the
only
people
that
are
assumed
to
be
able
to
read
that
information
can.
B
D
A
A
If
it's
not
as
the
same
thing,
I
mean
you
could
replace
them,
I
guess
I'm,
not
sure
if
we
need
both
I
know
that
the
in
the
the
iPhone
protocol
that
we
have
been
using
in
our
examples
and
more
time,
we
have
proposed
an
extension
that
actually
contains
alert
events
as
opposed
to
incident
events,
but
but
actually
the
documentation
about
that.
Those
events
say
is
that
this
alert
event
should
be
sent
when
there
is
an
incident.
So.
D
A
D
No,
no
I
was
just
curious,
I
mean
if
I
haven't
really
thought
it
through.
I
was
just
wondering
to
your
point
that
there's
there
seems
to
be
an
overlap
to
just
conceptually
between
an
alert
and
an
incident,
and
I
was
wondering
if
that's
something,
you've
kind
of
assessed
or
discussed
and
I
don't
have
a
strong
position
on.
C
Either
just
was
just
curious.
A
A
C
Don't
know
well,
it's
failure.
C
B
C
But
I
think
the
definition
of
incident
that
you
pointed
to
from
missed
glossary,
put
cover
that
as
well,
so
in
accordance
that
actually
are
potentially
jeopardizes
the
confidentiality,
Integrity
or
availability
of
an
information
system.
C
A
C
B
C
Still,
holders.
A
I
think
an
alert
could
be
not
necessarily
just
something
negative.
It
could
be
more
lesson.
Notification
of
something
has
happened
in
your
system.
Like
I,
don't
know
a
new
user
has
been
yeah
exactly
something
onboarded
or
something
that's
another
or
someone
has
started
using
this
service,
but
that's
not
really
the
reason.
For
this
event,
I
think
this
is
to
report
on
issues
or
problems
in
the
system
right.
D
D
And
maybe
the
the
question
of
alerting
some
separate
and
something
could
be
defined
even
have
separate
events,
I,
don't
know
which
then
could
I
don't
know.
The
relationship
then
would
be
to
incidents.
C
C
Yeah
something
we
can
consider
for
the
future,
I
think.
As
you
said,
the
middle
of
the
the
scope
you
wanted
to
cover
for
for
the
next
release
is
what
we
need
for
the
two
dollar,
metrics
and
I.
Think
corner
for
those
with
all
right.
I
will
update
the
the.
C
I
added
the
schema
for
the
two
detected
and
results
so
I
will
let
the
schema
of
the
third
one
as
well
and
yeah
and
anything
else.
Otherwise,
are
we
happy
with
the
initial
set
of
fields
that
we
have
in
the
events?
A
C
Environment
is
the
only
one
that
is
set
mandatory
or
both
events.
Yes,
because
there
could
be
an
incident
in
an
environment.
C
Yes,
it's
IDE
and
optionally
source
in
case
the
ID
is
associated
to
some
infrastructure
as
a
service
system.
C
A
But
I
think
it's
it's
fine.
We
then
we
need
we
require
more
or
less
that
they
have
previously
sent
an
environments
created
events
that
can
be
referenced
through
this
ID,
but.
C
Yes-
and
that
goes
back
to
I,
guess.
A
C
Maybe
we
will
have
to
revisit
this
once
we
have
a
decision
on
those
yeah,
so
there
is
IDs
Source
name
and
URL
in
the
environment.
Subject.
A
A
C
Think
we
have
Uris,
that's
where
so
we
are
a
bit
inconsistent,
but
I
agree.
We
should
use
your
eyes
as
opposed
to
urls.
D
A
A
C
A
A
good
answer
you
keep
in
the
top
clicking
and
talking
stable
for
this
repository.
Okay,
there's
value
yeah.
A
A
A
A
D
Think
I
did
at
least
should
have.
D
C
B
A
We
have
URL
but
no
formatting
on
it.
So
there's
you
don't
use
the
format
keyword
here.
Oh
we
didn't
so
that
should
be
part
of
the
issue
as
well
to
make
sure
that
we
verify
the
formats.
If
we
should
have
a
certain
point.
Yep.
C
D
Sorry,
you
mean
the
format.
Sorry.
A
C
B
D
C
C
Ation
of
an
application,
that's
what
it
was
meant
to
yeah,
okay,
sure,
because
yeah,
so
the
way
the
service
is
modeled,
the
service
refers
to
a
specific.
The
service
does
not
prefer
what
does.
D
C
So
if
you
just
have
the
service
ID,
you
don't
necessarily
at
which
point
in
well.
You
know
which
point
in
time,
but
you
you
would
have
to
find
out
at
that
point
in
time
which
version
of
the
artifact
that
he
was
associated
with
that
service,
which,
if,
if
you
have
all
the
whole
history,
you
might
be
able
to
do,
but
it
seemed
to
be.
C
It
seemed
to
me
to
be
useful
to
have
the
artifact
ID
there,
because
then
you
can
see,
for
instance,
if
an
update
is
done
and
you
have
a
number
of
incidents
associated
with
specific
artifact
ID,
it's
easier
to
correlate
them
and
see.
Okay,
the
specific
artifact
is
causing
a
lot
of
issues.
C
That
said,
right
now,
we
we
have
everything
everywhere.
We
use
a
single
artifact
ID,
but
there's
one
open
discussion
that
we
need
to
address
at
some
point
about
aggregations,
because
yeah
services
might
probably
be
many
cases
in
most
cases
collection
of
artifacts
rather
than
a
single
artifact.
C
C
A
Yeah,
that's
what
I
was
asking
I'm,
not
sure
and
but
I
yeah,
but
now
we
could
just
assume
it's
mandatory
was
thinking
I,
don't
really
see
what
use
cases
you
have
if
there
are
any
use
cases
where
we
might
not
have
an
idea
of
an
environment
yeah,
it
might
be
a
Unix
server
somewhere,
which
might
not
have
an
ID.
But
of
course
it
has
some
kind
of
identifier,
the
name
probably
yeah.
I
think
we
can
assume
that
it
has
some
kind
of
a
it
should
be
fine.
B
C
All
right,
we'll
still
have
about
20
minutes.
Does
it
make
sense
I
mean?
Are
we
happy
with
the
discussion
on
incidents
event
that
we
could
go
back
to
the
tests
cases
the
suits.
A
I
think
that's
why
we
I
don't
have
any
updates
on
the
connecting
events.
As
you
said,
they're
either.
What
else
do
we
have
in
the
end
of
the
agenda?
There.
B
D
Okay,
great:
how
do
we
want
to
play
this?
Can
you
open
that
yeah
PR.
D
C
Just
sorry
I'm
looking
for
the
right
one
to
display,
which
I
think
would
be
not
this
one.
If.
C
D
Sorry
so
yeah,
as
we
discussed
earlier
I,
can
rename
the
subjects
here
to
test
case
run
and
test
Suite
run.
Maybe
one
thing
I'd
be
interested
to
hear
your
thoughts
on.
If
you
go
down
and
I
see
here
that
test
case
URL
should
be
oops,
my
bad,
that
should
maybe
be
you
or
I.
If
you
go
further
down
to
the
predicates.
D
The
so
we
added
this
concept
of
a
trigger
to
to
understand
how
a
test
was
triggered
because
chests
can
be
triggered
manually.
They
can
be
run
by
a
pipeline.
It
can
be
scheduled.
You
know
in
relation
to
some
event
and
I
guess
it
would
be
I
I
wrote
you
a
trigger.type.
It
trigger.uri
as
a
representation
of
a
complex
object.
D
I
can
copy
the
model
you
had
for
environments,
so
I
guess
I,
don't
know
what
your
thoughts
are
on
that
and
then
here
also
we
added
the
concept
of
an
environment
to
understand
where
the
test
is
running
and
should
we
here
also
use
the
same
environment
object
that
you
had
in
the
incident
I'm
happy
to
obviously
reuse
that
object
definition
here.
A
Well,
one
thing
that
comes
to
mind
is
that
we
previously
had
a
test
case
queued
predicate,
which
model
says
that
this
test
case
execution
has
been
triggered
for
execution
or
acute
persecution,
which
essentially
means
it
was
triggered.
D
Well,
actually,
not
that's
kind
of
why
I
removed
it
so
so
I
and
my
understanding
of
the
previous
predicate
was
that
it
was
in
the
context
of
a
test
Suite
where
you
would,
if
you'd
launch
a
test
Suite,
which
contains
five
test
cases,
you
would
get.
D
You
know
the
first
one
would
start
if
they're
running
sequentially,
obviously,
and
then
you
would
get
queued
events
for
the
others
and.
D
A
D
D
So
I
don't
know
if
we
don't
need
to
have
a
canceled
event
or
a
so.
You
might
cue
something
and
then
predicate
that's
specific
to
unqueuing.
I,
don't
know
uncue.
A
Is
the
right
thing
I
mean
we
could
compare
it
to
Jenkins,
not
saying
that
we
should
make
it
for
Lee
Jenkins
only
compatible
or
something
like
that.
But
in
Jenkins
there
is
the
concept
of
queuing
and
it's
dequeuing
or
canceling
I.
Don't
remember
that
and
then
of
course
start
and
finish
this
when
a
business
is
being
executed,
so
I
think
it
makes
sense
to
be
able
to
to
show
that
in
events
that
something
has
been
put
into,
the
execution
queue
waiting
for
resources,
SO
waiting
for
something
so.
B
D
C
D
D
A
I'm
used
to
calling
it
canceled,
that's
what
we
do
in
Ifill
as
well.
Okay,
so
that's
fine
with
me!
I
realized
that
we
have
it
for
pipelines
today.
Don't
cancel,
wait,
don't
cancel
it,
but
very
cute,
started
and
finished,
but
we
don't
have
the
tasks
which
would
maybe
correspond
to
Jenkins
jobs,
for
example,
which.
B
D
B
B
D
D
I'm
happy
to
had
canceled
as
well,
if
you
I
mean,
while
we're
at
it,
because
so
so
the
reason
because
since
I
understood
it
being
in
the
context
of
a
test,
Suite,
that's
pretty
common
that
they
are
canceled,
because
the
predicate
might
be
or
the
be
that
you
know
all
tests.
Cases
previously
should
succeed,
and
if
one
of
them
fails,
you
don't
run
the
rest
of
the
tests.
So
so.
C
D
There
you
would
definitely
cancel
any
outstanding
queued
test
cases,
so
I'm
happy
to
cancel
if
you,
unless
you
want
to
have
a
more
separate
discussion
about
how
do
we
cancel
across
all
our
buckets
and
then
add
that
consistently
across
them.
A
Yeah
I'm,
not
sure
Andrea.
How
is
it
done?
We
text
them,
for
example,
in
pipeline
runs
the.
Is
there
a
queued
predicate
in
tecton,
or
is
it
some
that
is
that
known
to
take
them
that
something
is
skewed
in
a
pipeline.
A
C
Yes,
yes,
so
you
create
the
resource
the
way
you
you
run
things
in,
in
fact,
on
your
creator
resource
in
that
CD
and
that's
basically
the
queuing
and
then,
when
the
controller
picks
it
up,
it's
taking
off
the
queue
and
executing
it
and
you
can
cancel
it.
Yes,
you
can
have
a
user
requested
cancellation,
so
you
can
say
that
the
resource
should
be
canceled.
C
Yeah
absolutely
I
mean
we
could
definitely
have
that.
B
B
C
It's
it's
a
subtle
line,
how
certain
things
you
want
to
model
them
as
different
predicates
or
as
different
states
of
a
single
predicate.
You
have
several
possible
outcomes,
so
you
can
have
like
a
pipeline
which
is
timing
out.
You
can
have
a
pipeline,
for
instance,
that
fails
because
yeah
it
was
it
wasn't
successful.
Simply
it
you
write
the
completion
where
it
wasn't
successful.
C
A
Running
test
case
or
a
running
pipeline
is
canceled
by
user
interaction.
I
would
say
it's
more
or
less
more
aborted
at
that
I
mean
it's
still.
The
python
is
finished
in
the
sense
that
it
doesn't
run
anymore
and
the
result
that
could
be
included
in
the
finished
event
would
be
well.
It
didn't
result
in
a
successful
execution,
but
it
was
aborted
by
user
it
or
create
interaction
or
or
some
time
out
or
something
else.
It
was
still
finished
since
it
is
not
running
anymore.
A
A
So
those
are
like
both
Q
is
queued
and
started
are
two
different
kind
of
starting
events
and
the
well.
The
cute
event
doesn't
necessarily
need
to
have
a
finished
event
since
when
you
start
something,
then
then
it's
obviously
not
secured
anymore
right,
because
they
can't
stay
because
it's
somehow
in
the
transition
when
it's
skewed.
D
D
Although
you
could
cancel
a
running
test
case
just
for
the
sake.
C
D
A
D
C
B
B
D
Saying
that
a
canceled
event
could
be
Trigger
or
notified
or
published
even
after
it
has
started
running
to
your
point.
A
B
D
A
C
D
So
that
well,
it
has
passed,
fail.
Abort
error,
this
point
post
your
comment,
Andrea,
which
I
haven't
once
again
pushed
yet
because
you
suggested
to
add
an
error
States
here
as
well
or
value
yeah.
D
Yeah,
the
other
question
was
around
trigger
I,
guess
or
we're
almost
out
of
time.
Do
you
have
any
spontaneous
comment
to
that?
It's
something
that
at
least
from
our
point
of
view,
made
sense,
I'm,
just
curious,
I.
C
C
D
C
D
A
D
C
C
The
event
type
how
that
works.
To
be
honest,
that's
how
okay.
D
So
I'll
change
that
to
zero
one.
Zero
draft
and
I'll
add
a
note
about
that.
These
events
kind
of
supersede
the
old.
D
C
C
Okay,
this
cube,
is
it,
do
you
use,
go
like
yes
right.
C
D
Could
be
honest,
like
I,
think
that's
honest,
then,
to
maybe
do
that.