►
From YouTube: SIG Interoperability Meeting - Jan 20, 2022
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
B
A
B
So
I
hope
I
am
sharing
the
right
browser,
which
should
be
the
meeting
agenda
and
stuff.
C
B
We
had
few,
but
they
need
some
time
for
us.
You
know
fix
like
the
white
paper
stuff
which
we
discuss
almost
like,
so
we
don't
have
any
action
item.
C
Good
and
then
I've
got
a
really
nice
happy
announcement,
which
is
that
the
cdcon
cfps
are
open.
C
I've
left
a
link
in
the
notes
to
where
you
can
submit
and
find
out
a
little
bit
more
about
it.
C
I
have
had
questions
from
european,
especially
individuals
in
europe
who
maybe
their
company,
is
not
allowing
them
to
travel
yet,
and
they
won't
know
how
that
policy
evolves
until
after
the
cfp
closes,
and
what
I
have
advised
is,
please
submit
your
talks.
We
certainly
want
to
have
excellent
talks
from
as
many
people
as
possible
and
most
certainly
from
our
active
community.
C
In
addition,
my
feeling
is
that
a
lot
of
these
roles
are
going
to
be
revised
and
to
the
extent
to
which
they
are
revised.
They
were
likely
to
be
changed
more
or
less
in
tandem,
so
fingers
crossed
everything
just
gets
better
and
better
and
we're
all
in
person,
and
everyone
can
start
traveling
again.
C
C
That
is
not
right
now
foreseen
at
all,
but
I'm
just
saying
I
would
submit
your
talks
if
you
were
willing
to
fly
and
would
generally
be
able
to
fly
over
and
speak
in
person
and
fingers
crossed
all
the
different
rules
and
regulations
we
have
around
the
world
and
in
our
different
situations,
come
together
and
so
we're
able
to
actually
come
together
as
people
and
and
meet
in
person,
which
I
very
much
look
forward
to.
C
Okay,
so
that's
it
just!
Please
submit
your
talks.
We're
super
excited
to
read
them
and
review
them
and
to
welcome
you
all
in
person
at
citycon,
yep,
okay,
we'll
leave
it
at
that.
There's
other
stuff,
maybe,
but
I'm
not
gonna
talk
about
that
and
then
first
thing,
interoperability,
very
sadly,
fatty
who
has
been
probably
the
world's
best
coacher
ever,
has
really
done
an
amazing
job
in
the
sig
working
on
the
white
paper
arranging
great
speakers
leading
sessions,
bringing
us
all
together
on
this
topic
and
moving
our
understanding
on
this
topic
forward.
C
I
am
so
sad
to
hear
that,
naturally
enough
after
two
years,
it
is
time
for
him
to
step
down,
and
so
we
are
looking
for
another
co-chair
of
the
interoperability
sig
factory,
though
happily,
will
remain
involved
in
the
sink.
So
thank
you
very
much
heidi
for
everything.
You've
done
for
the
inaudibly
sick.
C
Is
there
anyone
on
the
call,
what
I
will
likely
do
is
send
out
an
email
asking
for
people
to
raise
their
hand
if
they're
interested
in
being
co-chair,
but
while
we're
all
here
together
now,
is
there
anyone
who
would
be
interested
in
being
co-chair?
Who
is
on
this
call
or
would
consider
it,
and
would
you
like
to
hear
more
about
what
it
involves
and
just
discuss
it
further.
B
Yeah
just
to
add
to
that
like,
if
some
of
you
are
interested
to
become
here,
but
you
are
not
comfortable
to
state
it
right
now,
you
can
reach
out
to
me
or
carol
slag
and
we
can
talk
about
like
what
like.
Is
it's
like?
What
kind
of
effort
you
need
to
put,
and
sometimes
we
can
give
you
some
information
about
those
things
and
try
to
answer
any
questions
you
may
have.
So
it's
fun
things
to
you
know,
because
you
have
opportunity
to
reach
out
to
different
communities.
B
C
C
Fun
funji
has
put
in
the
chat
that
the
cfp
for
open
info
summit
in
berlin
in
june
is
also
now
open.
Would
you
like
to
speak
to
this
subject.
D
Oh
yeah,
no,
it's!
It
was
just
announced
the
cfp.
In
the
past
week,
there's
a
ci
cicd
track
and
they're
accepting
talk,
submissions
and
it's
scheduled
for
june
7th
through
9th
in
berlin.
D
C
Yep,
that's
right!
Thank
you.
In
addition,
we're
likely
to
have
a
half
day
gathering
sort
of
a
co-located
event,
but
maybe
a
little
less
formal
sort
of
a
contributor
summit
event
connected
to
kubecon
europe
in
may.
In
valencia,
more
details,
as
that
becomes
finalized
will
be
announced,
but
I
would
imagine
a
number
of
people
in
this
group
would
be
interested
in
that
discussion
and
being
involved
so
by
all
means
if
you're
at
qcon
keep
an
eye
out
for
the
event,
because
it
should
be
really
fun.
B
B
New
york
foundation
now
took
it
under
open
source
summit
and
cfp's
for
that
event
is
also
open
votes
for
europe
and
north
america
one.
So
if
you
are
into
supply
chain
area,
if
you
want
to,
you
know,
propose
a
talk
about
the
supply
chain,
challenges
or
ideas
you
you
might
want
to
look
at
that.
I
am
trying
to
find
the
link
for
it
and
I
will
put
it
in
the
chat
and
on
the
meeting
minutes.
B
C
E
Point
hello,
I'm
new
nice
to
meet
you
all.
F
I
was
looking
at
that
red
hat
is
trying
to
implement
something
very
similar,
there's
also
another
project.
I
think
it's
called
phogios.
The
red
hat
had
been
working
on
with
the
us
government.
Anyway,
I
looked
across
these
projects
and
I
saw
that
the
sequence
of
steps
that
people
go
through
in
a
compliance
pipeline
is
usually
the
same,
so
they're
doing
the
exact
same
things,
they're
just
plugging
in
different
tools
to
accomplish
the
same
goal,
and
it
would
be
very
helpful
if
we
could
say
okay
now
I
have
a
step
that
is
of
type.
F
You
know
sign
my
code
and
I
know
that
you
know
that's
what
it's
going
to
do.
Semantically
and
everybody
understands
that.
That's
what
a
step
signing
sign
in
my
code
does
and
so
there's
two
pull
requests
and
I
think
the
stage
yeah
there's
the
step
types
and
the
stages.
I
think
the
stage
one
is
easier.
F
The
pipeline
stage
terminology
is
basically
what
people
talk
about
when
they
talk
about
like
the
devops
loop
cycle
diagram
right,
so
they
talk
about
like
plan
develop
tests
whatever.
So
we
could
look
at
that,
one
first,
that
one's
gotten
some
more
early
feedback.
I
think.
F
So
let's
look
at
this,
so
this
one
I
was
trying
to
keep
really
high
level.
I
won't
read
it
all
I'll,
just
but
there's
some
caveats
at
the
beginning.
You
know
like
this
document
overall
says.
Well,
not
everybody
agrees.
What
a
stage
is
even,
but
you
know
that
there
seems
to
be
some
consensus
about
that,
but
the
actual
stage
is,
let
me
put
it
in
formatted.
E
F
So
quick
summary:
first,
we
have
build
test,
release,
deploy
and
maintain
and
there's
kind
of
a
summary
here
of
what
each
of
these
things
are
taking
as
inputs
and
generating
its
outputs
and
then
in
the
details
up
here,
there's
also
information
on
what
the
semantics
are
like,
what
we
expect
to
happen.
B
I
have
a
question
in
general.
Actually
now
it's
great
that
you
started
I'm
very
when
I
was
looking
at
the
police,
both
of
them
like
I
commented
on
the
police
already,
but
my
question
is
like:
are
you
trying
to
capture
the
current
state
or
should
we
I
don't
know
if
it
is
the
right
place
to
do
that,
but
should
we
look
at
promoting
some
kind
of
good
practices
as
part
of
this
document?
F
So
it's
this
one
is
certainly
based
on
current
state
right
now,
although
it
is
a
little
bit
idealistic.
B
Yeah,
I
think
about
this,
especially
the
setup
step
as
part
of
build
stage.
I
think
eric
had
a
similar
comment
for
step
so
like
what
I
noticed
that
is,
like
build
environment
setup
is
considered
as
part
of
build
stage
in
the
stages.
Pr,
I
feel,
like
those
things
set
up
steps.
B
Perhaps
they
considered
as
separate
stages
and
build
stage
only
deals
with
building
artifacts,
whatever
happens
before
that
or
after
that,
maybe
they
are
distinct
stages,
so
the
build
environment
setup
could
take
in
its
own
set
of
input
files
like
configuration
files
or
whatever
is
required,
set
the
built-in
amount
or
test
environment,
and
then
it
is
ready.
The
build
stage
kicks
in
doing
its
own
stuff.
It's
done
leaves
the
artifacts
on
the
file
system,
for
example,
another
stage
or
step
applause,
those
things
and
the
final
stage
could
clears
down
resources
like
again
it's
just.
D
B
A
F
Yeah
I
mean
I
think
setup
could
be
something
you
could
see
within
each
of
these
stages
right
yeah.
These
I
want
to
be
pretty
high
level
without
getting
into
too
many
implementation
details.
F
The
steps
definitely
have
more
implementation
details,
but
I
think
if
you
like,
for
example,
if
you
think
of
it
as
like
the
devops
cycle
diagram
people,
don't
really
talk
about
setup
and
clean
up
at
that
level.
Right.
B
D
B
F
Okay,
yeah,
the
other
thing.
These
are
also,
I
think,
when
people
implement
their
builds.
F
D
Sorry
I
was
just
going
to
say
that,
from
the
rule
perspective
that
those
are
what
we've
been
calling
pipelines
for
the
past
10
years.
F
Yes,
sort
of
yeah,
it
depends
on
the
tool
right,
if
I
think
about
something
like
I
don't
know
something
simple
like
jenkins
or
or
travis
ci,
or
something
like
that,
they
usually
just
put
them
all
into
one
big
chain.
F
G
G
But
it
all
relates
to
this
vocabulary
document
that
we
started
working
on
like
one
and
a
half
years
ago,
or
something
and
yeah.
G
F
F
G
Exactly
because
the
table
is
below
you
see
here,
yeah
yeah,
so,
for
example,
you
have
the
many
tools
you
call
it
a
pipeline,
some
call
it
a
workflow
that
level
and
then
you
have
the
stage
and
job
or
yeah
also
on
that
harness
because
that
the
pipeline,
so
maybe
that's
what
you're,
referring
to
frankly,
maybe
that
you
have
individual
pipelines
for
each.
What
other
would
call
the
stage
with
the
builder
for
the
test
or
whatever?
G
F
Yeah,
I
think
some
tools
encourage
you
to
have
many
different
pipelines
too
right
and
some
don't
so
yeah.
I
chose
the
word
stage
because
it's
the
most
common
thing
in
this
column.
F
That's
why
I
chose
that
term
like
I
was
trying
to
refer
to
this
level,
but
at
the
same
time
it's
I
mean
what
we're
really
getting
here
is
a
concept
like
what
does
it
mean
to
build
something?
F
That's
that's
the
real
goal,
not
you
know,
are
all
tools
going
to
use
the
same
term
like
what
does
it
mean
to
release
and
deploy.
F
D
What
I'm
mainly
trying
to
figure
out
is
how
to
to
map
concepts
there
to
the
the
environments
I'm
familiar
with.
I
I
think
it
probably
is
going
to
boil
down
to
these
are
recommendations
for
for
setting
up
a
project,
not
necessarily
for
the
tools
that
would
be
used
to
implement
it,
because
the
tools
for
the
most
part
are
flexible
enough
to
be
able
to
decompose
this
in
a
variety
of
different
ways.
So
it's
really
more
of
a
of
a
workflow
question
than
a
cooling
question.
At
the
end
of
the
day,.
E
J
J
F
Okay,
can
we
look
at
the
other
one
too.
F
Okay
and
again,
I
used
the
most
common
word,
even
though
every
twelve
years
is
different
word
for
this
thing,
so
a
stage,
I
think
we
all
everybody
who's,
been
doing
this
for
a
while
kind
of
knows
what
this
is,
but.
F
F
Okay-
and
this
is
what
I
was
seeing
across
all
these
different,
like
reference,
implementations
of
best
practice
pipelines
for
security
and
compliance
okay.
So
these
are
the
steps
so
set
up
source
tag,
text
secrets,
build,
discover,
mediate,
test
coverage,
code
coverage,
scan
build
materials
package
sign
policy.
Some
of
these
are
a
little
harder
to
define
like
policy
like
or
analyze
versus
scan,
but
some
of
them
are
pretty
obvious.
Publish
provision
deploy,
verify
your
deployment
analyze
message,
create
a
request,
update
a
record,
run,
credit
results
and
clean
up.
F
So
I
know
you
know
from
experience
that,
for
example,
test
things
get
slotted
in
in
a
bunch
of
different
places
in
real
pipelines
right,
but
there
is
sort
of
a
logical
order
that
usually
they
happen
to
generally
disorder.
K
Well,
I
don't
know
tagging
is
something
that
typically
happens
after
usually
after
a
successful
deployment,
although,
if
I
I
mean
make
sure
I
read
this
to
see
what
it
really
is
talking
about
here,.
K
D
K
Annotating,
an
image
that's
after
building
the
image,
so
if
there's
any
kind
of
an
order,
that's
been
suggested
in
this
in
this
write-up,
you
know
cloning,
the
the
repo
and
building
it
is
like
one
of
the
first
things
that
happened.
K
F
K
F
F
K
Yeah,
typically,
in
my
experience
you
we,
we
want
to
know
like
for
a
trunk-based
development
when
you
have
a
single
main
branch
and
all
the
other
work
is
getting
done
on
on
sub-branches
and
once
they
pass
all
the
tests
they
go
through.
The
pr
is
approved
and
all
this
stuff
that
they
have
confidence
to
be
able
to
merge
it
into
the
main
branch.
K
The
delivery
pipeline
really
begins
at
the
merge
into
the
main
branch,
but
a
tag
of
did
it
was
it
successful.
Was
the
delivery
successful
to
production
and
everything
is
now
running
in
production?
The
tagging
comes
after
that,
and
it's
only
the
tag
that
lets
us
know
that
okay,
this
is
what's
in
production
now,
so
that's
just.
D
K
H
H
F
The
revision
and
one
would
be
tagging
the
image
I
think
yeah
yep
yeah,
and
there
are
a
number
of
these-
that
we
definitely
run
more
than
once.
F
And
some
of
them
are
pretty
generic
like
scan
right.
That
covers
like
a
static
application,
security
test
and
it
covers
what
linting
license
checks,
there's
a
lot
of
different
things
and
yeah.
When
I
look
at
real
implementations,
I
see
scan
steps
just
kind
of
scattered
almost
willy-nilly
right,
but
as
long
as
I
know
that
this
is
a
scan,
that's
that's
doing
a
lint,
then
I
can
check
something
off
in
my
tool
that
says:
okay,
they
lent
it
good
right.
This
is
a
dynamic
security
scan.
F
I
can
check
a
box
that
okay,
you
did
a
dynamic
security
scan.
You
know
I'm
gonna,
let
you
proceed
to
production
or
whatever
that's
what
that's.
What
I'm
trying
to
accomplish
with
these
really
is
like
at
a
higher
level,
having
a
tool
be
able
to
understand
these
steps
have
happened
and
that
they
semantically
mean
kind
of
the
same
thing,
because
I
think
every
company
changes
the
tools.
B
Also
some
like
now,
this
is
again
a
question.
I'm
not
trying
to
say
what
is
that
is
wrong,
but
there
may
be
some
activities
that
may
not
be
run
as
steps
distinctly
like
without
any
specific
end
point.
For
example,
there
must
be
a
starting
point,
maybe,
like
you,
have
something
running
on
production,
and
you
continuously
observe
that
and
trigger
certain
actions
based
on
what
may
be
happening.
If
you
consider
those
parts
like,
I
think
I
put
a
comment
to
stages
or
steps.
F
I
I
think
from
a
sig
event
perspective
or
cd
events.
I
guess
this
can
be
extremely
helpful,
because
one
thing
that
we're
discussing
now
is
like
what
kind
of
different,
basically
what
kind
of
different
activities
or
steps
or
stages
or
whatever
you
want
to
call
them.
Can
we
have
in
a
pipeline
and
since
one
of
the
goals
of
cd
events
is
to
enable
observability,
then
it
really
helps.
I
F
And
the
other
thing
I
wanted
to
do
by
sort
of
defining
what
the
inputs
and
outputs
are.
I
mean
we
want
to
literally
be
able
to
swap
out
some
of
these
steps
like
I
want
to
be
able
to
have
a
pipeline
defined.
That
says,
okay,
do
your
build
and
you
know
whether
you
do
a
node
build
or
a
java
build
or
python
build
or
whatever
kind
of
build.
I
Yeah
yeah
or
code
cover
whatever
yeah
yeah,
so
matthias
actually
called
us
from
seed
events
over
here,
because
this
is
a
discussion
I
mean
a
list
like
this
could
have
a
very
positive
impact
on
the
work
to
establish
the
events
protocol
because
yeah
it
would
support
interoperability,
as
you
say,
between
devices.
So
it
doesn't
matter
exactly.
As
you
said,
if
it's
a
python
builder,
it
will
be
followed
by
go
or
something
else.
I
F
Yeah
another
thing
I
see
is
like
the
discovery.
That's
the
thing
that
would
generate
like
your
dependency
graph
right
and
from
there
you
can
have
a
tool.
You
can
have
different
tools
that
can
generate
a
build
materials
off
of
that,
and
then
you
can
have
scanners.
Look
at
those
things
right
as
long
as
you're
using
standard
data
formats.
F
Okay,
yeah,
I
don't
know
if
I
missed
any
major
categories
and
some
of
them,
like
I
said,
was
a
little
bit
debatable.
J
I
F
It
kind
of
is
conceptually,
I
think,
in
terms
of
implementation.
D
F
D
And
actually,
there's
a
there's
a
corollary
to
that
too
again,
I
wasn't
familiar
with
the
with
the
github
example,
since
I
don't
really
use
github,
but
in
a
lot
of
the
open
source
projects
I
work
on.
D
We
do
analysis
of
build
outputs
to
try
to
find
injected
fabricated
secrets,
so
you're,
basically
stuffing
your
own
made-up
secrets
as
inputs
into
the
software
and
then
checking
things
like
like
system
logs
to
make
sure
that
those
haven't
leaked
through
into
the
logs
and
so
that
that
sort
of
secret
detection
actually
does
involve,
building
and
running
the
software
to
be
able
to
execute
it.
F
D
F
H
D
Well,
I
think
they're
all
kind
of
composable
too,
because
a
lot
of
the
things
that
you
think
of
doing
from
the
perspective
of
someone
who's
deploying
software
to
production
can
also
be
done
in
the
development
phase
of
the
software
itself.
If
your
focus
is
on
software
development
and
publishing
releases
of
software
for
others
to
consume,
rather
than
deploying
it
yourself.
F
H
E
C
D
But
again,
that's
something
that
you
would
be
doing
as
as
the
author
of
software,
primarily
I
mean
it
could
be
done
on
the
consumer
side
as
well.
But
but
it's
you
know
a
fairly
standard
technique
in
like
system
software
that
that
is
gonna
need
to
be
able
to
to
handle
things
like
keys
or
or
other
blobs
of
sensitive
data.
F
F
H
E
D
Something
similar
we've
done
with
canary
deployments
is
to
couple
it
with
tagging
on
the
revision
control
side.
So
we've
got
a
set
of
systems
that
get
continuously
deployed
from
every
change
that
merges
to
the
head
of
the
developing
branch,
and
then
those
are
evaluated
on
a
continuous
basis
to
make
sure
they're
functional,
but
then
there's
a
broader
set
of
production
systems
that
only
get
deployments
from
states
of
the
repository
that
have
a
new
version
tag
applied
to
them.
D
Well,
I
mean
the
the
ci
cd
systems
that
I
work
with
are
entirely
based
around
triggers
the
the
pipeline
definitions
you'll
see
in
the
glossary
for
result.
Basically,
a
mapping
of
triggers
to
action,
so
I
mean
triggering,
is
something
that
that
potentially
occurs
that
every
single
phase
stage,
whatever
you
want
to
call
it.
D
H
H
We
would
expect
to
see
five
five
minute
time
periods,
wherein
there
are
zero
errors,
and
I
wonder
if
we
could
generalize
weight
to
be
like
weight
with
condition
to
maybe
also
be
this
trigger
concept
like
we're
waiting
on
a
github
event,
or
I
don't
know
if
that's
too
generic
or
not.
C
D
I
mean,
I
think
those
are
concepts
that
are
relevant
to
low-level
ci
cd
systems
design,
but
they're,
probably
more
of
an
implementation
detail
when
you
get
to
the
workflow
level
of
we
want
this
to
happen,
and
then
this
happening
and
this
to
happen
and
based
on
these
conditions,
the
the
the
trigger
concept
is,
is
probably
more
what
the
ci
cd
system
is
built
on,
whereas
the
the
conditions
are
are
what's
really
relevant
to
to.
When
you're
looking
at
the
at
the
workflow
layer
of
your
layer
cake,
I
suppose.
H
Yeah,
okay,
yeah
yeah
I
get
like
it-
might
be
useful,
as
maybe
an
addendum
to
this,
to
come
up
with
some
example
pipelines
and
then
annotate
them
with
the
steps
that
they
exist
as
they
exist.
H
H
Like
a
there's
like
a
specific
there's,
a
specific
step,
which
is
big
time
and
it's
used
and
it's
like
at
the
same
level
as
like
test
and
so
like
the
layout
in
the
amazon
workflow
is
you
know
you
get
built,
then
you
after
build.
H
There
are
steps
that
happen,
and
then
you
progress
to
the
next
stage
and
then
the
steps
that
can
happen
are
like
security,
validation
and
you
and
and
coverage
enforcement
and
stuff
like
that.
And
then
you
progress
to
I'm
deploying
to
my
like
tiny
cluster
and
then
you'll
have
like
your
end-to-end
tests
and
so
on.
But
one
of
those
is
like
bake
and
it's
just
like
sits
there
for
30
minutes
and
another.
D
H
F
Metrics
of
evaluation
is
also
what
you
just
described,
is
a
little
bit
like
verified
deployment,
but
it's
more
it's
snazzier
than
that
right,
usually
verify
deployment,
means
just
make
sure
the
thing
deployed.
I
didn't
get
any
years
back
and
it's
running.
H
H
H
F
F
F
So,
okay,
unless
anybody
else
had
anything,
I'm
good
for
now,
just
yeah
feel
free
to
add
any
other
comments
on
there.
I
took
notes
I'll
put
another
revision
up
based
on
those
too.
C
Okay,
just
asking
again
looking
for
a
co-chair
so
that
email
will
go
out
to
listening
possible
culture.
Volunteers
suggest
it
to
your
friends
if
they
seem
the
type
I
don't
know
also
think
about
it.
For
yourselves,
I'm
sure
any
and
all
of
you
on
this
meeting
would
be
an
excellent
coach.
So
great,
thank
you
and
thank
you
once
again
to
fatih
you've
been
awesome
thanks,
bye
thanks.