►
From YouTube: Helm: The Charts and the Curious - Karena Angell, Paul Czarkowski, Andrew Block & Scott Rigby
Description
Don’t miss out! Join us at our next event: KubeCon + CloudNativeCon Europe 2022 in Valencia, Spain from May 17-20. Learn more at https://kubecon.io The conference features presentations from developers and end users of Kubernetes, Prometheus, Envoy, and all of the other CNCF-hosted projects.
Helm: The Charts and the Curious - Karena Angell, Paul Czarkowski & Andrew Block, Red Hat; Scott Rigby, Weaveworks
Have you ever wondered, how can I improve the processes and tooling around my Helm Chart development and distribution? Just like with a programming language, there are OSS projects in the Helmiverse, such as linters, testing tools, and automation you can use to help you with charts. In this session, you’ll learn about some of these tools and how you can use them to improve your workflow and CI automation. Along the way you’ll learn about supply chain security, GitHub actions, YAML validation, tools you can use in any CI system, and more. Charts are at the heart of using Helm, in this session you’ll learn how to have a healthier heart.
A
A
We
do
like
them
all
right,
so
we're
going
to
run
through
quick
intro
which
and
then
paul's
going
to
get
into
building
charts
and
then
we're
going
to
talk
about
publishing
and
if
you
want
to
get
involved,
go
to
helm.sh,
you
know,
go
read
through
what
helm
really
is
and
all
the
community
stuff
is
there
and
join
the
community
they're.
Actually
really
nice,
there's
rumors
about
that
too.
A
A
A
A
However,
your
helm
charts
is
an
amazing
package
manager
and
we'll
talk
about
the
primary
components
that
we
have.
So
your
home
charts
are
packages
that
represent
your
kubernetes
deployable
resources.
We
just
talk
about
all
the
different
resources
that
you
have
to
worry
about,
and
your
values
are
the
configuration
variables
that
are
injected
into
your
templated
resources
and
your
release
is
a
consolidation
of
those
resources
and
its
and
your
values
and
as
your
deployable
resource
into
kubernetes.
C
Hi
everyone,
my
name,
is
paul
chakovsky
and
I
also
work
at
red
hat
and
I
kind
of
just
want
to
get
get
going,
so
we
want
to
create
a
chart.
How
do
we
do
it
like
when
you're,
creating
a
new
project,
there's
a
ton
of
boilerplate
and
you're
doing
copying
and
pasting
and
stuff,
and
we
didn't
want
everyone
to
have
to
worry
about
boilerplate,
and
so
we
built
what
we
call
well.
Actually,
let's
talk
about
the
actual
anatomy
of
a
chart?
I
forgot
about
this
one.
C
So
we
have
the
chat.yaml
file
and
that
is
where
the
metadata
for
your
chart
lives,
so
its
name,
its
version,
any
dependencies
it
might
have,
etc.
There
is
a
templates
directory,
which
is
where
your
templates
live,
and
inside
of
that
is
a
couple
of
special
things.
You
have
your
helpers
file
and
that's
where
you
can
create
reusable
blocks
of
code
to
use
as
functions
inside
of
your
charts
and
you
have
the
notes.txt
file
and
that
doesn't
get
rendered
into
your
cluster.
C
It
gets
rendered
into
the
cli
when
someone
does
helm,
install
or
helm
upgrade.
So
you
can
provide
breadcrumbs
and
hints
to
your
application
users
on
how
they
can
access
the
app
once
it's
deployed
based
on
the
various
decisions
they
made
when
they
were
creating
the
values
file.
That
says
how
they
want
it
to
look,
and
that
leads
into
the
values
file,
which
is
kind
of
a
well-written
values
file
is
the
contract
between
the
the
helm,
like
the
chart
creator
and
the
chart
deployer.
So
it
contains
it's
a
yaml
file.
C
It's
a
list
of
keys
and
values
that
are
rendered
into
the
templates
and
contains
the
defaults,
and
so
the
user
will
then
change
those
defaults
to
suit
their
environment.
And
if
you
document
that
really
well,
it
does
really
become
that
contract
between
the
person
who
writes
the
chart
and
the
person
that
runs
the
chart.
C
So
we
don't
want
you
to
have
to
do
a
bunch
of
boilerplate,
because
you
know
any
programming
language,
there's
tons
of
boilerplate
you
need
to
go
through.
We
just
want
you
to
be
able
to
get
to
a
running
chart
that
you
can
modify
so
we
have
helm
create,
and
this
will
give
you
that
functional
chart
and
that's
what
gives
you
this
directory
structure.
That
is
your
your
chart
and
it's
just
enough
to
deploy
a
basic
nginx
application.
So
you
can
do
helm,
create
helm,
install
and
you'll
get
a
running
application
in
your
cluster.
C
So
then
you
just
start
changing
things
in
the
template.
Like
the
image
name,
you'll
change,
some
ports,
you
might
add
some
resources
like
a
config
map
or
a
secret,
but
you'll
just
use
the
same.
You
know
the
same
boilerplate
at
the
front
of
the
other
templates
and
copy
them
across.
So
there's
still
going
to
be
some
boilerplating,
but
it's
a
lot
less.
C
So
yeah,
so
this
is
kind
of
what
the
templating
looks
like
it
uses
the
go:
templating
language
and
there's
a
series
of
functions
in
sprig
which
are
brought
in
and
there's
a
couple
of
helm
specific
functions
as
well.
So
the
double
curly
braces
is
the
templated
bits.
It
is
pretty
straightforward,
but
also
is
templating,
so
it's
also
incredibly
complicated
when
you
do
complicated
things
and
that's
just
the
nature
of
this.
I
have
discovered
that
github
copilot
is
really
good
at
filling
filling
in
these
sections.
C
C
Okay,
I'm
gonna,
give
you
up
on
that,
and
so
this
default
set
of
templates
are
really
good,
but
chances
are
you
have
your
own
opinions?
You
have
your
own
processes.
You
have
things
that
are
unique
to
your
organization
that
you
to
embody
into
your
templates
and
it's
the
same
pieces
in
all
of
your
charts
right,
and
so
we
have
a
couple
of
ways.
You
can
do
this,
you
can
do
you
can
create
starter
charts
and
then
you
can
have
library,
charts
and
we'll
talk
about
the
library
charts
in
a
bit.
C
Let's
start
with
the
starters,
so
helm
starters
lets
you
create
your
own
boilerplate
templates.
So,
instead
of
doing
helm,
create
you
do
home,
create
and
specify
your
ch,
your
starter,
and
that
is
more
or
less
just
a
regular
chart
that
has
all
of
your
opinions
in
it
say
you
always
have
a
specific
set
of
like
prometheus
service
monitors,
or
you
have
a
specific
way.
You
want
everything
to
have
istio
endpoints,
you
would
put
those
into
your
starter
and
that
way,
anytime,
you
create
a
new
chart.
C
Those
bits
would
show
up
and
just
be
part
of
the
chart,
and
that
saves
you
a
lot
of
copying
and
pasting
and
the
helm
ecosystem
has
some
really
good
examples
of
starters.
If
you
want
to
figure
out
how
to
get
going
and
then
out
of
salesforce,
we
have
a
really
good
home
plug-in
for
managing
helm
starters,
so
it
becomes
pretty
easy
and
quick
to
you
know,
embody
your
own
thoughts
and
processes
and
best
practices
into
the
defaults
for
whenever
you
do
a
helm
create.
C
So
I
mentioned
library
charts
as
an
alternative
met
as
an
alternative
to
provide
opinions.
So
let's
talk
about
our
two
chart
types,
so
this
is
a
chart.yaml
file,
which
I
kind
of
mentioned
earlier.
The
helm
three
chart
chartspec
apart
from
the
name
version
dependencies
has
added
a
type
and
that
type
is
either
application,
which
is
the
default
or
it
is
library
which
is
this
type
of
library
chart.
C
So
the
library
charts
define
primitives
or
definitions
that
can
be
shared
in
other
charts,
so
library
charts
don't
render
into
templates
that
get
applied
to
kubernetes.
They
become
things
that
your
chart
can
consume
to
make
your
life
a
little
bit
easier,
and
so
you
can
use
them
across
charts
to
like.
I
have
these
opinions
about
pvcs.
C
So,
instead
of
writing
this
massive
block
about
pbcs,
I
can
just
like
call
like
my
own
pbc
function
and
let
it
kind
of
build
that
out
and
so
you're
able
to
start
codifying
your
own
opinions
standards
into
your
charts
and
bitnami
anytime.
I'm
like
how
should
I
do
this.
I
go
and
look
at
the
bitnami
helm
charts
because
they're
kind
of,
in
my
mind
at
least
the
way
to
do
charts
right
is
the
way
bitnami
does
them
and
they
have
an
excellent
common
library
chart.
C
So
if
you
want
to
get
a
better
idea
of
like
good
ways
to
do
library
charts,
I
highly
recommend
looking
at
the
bitnami
chart
library
chart
and
how
they
do
it
and
also
any
other
things
you're
thinking
about
best
practices.
You
know,
reading
documentation
is
great,
but
sometimes
seeing
really
well.
Written
charts
like
in
practice
is
better,
so
I
always
look
to
the
bitnami
charts
anytime.
I
have
questions
myself
about
a
particular
way.
C
I
should
be
doing
something
so
back
to
our
chat.yaml
file,
so
this
is
a
chat.yaml
from
a
bitnami
chart
that
has
that
is
using
both
a
library
chart
and
an
application
chart
as
dependencies.
So
you,
basically
you
write
your
chart.
You
want
to
use
your
library
chart,
add
that
as
a
dependency
and
then,
if
you
want
to
have
something
else,
like
a
mysql
database,
you
could
add
a
bunch
of
templates
to
run
my
sql
inside
of
your
chart.
C
And
then
you
can
also
you
can
also
say
no
thanks
to
the
dependencies
you
can
see
the
database
chart
there
has
it
enabled
true
you
can
set
that
to
false
in
your
values
and
that
will
allow
you
to
use
your
own
mysql
chart
if
it's
my
sequel
or
whatever
that's
in
there
or
mariadb,
and
so
that's
giving
a
lot
of
still
giving
a
lot
of
power
to
your
end
user.
But
it's
also
giving
them
a
lot
of
good
same
defaults
and
not
you
don't
have
to
redo
a
bunch
of
work.
C
A
couple
of
helm
life
cycle
features.
I
want
to
talk
about
hooks
and
lookups,
so
hooks.
Allow
you
to
provide
some
control
over
the
over
the
order
in
which
things
happen
when
you're
deploying
a
chart
or
upgrading
a
chart,
but
helm
is
not
an
orchestrator
right.
So
don't
think
you
can
get
full
orchestration
you're
getting
some
ability
to
say.
C
Oh,
I
need
to
make
sure
this
config
map
needs
to
be
created
before
this
pod
does
or
more
importantly,
I'm
about
to
do
an
upgrade,
and
therefore
I
need
my
database
to
be
like
migrated
to
the
new
schema.
So
I
can
have
a
hook
to
say
before
I
actually
do.
The
upgrade
run
run
a
job
to
migrate.
The
schema
then
do
the
upgrade
and
they
are
defined
as
annotations
in
the
templated
resources,
so
they're
pretty
easy
to
slip
in
there
and
they
can
do
be
done.
C
Pre
and
post
certain
events
through
the
life
cycle,
they're
pretty
straightforward
and
there's
not
a
ton
of
them.
This
is
kind
of
the
list.
One
here,
quick
mention
is
there's
a
test
one,
and
so
when
you
want
to
do
integration
tests,
if
you
annotate
resources
with
the
test,
they
won't
be
rendered.
Unless
you
run
a
helm
test
and
that
way
you
can
deploy
your
app
and
then
you
can
run
a
helm
test
and
it
will
run
jobs
pods,
whatever
you've
asked
for
to
actually
validate
that.
C
What
you've
got
is
what
you
asked
for
and
that's
how
we
can
then
look
at
doing
integration
tests
when
we're
actually
wrapping
it
into
our
like
software
delivery
pipelines
now
lookups,
maybe
they're
not
exactly
life
cycle
specific,
but
they
provide
a
way
for
you
to
actually
look
at
your
kubernetes
cluster
and
find
information
on
it.
So
there
are
times
where.
Maybe
you
need
a
something
that's
in
a
config
map,
but
you
need
to
actually
put
it
in
a
manifest
because
the
app
doesn't
know
how
to
read
a
config
map.
C
So
you
can
look
up
a
particular
key
in
a
config
map
or
you
can
look
up
anything
else
in
kubernetes
and
then
render
that
into
the
template
and
that
can
be
incredibly
useful
at
times.
But
there's
kind
of
a
last
resort
thing.
If
you
can't
do
it
another
way,
because
if
someone
runs
helm,
template
and
just
applies
that
they
might
not
have
a
kubernetes
cluster
like
that
they're
connecting
to,
and
so
there's
nothing
to
look
up
against
and
you'll
get
an
error
right.
C
So
if
you
do
something
like,
if
you
do
lookups
or
you
do
hooks,
you
want
to
really
think
about
that.
Your
end
users
use
case
and
if
they,
if
they
may
be
doing
just
a
home,
template
make
sure
that
they
can
still
get
a
fully
functioning
application,
even
if
the
hooks
and
the
and
the
lookups
don't
function.
If
you
have
them.
So
it's
just
something
to
keep
in
your
mind.
C
If
you
know
that
your
users
will
never
use
helm
template,
then
of
course
you
can
get
really
deep
into
your
hooks
and
look
ups
and
then,
of
course,
we
all
want
to
be
secure.
None
of
us
are
security
experts.
Well,
some
of
you
might
be,
but
I'm
not,
but
I
do
know
some
things
right.
I
know
that
every
pod
should
have
a
security
context.
C
That
says,
don't
run
this
container
as
root,
so
we
should
think
about
how
we
can
integrate
that
with
our
charts
to
give
users
the
ability
to
turn
those
on
and
off,
because
some
people
will
be
deploying
into
insecure
kubernetes
clusters
and
they
won't
care
if
it's
rude
or
not.
Some
people
were
deploying
into
clusters
that
are
inside
of
their
enterprise
that
have
very
strict
rules:
they're
running
oppa,
they're,
running
gatekeeper,
they're
running
something
that
will
actually
break
the
chart
from
running
the
home
chart
from
installing.
C
If
you
don't
have
a
good
security
context,
so
you
want
to
provide
that
way
for
those
people
to
use
your
chart.
Otherwise,
it's
going
to
fail
and
they're
going
to
move
on
and
they're,
not
going
to
use
your
chart
and
they're
not
going
to
get
the
opportunity
to.
You
know,
use
your
work
and
then
things
like
config
map
secrets,
think
about
which
values
should
be
in
which
and
also
think
about
how
people
might
use
external
sources
like
mozilla,
stops
sealed
secrets
or
hashicorp
vault.
C
So
if
you're
providing
secrets,
provide
them
an
alternative
way
to
use
a
pre-existing
secret
or
something
else
so
that
they
can
use
your
app,
even
if
they're
using
say
hashicorp
vault
operators,
so
we're
not
we're
not
at
war
with
operators.
There's
not
this
big,
like
operator,
verse,
helm
thing,
deploying
operators
and
their
operands
with
helm
is
such
a
common
use
case
that
if
you
go
to
artifact
hub,
which
scott
will
talk
about
in
a
bit,
you'll
see
a
ton
of
operators
and
then
operands
in
there
that
you
can
deploy
using
helm.
C
But,
as
I
said
earlier,
helm
is
not
a
orchestrator,
and
so
it
can't
really
be
aware
of
the
special
activities
that
you
might
be
done
to
upgrade
say
your
specific
operators
crds
and
the
resources
they
manage,
because
sometimes,
when
you're
upgrading
operate,
you
have
to
do
things
in
very
specific
order
and
helm
isn't
really
built
to
be
that
orchestrator.
So
we
took
a
fairly
naive
approach
and
we
said
you
can
have
a
crds
folder
and
anything
you
put
in.
C
There
is
a
straight
kubernetes
file
that
is
holding
your
cds,
they're,
not
even
templates,
and
we
will
deploy
them
before.
We
render
the
templates
and
apply
the
templates
to
your
kubernetes
cluster.
If
you
need
something
more
than
that,
you
may
need
to
reach
outside
of
helm
and
that's
okay,
because
we
should
be
able
to
pipe
these
tools
together.
C
C
C
So
that's
where
you
do
integration
tests,
so
you
can
deploy
your
chart
run
tests
make
sure
everything
is
there
and
everything
is
how
you
want
it
to
be,
and
you
know
again
you
do
that
locally,
but
you
also
want
that
to
be
part
of
your
software
factory,
which
scott
will
talk
about,
and
I
think
that
is
about
all
I
want
to
talk
about.
Oh
no,
there
was
one
other
thing:
don't
make
clever,
charts
right,
you're,
a
human
writing,
a
thing
for
other
humans
to
use.
C
B
B
B
B
We
can
use
the
helm
package
command
to
take
all
those
artifacts
and
put
it
into
a
compressed
archive.
That
archive
is
very
good,
very
simple,
but
it's
only
step.
One
step
two
is
looking
towards
the
future.
The
future
is
adopting
a
lot
of
the
paradigms
that
are
out
there
in
the
in
the
kubernetes
and
cloud
native
ecosystem
and
being
able
to
publish
it
using
oci
content.
How
many
of
you
have
heard
of
image,
registries
or
registries
at
all
that
support
additional
content?
Aside
from
traditional
container
images?
B
B
So
the
bigger
question
is
for
security.
I'm
very
security
minded,
I'm
sure.
You're
gonna
hear
a
lot
about
security
in
this
you
know
the
whole
conference.
How
many
of
you
are
signing
your
helm
charts!
That's
about
right
for
those
of
you
who
aren't
signing
your
health
charts.
Why
is
it
either?
Because
you
know
that
there's
a
feature
now
or.
B
B
C
B
I
I
I'll
be
honest
embarrassed.
I
did
struggle
a
little
bit
when
I
was
preparing
the
demo
that
I'm
gonna
show
getting
the
keys
set
up.
It's
a
pain,
it's
okay,
to
to
use
the
supportive
mechanisms
of
signing
charts.
Now
all
you
have
to
do
when
you're
packaging
a
chart
is
pass
in
the
dash
dash
sign
flag
point
to
where
your
key
store
is,
and
you
get
a
brand
new
signed
helm
chart.
What
it
will
do
is
it
will
create
a
providence
file.
It's
a
separate
file
right
next
to
your
artifact.
B
A
dot
prov
file
is
going
to
contain
your
detached
pgp
signature
and
some
metadata
about
your
chart.
The
checksum,
as
well
as
the
chart.yaml
file,
that's
step,
one!
That's
what's
supported
right
now,
let's
go
ahead
and
glaze
into
the
magic
future.
The
future
is
going
to
be.
How
do
we
make
signing
content
easier
and
one
project
that
aims
to
do
so
is
called
six
store?
How
many
of
you
have
heard
of
stick
store?
B
Zig
store
is
a
linux
foundation,
sponsored
project
that
aims
to
make
signing
and
verifying
content
easier,
and
the
home
community
has
a
a
plug-in
available
for
you
to
go
ahead
and
take
a
signed
chart
that
you
use
with
helm,
helm
package
sign
and
upload
it
to
what
they
call
a
transparency.
Log
transparency
log
allows
anyone
to
go
ahead
and
see
if
any
content
has
been
signed
and
verify
it
in
a
supported
way.
This
is
very
common
in
the
certificate
world.
B
We
want
to
extend
it
beyond
certificates
to
artifacts
as
well,
so
we
can
go
ahead
and
take
the
helm,
helm
package
that
you
created
and
publish
it
up
to
recore
record
is
the
same
store
project,
for
that
is
a
transparency
log
and
we're
going
to
walk
through
that
in
a
demo
in
a
second.
It
is
currently
a
you
know.
B
First
version
of
it
right
now
out
there
in
the
community
we're
going
to
be
working
with
the
entire
community
as
a
whole
to
talk
about
how
we
can
adapt,
enable
and
advance
the
technology
to
potentially
support
additional
mechanisms
of
signing
content.
That's
the
goal,
so
we
might
be
able
to
get
away
from
the
pain
of
pgp.
D
B
Techton
pipeline
that
enables
you
to
publish
release
and
then
use
tools
like
chart
releaser,
which
that
we'll
talk
about
to
sign
a
content.
This
is
just
a
typical
tech
time
pipeline
that
will
do
a
complete
release
process.
You
know
basically
take
an
existing
chart
package.
It
up
go
ahead
and
push
it
out
to
github,
which
is
going
to
be
our
hosted
repository
and
then
use
selmstick
store
to
publish
to
the
record
transparency
log.
As
you
see,
we've
gone
ahead
and
published
it
out.
We
have
a
release
out
in
github.
B
We
now
have
our
chart
repository
using
github
pages,
so
it's
now
available
for
verifying
the
helm
chart.
There
are
two
ways
to
do
it.
One
is
the
supported
mechanism.
First
thing
we
need
to
do
is
add
that
home
repository
that
we
now
have
it
published
to
github
we'll
go
ahead
and
add
that
we'll
then
pull
in
the
latest
updates
to
our
local
cache.
B
B
Now,
let's
go
ahead
and
let's
look
into
the
future
and
see
how
we
can
do
it
with
sig
store.
The
first
thing
we
need
to
do
to
enable
stick
store.
Verification
is
to
init
to
add
the
helm,
stick
store,
plug-in
so
we'll
go
out.
Add
the
elements.
Third,
stick:
six
store,
plugin,
we'll
then
go
ahead
and
use
the
helm.
B
Six
store,
verify
command
and
point
it
at
our
archive
that
we
have
locally,
it's
gonna
go
to
record,
say:
is
there
content
up
there
if
there
is
great
see
if
it's
there
and
then
do
a
quick
verification
of
it
using
a
lot
of
the
same
things
that
helm
does?
We
can
then
go
ahead
and
take
that
uuid
that
came
out
from
it?
This
is
a
universal
id
in
recore
and
go
ahead
and
actually
see
the
data
in
recore
in
record.
We
capture
the
signature,
the
public
key
and
other
key
content.
B
So
you
can
really
understand
what
content
is
out
there,
so
you
can
verify
so
nothing's
been
tampered
with
or
modified
as
part
of
your
software
supply
chain.
This
is
key.
Being
able
to
do
this,
extend
it
to
because
we've
already
done
it
for
images,
let's
go
ahead
and
extend
it
to
home
content
as
well.
B
So
so,
as
you
see,
we
went
ahead
and
provided
an
automated
packaging
signing
and
release
process
using
tekton
we've
populated
a
helm
chart
repository,
we
published
that
to
recore
we've
gone
ahead
and
used
this
helm
six
store
plug-in
to
be
able
to
verify
this,
as
well
as
using
the
integrated
helm
solutions.
I'm
gonna
pass
it
over
to
scott
who's.
Gonna
talk
a
little
bit
more
about
testing.
D
D
D
D
Thank
you
alison.
Let's
give
allison
a
big
hand
and
the
tech
people,
oh
my
gosh,
okay,
perfect,
all
right,
so
andy
was
just
talking
about
six
store.
This
is
our
transition
slide.
Paul
earlier
talked
about
chart
testing
that
you
do
during
your
chart
building
and
just
for
a
time
check.
I
think
we
have
five
minutes
I'll,
try
to
keep
it
under
that,
so
that
we
might
be
able
to
squeeze
in
a
question
or
two
and
also
if
we
don't
get
to
that.
Just
remember
we
are
here.
We
can
chat
with
you
afterwards.
D
There's
also
helm
folks
online,
but
everybody
in
the
room
come
chat
with
us.
If
we
don't
get
too
many
q
as
questions
okay,
so
basically
that's
the
that's
the
stage
you
want
to
use
helm
testing.
You
want
to
make
sure
to
do
that.
It's
really
great!
Just
remember
you
know,
even
if
you
don't
have
helm
tests,
even
if
you
haven't
written
helm
tests,
you
can
still
use
helm
testing,
because
it's
a
great
it's
a
great
tool.
D
There
is
once
you
get
past
the
just
the
helm
test
command
that
you
run
locally.
There
is
a
great
project
out
there
that
members
of
the
helm,
charts
and
chart
tooling
team
have
been
managing
all
this
time,
including
reinhardt
and
and
other
fine
folks,
here,
called
helm.
Chart
dash
testing
use
that
when
you
get
to,
you
can
actually
use
that
locally,
not
just
for
automation,
but
especially
once
you
get
to
the
automation
phase,
it
will
run
other.
It
will
do
other
things.
Besides
just
run
tests,
you
may
not
have
written.
D
So
if
your
charts
don't
have
tests
which
many
don't
it
will
actually
help
by
installing
those
charts,
but
you
know
spinning
up
a
kind
cluster
installing
those
charts,
at
least
the
action.
Does
you
can
do
this
yourself
in
any
way
you
want
is
try
to
install
those
charts.
It
even
has
flags
to
help
you.
D
If
you
have
any
values
in
the
values
file
that
are
star
dash
values
it
will,
it
will
automatically
run
those
sequentially,
so
you
can
actually
have
dev
dot
values
or
any
other
test
cases
that
you
want
and
the
helm
testing
tool
automatically
run.
Those
for
you
and
the
last
thing
that's
really
important.
I
wanted
to
just
mention
before
moving
quickly
from
from
testing
is
the
helm
chart
testing
tool
can
help
can
help
you
make
sure
to
automate
that
upgrading
between
versions
of
charts
works?
D
So
you
can
pass
that
flag
and
it
won't
the
the
the
ability
to
upgrade,
and
it
will
do
that
just
go
to
helm,
chart
testing
github
repo,
all
the
commands
are
there
all
the
flags
are
there.
I
won't
like
get
too
into
the
details
here,
but
please
just
like.
If
you
walk
away
with
anything
around
testing,
do
it
please
it's
really
awesome.
Okay,
so,
let's
see
wait
did
I
actually
mention
the
github
action?
D
I
did
okay,
so
so
here
are
just
some
links
and
we'll
make
these
slides
available
to
everyone.
But
that's
where
you
find
the
stuff
and
then
also
there
are
there
is
a
demo.
I
want
to
point
you
all
to
that.
Some
people
haven't
noticed.
That's
in
the
helm,
github
org
called
charts,
repo
actions,
demo
and
yeah.
So
that
is
something
that
we
wrote
to
be
able
to
help.
People
just
see
an
exact,
an
exact
working
example.
D
If
you
find
it's
behind
open
a
pr,
but
it's
usually
kept
pretty
up
to
eight
excuse
me
pretty
up
to
date,
and
you
can
pretty
much
just
emulate
that
and
you're
already
on
your
way.
So
there
are
lots
of
other
cool
tips
and
tricks.
You
can
do
paul
mentioned
annotations
earlier,
the
the
the
hook,
the
helm
hooks
for
testing,
just
one
tiny
tip
I
want
to
mention
before
we
move
on,
is
that
you
can
use
helm's
post
delete
hook
to
mixed
with
the
test
annotation.
D
D
Okay,
so
just
let's
see
time
check
here,
11,
34,
okay,
we
got
one
more
minute,
so
publishing
charts.
I
just
want
to
mention
what
it
is.
It's
a
core
concept
for
help.
This
was
already
discussed.
A
bit
packages
were
discussed.
I
think
the
most
common
thing
is
using
well.
What
we're
seeing
is
using
github
pages
to
package
them,
but
there's
other
methods.
There
are
just
the
main
thing
you
need
to
keep
in
mind.
Is
it's
just
an
index
file
with
metadata
that
points
to
a
chart?
D
Excuse
me
a
helm,
repo.
It's
just
an
index
file
with
metadata
that
points
to
the
locations
of
your
packages.
That's
it,
and
so
it
can
just
be
an
http
server.
It
can
be.
There
are
other
awesome
projects
in
the
ecosystem
like
chart
museum,
the
still
experimental
oci,
hopefully
not
for
very
long.
You
can
have
public
repos
private
repos,
et
cetera,
it's
just
a
matter
of
controlling
access
to
those
http
web
servers.
Basically,
however,.
D
Make
them
work
so
the
nice
thing
that
to
keep
in
mind
is
that
we
have.
We
have
another
tool,
that's
very
similar
to
chart
chart
testing
for
the
releasing
side
called
chart
releaser
and
that
can
that
right
now
integrates
with
github,
because,
let's
face
it,
when
you,
when
you
one
of
the
old
ways,
is
you
you
upload
your
index
file?
You
also
upload
a
ton
of
binaries.
You
can
see
that
on.
D
If
you
go
for
an
example
to
the
prometheus
community,
helm,
charts
repo
you'll
see
that
there's
a
lot
of
chart
binaries
in
the
github
pages
branch.
That's
not
the
way.
It's
working
now,
that's
just
for
backwards!
Compatibility
with
older,
with
older
charts.
Before
we
move
to
that,
we
now
use
the
tool
called
chart
releaser,
which
also
has
an
accompanying
wrapping
action
that
will
use
the
concept
of
releases.
You
know
github
releases,
where
you
download
each
release
for
for
software.
We
attach
that.
D
Excuse
me
that
tool
attaches
the
binaries,
the
tarballs,
to
the
release
that
it
creates
for
that
version
of
that
chart
for
each
chart.
So,
even
if
you
have
a
repo
with
multiple
charts,
there
will
be
releases
prefixed
by
default
with
the
name
of
the
chart,
the
version
of
the
chart
and
that
release
will
have
the
the
chart
artifacts
connected
to
it.
So
this
will
do
it
for
you
again
we're
talking
not
to
ch,
chart
consumers
right
now
or
you.
You
all
are
people
who
are
interested
in
publishing,
charts
and
distributing
them.
D
D
Please
check
out
and
use
artifact
hub,
it's
a
central,
cncf
project
that
is
there
to
what
did
I
say
to
find,
install
and
publish
kubernetes
packages
of
various
kinds,
so
it
includes
support
for
helm,
charts
and
plugins.
It
also
has
many
other
types
of
artifacts,
including
excuse
me,
including
two
control,
plugins,
etc.
So
please
check
that
out
and
there
are
really
great
features
that
as
chart
publishers
and
chart
distributors,
you
really
want
to
make
use
of
the
only
few
that
I
want
to
mention
that
you
just
want
to
have
in
your
brain.
D
Is
there
there
are
artifact
hub,
supported
annotations
that
you
can
add
to
your
chart.yaml
file
under
the
annotation
section,
and
that
really
can
help.
You
drive
your
users
to
important
information
about
your
charts,
for
example,
where's
the
source
code
and
things
like
that
related
packages
and
other
and
other
such
things.
I'd
be
really
remiss
in
not
saying
that
if
you
all
remember
the
the
github.com
helm,
slash,
charts
repo,
that's
now
archived
a
lot
of
people
were
concerned.
Where
did
all
that
stuff
go?
Well
all
the
history.
D
Is
there
if
you
read
the
helm
blog
posts?
Luckily,
github
has
been
very
generous,
picked
up
the
baton
from
google
and
is
now
hosting
all
of
those
all
that
chart
package
history,
but
for
ongoing
chart
work
new
charts,
the
way
to
find
it
is
artifact
hub,
and
so
as
chart
distributors.
It's
your
responsibility
to
make
sure
to
list
that
in
the
centralized,
cncf
artifact
hub,
just
like
you
would,
if
you
were
supporting
a
yum
or
an
app
package,
you
would
have
to
make
sure
that
that
is
listed
and
aggregated
for
discoverability.
D
There's
a
lot
of
great
features
for
end
users
that
I
will
not
mention,
but
things
that
are
extremely
important
for
owners
is
if
you
are
or
want
to
be
an
owner
of
one
of
the
helm
charts
that
is
currently
archived
in
the
chart,
the
helm,
charts
repo.
It
doesn't
yet
have
a
home
right.
You
want
to
work
on
it.
Your
company
is
working
on
it.
You
use
it
all
the
time
you're
making
improvements.
Maybe
you
even
have
a
fork
of
that.
D
Consider
owning
that
and
consider
making
that
available
for
others,
and
if
you,
if
you
want
to
take
ownership
of
that,
there
is
a
feature
in
artifact
hub
to
claim
ownership,
because
we
we
migrated
all
of
those
old
packages
to
artifact
hub,
but
most
of
those
are
under
the
helm,
org
right
now,
because
no
one
wanted
to
claim
them.
I
mean
many
of
them
did,
but
there's
still
a
lot
that
have
yet
to
be
claimed.
So
please
do
that.
D
Talk
with
your
colleagues
talk
with
people
who
are
supporting
those
applications
that
those
charts
are
distributing
and
make
sure
if
you
can
please
to
contact
us
ping
and
slack
whatever
you
need
to
do,
but
let's
just
keep
that
ecosystem
rolling,
because
the
reason
helen
is
so
important
is
because
of
people
like
you.
Obviously,
the
end
user
is
the
most
important
user.