►
Description
Join us for Kubernetes Forums Seoul, Sydney, Bengaluru and Delhi - learn more at kubecon.io
Don't miss KubeCon + CloudNativeCon 2020 events in Amsterdam March 30 - April 2, Shanghai July 28-30 and Boston November 17-20! Learn more at kubecon.io. The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects
Deep Dive: CNCF CI - W. Watson, Vulk Coop & Denver Williams, Vulk Coop
The CNCF CI status dashboard -- cncf.ci -- provides a third party validation of builds, deployments and end-to-end testing for CNCF’s Graduated and Incubating projects. The newest iteration of the cncf.ci status dashboard focuses on supporting a sustainable and scalable project ecosystem. To accelerate adding & maintaining projects on cncf.ci, the status dashboard can integrate with a project’s existing CI System and accept contributions from CNCF project maintainers. This Deep Dive session will include a walk-through of integrating a CNCF project with Travis CI to utilize the Travis CI build status and artifacts in the cncf.ci dashboard and allow time for Q&A.
https://sched.co/UahV
A
We're
gonna
have
three
portions
to
our
agenda
today.
We're
gonna
do
a
introduction
to
the
CN
CF
team
really
quickly
we're
gonna
go
over
the
goals.
We're
gonna
go
over
the
key
features
and
to
do
a
dashboard,
walkthrough
and
then
we're
gonna
get
into
the
deep
dive
which
is
going
to
go
over
the.
How
to
add
a
project
to
CN
CF
CI
we're
gonna
go
over
our
challenges
or
benefits.
Gonna.
Do
a
quick
code
review
and
show
you
how
to
stay
connected
with
us
and
then
a
Q&A.
A
There
we
go
alright,
so
first,
a
little
bit
about
us
we're
the
Volk
cooperative,
a
software
cooperative
based
in
Austin
Texas.
We
started
in
2013.
If
you
want
to
meet
us
in
person
and
you're
in
Austin,
we
have
a,
we
have
various
software
or
various
meetups.
We
have
the
software
cooperative
meetup
and
then
we
also
have
open
source
axes
meet
up.
If
you
want
to
throw
some
axes
with
us,
you
can
also
connect
with
us
on
Twitter,
with
advil
co-op
and
at
open
source
axis.
A
A
Cnc
FCI's
project
consists
of
the
CI
testing
system,
the
status
repository
and
then
the
dashboard.
The
CI
a--
testing
system
validates
the
build
and
deployment
phase
for
the
CNC
f
projects
for
any
commit,
unstable
or
head
and
four
different
architectures
such
as
x86
and
arm,
and
we
do
that
in
a
neutral
environment
on
bare
metal,
a
packet
happens
to
be
the
bare
metal
part
provider.
A
A
Here's
a
overview
of
the
graduated
and
incubating
projects,
there's
eight
graduated
and
fifteen
incubating.
We
also
host
a
Lennox
project,
onap
project
for
the
Lenox
foundation.
It's
this
service
Orchestrator
piece
of
the
oh
now
so
there's
about
35
projects
within
on
that
which
is
one
piece
so
key
features
of
CNC
FCI
we've
got
the
project,
centric
features
where,
basically,
where
we
highlight
and
we
validate
CN
CF
hosted
graduated
and
incubated
project.
So
our
main
goal
is
to
to
demonstrate
stable
and
head
releases
for
the
Graduate
and
incubated
projects.
A
Alright,
the
version
3.
We
also
want
to
streamline
the
way
that
we
engage
with
the
projects
and
the
project
maintainer
z',
so
maintainer
x'
now
can
update
their
own
project
and
release
details
via
a
github
pull
request.
They
also
can
provide
the
helm,
charts
and
smoke
tests
to
us
for
the
deploy
phase,
and
then
we
will
use
their
end
tests
as
well.
So
the
CI
testing
system
is
going
to
integrate
with
the
external
CI
systems
of
the
projects
and
retrieve
their
bill
status
and
their
container
artifacts
and
display
and
use
those.
A
So
CNC
FCI
is
an
agnostic
testing
system.
We
validate
projects
in
a
configurable
and
neutral
test
environment.
The
configuration
at
the
then
you'll
see
when
we
display
the
dashboard,
but
we
can
configure
kubernetes
with
head
and
stable
and
we
our
test
environments
gonna,
allow
you
to
go
between
those
two
things
and
then
also
you
can
configure
the
the
architecture
so
that'll
be
x86
or
arm
and
we
deploy
in
bare
metal.
So
it's
gonna,
that's
where
it's
where
we
call
it
neutral.
So
now
we're
going
to
do
a
quick,
dashboard,
walkthrough.
A
The
test
environment
at
the
top
of
the
dashboard
is
going
to
be
where
we
allow
you
to
select
kubernetes
header
stable,
and
then
we
also
show
container
D
version
there,
and
then
you
have
the
architecture
which
is
x86
or
arm,
and
then
we
display
the
bare
metal
provider
which
is
packet
under
the
test
environment.
There's
a
list
of
projects
so
now
we're
going
to
go
into
the
deep
dive,
how
to
add
a
project.
So,
as
a
project
maintainer
a
quick
show
of
hands,
are
there
any
contributors
here
to
any
of
the
CN
CF
hosted
projects?
A
Ok
as
a
as
a
project
maintainer.
The
first
thing
that
you're
gonna
do
is
go
to
cross
cloud
CI
and
go
to
your
project
name
configuration
and
within
that
repo
you're
gonna
go
ahead
and
fork
it
and
then
go
ahead
and
take
a
look
at
CN,
CF,
CI
yamo,
and
that's
where
you're
going
to
be
doing
mostly
with
configuration
really
all
of
your
configuration
inside
of
CSC
FG
animal
you're
gonna
be
able
to
modify
these
different
elements
here.
A
One
of
the
new
things
for
version
3
is
the
system
CI
system
configuration.
We
have
a
new
element
where
there's
a
list
of
your
CI
system.
Some
projects
have
more
than
one
CI
system
the
elements
here,
our
CI
system,
which
would
be
something
like
Travis
and
that's
one
of
the
systems
that
we
support.
Now
we're
working
on
github
actions
and
also
circle
CI,
the
system
type
is
going
to
be
that's
what
the
Travis
guys
inside
the
project.
A
Url
is
going
to
be
most
likely
a
github
URL
for
your
project
and
then
the
project
name
really
is
the
identifier
within
your
CI
system,
most
likely
it's
the
organization,
slash
project,
name
and
architecture,
is
the
list
of
architectures
that
you
support
in
your
sky
system,
which
would
be
x86,
maybe
arm,
let's
go
through
all
these,
so
challenges
that
we
ran
into
this
is
a
in
my
opinion.
One
of
the
biggest
challenges
that
we
ran
into
is
the
cross
pipeline
problem
within
CNC
FCI.
A
The
cross
pipeline
problem
is
when
you
have
one
organization
with
one
pipeline
and
there
see
ICD
tool,
that's
used
by
another
organization
with
a
separate
pipeline
and
a
totally
separate,
CI
CD
tool.
So
the
quick
show
of
hands.
Do
you
guys
which
who
in
here
has
worked
with
with
even
within
one
organization,
multiple
CI
tools
and
different
pipelines?
A
C
Yeah
42
MIG
I've
worked
for
Acheson
based
in
Stockholm
Sweden
and
involved
in
C
ICD
domain
for
few
years,
like
internally
in
our
organization.
We
have
challenges
exactly
like
this
videos,
different
tools
and
technologies
like
Jenkins,
spinnaker
and
so
on,
and
since
we
are
very
large
or
large
organization
about
hundred
thousand
people,
it
is
very
difficult
to
construct
and
run
complex
and
to
NCI
CD
pipelines
because
they
use
different
tools
and
all
these
tools
have
different
ways
of
doing
stuff
and
there
is
no
straightforward
way
to
again
create
pipelines.
C
Using
these
tools
and
often
we
have
to
create
our
own
scripts
glue
solutions
to
overcome
these
issues
and
on
a
daily
basis.
Our
pipelines
are
broken
because
something
changes
in
Jenkins
that
breaks
our
regular
expressions,
perhaps
and
breaks
our
pipelines
in
addition
to
what
we
are
doing.
Our
company
I
am
also
involved
in
the
u.s.
foundation.
Networking
projects
and
it's
very
similar
to
what
CN
CF
cross
Claudia
is
going
through.
C
We
have
a
deaf
networking
cross
community
CI
there
and
we
are
trying
to
integrate
different
open-source
communities,
projects
to
bring
up
new
telecom
networks
like
n,
FBI
or
CNF
type
work,
and
unfortunately,
we
haven't
had
too
much
progress
there
because
again,
the
same
problem
exists
in
open
source
as
well
cause
OpenStack
uses
a
different
CI
CSF
uses
another.
If
you
look
at
the
next
foundation,
networking
projects
they
use
Jenkins,
and
it
is
nearly
impossible
to
make
these
things
talk
to
each
other
so
to
tackle
this
problem.
C
Actually
we
start
talking
under
contains
the
Reformation
I
know
if
you
heard
that
it's
a
new
foundation
six
months
all
to
actually
deal
with
challenges
like
such
as
this,
and
we
proposed
a
new
special
interest
group
to
work
on
these
things
called
special
interest
group
interoperability
and
Jenkins.
Tecton
spinnaker
folks
joined
two
special
interest
groups.
So
if
you
have
this
type
of
challenges,
if
you
want
to
make
your
voice
heard
come
and
talk
about
the
problems,
the
solutions
you
may
have
shared
these
with
the
other
projects
and
work
on
these
things
together.
C
D
A
E
Hey
so
I'm
a
software
consultant
and
I
end
up
working
at
a
different
lot
of
different
companies
and
we've
run
into
a
lot
of
clients.
Who've
had
this
situation,
we've
experiment
with
a
few
different
options
for
dealing
with
this
one
is
using,
for
example,
a
higher-level
Orchestrator
to
orchestrate
pipeline
triggers
across
several
different
pipeline
technologies.
A
popular
tool
for
that
is
a
de
mist.
E
You
guys
heard
of
that,
but
the
most
the
easier,
more
consistent
way
that
I
found
to
do
this
situation
is
to
develop
the
business
logic
of
my
part,
my
pipelines
and
a
higher
level
or
a
language
like
a
note
or
Goodling,
and
then
compile
that
to
a
CLI
that
can
be
executable
on
all
the
different
pipeline
technology.
So
that
can
be
migrated
more
easily.
A
So
some
of
the
benefits
of
version
3,
we're
gonna,
allow
project
maintainers,
have
more
control
over
the
visibility
of
their
projects
so
for
their
branding,
their
logo,
subtitles
names
and
all
that
stuff
and
then
also
control
their
release.
So
with
the
stable
version
and
the
head
branch,
one
of
the
issues
that
a
project
maintainer
may
run
into
is
that
their
stable
branch
may
be
actually
showing
that
it's
failed.
A
They
may
not
like
that,
so
they
may
want
to
have
control
over
that
and
say:
let's
go
ahead
and
move
the
stable
branch
to
a
previous
version
and
show
that
it's
passing
you
know
so
that
their
customers
or
whoever's
interested
in
their
project
can
see
that
they're
passing
so
up
until
now,
we've
been
managing
that
and
I
think
project
maintainers
are
better
suited
for
that
type
of
thing.
The
version
3
our
pipeline
architecture
took
a
stab
at
trying
to
solve
some
of
the
cross
pipeline
problems.
A
A
So
now
we're
going
to
do
a
little
bit
of
a
code
review,
so
one
of
the
first
things
there's
a
project
maintainer
if
you
come
in
I
mean
after
you've
done
the
previous
steps.
You've
you've
modified,
CNC,
FCI,
animal
and
all
that
stuff.
You
probably
want
to
take
a
look.
We
use
as
our
CI
tool,
CI
CD
tool.
We
use
git
lab
you're
gonna
want
to
go
ahead
and
take
a
look
in
your
project.
Configuration
repo
you're
gonna
want
to
look
at
your
gett
lab
CI
mo
file.
A
We
and
everything
in
there
is
generic,
but
when
you're
gonna
want
to
do,
if
you
want
to
do
any
customizations,
that's
kind
of
what
you're
going
to
be
responsible
for.
If
you
want
to
do
that,
they're
gonna
probably
happen
in
this
file.
What
we
have
in
there
is
a
curl
command
to
the
external,
see
I
what
we
call
the
external
CI
proxy
tool
and
this
CI
proxy.
A
It's
just
gonna,
be
a
coral
command
that
we
have
in
there
and
what
it
does
is
it
goes
ahead
and
it
gets
the
build
status
from
your
CI
tool
right.
So
in
the
future
that
we
have
built
status
right
now,
but
in
the
future,
as
in
May
before
the
end
of
the
year,
we're
gonna
have
the
ability
to
get
the
artifacts
from
your
CI
tool,
hopefully
your
exposing
artifacts
and
then
also
the
test
statuses.
So
actually
that's
another
question.
F
A
F
It's
really
helpful
when
they're
there
for
a
head
that
it
seems
like
it's
from
most
of
the
projects.
Externally,
it's
50/50
they'll
build,
but
it
seems
like
a
common
strategy
when
you're
building
for
a
hit
or
master
release
to
dispose
of
the
artifacts.
But
the
problem
with
that
approach
is
it
makes
it
really
difficult
to
go
back
in
time
and
go
what
happened
back
there?
Did
it
fail
yeah.
A
G
I'm
wondering
if,
as
a
cig,
interoperability
is
looking
at
this
too.
So
we're
talking
about
the
publishing
the
build
artifacts
so
I
know,
and
what
one
of
our
first
integrations
or
it
was
the
first
integration
was
with
ona.
So
you
had
jenkins
was
the
CI
system
used
and
we
were
able
to
actually
get
the
artifact
that
was
created
during
the
build,
which
is
different
from
saying
you
have
a
build
happening
and
it's
running
all
your
tests
and
then
someone
else
happens
to
publish
an
artifact.
G
That's
not
going
to
make
sure
that
those
are
joined
so
that
what
was
tested
and
validated
is
what
you're
downloading
with
own
app.
They
actually
had
that
that
was
like
one
of
the
first,
the
ones
that
we
did
and
that
was
Jenkins
for
the
CI,
and
then
they
used
an
Nexus
for
the
image
repository.
It
doesn't
really
matter.
Where
is
the
the
main
point
was
publishing
on
every
stable
release?
G
You
you
did
a
CI
built
for
it
and
and
then
published
it
and
then
their
master,
our
what
was
essentially
nightly,
builds
of
whatever
was
on
master
had
that
was
happening,
so
we
could
actually
match
the
build
that
was
shown
with
the
artifact
or
the
image
that
we
download
from
there.
So
that's,
ideally
what
we
want
and
I'm
wondering
if
that's
like
on
the
agenda
for
accessing
and
if
anyone
else
has
been
thinking
about
that,
and
ideally
we
could
look
at
like
specification
around
that,
because
the
regex
is
and
stuff
that
was
mentioned.
C
Yeah,
actually,
we
propose
to
seek
yesterday,
so
it's
pretty
young
and
if
you
go
and
look
at
the
pull
request,
we
submit
to
continue
the
Reformation
github
repo.
This
is
one
of
the
problems
we
highlighted
passing
metadata
and
artifacts
across
different
pipelines
because,
like
you
can
get
artifacts,
but
it
can't
be
a
random
man.
You
have
to
pick
and
choose
what
you
want
to
get
and
pipelines
should
provide
all
the
metadata
about
all
the
artifacts
and,
as
you
said,
there
is
no
even
de-facto
standard.
C
How
to
do
this,
and
this
picture
not
just
Jenkins,
is
involved.
Artifact
repositories
are
involved
test
without
the
system
system
or
and
all
these
things
could
be
put
together
and
present
to
whoever
might
be
interested
in
those
artifacts.
So,
yes,
this
is
one
of
the
areas
we
want
to
work
on
and
again
it's
in
the
proposal.
C
But
since
we
haven't
start
yet
it's
not
that
book,
yet
we
will
present
it
for
approval,
just
come
and
join,
and
we
talk
about
these
things
and
there
are
other
ideas
around
interoperate,
because
when
you
talk
to
people,
some
people
bring
up
questions
like
what
you
asked
passing
metadata
and
artifact.
Some
others
are
more
interesting.
Common
pipeline
languages,
for
example.
That's
another
interoperability
issue.
C
If
we
had
a
pipeline
language
or
templating
that
could
help
end
users
to
change
their
tooling
without
breaking
their
pipelines
just
porting
to
pipeline
on
another
tool,
so
that
could
be
different
areas.
We
can
focus
on
this.
Second
people
interested
in
different
parts
can
take
part
in
those
things.
Have
conversations
drive
the
topic
write
the
specifications
release
white
papers
whatever
to
raise
the
awareness.
So
long
answer.
Sorry,.
A
All
right,
so
this
is
optional
for
the
project
maintainers.
Everything
that
we
that
we
talked
about
up
until
now
is
all
kind
of
mandatory.
Here
this
is
optional,
so
what
we
provide
for
collaboration
is
a
way
and
what
we
would
like
is
for
people
to
help
us
in
building
CI
proxy
plugins.
They
said
before,
we've
got
Travis
working,
we've
got
and
we're
working
on
github
actions
and
circle
CI.
A
What
we
would
would
like
us
for
more
people
and
maybe
specialized
custom
plugins
are
also
an
option
here
for
people
to
submit
pull
requests
and
even
maintain
their
own
plugin.
So
what
is
the
CI
proxy
plugin?
It's
a
simple
Thea
CLI
tool
like
what
we
were
talking
about
earlier,
consuming
status,
information
from
a
project
CI
CD
pipeline.
So
we
try
to
make
it
as
simple
as
possible.
A
The
API
the
API
is
going
to
be
be
for
project,
which
is
going
to
be
the
identifier
in
that
CI
CD
tool
and
then
C
for
the
commit
reference
t
for
tagging
and
as
a
right.
Now
the
the
response
is
going
to
be
tab
delimited
and
we
have
the
build
status,
success/failure
running
and
the
build
URL,
and
so
for
the
dashboard.
That's
what's
going
to
get
consumed
as
far
as
a
plugin.
A
So
why
even
have
a
CI
proxy?
In
the
first
place,
we
want
to
have
a
one-stop
shop
for
the
build
status
and
the
artifact
links
and
possibly
the
integration
test
results,
and
so
when,
if
you
decide
to
make
a
CI
plug-in,
you'll
also
need
to
make
a
pull
request
to
make
us
aware
that
there's
a
new
plug-in
avail
and
the
way
to
do
that
is
to
modify
the
CI
plugins
animal,
which
is
an
exe
I
proxy
repo.
And
so
you
have
four
elements:
yeah
mo
elements
that
you'll
need
to
modify
and
add.
A
So
there's
gonna
be
the
name
of
your
CI
plug-in.
You've
got
the
interface
which
is
most
likely
a
CLI
style.
You've
got
the
repo,
which
is
your
repo,
for
what
your
plug-in
that
you
made
and
then
the
ref
as
far
as
we're
gonna
expect
you
to
have
certain
releases
or
proper
releases
for
your
plug-in
and
everything
like
that.
So.
A
A
B
Hey
probably
this
is
a
couple
of
questions
are
going
to
be
repeat:
I
had
a
good
chat
with
general
yesterday
by
the
way
I'm
Omar,
we
are,
the
maintenance
of
sandbox
project
called
open
ideas.
We
have
a
very
similar
I
mean
like
a
kind
of
a
clone
of
what
is
CNC,
have
cross
cloud
CI
long
back,
but
I
have
couple
of
questions
the
e2e
tests
that
you
have.
Maybe
there
are
only
few.
How
do
we
get
the
visibility
of
the
Ute
test
from
the
dashboard?
I
can
see
the
build
and
the
success
badges.
F
All
right
so
right
now
with
the
v3,
we
actually
went
for
a
stage
where
we've
kind
of
disabled
DHS,
because
we're
migrating,
but
once
we're
in
a
belen.
What
we're
wanting
to
do
is
work
with
upstream
projects
that
already
have
tests
in
a
way.
That's
similar
to
this
is
have
a
configuration.
That's
high
level
be
able
to
go.
This
is
a
CI
system
and
these
are
artists,
and
these
are
how
to
execute
them
and
then
that
in
a
badge
under
the
Ito
ETS
column
will
be
populated.
F
B
And
the
second
question
is
on
the
backend
platform:
you
said
you
or
using
packet.
If
the
e2b
tests
are
going
to
be
long
and
then
which
are
going
to
require
some
obviously
more
resources
than
just
the
build.
How
is
that
going
to
happen?
You
have
certain
pool
of
packet
clusters
or
you
know
what,
if
I
want
to
run
a
little
bit
of
a
scale
testing
as
part
of
my
ete,
which
requires
about
10
to
12
nodes
or
is
that
work.
F
All
right,
so
that's
something
that's
also
coming
when
we
populate
that
you
do,
we
feel
we're
gonna.
Add
things
like
configuration
for
how
big
is
your
work?
What
resources
do
you
need
so
then,
when
the
tests
run
we'll
go
through
that
configuration
go
okay.
This
is
the
amount
of
resource
link
to
provision
our
cube
entities,
cluster
the
size
and
then
execute
the
tests.
B
H
B
D
D
We
have
a
lot
of
different
projects
that
all
have
kind
of
their
own
special
snowflake
CI
and,
in
some
cases
their
own
special
snowflake
CD
and
we're
kind
of
actively
in
the
process
of
trying
to
unify
some
of
that
stuff
and
present
some
unified
dashboards
and
this
kind
of
stuff,
so
technology
that
feels
very
similar.
So
I
guess
the
question
is:
what's
your
advice
for
an
organization?
That's
trying
to
kind
of
wrangle
this
stuff
together
and
really
kind
of
drive
home
consistency
and
sort
of
transparent
view
for
everyone.
A
Well,
definitely
would
recommend
forking
the
project
and
trying
to
solve
some
of
the
problems
with
using
CNC
FCI
I'm
interested
in
hearing,
and
maybe
we
can
talk
later.
Cuz
we've
got
one
minute,
but
in
hearing
about
your
story
as
far
as
what
you're
doing
right
now
with
your
pipelines
and
probably
we
can
try
to
direct
the
way
that
we're
doing
our
development
to
try
to
help
what
it
is
that
you
guys
are
doing.
Yeah.