►
From YouTube: CDF - SIG Interoperability 2021-04-01
Description
For more Continuous Delivery Foundation content, check out our blog: https://cd.foundation/blog/
A
A
B
A
D
B
B
B
Good
great
well
welcome
to
today's
interoperability.
Seg
meeting
vincent
behar
is
going
to
give
a
presentation
on
tell
me
if
I'm
describing
this
correctly
on
using
jenkins
x,
to
gather
metrics
on
using
the
door
metrics
and
nicole
farthens
new
space
metrics
developed
with
her
github
team.
We
have
a
link
in
the
notes
to
the
paper
that
they've,
just
written
so
that'll,
give
you
some
background
on
these
new
metrics,
so
that'll
be
really
exciting.
But
first
let
me
share
my
screen
and
we'll
go
over
just
some
of
our
admin.
B
E
So
I
kind
of
broke
it
down
into
five
types
of
artifacts,
and
this
is
not
the
definitive
list
and
if
we
need
to
change
any
of
this,
I'm
totally
open
to
it.
One
of
the
first
one
is
more
of
the
traditional
file
artifact
that
we
think
of
like
a
jar
file,
ear
file
where
those
get
pushed
to
a
some
sort
of
repository,
artifactory
nexus,
maven
repository
and
when
they
get
pushed
to
those
artifact
repositories,
they're
going
to
have
certain
attributes
around
them,
and
mainly
you
know
the
basic
stuff
around
a
file.
E
You
can
have
multiple
ones,
those
pointing
to
the
same
artifact
version,
so
you'll
see
like
you'll,
have
like
a
snapshot
or
it'll,
then
get
transformed
from
a
snapshot
to
a
release
candidate
and
then
it'll
get
transformed
from
release
candidate
to
the
the
final
version.
So
there
is
some
transformation.
The
these
artifact
repositories
are
not
immutable,
they
can
like
the
tags
can
be
changed
and
things
like
that
you
can
go
and
replace
the
version.
E
E
Both
of
those
are
typically
different
file
names.
I
I
an
example
of
a
roll
forward.
Is
I'm
going
to
add
a
column
to
a
table
and
the
roll
back
is
going
to
be
dropping
that
column
that
I
just
added
what
this
allows
is
databases,
acting
in
an
incremental
up
way
when
you
need
to
update
them,
so
you
have
to
go
through
your
whole
versioning
of
the
tables
and
apply
all
the
different
versions
in
the
right
order.
E
E
E
I
looked
at
once
a
container
has
been
built
that
we're
going
to
do
something
with
that
built
image
and
usually
that
gets
pushed
to
a
registry,
and
that
registry
is
where
you
can
retrieve
it
from
registries,
can
be
either
public
or
private.
They'll
have
an
organization
as
part
of
the
naming
convention.
You
know
so
this.
This
image
belongs
to
this
organization.
E
E
So
if
I
do
like
a
docker
build,
I'm
not
going
to
have
a
digest,
which
is
one
of
the
things,
and
these
are
immutable
as
part
of
that,
so
we'll
never
get
the
the
duplicate
on
on
that
that
point.
So
that's
one
of
the
nice
things
with
the
the
the
container
images
is
they're
immutable.
The
tags,
though
tagging
you
can
re-tag
something,
so
you
can't
trust
the
tag
to
be
the
definitive
go-to
for
if
you're
gonna
do
like
reporting,
you'd
wanna
be
moving
and
or
tracking
the
digest.
E
The
next
one
is
endpoint.
Artifact
endpoint
is
like
a
loose
term.
I'm
trying
to
use
there
if
somebody
has
a
better
idea
of
of
something
other
than
endpoint
just
feel
free.
But
what
I'm
trying
to
gather
here
is
something
that
a
target
that
we
deploy
to
it
could
be
a
server.
It
could
be
a
physical
server.
It
could
be
a
virtual,
a
vm.
It
could
be
ec2
instance
a
kubernetes
cluster.
It
could
be,
you
know,
aws
lambda
function,
you
know
we're
going
to
go
somewhere
inside
of.
E
This
world
and
what
I'm
trying
to
gather
here
for
endpoint
artifact
is
what
is
the
definition
of
the
end
point?
You
know
what
is
making
up
the
end
point,
and
so,
in
the
case
of
like
on
the
the
kubernetes
kind
of
cloud
provider
side
there
we're
gonna
have
something
like
a
terraform
or
cloud
formation.
E
Some
sort
of
yaml
file,
that's
going
to
describe
what
the
endpoint
is
going
to
look
like
and
that
that
yaml
json
definition
is
what
I
was
thinking
that
we
would
be
in
the
a
repository
that
you
could
always
go
back
to.
So,
if
you
want
to
go
recreate
a
an
endpoint,
you
go
pull
it
from
the
repository
and
then
run
the
appropriate
program
against
that
file
to
go
ahead
and
create
that
endpoint
as
part
of
that
process.
E
This
really
is
describing
or
trying
to
describe
the
different
pieces
of
hardware
that
are
actually
on
a
machine
that
we're
going
to
be
working
with
this
one
is
more
of
a
what
I
would
call
a
representation
or
a
reporting
of
a
hardware,
artifact
versus
a
way
to
stand
up
a
new
hardware
artifact
because
you
have
to
actually,
if
you
want
to
stand
up
a
new
piece
of
hardware,
you
actually
have
to
have
somebody
physically
go
put
in
a
graphics
card.
You
have
to
go.
E
Somebody
go
physically
put
in
a
disk
drive,
so
this
is
more
along
the
lines
of
reporting
for
hardware
artifacts,
and
there
could
be
a
disconnect,
as
par
as
part
of
what
a
technician's
doing
to
a
machine.
They
go
and
swap
out
a
graphics
card
and
they
don't
put
a
new
one
in
that's
exactly
the
same
as
the
old
one.
They
have
a
slightly
different
model
or
whatever.
So
we
could
end
up
with
drift
at
the
hardware
level
and
that
would
be
need
to
be
addressed.
E
But
if
we're
looking
at
pulling
together,
everything
as
a
whole,
you
know
from
the
base
level
hardware
all
the
way
up
through
cloud
up
to
databases
contain
you,
know,
container
images
and
files,
that's
what
I
was
trying
to
achieve
here
at
that
level
and
if
there's
anything
I
missed
feel
free
to
go
ahead
and
change
it.
This
is
just
my
initial
thought
of
where
we
could
start.
B
A
A
He
mentions
that
spdx
accepted
as
international
standard
for
how
open
source
metadata
is
shared.
So
this
made
me
think
that
maybe
we
should
you
know,
get
in
touch
with
spdx
folks
and
to
learn
more
about
what
they
are
doing.
What
this
standard
consists
of
and
perhaps
get
someone
from
spdx
to
join
one
of
our
meetings
and
thanks
to
tracy
miranda,
he
got
in
touch
with
kate
stewart
from
spdx,
so
she
will
join
our
meeting
in
two
weeks
on
15th
of
april.
A
B
E
E
E
Now,
when
we
get
to
a
container
a
container,
let's
say
we're
doing
a
python
flask
application
and
a
container
we're
going
to
have
many
python
modules
installed,
so
we're
going
to
have
many
spdx
files.
One
for
each
package
should
be
there
same
thing
like
node.js,
there's
gonna
be
one
for
each
anything.
You
bundle
up
and
you
push
out
to
you
know
like
to
pi
pi
or
any
of
those
anytime.
You
do
your
packaging.
This
is
where
they're
basically
requiring
you
now
to
give
us
some
basic
information.
E
E
E
B
E
E
So
a
lot
of
the
information
that
we're
looking
at
the
concepts
are
going
to
be
the
same
but
like
for
package,
download,
location
and,
let's
say
we're
dealing
with
a
java
jar
that
would
make
sense
that
this
would
be
the
maven
repository
that
the
jar
file
is
going
to
come
from,
so
that
would
be
around
a
jar
file,
that's
being
packaged.
Now,
when
you
create
a
jar
file,
you
don't
necessarily
have
a
way
to
embed
spdx
information
into
it.
E
E
E
Then
I'm
going
to
have
a
package
of
spdx,
that's
going
to
include
other
spdxs,
so
it's
kind
of
this
nested
cascading
effect
that
you
have
to
roll
up
the
information
and
then,
if
you
put
that
node.js
into
a
container
and
then
you
have
multiple
other
pieces,
you
have
to
keep
rolling
up
these
relationships
to
get
the
true
representation
of
what
a.
What
is
it?
What
is
in
the
container
to
describe
that
so
the
way
I
look
at
it
compared
to
what
I
just
described
around
file,
you
know
artifacts,
this
is
information.
E
A
F
Yeah,
I
will
say
it's
well
worth
having
the
conversation
with
kate.
I
had
a
a
quick
chat
with
her
and
yeah
this
there's
the
licensing
part
of
spdx,
which
is
less
interesting,
but
the
package
management
side
and
yeah.
I
appreciate
that.
That's
pretty
complicated
but
yeah,
I
think
to
spdx
2.2
is
what's
out
now,
but
they
are
working
to
3.0,
so
we
should
kind
of
be
aware
of
what's
happening
there
and
the
direction
as
well
she
mentioned
is
a
lot
of
the
they're
kind
of
in
the
the
s-bon
space,
so
software
bill
of
materials.
F
That
being
said,
I
think
the
specifics
of
cicd
is
not
going
to
have
that
domain
knowledge,
and
we
are
the
right
folks
to
kind
of
bring
that
perspective
into
that.
I
think
it's
it's
well
worth
working
with
them
and
layering.
On
top,
where
we
can
just
because
I
think
yeah
from
all
the
indications,
it's
picking
up
a
lot
of
momentum
in
adoption
as
well
across
platforms.
E
Yeah
there's
a
lot
of
terms
in
the
spdx
world
that
we
can
adopt
without
reinventing
them.
You
know
what
is
a
versioning
schema.
What
is
a
git
repo?
You
know,
though,
those
those
terms
are
already
been
defined
in
in
the
spdx
specs,
so
we
can
just
refer
to
them
instead
of
creating
our
own
and
being
you
know
slightly
off,
I
I
would
say
that
we
as
much
as
we
can
adopt
from
the
standard,
especially
since
it's
being
put
put
in
front
of
iso,
that
will
will
save
ourselves
a
lot
of
time.
E
E
Yeah
and
like
I
said,
the
the
spec
is
really
what
I
consider
low
level
it's
when
I
create
a
package
of
of
code
that
I
want
to
share.
It
may
not
go
through
a
ci
cd
process,
but
it
is
a
shareable
object
and
because
it's
shared,
I
wanted
to
attach
certain
attributes
to
that.
So
people
understand
when
they
go.
Look
at
my
module.
You
know
who's
the
author
of
it
where's
the
website.
E
You
know
what
are
the
other
dependencies
that
you
need
to
install
to
make
this
this
piece
run.
So,
like
I
said
it's
it's
for
us,
it's
a
little
low
level
and
we'll
need
to
look
at
it
at
a
roll-up
perspective,
and
that's
one
of
the
things
we're
doing
on
the
artelia
side
is
is
rolling
that
up
we're
actually
bringing
in
cyclone
dx
has
some
decent
tools.
E
E
Well,
that's
what,
as
part
of
the
vocabulary,
that's
why
I
was
saying
we
should,
instead
of
us
going
through
and
trying
to
come
up
with,
what
we
consider
is
a
the
definition
for
a
source
control
repository
and
we
come
up
with.
You
know:
subversion
git,
you
know
whatever
and
we
go
through
and
do
all
of
our
definitions
that
instead
of
doing
that
project
that
we
just
refer
to
what's
already
been
done
on
the
spdx
side.
E
A
And
yet
the
other
thing
tracy
miranda
highlight
is
that
they
may
lack
the
perspective
from
cic
domain.
So
we
can,
you
know,
look
at
what
they
are
doing
and
see
if
there
are
gaps
and
contribute
them
there
or
you
know,
but
yeah,
as
tracy
mentioned,
like
kate
stewart
will
join
our
meeting
15th
of
april
so
like
that
would
be
a
great
great
opportunity
for
us.
A
You
know
hear
what
they
are
working
with
like
version
three,
they
start
working
with
that
and
we
can
share
our
thoughts
and
what
we
are
doing
within
cdf
and
see
what
she
says.
Maybe
they
already
thought
about
these
things,
but
they
may
not.
Have
you
know
the
right
contacts
or
whatever
you
know?
That
is
like
kind
of
why
I
brought
spdx
to
pickup.
E
Yeah
and,
and
what
I
found
initially
is
vendors
or
open
source
projects
are
the
only
thing
that
they're
really
putting
in
the
spdx
record
is
the
license
at
this
point.
I'm
hoping
that
as
people
adopt
that
they're
going
to
start
putting
in
more
information
more
of
the
individual
records,
I
have
not
found
anybody,
that's
doing
the
dependencies.
Yet
when
you
look
at
the
projects,
so
there's
a
lot
of
information
on
the
spec,
but
people
are
just
doing
a
couple
one-liners
in
in
their
in
their
spdx
records.
For
now,.
C
C
You
know
whether
it
be
jar
file
or
whatever
give
you
a
slew
of
metadata,
as
well
as
anything
that
adheres
to
the
to
the
docker
hub
standard
for
images
that
already,
given
you
know,
red
hat
with
their
quay
repository.
That
already
gives
you
everything
you
would
imagine
about
the
image
itself,
so
I
don't
I'm
not
sure
how
much
value
there
is
with
anyone
else,
trying
to
define
a
standard
for
for
meta
metadata
having
to
do
with
those
types
of
artifacts.
C
So
all
you
need
to
do
really
at
the
end
of
the
day
is
to
refer
to
and
say
this
is
an
npn
module,
here's
the
address
for
its
repository
and
a
story,
and
then
anybody
who
wants
to
create
let's
say
somebody
wants
to
crawl
through
various
dependencies
of
a
fully
fully
fledged
software
system.
All
they
need
to
know
is
that
oh
okay,
I've
got
an
npm
module
module.
C
I've
got
a
javascript
application,
I
have
here's
a
quay
address
and
if
they
have
adapters
for
that
system,
those
adapters
know
exactly
what
to
do
to
retrieve
the
metadata
from
quay
or
from
npm
or
from
artifactory,
and
that's
that
there's
really
no
need
to
re
to
you,
you'd
be
reinventing
the
wheel,
and-
and
why
do
that?
So
I
can
totally
understand
why
they
don't
do
that.
E
Now
you
have
to
have
two
different
adapters
and
what
the
the
standard's
trying
to
do
is
is
literally
standardized
we're
going
to
use
author
instead
of
creator
as
spdak
standard
across
all
these
different
programming
languages.
So
now,
when
we
go
and
crawl,
this
stuff
we're
not
having
to
rewrite
different
adapters
and
and
change
switch
adapters
on
the
fly
as
we
go
through
the
different
languages,
because
if
you
look
at
a
container
that-
and
this
this
applies
to
like
rpms
as
well
at
the
operating
system,
level
that
the
spdx
applies
to
those.
E
So
if
I
want
to
go,
get
a
list
of
all
the
licenses
that
are
installed
in
the
container,
and
I
have
some
of
it's
in
node,
some
of
it's
in
golang
and
then
I
have
my
rpms.
I
have
to
have
three
different.
I
have
to
scan
it
three
different
times,
because
I
had
three
different
standards
I
had
to
look
for
and
the
spdx
is
trying
to
make
it
a
make
it
easier
to
do
it
just
scan
once
and
get
all
the
the
data
that
I'm
looking
for.
G
I
was
wondering
I
guess
there
are
some
attributes
in
those
that
are
the
same
for
all
artifact
types
right,
so,
for
example,
I
guess
like
name
and
path
and
size
are
more
or
less
there
for
all
of
them.
Would
it
be
feasible,
then,
or
maybe
good,
even
to
have
a
common
something
had
a
high
level.
Artifact
definition
with
these
are
the
common
attributes
for
all
artifact
types,
and
then
we
have
for
these
certain
types.
We
have
some
other
attributes
as
well.
E
Base,
like
you
said,
like
name
or
path,
would
be
at
the
base
level
and
then
like
a
database
would
inherit
from
a
file,
and
then
you
know
that
type
of
inheritance.
That
was
one
of
the
other
ways
I
was
thinking
of
laying
it
out,
but
I
wanted
to
get
your
feedback
and
look
at
you
know.
This
is
just
like
an
initial
brain
dump.
I
think
there's
some
scenarios
that
or
some
other
types
of
artifacts
I'm
not
thinking
of
that.
We
need
to
look
at.
G
Yeah
another
way,
I
guess
to
do
that
instead
of
having
and
here
a
hierarchy,
would
be
that
you
can
have
these
common
attributes
as
mandatory
attributes
and
then
the
other
ones
could
be
optional
and
depending
on
what
type
of
artifact
you
are
talking
about.
Those
will,
of
course,
not
be
optional,
then
to
you,
but
there
was
concealed
the
optional
in
the
whatever
manner
the
metadata
scan
my
schema
or
something
like
that.
E
Some
of
them,
you
know
like
the
base
ones,
like
name
well,
name's,
the
main
one
version
would
be
the
other
one.
Those
would
be
the
two
main
ones
size
is,
you
know
a
size
of
a
hardware.
Artifact
is
questionable
because
we're
trying,
I
I
define
the
the
a
hardware
artifact
is
basically
is
a
file
that
describes
what
the
what
is
on
the
hardware.
So
it's
basically
a
a
description
of
the
hardware.
Now
you
could
do
the
size
of
that
file
would
be
another
required
argument,
but
that's
one
of
those.
G
G
E
I
think
that
would
be
an
interesting
way
to
describe
an
artifact,
and
now
I'd
have
to
look
at.
What
we
need
to
do
is
look
at
what
something
like
the
maven
repositories,
because
they've
been
having
the
most
experience
around
this
like
artifactory
nexus
those
those
repositories
to
see
what
they're
doing
at
that
level,
because
that's
who
we're
what
we're
really
trying
to
describe
the
way
I
look
at
it
is
is,
if
I
want
to
go,
get
an
artifact.
What
do
I
need
to
go?
Get
it?
E
I
need
to
know
the
name
of
it
which
the
path,
the
version
and
then
the
the
the
location.
Those
are
like,
the
four
things
I
need
in
order
to
to
retrieve
something
now.
The
immutable
part
is
where,
like
on
the
docker
side
of
the
digest,
is
the
immutable
id
that
you're.
Referring
to,
I
don't
know
if
we
can
get
to
that
on
a
file
type
you
possibly
could
be
could
by
storing
the
md5
of
the
file
and
use
that
as
the
descriptor
of
it.
But
those
you
know
that.
E
G
Some
sort
of
digest,
yeah
in
a
city
or
clc,
I
see
a
context.
We
would
also
need
a
way
to
to
identify
what
specific
version
or
version
of
the
artifact
that
we
have
run,
for
example,
a
test
for
or
if
we
want
to
to
rebuild
a
certain
integrated
artifact
based
on
some
baseline
or
whatever.
We
need
to
be
able
to
fetch
exactly
the
same
versions
to
rebuild
the
same
thing
again,
so
we
need
to
know
exactly
what
to
have
built.
G
E
B
Excellent
good
good
start
on
this
work,
great
discussion.
I
think
we
should
move
on
to
vance
presentation,
because
we
have
20
minutes
left
in
the
meeting,
and
I
want
to
make
sure
we
have
time
for
it.
We
will
discuss
policy
driven
ci
cd
if
there
is
time
afterwards,
otherwise
we'll
have
to
bookmark
that
for
next
meeting
van
time,
would
you
like
to
present?
Do
your
demo
yeah
great.
D
D
So
it's
the
topic,
so
I'm
going
to
talk
about
continuous
delivery
indicators.
So
it's
a
topic
that
we
wanted
to
address
for
a
while
at
the
emotion
and
recently
we're
starting,
we
started
to
to
collect
metrics
and
to
put
some
visualization
for
it
using
grafana
and
at
the
same
time
there
was
another
track,
other
people
at
work
starting
to
collect
feeling
of
developers.
D
D
We
think
that
it
was
very
interesting
because
it
makes
the
two
efforts
we
are
trying
to
do
like,
at
the
same
time
collect
system
metrics
to
see
how
our
application
and
cicd
platform
was
doing
like.
This
is
an
example,
for
example,
for
one
single
repository,
so
we
can
easily
see
which
version
has
been
released,
deployed
in
staging
or
production.
If
you
have
undeployed
release
in
position,
for
example,
and
for
a
specific
time
range
so,
for
example,
for
the
last
two
weeks
so
the
last
sprint
we
have
a
sprint
of
2x.
D
There
are
lots
of
things
like
release,
interval,
deployment,
interval
and
more
technical
metrics,
too,
or
indicators
such
as
moon
duration
for
the
pipeline
pipeline
failure,
and
things
like
that.
So
it's
not
finished.
We
we
have
other
indicators.
We
would
like
to
try
and
to
add,
of
course,
and,
as
I
said
at
the
same
time,
we
had
some
people
started
to
put
some
internal
framework
to
collect
developers,
productivity
and
feeling
at
the
end
of
each
sprint.
So
this
is
an
example
where
we
can
see
for
a
small
team.
For
example.
D
D
And
so
basically,
it's
a
form
of
that
split
matrix
in
two
categories:
the
matrix
you
can
collect
from
the
system
as
what
we
are
doing
with
insects,
collecting
events
from
the
cluster
or
from
the
gate
system
like
pull,
request,
events
and
so
on,
and
the
survey
metrics
that
you
can
collect
from
asking
questions
to
the
developers
and
into
five
categories:
satisfaction,
performance
activity,
communication
and
efficiency,
space
and
a
different
level,
so
individualized
group
and
the
system-
and
we
can
put
some
metrics
in
different
category
and
novella,
and
what
we'd
like
to
do.
So.
D
So
it's
a
big
complex
in
our
situation,
because
we
have
teams
that
are
working
across
multiple
repositories.
We
don't
have
the
one
repository
or
one
team
per
repository.
So
it's
a
it's
more
complex
but
we'll
try
to
manage
something
so
yeah.
So
we
can
have
a
view
different
view
of
the
system
matrix.
So
this
is
for
sorry
that
one
was
for
a
single
repository.
D
D
And
what
else?
Yes?
As
I
said,
we've
open
sourced
that
in
the
genson6
project,
so
it's
not
enabled
by
default
yet,
but
it's
just
easy
to
enable,
and
the
goal
is
that
people
using
shooting
stacks
can
benefit
from
these
indicators
that
will
be
automatically
collected
from
the
system
and
displayed
in
grafana,
and
they
can
add
more
and
continue
so
how
it
works.
D
D
So
that
works
well
for
general
insects.
In
fact,
it
can
be
easily
adapted
to
a
different
system,
because
that's
the
beauty
of
kubernetes
is
that
everything
is
an
event.
You
can
watch
for
a
lot
of
things
and
when
you
are
practicing,
github
is
the
same
with
your
git
system,
so
you
can
easily
collect
all
kind
of
events,
so
our
smaller
collector
is
then
going
to
store
everything
in
a
simple
postgresql
database.
D
And
so
on
and
after
that,
we
can
use
the
pathfinder
to
to
extract
all
the
data
and
put
some
nice
visualization,
and
the
nice
part
is
that
you
can
mix
multiple
data
sources
with
kafana.
So
we
can
have
one
dashboard
for
an
application
where
we
can
have
a
metrics
or
indicators
for
for
the
cicd
part
of
the
application
like,
for
example,
the
time
to
review,
attempt
to
mail
time
to
release
and
so
on,
and
you
can
also
have
your
blogs
from
your
application
running
in
your
production
system.
D
E
D
E
F
Yeah
no
great
initiative
and
love
the
dashboard,
the
the
spaceware
mark,
that's
something
we
started
looking
at
in
the
end
user
console
and
yeah
I've
read
through
it's
pretty
pretty
interesting
stuff.
Have
you
looked
at
all?
I
know
I
don't
know
if
you've
seen
the
the
four
keys
project
from
google
on
the
the
dora
metrics
itself
is.
D
D
So,
for
example,
we
are
collecting
and
displaying
the
time
for
review
and
it's
a
it's
much
easier
to
understand
for
people
than
to
to
act
on
it,
since
the
mean
lead
time,
which
is
like
too
big.
It
has
two
too
many
steps
in
it.
So
it's
a
good,
it's
good
indicators
to
track
to
give
a
high
overview,
but
we
need
other
indicators
too,
that
we
can
act.
Oh
no,
so
yeah
and
I
didn't
yeah.
D
So
we
are
creating
the
events
we
are
creating
from
the
kubernetes
cluster.
We
are
creating
a
custom
resource
definition
that
have
been
defined
by
by
argentine
so,
for
example,
the
pipeline
custom
resource
definition
or
the
release
open
definition,
but
in
fact
it
can
be
something
else.
For
example,
we
don't
have
to
track
the
pipeline
crd.
We
can
try
because
the
champion
sex
is
built
on
top
of
section.
We
can
strike
tech
pens
pipeline
run
and
it
will
be
similar
the
release.
We
can
also
watch
for
a
git
release.
Events.
C
A
D
D
So
yeah
you
see,
I'm
I'm
looking
to
the
junction
6
api,
but
the
code
is
like
100
line
to
collect
the
pipeline,
so
it
just
it's
just
a
small
small
controller
controller
that
will
watch
for
a
specific
event
and
yeah
and
store
that
in
the
in
a
positive
database.
So
it's
easy
to
change
that
we
can
even
make
make
one
that
can
listen
to
easier
pipeline
or
watching
sex
pipeline
activity.
C
D
C
Know
a
bit
more
things
in
it.
I
understand
I'm
wondering
if
it
would
be
helpful
to
it
would
be
valuable
to
adapt
this
to
the
underlying
pipeline
mechanism,
which
is
really
technon
itself,
and
this
is
something
we
are.
We
are
using
tecton
in
ebay
and
our
next
generation
cd
system
will
be
completely
based
on
that,
and
something
like
this,
this
kind
of
a
metrics
gathering
automatic
metrics
gathering
would
be
huge.
It
would
be
awesome.
Maybe
we
can
contribute
to
to
this
project.
Is
this
something?
That's?
C
C
F
C
F
C
F
C
D
Yeah,
that
would
be
a
good,
a
good
project,
as
I'm
sure
the
other
interesting
part
will
be
how
to
to
to
get
events
from
the
git
system.
So
in
the
context
of
drinking
sex,
it's
easier
because
we
have
lighthouse,
which
is
so.
I
don't
know
if
you're
familiar
with
lighthouse,
but
it's
a
system
that
does
all
the
interaction
between
vector
and
everything
that
happens
inside
the
agency's
x
cluster
and
the
external
repositories,
which
are
hosted
on
github
or
pitt
bucket
or
whatever.