►
From YouTube: CDEvents Working Group - 2022-11-09T11:00:05Z
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
E
A
I
was
hoping:
Andrea
had
prepared
this
meeting
and
was
supposed
to
to
be
here,
but
apparently
he
got
some
some
inevitability,
so
you
couldn't
join
I,
don't
know
why
so
I
haven't
prepared
anything
with
this
now
I
haven't
even
looked
into
the
agenda,
so
I
guess
we
can.
Just
if
you
have
anything
you
would
like
to
bring
up
please
do.
A
A
G
E
D
C
E
G
E
A
A
Quite
all
right,
I
guess
what
else
so
yeah
I
just
started
to
say
that
I
was
hoping.
Andrea
should
be
here.
I
I
want
to
share
the
meeting,
but
it's
not
so
I
guess
we
need
to
do
it
in
some
kind
of
cooperation
at
least,
but
one
idea
other
debugger
is
that
we
could
talk
about
guitar
actions
more.
If
you,
if
you're
interested
in
discussing
that
further,
is
there
anything
there
that
you
would
like
to
dig
deeper
into.
D
D
D
A
D
D
D
E
D
D
So
whenever
a
pull
request
is
opened,
a
change
created
event
will
be
sent
whenever
the
pull
request
is
edited
or
actually
any
other
events
from
these
events
happen.
Updated
event
is
sent.
Then
if
a
pull
request
is
closed
but
but
not
most,
then
the
change
abandoned
event
is
sent
if
a
pull
request
is
closed
and
merged,
because
GitHub
code
request
will
just
send
a
close
and
we'll
have
to
check,
dig
deeper
and
check
if
it
is
merged
on.
So,
if
that
has
happened,
we
will
send
a
change
most
event.
D
D
D
Yeah,
so
I'll
just
go
back
to
the
demo
here,
so
it's
not
really
a
demon,
so
I
have
taken
the
payload
from
there
and
then
put
in
this
file
here
called
event.json.
So
I
can
work
with
this
one
locally
I
am
push
how
I'm
working
with
this
in
GitHub
actions
itself
is
in
GitHub
actions,
I'm
taking
the
event
payload
and
putting
it
in
a
environment,
video,
so
I'm
dumping
it
in
the
environment.
Variable
here
called
GitHub
context
and.
D
Go
go
file
as
a
script,
so
I'm
doing
go,
run
and
then
running
it
like
this.
So
it
is
easier
for
me
to
test
also
locally
and
for
local
testing.
What
I'm
doing
is
I'm
running
this
command
and
putting
all
of
the
event
data
in
this
environment
variable
and
then
reading
it
back
from
here
in
the
script,
so
how
I'm
testing
it
is.
D
If
there
is
a
event
of
event,
name
is
pull
request
and
the
action
is
open
when
I
say,
send
a
new
change
created
event
currently
I'm
not
able
to
really
make
this
work.
So
if
I,
if
I
run
this
here,
I
get
a
invalid
memory
address,
so
I
get
a
sick
for
sick,
sick
I
I'm,
not
sure
why
this
is
happening.
It's
been
a
long
time
since
I've
done
goals.
Also
I
think
it
might
be
something
related
to
this
Cloud
event.
Map
cloud
event
over
here.
D
Also,
I
am
not
really
failing
this
anywhere,
so
it
might
be
silently
feeling
I
I,
don't
know
if
something's
going
wrong
so
where
I'm
sending
this
is
this
link
over
here?
It's
basically
I'm
running
k-native
and
I'm
running
the
cloud
cloud
events,
player
and
I'm
hoping
to
get
this
CD
event
on
the
cloud
events
player.
So
it's
running
over
here.
H
F
H
D
D
D
D
So
I'll
set
up
go
over
here
and
then
I'm
running
it
like
this.
So
I
did
a
simple
check
in
the
beginning
to
just
pass
the
Json
and
it
worked
pretty
well.
So
the
only
I
think
hurdle
that
will
come
in
running
this
without
a
Docker
file
would
be
modules,
but
that
also
should
be
pretty
straightforward,
but
every
time
it
runs,
then
it
will
have
collect,
pulled
the
CD
CD
event,
Library
I,
don't
know
which
is
which
is
better
or
worse
like.
D
C
F
F
D
D
G
A
F
F
So
you
can
use
JavaScript
my
effort,
yeah
JavaScript,
I
I,
like
personally,
to
use
Docker
file
and
Bash.
So
for
the
entry
point
of
the
docker
file,
you
just
have
a
bash
script
and
then
that
can
run
and
and
the
user
can
specify
what
version
of
things
that
they
want
as
well.
So
it
works
quite
nicely
instead
of
baking
it
into
the
image.
G
F
F
F
B
F
A
F
A
F
B
X
has
a
has
a
feature
called
lighthouse,
which
is
how
how
it
currently
responds
to
all
of
the
events
that
are
coming
in
from
GitHub
or
whichever
source
code
control
system
you're
using
and
I
think.
The
intention
was
to
extend
that
Lighthouse
functionality
to
to
accept
native
events
so
where
those
events
are
coming
from
is
an
open
question
at
the
moment.
So
it's
possible
that
there
would
be
a
broker
container
that
that
you
could
instantiate
on
either
side,
but
the
the
formal
interface
where
Jenkins
X
would
be
through
lighthouse.
G
A
A
E
E
A
A
E
D
But
I
think
it
will
be
a
good
place
to
start
getting
like
real-time
CD
runs
so
or
regarding
pull
requests,
changes
and
stuff
and
I'm
guessing
pactone
already
must
be
doing
it.
Oh,
but
but
I,
but
I
feel
like
this.
Could
this
could
like
be
for
like
just
experimentation
with
some
metrics,
probably
which
will
be
GitHub
specific.
A
A
F
A
A
A
A
D
H
A
F
F
H
A
B
So
that
means
that
we
we
need
to
be
consistent
about
how
we're
doing
that
and
have
a
a
sort
of
General
process
for
managing
the
release
cycle
of
that,
and
also
addressing
any
presentation
and
style
issues
that
that
might
come
along
with
that.
So
that
we're
we're
getting
a
consistent,
look
and
feel
on
the
website.
But
we're
not
creating
a
lot
of
overhead
that
that's
adding
to
the
difficulty
of
maintaining
the
the
specs.
B
A
C
A
Yeah
I
guess
one
one.
First
input
would
be
that
it's
impossible
to
select
the
revision
of
the
spec
graphic
on
the
website
through
a
drop
down
menu
or
something
I
guess
and
have
the
correct
version
of
the
spec
shown,
depending
on
what
what
revision
you
selected
and
then
we
also
briefly
touched
upon
if
we
should
somehow
run
the
documentation
from
the
sdks
and
maybe
from
other
things
as
well
in
the
organization.
A
That's
certainly
a
stretch
for
this
work
that
you're
doing,
but
we
should
maybe
have
it
in
our
minds
in
a
way
when
thinking
about
how
to
visualize
the
different
revisions
for
such
things
as
well.
If
those
should
go
around
finding
out
in
some
way
so
selecting
a
revision
of
the
specs
should
then
also
affect
maybe
other
parts
of
the
same
website
which
could
contain
other.
B
A
B
A
A
Oh,
that's
a
good
question:
I,
don't
know!
Actually
I
mean
I,
haven't
done
it,
it's
it's
Andrea
I
will
stand
it.
We've
done
it
twice
now,
one
for
this
zero
one,
zero
version,
and
once
for
this
year
one
one
version:
I
guess:
that's
Andrea
would
go
to
the
city
event
stopped.
Every
Point
update
some
tag
there
and
then
regenerate
it.
But
I
I
can't
say
I,
don't
know.
A
To
always
look
at
to
get
the
latest
from
the
spec
now
that
could
also
be
one
way.
Maybe
that
is
okay,
because
yeah
this
was
actually
I
mean
the
the
setup
of
the
website.
The
rendering
of
the
documentation
was
done,
of
course,
before
we
made
the
first
release
and
then
the
Run
of
tags
really
to
do
to
look
for
so
maybe
it's
just
a
nightly
job
that
takes
the
latest.
That
could
actually
be
the
case
today.
You
might
be
right
so
then
it's
not
that
all
a
finished
process.
A
Yeah
I
guess
you
would
you
would
have
quite
three
hands
down
here.
I
remind
you
if
you
have
ideas
on
what
would
benefit
from
the
document
generation
there,
but
I
would
guess
that,
of
course,
one
way
is
to
have
a
configuration
file
in
the
city
events.devel
report
for
the
documentation
that
states
what
tag
should
we
now
get
from
the
Spectrum
when
we
render
this.
C
B
A
I
can
I
can
certainly
say
it
with
99.9
certainty
that
it's
not
considering
that
at
all.
Yet
this
is
too
too
new
for
that,
but
and
obviously
it
sounds
probably
easier
to
just.
We
render
everything.
So
we
know
that
we
have
the
correct
things
of
everything
every
time
and
that
might
work
the
first
say
10
or
20
revisions,
but
then
we
might
end
up
in
very
slow
publishing
on
the
website.
G
A
C
B
G
G
A
G
B
A
B
A
Right,
yeah,
I
think
what
we're
quite
you
know
in
a
quite
good
situation
in
a
way
because
we
have
our
primer
and
our
readme
and
all
those
things
in
the
same
repository
as
the
spec
itself.
Currently,
what
we
don't
have
there
is,
of
course,
obviously
the
actual
website
text,
which
is
specific
for
the
website.
A
So
whenever
that
comes
out
of
sync
with
a
spec,
if
you
do
some
groundbreaking
changes,
which
then
makes
the
the
documentation
on
the
websites
invalid
or
need
to
be
updated
for
some
reason,
then
we
will
have
that
problem,
I
guess
anyway,
but
for
now
we
have
most
of
the
text
in
the
same
repo
and
that's
one
benefit,
then
I
guess
I,
don't
know,
I
mean
before
we
reach
the
1.0
version
of
CD
events.
It
doesn't
make
too
much
sense
to
have
a
very,
very
easy
access
of
old
revisions
of
the
spec.
A
Obviously,
when
we
Implement
our
proof
of
Concepts
and
different
things,
we
need
to
be
to
be
able
to
find
the
old
versions
as
well
if
we
are
compatible
with
this
0.1
or
0.203
version
or
whatever.
But
it's
not
as
important
as
when
we
have
reached
1.0
and
and
after
that
so
I'm.
Thinking
now
on
your
assignment
territory,
we
we
requested
to
have
a
versioning
of
of
the
website
right
in
place.
C
A
I
guess
the
list
that
could
be
done,
then,
is
that
is
to
just
show
what
what
version
of
the
spec
are.
We
now
looking
at
what?
What
is
this
latest
version
that
we
see
now?
Is
it
version
0.1
or
zero
two?
What
is
it
and
that
could,
of
course,
be
retrieved
from
the
file
in
the
spec
repo
or
a
tag?
Maybe
yeah.
B
A
B
B
A
Yeah
yeah
and
we
don't
want
to
spend
most
of
our
time
on
the
actual
website
documentation.
We
want
to,
of
course,
work
on
the
protocol
and
the
Box
primarily
but
yeah.
It
needs
to
be
get
to
go
around
and
on.
Of
course,
we
the
website
information
is
up
to
date,
always
whether
the
least
minimum
effort
required,
of
course
or
whatever
but
I,
mean.
A
That
I
would
like
to
see
that
there
is
a
way
to
to
handle
it
through
differentiating
different
versions
through
URL
parameters,
maybe
them
or
something
similar.
But
then
again
we
need
to
say
sure
this
decide
should
we
remember
all
versions
every
time
we
render
the
documentation
or
should
we
just
render
the
last
one
and
then
somehow
keep
the
old
ones,
but
then
we
need
to
make
sure
that
the
links
still
work
from
the
old
one.
I
don't
know
between
wherever.
If
you
replace
some
files,
what
happens?
C
B
If
you,
if
you,
if
you're
doing
it
dynamically,
then
well
I,
suppose
it's
gonna,
it's
gonna
run
as
a
independent
process.
Isn't
it
so
it's
yeah
you
are.
You
are
going
to
hit
that
situation
where,
as
you
get
more
versions,
you
are
going
to
slow
down
the
overall
rendering
process,
but
you
won't
be
re-importing
content
against
the
historical
spec
versions.
So
in
theory
you
could
go
through
and
manually
prune
out
ones
that
you
you
felt
were
deprecated
and
that
would
allow
you
to
keep
on
top
of
it.
A
C
B
Because
of
the
way
this
is
deploying
as
a
CI
CD
process,
it
is
effectively
going
to
render
the
whole
website
every
time
you.
You
merge
a
pull
request,
but
that
will
that
that
will
be
very
rapid
with
only
a
handful
of
versions
in
place
and
if
it
starts
to
become
a
problem,
you
can
manually
prune
old
versions
out
of
the
website,
repo
and-
and
so
you
know,
you
can
deprecate
versions
and
remove
them
and
then
you'll
speed
things
up
again.
A
Yeah
I
guess
there
needs
to
be
a
process
for
that
as
well.
I
guess
there
could
be
some
kind
of
should
we
call
it
this
allow
best
file
or
something
that
says
these
versions
should
not
anymore
be
rendered,
or
these
are
too
old,
just
render
the
ones
which
are
maximum
one
year
old
or
two
years
old
or
something.
C
B
Because
you're,
if
you're,
if
you're
import,
if
if
your
publication
of
a
new
specification
is
always
just
taking
the
the
latest
release
version
and
adding
that
to
the
repo
in
a
new
namespace,
then
what
that
will
enable
you
to
do
is
just
you'll
have
an
accumulating
set
of
namespaces
in
in
the
the
website.
Repo
yeah.