►
From YouTube: CDEvents Working Group (EMEA/APAC) - April 24, 2023
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
Yeah,
it
was
nice.
Thank
you
so
over
here
we
had
at
least
Sunshine,
like
until
one
or
two
pm
yesterday,
yeah
yeah
yesterday
and
Saturday.
The
rest
of
the
day
was
raining
but
like
yesterday
afternoon,
when
we
went
to
a
museum,
so
we
we
could
like
walk
around
in
the
mornings
and
stay
more
indoors
in
the
in
the
afternoon.
But
it
was
nice.
Nice.
D
B
C
B
B
Enzoil
Museum,
it
was
a
bit
too
too
crowded,
but
okay,
still,
okay.
He
could
play
with
a
lot
of
things
and
right.
C
Hey
should
we
expect
someone
else
I
guess
we
can
get
started,
I
thought
that
only
had
made
some
comments
and
Ben
as
well.
Maybe
it
was
initiated
by
then
yeah
on
the
testing
events.
Have
you
seen
that.
B
Yes,
but
I've
not
read
yet
no.
B
Starting
on
test
events
yeah,
the
reason
it
wasn't
merged
is
that,
even
though
we
approved
it,
it
requires
signing
yeah
and
so
in
order
to
kind
of
do
the
rebates
and
squash
to
to
sign
the
commits,
but
I
think
is
still
working
on
that,
because.
B
D
A
B
B
I
mean
if
we
see
that
some
point,
the
the
link,
all
the
connecting
events
capability
is
able
to
provide
enough
information
to
remove
the
trigger
we
can
remove
it,
but
I
think
we
could
start
with
it
and
yeah
makes
sense,
because
this
is
ready
to
go
and
we
could
implement
it
now
and
the
connecting
event
is
with
a
loss
yet
yeah
when
it's
happening.
D
C
About
the
next
one
we
actually
did.
They
discussed
that
already
in
the
pull
request.
I
had
a
similar
comment
about
the
the
strings
there.
If
it
should
be
to
be
an
enum.
That
was
my
comment
if
it
should
be
a
free
text
string
instead,
but
because
there
will
always
be
cases
where
maybe
two
of
these
are
okay
or
none
of
them.
But
then
we.
C
Other
value
there
so
so
I
think
the
the
option
would
be
to
let
go
of
the
enum
to
make
it
a
free
text
string
instead,
but
I
think
I
agree
with
all
the
hair
that
we
we
can
keep
it
for
now
and
then
see
how
it
can
be
used
when
it's
in
the
platform.
C
C
That
don't
see
the
that
one
of
these
fit
really
so,
but
then
it's
it's
fine
to
just
use
the
other
or
skip
the
field
completely.
B
I
was
just
thinking
again
whether
we
should
have
the
other
option
or
not
whatever
other
is
more
valuable
than
not
specifying
the
type.
B
D
B
C
A
C
Paragraph
there
is
I
think
it's
an
important
one
from
Muller
but
and
I
agree.
It's
not
I
wouldn't
say
that
Jenkins
itself
will
send
the
the
test
events
that
would
be
from
the
the
test
framework
and
and
if,
of
course,
if
the
tests
are
performed
as
like,
you
know,
bash
scripts
or
something
else
within
the
Jenkins
Dash
job,
then
of
course
it
can
be
sent
from
within
Jenkins,
but
but
not
by
the
Jenkins
engine
itself.
C
C
Hits
the
the
process
that
actually
performs
the
tests
or
the
bills
or
something
else
that
should
send
these.
These
events
that,
just
as
older
sister
and
not
Jenkins
itself,
then
noise
tests,
Suite
related
events
is
a
something
that
Yankees
would
know
about
either.
B
B
Yeah
I
I
agree,
I
mean
you,
you
could
have
some
Jenkins
plugin.
That
is
aware
about
tests
and
some
more
test
specific
functionality.
But
then
it
would
be
the
plugin
that
manages
these
events
yeah,
but
not
not
changing
score.
I
mean
Yankees
score
is,
as
you
said,
is
managing
more
like
Department,
orchestration
thing,
side
of
things
or
even
the
the
build
orchestration
I
should
say:
I
guess
the
pipeline
functionalities
is
in
a
plugin
as
well,
but
I
think
but
yeah.
So
I.
C
B
Yeah
no
I
mean
again
you
could
you
could
you
could
build
a
detect?
An
extension
controller
that
is
managed
is
used
to
manage
specific
text
functionality
within
tecton,
but
again
it
would
be
something
on
top,
so
it's
yeah,
that's
so
effect
on
natively
does
not
know
about
tests
or
bills,
or
this
kind
of
thing
so
not
not.
For
now
at
least
I
mean
and
but
I,
don't
think
it
will
in
future.
No.
C
B
Yeah
yeah,
that's
a
great
point.
B
C
B
Yeah,
nice,
okay,
so
I.
C
C
C
C
It
seems,
okay,
that
could
maybe
argued
I'm,
not
sure,
but
yeah
the
the
test
Suite
could
be
something
dynamical
which
doesn't
look
the
same
for
every
execution.
It
depends
on
what
the
needs
are
in
testing
something.
So
the
the
list
of
test
cases
to
be
executed
in
a
suite
might
be
different
from
time
to
time,
and
maybe
that's
the
reason
to
have
it
in
the
Run
objects
instead
of
in
the
actual
test,
Suite
objects.
A
B
C
Yeah
but
I
mean
the
definition
of
a
test.
Suite
could
be
like
a
name
and
some
some
type
or
something.
What
does
it
have
a
name
version:
URI,
okay,
but
something
that
is
quite
small
but
just
like
what
is
this
statute
about
and
then
to
know
what
it
actually
consists
of
when
running,
you
need
to
look
at
the
running
objects
because
it
could
be
thermodynamic.
A
A
C
So
I'm
not
positively
I,
remember
exactly
sure
that
this
will
hold
for
forever.
The
the
fields
we
have
here
now
in
the
test
case
run
tests
we
run,
but
let's
try
it
I
would
say
and
see
how
it's
how
it
can
be
used.
Hopefully
it
works.
It
should
work
well
with
this
Cube
at
least,
and
the
first
implementation
of
these
test.
Events
will
probably
be
in
this
Cube.
C
A
B
A
D
B
B
One
could
could
try
to
to
build
this
kind
of
test.
Suite
of
all
I,
don't
know
all
the
security
related
events
and
it
could
be
the
security
related
answer
managed
by
different
test
Runners,
because
my
CDE
scans
some
other
static
scans,
also
for
but
yeah
so
building
this
kind
of
like
Dynamic
distributed
test
Suite,
it's
a
bit
more
complex,
so
I,
don't
think
really
necessarily
to
cover
that
that
use
case.
That
scenario
with.
C
B
Yes,
it
could
be,
but
if
we
Define
something
like
this
Global
ID
or
context,
ID
is
something
that's
probably
what
should
be
used
also
in.
D
B
Okay,
so
what
what
shall
we
say
then
I
think
I
would
say
plus
one
on
all
this
answer.
Yeah
anyway,.
C
A
C
C
A
B
Me,
the
pr
anyways.
C
B
Looks
good
to
me
so
I
think.
Hopefully,
once
we
we
get
the
very
base
from
all
the
other
cautions
signature,
then
it
can
be
merged.
C
B
B
But
he
said
he
he
ran
into
issues
because
he
had
some
merge
commits,
but
then
I
suggested
a
different
strategy
on
how
to
do
it.
For
me,
I
think
it's
it's
important.
It's
good
to
keep
the
same
PR.
B
So
if,
if
your
local
branch,
for
some
reason
is
not
is
somehow
corrupted
or
difficult
to
use,
I
suggested
to
create
a
new,
a
new
Branch
put
the
latest
content
in
there.
Then
you
can
create
simply
just
a
new
commit,
but
you
can
still
push
it
against
the
same
remote
branch
on
your
fork
and
then
it
will
go
in
the
same
PR.
B
B
I
I
had
it
in
here
connecting
events
because
I
wasn't
sure
well.
C
C
A
C
B
Yeah
yeah
definitely
I
think
it's.
We
look
forward
to
to
his
proposal.
B
So
the
next
item
in
there,
the
the
artifact
science
event,
that's
what
we
discussed
there
in
kubecon,
it's
just
a
small
VR,
and
that
includes
an
example.
A
schema.
B
And
some
changes
to
the
markdown
do
I
have
the
signed
event.
C
D
B
B
C
Should
we
have
we
written
some
in
the
documentation
there?
Did
you
write
something
about
the
reasoning
on
by
it
should
be
its
own
event
and.
D
C
C
I'm
not
sure
if
it's
a
bad
thing
that
we
now
Force
producers
to
produce
two
events
for
one
artifact
when
they
are
signed
instead
of
just
having
one
packaged
event
with
the
same
information
in
and
the
same
for
consumers,
it
could
be
a
bit
more
cumbersome
for
the
consumers
to
to
parse
the
data
when
it
comes
from
two
different
events
and
relate
them.
But.
C
B
We
could
I
think
we
discussed
this
last
time
you
mentioned
earlier
that
there
would
be
might
be
confusing
for
consumers,
because
then
you
don't
know
where,
where
to
expect
the
signature,
whether
it's
on
one
side
or
the
other.
So
you
need
to
add
the
logic
that,
on
the
receiving
side
that
checks
both.
B
C
Always
of
course,
the
the
drawback
and
I
think
that's
that's
also,
maybe
a
good
thing
that
we
haven't
explicitly
stated
somewhere
that
we
should
maybe
as
a
common
level
of
system,
that
we
we
want
to
have
often
at
least
one
way,
to
express
Express
things
and
not
multiple
ways,
but
the
drawback
will
be
that
there
are.
There
could
be
multiple
events
instead,
like
in
this
case.
B
Yeah
I
think,
like
you,
you
proposed
something
along
the
lines
in
the
past
of
having
a
number
of
like
small,
diagrams
or
small
use
case
representations.
Somehow
maybe
it
would
be
good
to
have
like
for
each
event.
A
B
A
B
C
Guess
one
thing:
I
learned
on
kubecon
and
of
course
I
have
heard
about
it
before-
is
that
it's
it's
very
important
to
have
good
examples
and
good
documentation
and
good
ways
to
get
started
with
your
open
source
projects,
whatever
project
it
is
and
I
think
we
like
that
to
some
extent
in
this,
and
obviously
we
we
like
contributors
on
the
foreign
improvements
we
can
do
in
the
documentation
and
surrounding
things.
But
let's
try
to
at
least
do
something
here
by
writing
something
more
in
the
documentation,
at
least.
A
B
When
things
I
add
in
here
released
data
free
Status,
we
can
have
a
quick
look
and
then
updates
on
the
several
sdks
yeah.
So
for
release.3.
B
A
A
A
A
B
C
A
C
C
B
C
B
Maintained
all
right,
and
so
for
the
SDK
I,
guess
something
that
I
wanted
to
to
start
drafting.
So
I'll
I'll
try
to
to
work
in
it
for
this
0.3
time
frame.
B
D
B
Okay,
yeah.
C
B
B
Regardless
of
that.
So
we
can
have
the
test
events
and
hopefully
we
can
have
the
artifacts
signed
event
yeah
and
some
some
updates
on
the
sdks.
B
B
C
Have
we
got
any
comments
from
refactoring
the
code
I
see
the
Challenger
has
opened
a
new
pull
request
there
on
geographical.
B
Yes,
yes,
he
started
working
on
it,
I've
not
looked
at
the
pr
yet,
but
we
can
actually,
we
can
probably
switch
to.
A
A
C
B
Is
no
I
was
I,
was
going
to
try
and
reach
out
see
if
it's
on
slack,
perhaps.
B
And
then,
as
you
were
saying,
yeah
jalander
started
working
on.
B
B
C
B
Yeah
I
think,
if
I
remember
correctly,
generaliza
will
also
help
linking
the
GitHub
release
to
the
maven
release
and
it
will
provide
better
change.
Log
Automation
and
these
kind
of
things.
B
But
yeah,
so
it
seems
that
he
is
keen
on
helping
us
and
even
and
implementing
this
for
the
job,
SDK
and
I.
Think
it's
it's
it's
good
I
mean
the
more
automation
will
get
in
place.
The
easier
for
for
us
to
to
maintain
a
team
feature
so
sure.
B
And
maybe
the
thing
worth
mentioning
about
this
is
that
I
created
a
user
called
CD
events,
bot
it's
a
GitHub
user
yeah,
and
that's
so
we
can
use
it
as
kind
of
a
service
account
to
to
drive
these
releases
in
automation
so
that
we
don't
have
to
use
personal
accounts.
B
C
B
Credentials
the
little
factor
of
the
indication
beat
for,
but
that
account
are
in
in
one
password.
So
should
you
ever
need
to
login
in
a
set
user?
You
can
you
can
find
the
credentials
in
one
in
one
password.
D
B
Yeah,
so
that's
I
think
that's
the
status
for
the
Javas
Decay.
B
No
I
know
Avon
is
looking
at
the
release,
automation
there
as
well
one
of
the
issues,
the
lack
of
a
service
account
so
I
configure
the
same
user
for
the
python
SDK
repo
as
well.
C
A
C
It's
a
little
actually
I
already
say:
okay,
yeah,
that's
right!
I'll
see
the.
A
B
Sorry
once
the
yeah,
the
test,
PR,
is
the
test
event.
Pr
was
merged.
We
will
make
an
update,
update
and
I
was
planning
to
meet,
maybe
with
some
of
the
test
Cube
folks
this
week,
also
to
show
them
how
to
use
the
generation
feature:
okay,
yeah,
so
that
they
may
generate
the
SDK
for
themselves.
Before
we
release
0.3
that
I
can
they
can
proceed.