►
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
B
C
D
B
B
That's
good
to
know
yes,
so
I
know
you
probably
know
this
weekend
is
like
easter
weekends
and
that
is
observed
in
many
different
countries,
especially
in
europe.
So
it
was
kind
of
our
mistake
to
you
know,
schedule
this
meeting
for
today,
because
we
may
have
lower
attendance
than
usual,
like
people
already,
you
know,
went
for
their
long
values
are
deserved,
vacation,
so
we'll
see
we
can
wait
one
or
two
more
minutes
and
then
you
can
start
and
the
meeting
is
recorded.
B
B
B
So
you
can
now
talk
about
tecton
cd
chains
do
demo,
and
you
know
we
have
conversation
about
techno
cd
chains
or
you
know
general
supply
chain
topic,
and
you
will
have
also
noticed
that
the
proof
of
concept
also
looks
at
techbomb,
because
it's
part
of
secure
software
factory,
which
would
be
something
we
can.
You
know,
discuss
if
the
time
allows
and
we
can
start
so.
B
B
If
you
don't
have
them
or
if
you
are
not
subscribed
to
the
mail
list,
then
you
can
subscribe
to
my
list
and
any
updates
to
meetings
like
links
or
you
know
logistics
or
meeting
agenda
and
minutes
they
will
be
sent
to
main
list.
So
you
can
get
that
information
directly
by
a
mail
list
if
you
subscribe,
so
that
is
the
logistic
and
then
the
proof
of
concept.
B
So
a
summary
or
a
background
about
this
idea
by
the
way,
please
share
your
thoughts
about
the
proof
of
concept
idea.
If
you
think
this
would
be
beneficial
or
not,
based
on
what
I'm
going
to
summarize
right
now
when
we
originally,
you
know,
proposed
this
special
test
group.
There
were,
you
know
some
concerns
about
like
if
we
are
duplicating
the
work
that
is
done
as
well
like
cncf
or
openssf,
and
our
response
to
those
commands
or
concerns
was
like.
B
Okay,
everyone
is
doing
lots
of
work
in
our
software
supply
chain,
including
cncf
and
openssf,
and
they
are
looking
at
different
aspects
like
cloud
native
communities.
Looking
at
software
supply
chain,
connect
cloud
native
perspective
of
necessary
is
looking
at
the
supply
chain
aspects:
the
supply
chain,
security
from
splash
chain
perspective,
but
we
noticed
that
ci
cd
wasn't,
you
know,
highlighted
as
part
of
those
efforts
as
much
as
we
expected,
and
that
actually
resulted
in
few
of
us
talking
about
proposing
this
special
terrorist
group,
because
we
don't
have
this
topic
discussed.
B
Probably
within
cdf
we
had
few
discussions
under
special
terrorism,
internal
ability,
but
internal
ability
is
a
big
area
as
well,
and
it's
not
fair
to
you
know,
take
over
those
discussions
and
focus
on
supply
chain,
because
we
came
up
with
this
patient
test
group
and
one
of
the
ideas
within
the
proposal
was
to
establish
this
proof
of
concept
to
look
at
what
other
communities
are
doing.
Cncf
openness
seek
store
and
elsewhere
and
see.
B
If
can
we
use
what
they
develop,
or
you
know,
establish
and
attempt
to
contribute
to
that
broader
effort
of
improving
the
state
of
software
supply
chain
by
bringing
our
you
know,
expertise
or
knowledge
from
cic
domain
as
cicd
practitioners.
So
that's
the
main
idea
behind
this
proof
of
concept
and
to
get
that
conversation
started.
A
few
of
us
start
talking
about
like
how
we
can
get
you
know
some
basic.
B
One
topic
is
activities,
so
when
I
say
activities,
I
literally
mean
pipelines,
stages,
steps
and
so
on.
So
that
is
one
aspect
we
could
look
at
and
see.
Okay,
everyone
talks
about
how
we
can
improve
the
state
of
software
supply
chain
and
people
talk
about
different
activities
like
okay,
generating
s-bombs
or
license
checks
or
vulnerability,
analysis
or
artifact
signing
and
most
of
these
activities
have
corresponding
stages
in
pipelines.
B
Essentially,
talking
about
those
activities
is
important,
but
demonstrating
those
things
for
anyone
who
wants
to
you
know
establish
such
pipelines,
for
their
use
would
be
valuable
as
well,
and
this
would
perhaps
help
us
to
you
know,
contribute
to
those
initiatives.
So
activities
is
one
aspect
of
the
proposed
talk.
B
Second
aspect
is
technologies,
and
this
is
based
on
ankit's
comments
during
the
sake
of
software
factory
presentation
two
weeks
ago,
because
our
idea
was
to
start
the
proof
of
concept
by
reusing
sacred
software
factory
reference
implementation
and
they
made
some
technology
selections
as
part
of
their.
You
know,
proof
of
concept
or
project,
and
in
that
project
they
use.
C
B
Tools
such
as
tecton,
cd,
tecton,
cd
chains
or
kyverno,
and
some
artifact
image
registry
and
so
on,
and
when
ankit
asked
okay
can
we,
you
know,
use
zhang
sex
instead
of
techno.
The
response
was
positive
from
michael
lieberman,
and
that
resulted
in
me
adding
technology
aspects
into
poc.
If
we
have
people
interested
in
trying
different
tools
like
instead
of
tool
x,
people
may
want
to
try
to
light
to
see
how
those
tools
could
help
improve
the
you
know:
status
of
supply
chain.
B
B
And,
finally
again,
the
original
intention
was
to
look
at
on-premise
ci
cd
pipelines,
but
someone
said
okay
majority
may
be
using
you
know,
on-premise
deployments
or
of
their
own
class
to
install
their
technologies
or
establish
pipelines,
but
some
organizations
may
be
using
cloud
provider
services
like
code
pipelines
and
whatever,
and
that
result
in
inclusion
of
environments
into
pork,
as
you
can
guess
this
make.
This
could
make
the
pork
quite
big,
and
that
is
another
topic.
B
So
the
intention
is
simply
look
at
that
extreme
working
special
interest
group
interview,
the
combined
network
with
the
force
from
opencf
and
cncf,
and
come
up
with
a
more
complete
list
of
activities,
stages
and
steps,
and
then
start
you
know
establishing
those
pipelines
and
technologies
are
here,
and
environments
are
here
and
lots
of
references
here
as
well.
Now
I've
been
talking
about
10
minutes,
so
any
comments
questions
this
idea,
good.
D
Yeah
I
mean
I
like
it.
I
think
the
I
think
the
the
real
important
thing
is
going
to
be
how
how
is
cdf's
recommendation
or
or
proof
of
concept.
What
is
it
demonstrating
that
the
cncf
one
isn't
or
that
open?
You
know
various
open,
ssf
efforts
are
doing
like
I
want
to
work
together
right
we're
not
going
to
do
this
alone,
but
also
I
want
to
make
sure
that
the
cdf's
thing
is
somehow
saying
and
saying
a
new
thing.
D
Taking
a
different
perspective,
I
think
you've
identified
some
ways
that
can
do
that,
like
specifically
choosing
different
technologies.
Perhaps
then,
then
the
supply,
the
secure
software
factory
did
or
focusing
on
non-cloud
native
use
cases
I
mean
we
are.
We
are
cdf,
not
necessarily
cloud
native,
continuous
delivery,
right,
continuous
delivery
of
mobile
apps,
continuous
delivery
of
traditional
non-cloud
native
software,
so
I
think
yeah.
D
If
we
could,
if
we
could
find
ways
to
really
demonstrate
something,
novel
and
unique
specific
to
cdf's
per
view
and
focus,
I
think
that
would
be
really
successful,
not
that
just
replicating
the
same
work
as
these
other
groups
is
not
useful.
I
think
just
just
having
another
example
of
it
would
be
nice,
but
also
having
a
specific
cdf.
B
B
I
think
this
what
you
said
like
cloud
native
like
focus
being
on
cloud
native,
I'm
not
saying
it's
not
a
good
idea,
but
I
remember
a
talk
from
one
of
the
cdf
events
or
something
someone
was
actually
saying.
Okay,
cloud
native
is
cool
and
everyone
is
going
cloud
native,
but
there
are
some
organizations
who
are
not
doing
cloud
native
like
you
exemplify
something
like
mobile
development
or
you
know,
telecom,
for
example,
it's
not
cloud
native
yet
so
it
would
be
pretty
cool
to.
You
know,
look
at
both
aspects
of
it.
What
to
do?
D
Yeah,
the
the
the
stuff
that
we
are
talking
about
is
not
necessarily
cloud
native
right.
You
should
have
a
secure
supply
chain,
whether
or
not
you
are
producing
you
know,
kubernetes
deployments.
You
should
also
have
a
secure
supply
chain
if
you're,
making
an
ios
app
or
something
so
yeah.
I
guess
I
think
we're
in
violent
agreement,
but
I
want
to
I
want
to
like
reiterate
that
I
think
this
will
be
most
successful
if
we
are
doing
something
unique
from
those
other
efforts,
and
I
think
we.
B
Okay,
and
since
this
is
the
first
time
you
are
seeing
this
document,
I
don't
expect
no
to
read
it
in
two
minutes
but
yeah.
It's
I
put
the
link
on
zoom
chat
and
I
will
share
the
link
on
slack
channel
as
well
as
mail
list.
So
please
go
there
and
just
add
your
toast
directly
document
or
comment
on
documents.
So
we
can
see
like
what
kind
of
you
know
contributions.
B
We
could
make
like
reviews
what
other
communities
are
doing,
but
what
we
could
introduce
on
top
of
that,
for
example,
another
idea
we
had
was
like
open,
ssf
or
yeah
cncf
secrets
of
factory
didn't
talk,
much
about
production
aspects,
and
one
of
the
ideas
we
had
was
like.
Okay
development.
Iran
talks
about
okay,
what
happens
on
the
left-hand
side
of
the
software
development
life
cycle?
B
If
you
put
that
way,
but
the
focus
on
right
hand
side
like
what
happens
if
evernote
is
disclosed
for
an
application
or
your
product
running
in
production,
already
how
you
can
accommodate
those
things
like
you
may
do
rolling
upgrades
like
bringing
new
version
with
this
fixed
or
in
mobile
case.
You
may
push
updates
to
your
users,
so
looking
at
production
side
right
most
hand,
side
would
be
something
good,
because
and
then
we
are
talking
about
continuous
delivery
here
and
one
of
the
key
benefits
of
contemporary.
B
We
all
know
what
that
is
like
bringing
things
production
as
fast
and
good
as
possible,
so
that
is
currently
tbd
here,
because
the
idea
to
do
with
that
part
is
to
look
actually
this
potato
hat.
That
is
again
another
initiative
coming
from
cncf.
They
are
looking
at
different
types
of
cloud
native
deployments,
so
this
could
perhaps
cover
cloud
native
production
deployments,
and
then
we
can
think
about
what
about
other
type
of
deployments,
non-cloud
native
deployments,
extending
the
supply
chain
and
trends.
Maybe
that
could
be
the
right
way
to
put
it.
B
So
that's
all.
I
want
to
talk
about
the
proof
of
concept
idea
and
again,
just
to
say
this
unmarried
from
red
that
has
been
working
on
the
stages
and
steps
vocabulary
or
term
knowledge
document
that
those
two
pr's
they
are
awesome
like
if
you
haven't
seen
them
just
look
at
them.
She
put
other
reports
on
those
pr's
and
there
were
a
lot
of
conversations
around
what
she
contributed.
B
They
are
still
open
and
we
intend
to
get
them
merged,
so
we
can
base
our
you
know,
stages
and
steps.
We
may
come
up
with
on
top
of
that
work
if
they,
the
stages
and
steps
we
come
up
with,
are
not
there
already.
So
that
is
how
we,
you
know,
converge
these
different
efforts
together
within
cdf,
and
then
we
can
use
that
as
a
means
to
reach
out
to
other
communities
highlighting
our
thinking
to
them
and
then.
B
B
C
Okay,
cool:
can
everyone
see
that
okay,
great
yeah,
so
I'm
just
gonna,
do
a
quick,
andrea,
tecton
change
today
and
then
a
demo,
so
you
can
see
how
it
works.
There
is
kind
of
a
bit
of
overlap,
probably
from
the
with
the
secure
software
factory
demo.
You
got
last
week,
but
hopefully
this
will
go
a
little
bit
into
depth
and
answer
some
of
the
more
unspecific
questions
you
might
have
had
cool
quick
agenda.
C
I'm
gonna
just
quickly
cover
what
tacton
is
a
super
basic
level
just
in
case
anybody
hasn't
used
it
before
talk
about
tucked
on
chains,
talk
about
salsa
and
do
a
quick
demo,
and
I
realize
now
that
I
actually
moved
these
slides
around
this
morning.
So
actually
the
demo
will
happen
before
I
talk
about
salsa,
okay,
cool.
What
is
that
con?
So
techton
is
an
open
source,
kubernetes
native
cacd
platform,
and
it
allows
users
to
build
test
and
deploy
across
cloud
providers.
C
I'm
I
feel,
like
probably
people
are
pretty
familiar
at
this
point,
so
I'll
just
go
through
this
quickly,
so
the
basic
unit
of
configuration
and
tecton
is
the
tacton
task.
You
can
deploy
a
task
to
your
cluster,
where
it
can
be
used
as
a
building
block.
It
can
either
be
run
on
its
own
or
as
part
of
a
larger
pipeline,
or
it
can
be
referenced.
C
So
you
can
apply
the
task
to
your
cluster
and
then
the
task
run
basically
actually
takes
that
off
and
runs
it
turns
it
into.
It's
actually
makes
the
thing
happen
yeah,
so
this
is
kind
of
where
text
on
chains
comes
in.
So
with
typed
on
you
can
run
your
pipeline.
You
can
kind
of
do
what
you
would
normally
do
with
any
ci
cd
platform,
whether
that's
building
binaries,
building
images
and
then
storing
them
somewhere,
maybe
in
an
oci
registry
or
storing
them
in
a
bucket
for
your
users
to
pull
and
then
use.
C
The
idea
behind
texan
chains
was
to
basically
be
the
supply
chain.
Security
manager
for
tecton
after
this
build
is
complete.
So
once
your
pipeline
is
completely
finished
running
your
artifacts
have
been
built
and
stored
wherever
they
need
to
be
stored.
That's
where
taxon
chains
will
come
in
and
basically
take
care
of
anything
related
to
supply
chain
security
for
you.
So
this
could
be.
This
can
include
things
like
signing
artifacts
that
were
generated
by
your
tax
on
pipelines.
This
could
be
a
ci
image
or
a
file
or
a
binary.
C
So
how
does
it
do
this?
It
leverages
sixer
under
the
hood
and
basically
takes
advantage
of
all
the
six
door
tools
and
services
to
actually
make
this
happen,
so
the
key
components
of
six
stores.
So
what
is
six
door
system
is
an
open
source
project
which,
with
the
goal
of
making
signing
and
verifying
software,
easy
and
accessible,
so
it's
free
to
use,
and
there
are
public
instances
of
the
two
main
six
store
services,
pulsio
and
recore
running
just
for
open
source
use
for
anybody
who
wants
to
use
them.
C
C
C
Recore
is
safe
stores,
transparency
log,
so
it's
an
append
only
log
where
you
can
store
signatures,
it's
public
for
anyone
to
query.
So
the
idea
is
that,
once
you
have
signed
your
artifact,
you
can
store
the
signature
in
record,
and
that
makes
it
really
easy
for
end
users
to
find
signatures,
certificates,
attestations
kind
of
associated
with
your
artifact
and
then
finally,
cosine
is
a
cli
tool
and
library
used
for
signing
and
verification.
C
So
this
is
a
badly
drawn
diagram
by
me
trying
to
explain
how
this
all
works.
So
in
your
kubernetes
cluster
you'll
have
checked
on
pipelines
running
you
can
see
it
on
the
left
side
and
then
text
on
change
running
in
a
separate
name
space.
When
you
start
a
task
run.
First
text
on
pipelines
is
responsible
for
executing
it,
and
once
the
task
run
is
complete,
tecton
chains
will
constantly
be
observing
all
the
task
runs
in
the
cluster
once
it
notices
that
the
task
run
is
complete.
C
It
will
attempt
to
sign
any
artifacts
that
may
have
been
generated
by
that
task
run
so
tagged
on
chains
will
take
an
assigning
key,
which
the
user
has
configured
themselves,
generate.
Signatures,
generate,
attestations
and
then
mark
the
task
run,
assigned
it'll,
also
store
provenance
and
the
signature
associated
with
that
artifact
and
whatever
storage
back-end
you've
configured
for
tecton
chains.
So
right
now
we
support
storing
things
in
oci
in
google
cloud
storage
and
in
a
variety
of
like
dock
db
back
ends,
but
oci
is
probably
the
most
popular
one
at
the
moment.
C
C
Basically,
under
the
hood,
cosine
will
take
a
look
at
your
artifact
pull
out
the
correct
related
entry
from
the
record
transparency,
log
use
the
signature
or
the
certificate
in
that
entry
to
verify
against
the
signature
and
sign
provenance
that
have
been
stored
in
whatever
back
end
you
configured,
okay.
So
that's
a
lot
of
information:
let's
do
a
really
quick
demo,
so
I
already
created
this
cluster
in
oops
in
amazon
eks,
and
you
can
see
that
it
was
created
with
this
flag
with
oagc.
C
So
this
is
basically
how
the
cluster
itself
will
later
authenticate
to
the
full
co
certificate
authority
service,
improve
identity,
so
that'll
come
up
towards
the
end
of
the
demo.
I
also
already
applied
tecton
chains
and
text
on
pipelines
with
these
two
different
control
apply,
commands
just
two
files,
nothing
super
unusual
and
then
before
we
actually
get
into
the
demo,
we'll
want
to
configure
tekton
chains
with
some
with
some
configuration
that
we
need.
C
C
So
this
basically
means
that,
instead
of
having
to
set
up
our
own
key
pair
or
point
chains
to
kms,
which
it
also
supports
we'll
take
advantage
of
an
ephemeral
or
a
kind
of
keyless
mode,
which
means
that
using
cosine
libraries
under
the
hood
chains
will
generate
an
ephemeral
key
pair
and
memory
requests,
a
certificate
from
full
co
using
that
key
pair
and
then
actually
only
store
the
certificate
with
the
public
key
embedded
in
it
in
report.
So
it's
kind
of
nice
because
we
don't
need
to
manage
keys.
C
We
don't
need
to
keep
track
of
a
private
key
and
we
also
don't
need
to
figure
out
how
to
distribute
public
keys
to
end
users,
we'll
just
store
the
certificate
in
the
transparency
log
and
then
end
users
can
use
cosign,
which
knows
how
to
query
the
transparency
log
for
the
correct
entry.
So
I've
already
run
all
of
these
as
well.
So
I
won't
hit
enter
a
couple
of
things
that
I
had
to
do
to
configure
the
cluster
before
we
can
get
going.
C
We're
going
to
use
this
to
build
an
image
and
push
it
within
techton,
and
then
I
also
created
another
service
account
the
tecton
chains,
controller
service
account,
which
also
has
permission
to
push
to
my
ecr
container
registry.
So
techton
chains
is
going
to
use
this
to
push
the
signature
that
it
ultimately
generates
to
to
my
registry,
and
then
my
signature
is
going
to
live
right
next
to
the
oci
image
that
will
be
created
in
my
tekton
task
run
cool.
C
C
So
just
taking
a
look
at
the
task,
we
have
a
bunch
of
parameters
that
are
passed
in
the
most
important.
One
is
just
image,
which
is
the
name
of
the
image
that
we're
going
to
want
to
push
the
final
image
to,
and
then
there's
a
couple
of
workspaces
here,
including
build
context
and
the
docker
file
docker
config,
which
will
create
contain
any
authentication
required
for
pushing
to
my
registry.
C
So
basically,
when
tucked
on
chains,
it's
observing
this
task
run
once
this
task
screen
is
complete,
it'll
recognize.
Oh
an
image
was
built
because
I
know
that
the
I
like
recognized
these
image,
url
and
image,
digest
results
and
then
it'll
extract
that
image
and
attempt
to
sign
it.
So
we
have
just
a
couple
of
steps
here.
The
first
one
basically
just
adds
a
docker
file,
because
it
was
easier
for
me
to
do
that
than
that
one
and
it's
just
a
quick,
small,
hello
world
docker
file.
C
C
And
I'm
going
to
store
and
we're
going
to
push
the
final
image
to
this
ecr
registry
in
my
project,
so
I'm
just
going
to
store
that
as
an
environment
variable
and
start
the
task
with
tkn.
So
we're
going
to
start.
This
can
go
chains
task
using
def,
just
whatever
defaults
were
set
in
the
parameters
we
wanted
to
push
to
this
image
and
then
there's
some
config
and
we're
going
to
use
that
ecr
pusher
service
account
that
I
created
earlier,
which
will
give
this
task
permission
to
push
the
image
to
my
registry.
C
E
C
C
C
Cool
okay,
so
the
image
was
built
and
pushed
successfully,
but
what
happened
once
the
top
screen
actually
completed?
So
this
is
where
text
on
chains
is
supposed
to
come
in,
and
the
nice
thing
is
that,
once
the
task
run
is
done,
you
can
kind
of
just
let
tekton
chains
run
in
the
background
and
it
should
take
care
of
signing
and
generating
provenance
for
you
completely.
C
C
It
basically
leverages
that
with
oitc
feature
that
we
used
and
it
was
on
eks,
so
we
can
also
take
a
look
at
the
attestation
that
was
generated
by
using
cosine
varies
by
attestation.
This
should
give
us
some
more
details
into
how
the
image
was
actually
built,
so
you
can
take
a
look
at
the
payload
code
it
to
jq,
and
we
can
actually
see
the
all
the
details
of
the
task
frame
that
we
just
ran
now,
which
are
stored
in
the
log
for
any
end
user.
C
Who
wants
to
run
this
image,
so
the
provenance
contains
the
name
of
the
image,
the
digest
all
of
the
parameters
that
we
set
and
every
single
step
that
was
run
in
the
cluster
along
with
sometimes
that
when
the
build
started
and
when
the
build's
finished
so
it's
kind
of
cool.
Basically,
all
you
have
to
do
is
install
checked
on
chains
once
in
your
cluster
and
it'll
kind
of
handle,
signing
and
generating
prominence
for
all
your
task
runs
from
there.
A
I
have
a
question.
Thank
you
from
the
demo.
I
tried
it
a
couple
of
weeks
ago
and
I
was
not
able
to
make
it
work.
I
didn't
spend
too
much
time,
but
one
thing
it
was
difficult
for
me
was
to
to
find
out
where
I
was
doing
something
wrong.
Could
you
try
if,
for
example,
you're
in
your
task
frame,
you
are
not
specifying
image
image
digest.
A
C
The
logs
could
use
some
work,
so
the
way
I
usually
debug
is
just
is
by
looking
at
the
logs
for
the
text
and
change
controller.
The
thing
the
main
issue
with
that
is
that
there's
a
lot
of
logs
as
you
can
see,
it
will
kind
of
generate
the
logs
for
each
task
run.
So
you
will
usually
search
into
the
logs
by
the
taskbar
id
and
then
kind
of
see
what
happens
after
it
will
print
out
all
errors.
C
C
Often
this
is
where
it
kind
of
fails
when
it
tries
to
upload
due
to
authentication
errors.
So
you'll
usually
see
like
some
sort
of
error
printed
out
here,
but
I
can
definitely
keep
up
with
you
on
the
side,
because
it's
true
it's
it's
not
an
easy
thing
to
debug
and
we
could
definitely
work
on
our
documentation
around
it
as
well.
C
Okay,
we
can
just
wait
till
the
end
yeah,
so
the
last
thing
I
wanted
to
mention
is
the
salsa
framework,
so
there's
also
security
framework
checklist
for
software
integrity,
so
right
now
attacked
on
insect
and
chains
achieves
also
level
two,
and,
as
you
can,
you
could
have
seen
in
the
demo.
This
basically
just
means
that
the
builds
run
in
a
build
service.
C
E
C
So
we
only,
I
think,
right
now,
chains
only
supports
instance
as
a
full
co.
So
if
you
have
your
own
instance
of
full
co
running,
you
can
point
to
that.
But
generic
ca
is
it.
I
don't
think
it
works
with
at
the
moment.
But
if
it's
an
open
source
thing
I
feel
like
we'd,
be
open
to
adding
other
options
as
well.
If
they
work,
if
they're
also
code
signing
certificate
authorities.
C
D
So
I
don't
know
if
this
is
not
exactly
a
question
for
priya
unless
you
know
the
answer,
so
this
is
really
cool
for
tekton,
and
things
like
jenkins,
x
and
shipwright
that
are
built
on
tekton
can
take
advantage
of
it
relatively
easily
just
by
virtue
of
being
attacked
on.
But
does
anybody
know
of
any
effort
to
simply
emulate
this
in
jenkins
or
any
other
thing,
not
even
cdf
projects,
but
other
projects
in
the
area
like
observing
a
jenkins
x,
run
and.
E
So
we
actually
have
have
you
know
like
a
project
that
will
start
from
this
month,
or
maybe
you
know
like
next
month
where
we
want
to
integrate
with
you
know
like
tecton
chains
and
also
build
something
which
is
you
know
like
native
for
jenkins
x,
because
we
have
you
know
like
pipeline.
I
mean
we
have.
You
know
like
lighthouse
jobs
and
pipeline
things
that
are
built
on
top
of
you
know
like
techton,
so
we
would
probably
want
you
know
like
cryptographically.
E
B
B
B
In
two
weeks
same
time,
then
we
can
perhaps
talk
about
you
know
our
approach
in
the
park
and
how
we
can
use
this
effort
there.
So
if
you
are
interested
to
hear
what
they've
been
doing
and
ask
questions
and
take
part
in
conversations,
please
join
on
28th
and
our
meeting
on
may
12th
will
have
james
rollins
with
us
talking
about
cartographer,
which
is
a
new,
a
kind
of
relatively
new
project,
taking
a
choreography
approach
to
crcd
pipelines
to
orchestrate
things
and
that
presentation
demo
will
take
place
on
may
12th.