►
From YouTube: CDF - SIG Events Meeting - 2021.11.02
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
B
So
when
we're
waiting,
have
you
gotten
any
idea
about
I'm
switching
subject
now
idea
about
the
images?
For
example
in
tecton,
you
had
a
bunch
of
images
in
and
the
cdf
repo,
the
originals
for
those
images.
A
Right
I
asked,
but
I
didn't
get
any
reply
on
that,
so
I
don't
think
usually
we
we
get
those,
but
I'm
not
sure
if
there
is
any
reason
we
couldn't.
A
The
files
are
provided
by
a
design
team
which
I
don't
interact
to
directly,
but
we
interact
for
them
to
them
with
them
through
the
cdf,
and
there
is
a
brief
and
like
creative
brief
that
it
was
sent
out
and
usually
on
the
brief.
There
is
a
kind
of
the
output
format
that
we
we
want,
you
to
get
and
that's
usually
svg
and
png,
and
then
those
are
stored
in
git.
B
A
Yes,
so
I
and
to
be
honest,
I'm
not
sure
there
is
a
some
design
team,
I'm
not
sure
if
it's
a
part
of
the
linux
foundation
or
it's
a
third
party
that
the
cdf
works
with.
C
I
believe
there
are
constructors,
but
I'm
not
100
sure.
Last
time
we
worked
with
the
cdf
labor
contractors
by
the
linux
foundation.
B
Okay,
that
one
I
was
just
wondering
our
background-
is
that
we're
for
a
full
we're
having
an
internal
discussion
for
how
to
handle
images
and
how
to
handle
originals.
So
that's
why
I
was
digging
around
to
see
how
other
communities
are
doing
it
and
just.
B
B
You
could
do
like
we
do
in
second
durability
that
everyone
signs
in
the
documents.
Instead,
if
you
want
to.
A
All
right,
I
know
steve,
will
not
join
today.
A
So
hello,
everyone
and
joining
today
and
I
think
for
the
agenda
today,
we
basically
have
to
review
of
the
actions
and
discussions.
D
So
when
it
comes
to
the
first
one
there,
generic
versus
concrete
activity
events,
I
know
we
already
discussed
it
on
the
5th
of
october
and
I
seem
to
recall
us
reaching
a
conclusion
that,
yes,
we
want
to
have
both
concrete
and
generic
activity
events,
but
I
couldn't
find
that
written
down
anywhere.
So
I
didn't
dare
close
the
discussion
really.
Did
we
decide
that
we
wanted
to
have
both
concrete
and
generic
ones.
A
I
think
we
did,
at
least
that
would
be
my
try
to
remember
if
you
decided
or
not,
I'm
definitely
supporting
that.
E
E
D
E
Yeah
yeah
and,
as
you
know
again,
maybe
others
as
well
in
eiffel.
We
have
this
generic
activity
only
and
what
we
have
there
is
that
we
have
a
an
enum
that
says
what
type
of
activity
it
is,
which
is
more.
That's
what
we
talk
about
now,
the
different
types
of
activities
or
yeah
specific,
but
we
haven't
really
identified
the
need
so
far
for
further
parameters
that
are
so
say,
activity
type
specific.
E
So
that's
why
we
can
still
stay
with
that
in
eiffel.
I
guess,
but
if
we
see
that
well,
a
build
activity
should
always
have
this
additional
parameter.
Just
because
it
is
a
build
activity,
then
that
makes
sense
to
have
it
as
a
specific
event
type
as
well,
but
I
think
it
would
be
good
to
see
that
all
of
these
specific
activities
are
somehow
children
of
a
generic
activity.
D
But
I
think
in
in
afl
you
have
parameters
with
the
links
concept.
I
think
you
can
provide
a
lot
of
the
metadata
or
reference
a
lot
of
the
information
that
that
would
perhaps
go
into.
For
instance,
yeah
say
that
you
have
a
build
activity.
One
parameter
that
you
might
really
want
to
have
is
is
what
source
did
I
build?
I
mean
in
aphil
that
would
be
solved
by
a
link.
I
think,
and
the
same.
D
B
E
Yeah,
I
think
one
reason
for
for
having
a
generic
top
level
activity
or
would
be
that
we
need
somehow
to
trace
how
our
activities
connected
to
each
other,
regardless
of
if
they
are
builder
tests
or
delivery
activities
or
whatever
the
kind
of
activity
they
are.
A
Yeah,
so
basically
we
would
say,
but
we
would
have
a
section
in
our
spec
where
we
say
these
are
like
general
properties
that
needs
to
be
available,
regardless
of
what
specific
activity
that
we're
talking
about,
and
then
specific
activities
could
extend
that
with
additional
parameters.
A
Does
it
does
it
does
it
does?
Does
it
mean
that
we
would
also
consider
consider
it
possible
for
a
system
to
like
emit
a
generic
activity
without
being
a
specialized
one,
or
I'm
not
sure
that
the.
B
A
B
Be
be
nice
with
with
having
a
generic
event,
because
there
is,
I
mean
you
can
have
two
scenarios,
for
example,
in
this
case,
it's
it's
like,
for
example,
foss
scanning,
where
you
have
some
other
step.
That
is
not
a
common
one,
and
then
you
could.
If
you
only
have
like
build
test,
deliver
and
deploy
those
fixed
events,
then
you
would
be
kind
of
like
okay.
This
is
a
security
step
or
some
kind
of
other
thing
and
you
map
it
into
build,
and
that
is
not
100
correct.
B
E
A
If
we,
if
we
allow
for
generic
activity
to
be
sent,
that
platform
will
use
generic
activity
in
most
cases
because
they
will
fill.
Maybe
this
is
the
others
are
not
the
perfect
fit,
and
then
we
will
end
up
with
everything
having
every
platform
we
might
end
up
having
every
plasma
sending
events
which
other
platforms
do
not
understand,
because
they're,
just
generic
activities
and
the
semantic
of
that
event
is
not
understood
which
is
well.
E
A
Yeah
good,
no,
I
mean
there
is
already
some
value
because
at
least
you
get
like
something
was
started
and
finished,
or
queued
and
successful
or
unsuccessful.
So
you
get
that
part
of
the
information
but
yeah
you
kind
of
risk
to
lose
on
these
comments.
E
I
think
that's
that's.
On
the
producer,
I
mean
a
requirement
to
the
producers
of
these
events
that
if
you
want
a
consumer
to
understand
that
this
is
a
build,
if
it
is
actually
built,
then
you
need
to
set
it
as
a
build
activity
and
you
can't
just
start
it
on
a
generic
activity,
because
people
won't
or
out
consumers
won't
understand.
We
won't
interpret
this
as
a
build
activity.
E
E
If,
for
some
simple
event,
sending
use
case,
you
would
only
like
to
see
whatever
activities
are
in
this
pipeline
and
how
are
they
connected
and
if
they
are
successful
or
not,
it
doesn't
matter
if
they
are
built,
build
activities
and
test
activities.
There
could
be
such
consumers
that
just
care
about
the
actual
activities
generically
and
then
it
could
be
okay
for
those
producers
to
just
send
those
events.
E
E
A
Yeah,
I
think
so
so
I
I
try
to
capture
this
and
say
we
we
define
them
generic
activities.
The
generic
activity
defines
common
params
required
by
all
activities.
We
also
define
specific
activities
and
implementers
should
use
the
specific
activities.
A
If
available,
does
this
capture
at
least
the
high
level
discussion,
and
is
this
something
that
we
can
then
agree
on,
and
then
we
could
close
this
discussion
please
and
capture
these.
E
It
makes
sense
to
me:
I
think
there
are
maybe
two
ways
to
implement
this,
that
we
might
not
be
able
to
solve
today
if
it
should
be
really
a
hierarchical
event,
type
set
up
here
or
if
we
should
just
have
the
generic
activity,
it's
just
another
activity,
another
event
of
the
same
level.
Somehow
I'm
not
sure
if
that's
really,
if
we
want
to
introduce
a
hierarchy
of
event,
types.
B
B
B
So
that
could
be
as
you
do.
What
you're
describing
could
be
a
motivation
for
having
hierarchical
things
to
keep
track
of.
If
we
create
other
events,
because
I
guess
we
want
to
have
a
pretty
rich
vocabulary
of
events
because
just
build
tests
deliver
deploy,
I
mean
they're
going
to
come.
Other
events
in
the
future
yeah
I
mean
there's
a
lot
of
problem
security
scanning
and
so
on.
A
I
think
saying
that
a
generic
activity
defined
common
parameters
that
are
required
by
all
activities,
kind
of
imply
this
hierarchy,
and
it's,
I
think,
that's
yeah.
That
was
my
question
is
something
we
can
agree
on
and
I
think,
rather
than
how
this
maps
into
json,
schemas
or
validation
of
events,
it's
something
that
may
be
specific
to
the
json,
payload
binding
and
maybe
discussion.
We
can
reserve
to
do
when
we
design
that
part.
B
A
A
A
A
A
A
D
I
have
updated
this
page
to
mark
that
as
as
a
result,
the
next
one
is
a
bit
tricky.
I
think
there
is
already
a
lot
of
input
and
I
put
an
action
on
myself
to
go
through
the
discussion
and
try
to
figure
out
what
the
heck
is
going
on,
but
I
don't
think
it
would
be
too
productive
to
look
into
that
now.
I
think
I
need
to
look
at
the
discussion
first
and
yeah
come
back
to
it.
D
A
A
D
Many
types
of
continuous
delivery
flows,
an
artifact,
will
mainly
be
the
result
of
some
build,
which
is
like
a
docker
image
or
a
built
binary,
or
something
like
that.
D
But
for
the
types
of
continuous
delivery
flows
that
I
typically
and
that
I
am
typically
involved
in
then
there
are
many
other
things
that
are
produced
by
continuous
delivery
pipelines.
It
can
be
like
documentation,
it
can
be
not
necessarily
hardware
that
would
be
produced
by
it,
but
a
hardware
definition
could
be.
It
could
be
something
like
it
and
also
what
we
could
call
that
or
what
a
file
calls
a
composition
where
you
have
selected
a
bunch
of
different
built
binaries
or
something
and
combine
them
together
and
say.
D
I
don't
remember,
if
I
call
it
composition,
I
call
it
baseline,
sometimes
as
well,
but
my
sort
of
question
is:
do
we
see
all
these
things
as
artifact
is
like
everything
that
is
produced
by
a
continuous
delivery
pipeline?
Is
an
artifact
or
do
we
have
different
types
of
things
that
are
produced
and
we
we
call
files
artifacts,
that's
like
another
way
of
looking
at
it
yeah.
A
Okay,
so
just
what
comes
to
mind
to
me,
I
think
listening
to
to
your
presentation,
this
areas
that
we
could
have
similar
to
to
the
events,
if
you
would
like
a
generic
artifact.
A
So
you
could
say
artifact
is
something
that
is
produced
by
an
activity
that
happened
and
if
you
wanted
to,
then
we
could
leave
some
space
for
all
specialization
of
this
artifact
and
we
could
discuss
whether
we
want
to
have
that
captured
at
the
protocol
level
or
not,
or
you
could
leave
it
like
free
form
for
platform
to
if
they
want
to
provide
extra
metadata,
and
they
want
to
say
this.
Artifact
is
artifact
of
type
container
image
or
is
artifact
of
type
it's
bomb
or
it's
artifact
of
type
yeah.
A
Then
a
hardware
description,
deployment
description,
whatever
it
is
yeah.
I
guess
again.
If
we
do
provide
certain
types,
that's
always
that
might
go
in
the
direction
of
making
it
possible
for
different
platforms
to
understand
them,
each
other
better,
because
if
you
know
that
a
container
image
was
produced,
you
may
be
able
to.
A
D
Yeah,
I
think
that's.
I
think
that
would
work
out
quite
nicely,
and
I
I
should
be
the
first
to
admit
that
my
my
world
is
is
embedded
software
in
in
complex
products.
D
We
could
have
one
artifact
type,
as
you
said,
that
is
like
a
container
image
and
that
could
have
references
to
specific
files
and
stuff
and
we
could
have
another
artifact.
That
is
more
like
a
composition
or
super
group
of
artifacts
or
whatever
you
want
to
call
it.
That
would
be
fine
as
long
as
we
yeah
the
important
thing
for
me,
I
guess,
is
that
we
don't
write
the
specification
that
assumes
that
every
single
artifact
corresponds
to
a
single
file
and
we
limit
the
protocol
to
that
but
yeah.
So
your
solution
would
work.
Fine.
I
think.
E
I
also
agree,
I
think
it's
in
an
interesting
thought,
should
have
the
hierarchical
event
types
here
as
well.
I
haven't
really
thought
of
it
before,
but
maybe
that
actually
works,
but
maybe
we
need
to
somehow
describe
what
we
what
is
then
specific
to
a
artifact
on
the
top
level,
what
what
parameters
maybe
not
need
to
specify
all
of
them
now.
But
what
parameters
are
I
mean,
identifies
an
artifact
somehow
and
distinguishes
this
from
something
else.
That
is
not
an
artifact.
E
D
I
think
I
think
you
you,
you
are
asking
very
important
questions.
I
think
for
me.
If,
if
I
were
to
just
throw
something
out
there,
then
probably
an
artifact
has
a
unique
identifier
and
it
has
a
version,
and
probably
it
has
some
sort
of
reference
as
to
how
it
was
produced
or
like
who,
who
created
it
or
how
it
was
created.
D
E
D
E
D
D
I
agree:
yes,
I
would
say
that
it
doesn't
have
to
be
built
in
the
pipeline.
It
can
be
built
by
someone
else
or
somewhere
else,
like
a
common
common
thing
in
the
vehicle
industry.
Is
that
you
get
something
from
a
supplier
and
I
would
defend
or
I
would
define
what
we
get
from
the
supplier
as
an
artifact,
even
though
we
didn't
build
it,
someone
built
it
and
now
we
need
to
react
to
the
fact
that
there
is
a
new
artifact,
but,
yes,
it
wouldn't
be.
D
A
I
think,
from
a
station
point
of
view,
email
was
saying:
okay,
how?
Where
does
this
come
from?
I
mean
if,
if
you
don't
build
something,
but
you
provide
it
as
an
output
of
your
of
a
pipeline,
you
should
at
least
kind
of
own
the
the
station
for
that
or
be
able
to.
You
know,
provide
an
attestation
for
that.
They're
saying
me
as
a
pipeline,
I
kind
of
certify
that
this
artifact
is
what
what
it
is
and
then
then
I
can
relate
as
an
output
of
this
other
artifact
if
it
makes
sense.
B
A
B
Go
ahead,
I've
linked
further
up
in
this
discussion
to
the
piadia,
where
they
define
soft
artifacts
in
software
development
and
there
they
state
it's.
Basically,
an
artifact
is
one
of
many
kinds
of
tangible
byproducts
produced
during
developmental
softwares.
B
D
Yeah-
and
I
think
both
a
full
and
esci
has
chosen
to
have
a
different
term
for
that.
If
it
calls
it
a
composition,
eci
calls
it
the
baseline,
but
I
mean
we
could
absolutely
implement
it
if
we
could
get
a
specialized
artifact.
That
is
a
composition.
I
mean
that
wouldn't
be
a
technical
problem.
It's
more
a
matter
of
terminology,
as
you
say
here,.
E
A
A
D
D
E
D
Question
to
you,
based
on
on
how
you
use
composition
defined
event
in
a4,
do
you
foresee
any
problems
for
those
use
cases
if
it
was
rather
a
subclass
of
artifact.
E
Yeah,
I'm
thinking
about
it.
I
don't
really
think
it
is.
I
mean
in
alpha
we
can.
We
can
refer
to
both
compositions
and
artifacts
as
subjects
for
something
that
you
test,
for
example,
and
you
can
set
what
we
call
a
confidence
level
or
maturity
level
on.
I
think
both
compositions
and
artifacts
as
well.
E
So
to
me
it
makes
kind
of
sense
to
see
compositions
as
some
kind
of
artifact
as
well.
I
mean
it's,
of
course
you
build
this
baseline
or
whatever
you
call
it.
So
it's
something
that
is
created
probably
within
the
pipeline.
E
So
in
that
sense
it
is
an
artifact
I,
as
we
use
it
mostly
in
erickson,
at
least,
is
that
we
we
don't
always
have
identities
on
these
compositions,
so
I
mean
we
created
a
baseline
and
the
identity
of
it
is
maybe
where
it
is
stored
in
in
the
git
commit
or
whatever
so
the
gate
commit
more
or
less
identifies
the
baseline
together
with
a
lot
of
other
things.
E
In
their
world,
a
composition
actually
contains
all
it
has
a
list
of
all
these
included
things.
So
the
event
itself
is,
of
course,
immutable,
but
it
doesn't
point
to
anything
that
exists
somewhere
else.
That
is
immutable
as
a
baseline
file
or
whatever.
E
B
Do
we
have
need
for
because
what
we're
talking
about
here
is
basically,
we
define
some
kind
of
a
grouping
or
or
a
file,
but
we
don't
want
to
put
it
on
the
file
system.
Is
there
other
places
within
our
protocol
that
we
need
to
have
create
like
lists
or
something
that
we
don't
have
a
file
for.
D
It
would
have
like
a
url
that
you
could
visit
to
figure
out
or
to
find
everything
that
you're
interested
in
in
this
composition.
So
I
think
what
a
file
allows
this
like
sort
of
on-the-fly
compositions
can
be
quite
powerful,
but
in
sei
we
don't
have
a
use
case
for
it.
As
I
see
it
right
now,
at
least.
B
Yeah,
just
as
a
we
should,
if
we
want
to
have
on-the-fly
compositions
or
something
we
should
point
that
out,
because
that
might
be
a
divergence
from
the
rest
of
the
information
that
I
have
that
we
are
pointing
to
other
factors.
But
here
we
have
the
information
inside
the
message
itself.
B
That
ml,
do
you
see
for
see
a
problem
other
than
maybe
have
storage
and
so
on,
for
instead
of
having
on
the
fly
compositions
that
you
actually
define
the
composition
as
a
file.
E
Of
if
we
would
require
that
it
would
affect
our
flows
a
lot,
I
guess
if
we,
if
there
isn't
a
way
to
deal
with
identities
in
another
way
than
we
do
today,
example,
and
if
we
always
require
that
compositions
or
baselines
need
to
be
a
file
that
is
possible
to
point
out
from
some
repository
artifact
repository.
E
B
Because
another
way
would
be
that
we
defined
artifacts
always
point
to
something
else.
I
mean
the
artifact.
We
don't
define
something,
but
then
we
can
in
the
protocol,
define
as
like.
I'm
talking
more
like
virtual
or
something
temporary
like
a
list
or
something.
If
we
have
a
message
that
can
define
some
kind
of
grouping
and
then
the
artifact
can
point
to
this
grouping.
Instead
of
writing
to
file.
B
D
E
Yeah
this
may
be
it's
hard
to
to
describe
bigger.
I
mean
we
shouldn't,
have
a
c
file
in
the
git
repository
being
an
artifact.
That
is
because
that's
something
that's
created
by
a
developer,
but
of
course
there
could
be
artifacts
included
in
a
source
change.
I
mean,
I
think,
libraries
that
are
built
whatever
that
are
somehow
stored
in
in
a
in
repository
in
git,
and
then
that's
that
source
contains
artifacts.
D
Yeah
definitely
configuration
files
would
be
a
candidate
for
me
for
artifacts
that
you
might
have
like.
You
have
a
code
repository
and
you
have
a
bunch
of
c
files,
for
instance,
and
then
you
also
have
an
xml
file
that
defines
a
configuration
and
we
might
want
to
publish
the
xml
file
as
an
artifact
thing.
Here
is
something
that
could
go
into
other
compositions,
but
the
c
files,
since
they
need
to
be
sort
of
built
to
become
an
artifact.
They
wouldn't
be
artifacts
in
themselves,
but
this
is.
A
I
think
it's
a
blurb
line
there,
because
then
you
could
consider
xml
or
yaml
file
source
code
as
well
like
if
you're
developing
a
tecton
task.
Then
it's
in
yaml,
it's
a
configuration
file,
but
it's
it
can
be
sophisticated.
It
becomes
sophisticated
enough
that
you
could
actually
consider
it
as
a
source
code,
because
it's
written
by
by
someone,
but
on
the
other
side
you
could
have
like
a
template,
templated
files.
D
Maybe
it
would
be
sufficient
to
start
with
to
say
there
is
no
expectation
that
see
the
event
producers
send
out
artifact,
updated
or
created
events
for
every
single
source
code
change,
because
we
have
other
events
for
that.
It's
more
like
it's
somehow
up
to
the
producer
to
to
think
about
what
what
individual
files
may
someone
want
to
take
action
on
and
make
sure
that
those
get
published
as
artifacts
yeah.
I
can't
even
describe
it
in
a
good
way,
but.
A
A
I
don't
know
if
I
have
some.
If
I
create
generate
some
patch
files,
it
can
be
then
applied
to
reproduce
my
pr
adults,
an
artifact.
D
Maybe
it's
sufficient
than
to
say
is
this
the
file
that
I'm
thinking
about?
Is
that
something
that
where
I
want
to
make
that
individual
file
announced
to
the
rest
of
the
system?
And
if
that
is
yes,
then
you
should
send
that
out
as
an
artifact.
And
if
the
answer
is
no,
then
it
might
be
fine
to
just
consider
it
part
of
a
source
code
repository
or
something
else,
because
no
one
will
be
interested
in
that
individual
file.
D
But
it
would,
it
would
sort
of
put
the
responsibility
on
whoever
sends
those
not
those
messages,
but
maybe
that
is
fine,
because
maybe
they
are
the
ones
that
knows
yeah.
As
somebody
I
said,
this
is
a
blurred
line,
so
maybe
maybe
we
can't
give
a
super
clear
answer,
but
definitely
I
would
stand
by
that.
Every
every
individual
file
that
someone
wants
to
be
able
to
take
action
on
should
be
an
artifact.
That
makes
sense
to
me.
B
Because,
as
I
said,
I
mean
yaml
file
or
xml
file
might
be
checked
in
yeah,
or
in
one
case
it
might
be
checked
in
and
part
of
the
source
code
and
one
other
way.
It
might
be
something
that
that
signals
like
a
bill
recipe
or
something
that's
going
to
be
used
by
build
process.
So
yeah
yeah.
A
So
I
would
shall
I
I
will
let
this
comment.
Let
this
to
the
discussion.
I
think
we
might
have
specific
items
defined
like
what
are
the
properties
of
an
artifact.
That's
something
that
we
could
discuss
more
specifically.
A
B
But
should
we
pin
down
what
we
said
there
with
our
an
artifact?
This
is
something
when
you
want
to
announce
a
file
or
something
for
the
outside
world.
You
send
an
artifact
event
for
it,
so
that
is
basically
an
artifact
is
something
that
that
you
want
to
now.
Success.
D
So
basically,
maybe
this
statement
could
be
when
it
comes
to
files
in
source
code
repositories,
then
it
would
be
up
to
the
producer
to
state.
Is
this
individual
file,
something
I
want
to
make
the
rest
of
the
world
aware
of?
If
it
is,
then
I
should
should
send
it
as
an
artifact,
and
if
it
is
not,
then
it
doesn't
need
to
be
resent
that
way.
D
B
D
For
my
use
case,
it
would
be
fine
to
say
that
a
composition
is
a
specialization
of
an
artifact,
because
the
things
that
we
say
hold
true
for
an
artifact,
meaning
that
it
has
an
id
and
name
possibly
version
and
some
other
things.
For
me,
that
is
true
for
compositions
as
well.
It
becomes
an
issue
for
a
full
compositions
which
are
defined
in
the
event
themselves
or
itself.
A
Okay,
right,
and
so
like
an
example,
would
be.
If
I'm,
if
I
have
a
container
image,
I
mean
I
could
store
like
an
index
or
manifest
in
a
container
registry
which
is
actually
a
json
file
that
points
to
other
to
actual
container
images.
So
that
would
be
a
composition
right
yeah,
but
it's
not
something
that
the
protocol
itself
is
aware
of.
A
Okay,
so
that
would
be.
D
Like
the
type
of
discussions
that
we
have
today,
I
feel
like
I
feel
like
it's
it's
great,
to
revisit
topics
that
that
we
haven't
really
closed
before,
especially
now,
because
I
think
we
have
all
done
some
thinking,
even
if
it's
subconscious
thinking
so
that
we
actually
get
stuff
closed
in
some
sense,
so
we
can
can
work
on
the
protocol
for
those
like
decided
parts
I
really
enjoy
it.