►
Description
This was the inaugural New Contributor Meeting. We are hosting monthly New Contributor Meetings (every 2nd Monday of the month at 10:30am ET / 4:30pm CET) to help you as you begin your Keptn contribution journey! Bring your questions, feedback, or suggested topics we can cover to help improve your Contributor Experience!
08:49: Keptn Maintainer, Ondrej Oubaj gives you hints, tips, and tricks on how to setup your local development and test environments effectively.
Meeting notes document: https://docs.google.com/document/d/1rTwjhzoNiWRvNk7LdcADI50Kon9uTT8PtYPmYjiE_sQ
Learn more: https://keptn.sh
Get started: https://lifecycle.keptn.sh/docs/getting-started/
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/lifecycle-toolkit
Follow us on Twitter: https://twitter.com/keptnProject
Sign up to our newsletter: https://bit.ly/KeptnNews
A
A
I
have
pasted
the
notes
in
the
chat.
So
if
you
could
add
yourself
in
this
attendee
and
then
you
know
the
the
the
reason
for
this
whole
meeting
is
just
to
answer
really
any
questions
that
you
as
a
new
contributor
might
have.
So
you
know
at
this
point
we
can
leave
it
very
open
and
we
can
just
have
like
a
little
bit
of
a
q
a
session.
A
We
want
to
really
just
kind
of
keep
it
open
at
this
point
and
and
see
what
kind
of
of
questions
or
help
that
you
guys
need,
and
then
Andre
I
know
has
a
topic
that
he
could
dive
into
as
well.
But
really
it's
just
kind
of
opening
the
floor
to
say
what
you
know.
What
do
you
need
from
us
right
in
the
on
the
community
side?
A
How
do
you
need
us
to
better
explain
some
things?
Are
you
running
into
some
issues
or
blockers
that
you
don't
understand
something
so
I'll,
just
kind
of
start
that
off
I
guess
maybe
some
introductions
actually
might
be
good.
First
too
so
I'm
Stacy
I'm
a
community
manager
with
the
captain
project
and
yeah
I'm
just
here
to
facilitate
all
this
kind
of
good
stuff
and
then
Andre
I,
don't
know
if
you
want
to
maybe
introduce
yourself
as
well.
B
A
C
A
D
A
E
A
D
F
D
F
Think
I
think
I'll
go
next,
so
have
a
wonderful!
It's
me.
It's
shivang,
chandelier
I
am
cncf
New
Delhi,
organizer
and
I've
also
been
a
Google
summer
of
code
mentee
for
a
different
project,
not
Captain.
It's
called
a
murder
and
I
am
basically
also
new
to
the
captain.
I've
been
contributing
to
Captain
for
like
a
month
or
a
half.
Now
so
yeah
really
wanted
to
check
out
this
new
contributor
meeting
and
yeah
really
glad
to
meet
you
all.
Thank
you.
A
G
H
I
H
I
A
J
A
A
A
Oh
sorry,
Aaron
I'm
I'm,
just
seeing
that
you've
put
something
in
the
chat
great.
Thank
you
just
a
brief
introduction
appreciate
that
thanks
Aryan
so
yeah,
if
it
does
I'll
just
kind
of
open
it
up
and
make
the
floor,
be
yours
and
then,
if,
if
nobody
has
anything
I
guess
we
could
do
kind
of
just
a
quick
overview
of
things
from
Andre.
G
Well,
I
just
have
a
simple
question
like
when
I
started,
contributing
to
Captain
or
even
now,
as
I
am
trying
to
start
contributing
again
it's
for
me
as
a
beginner,
it's
difficult
to
set
up
the
local
development
and
test
environment.
How
do
you
set
that
up
if
we
have
a
video
tutorial
or
some
blog
post
like
showing
how
a
senior
maintainer
sets
up
his
own
environment,
that
will
be
I,
think
beneficial
for
new
contributors.
B
That's
basically
what
it
planned
after
this
question
and
answer
session
or
part
of
this
session,
I
will
go
through
basically
how
to
set
up
a
developer
environment.
What's
needed,
give
some
hints
and
tips
and
tricks
how
to
set
it
up
effectively
and
how
to
actually
develop
test
and
deploy
the
things
that
you
change,
or
that
you
want
to
test
the
best
way
or
how
at
least
not
maybe
not
the
best
way,
but
how
we
do
it
actually.
B
B
B
I
guess
most
of
you
already
have
seen
and
know
this
repository,
but
I'll
still
kind
of
give
it
a
brief
introduction
to
this.
But
personally,
I
would
start
with
when
coming
across
such
a
repository
is
our
documentation
web.
It's
our
web
Captain
website,
which
you
probably
know
as
well,
but
what
I
would
do
is
go
through
all
the
tutorials
on
Captain
sh
coming
for
the
documentation,
try
to
understand
what
Captain
is
actually
all
about
play
with
it.
We
have
multiple
examples.
B
A
A
B
So
if
you
look
at
the
repo
just
from
a
ego
perspective,
you
can
see
that
the
repository
contains
multiple
directories
with
multiple
components.
So
Captain
is
not
just
one
single
binary
or
one
single
component.
It
contains
multiple
components,
as
previously
we
call
it.
The
lifecycle
toolkits
now
known
as
a
captain
since
few
days,
I
guess
so.
Firstly,
it's
it's
built
from
kubernetes
operators
and
kubernetes
scheduler,
and
it's
kubernetesert.
H
B
B
Operator
second,
one
is
lifecycle
operator,
then
Captain,
scheduler
and
also
the
third
manager.
These
four
components
together
provide
the
full
functionality
be
described
in
the
introduction
of
the
captain.
I
mean
we
can
speak
for
about
this
for
hours
or
for
a
long
time.
I
don't
want
to
go
into
details
here.
Just
want
to
focus
on
the
development
perspective,
so
I
would
maybe
assume
some
things
that
contributors
know,
but
if
you
do
not
know
them,
I'm
speaking
about
things,
you
do
not
understand.
B
So
therefore
it's
it's
quite
a
complicated
piece
of
code
or
the
most
complicated
piece
of
code
of
this
toolkit
or
captain.
Then
second
part
metrics
operator.
We
use
this
operator
to
evaluate
metrics
fetched
from
a
metrics
provider
such
as
Prometheus
or
dyno,
trace
and
evaluate
them
in
in
real
in
real
time.
Therefore,
you
can,
for
example,
with
a
matrix
operator
scale
up
and
down
your
applications
based
on
the
load,
for
example.
B
B
B
Here
we
have
dinner
run
as
part
of
the
life
cycle
orchestration.
We
provide
the
possibility
to
run
tasks
which
is
a
wrapper
around
kubernetes
job.
Therefore,
we
can
provide
multiple
Runners
out
of
the
box.
For
example,
Runners
about
Dino,
runtime,
Runner,
python,
runtime
Runner,
but
also
the
default
container
runtime
run
more
information
about
Runners.
You
can
actually
find
in
our
in
not
introduction
to
Captain
or
with.
E
B
B
B
From
our
perspective,
it's
not
needed
that
you
have
a
real
cluster
on
AWS
you
for
the
development
reasons
it's
more
than
enough
to
use.
For
example,
your
local
cluster,
for
example,
create
your
local
cluster
and
manage
it
with
a
kind.
That's
what
most
of
us
as
developers
are
using.
Certainly,
there
are
also
other
options
in
this
regards,
but
you're
free
to
use
whatever
you
want
here,
I
wouldn't
go
through
the
installation
of
kind.
You
can
find
a
lot
of
documentation
on
the
official
kind
cluster
side.
B
B
The
second
thing
which
is
basically
necessary
for
developing
is
the
knowledge
of
a
goal
language
that,
as
this
is
an
application
which
is
written
in
Gold.
We
highly
recommend
going
through
the
getting
started
guides
with
go:
go
through
the
go,
tutorials
go
through
the
tutorials
about
managing
dependencies
with
Ingo
and
try
to
just
play
with
the
language.
As
always
I
guess
you
guys
do
not
know
only
one
programming
language.
So
it's
always
a
bit.
There's
always
some
bit
of
a
time
needed
before
you
actually
start
to
develop
a
real
applications.
So
just.
D
G
C
I
D
B
We
now
assume
that
you
have
a
running
kind:
cluster
Cuban
in
general,
kubernetes,
cluster
managed
by
kind
or
whatever
technology
you
prefer.
And
what
do
you
want?
You
want
to,
firstly,
deploy
the
whole
application
on
your
guide
cluster,
so
you
can
play
with
it,
but
you
do
not
want
to
install
already
of
the
some
kind
of
version
you
want
to
deploy
development
version.
So
the
version
which
is
you
have
currently
cloned
in
your
local
Repository.
B
B
A
dedicated
set
of
commands
or
one
command
which
you
can
deploy
on
you.
If
you
have
your
cubeconfig
set
up
correctly,
you
can
deploy
the
whole
application
running
on
your
cluster
I
already
this
this
part,
but
as
it
takes
approximately
10
minutes
to
build
up
all
the
images
and
deploy
them
after
deploy
the
images
with
the
manifests
to
your
cluster,
but
I
will
briefly
go
over
how
it
works.
How
with
that
and
how
would
I
recommend
doing
it?
B
So
if
you
look
at
our
root
make
file,
you
can
see
multiple
comments:
how
to
build
and
deploy
each
piece
which
I
was
referring
to
previously.
So
here,
First
Command
is
to
build
and
deploy
operator,
and
this
means
we
need
we're
speaking
about
the
lifecycle
operator,
so
what
this
command
does.
Firstly,
it
takes
your
local
code,
builds
it
to
a
binary
and
afterwards
to
an
image
with
that.
It's
uploads
this
image
to
your
local
on
to
your
remote
image,
repository
or
local
image.
Repository,
that's
on
your
that's!
B
B
Secondly,
in
the
same
manner,
build
and
deploy
metrics
operator.
Basically,
it's
completely
the
same
like
with
lifecycle
Operator,
just
a
different
piece
of
code
is
built
and
pushed
and
applied
to
your
cluster
same
thing,
with
the
scheduler
and
complete
the
same
thing
with
the
manager
to
make
the
first
installation
of
your
Dev
environment
as.
D
B
Possible
we
created
the
build,
deploy,
diff
environment
command,
which
actually
builds
all
four
components
and
deploys
them
to
your
cluster.
So
after
executing
this
command,
you'll
be
able
to
see
all
four
components
deployed
on
your
cluster
I'll.
Just
give
it
a
run
yeah
you
can
see
in
the
time
in
the
root
repository
of
the
lifecycle,
toolkit
and
now
and
I'm
typing
build
deploy,
different
environment.
B
B
And
you
can
obviously
specify
also
attack,
which
I
just
built
the
main
so
I
call
it
the
main
as
a
developers
I
think
you
can
go
through
the
make
files,
try
to
look
what
you
can
configure.
We
do
not
have
these
things
documented
anywhere.
You
just
need
to
dig
in
through
the
code
and
check
what
environment
or
variables
you
can
specify
and
what,
how
are
they
used
and
just
look
through
try
to
play
with
it?
Yes,
as
we
did
previously,
and
you
that's
a
very
good
start,
so
now
we
assume
we
have.
B
B
Adapt
something
in
the
metrics
operator,
so
you
do
not
need
to
when,
when
you
make
some
changes
in
The
Matrix
operator,
which
you
want
to
test
manually,
that
if
they
work-
and
so
you
do
not
need
to
deploy
the
whole
all
four
components,
you
just
need
to
deploy
the
one
components
which
you
change.
So
the
metrics
operator,
which
you
can
use
different
command,
build,
deploy
Matrix
operator,
then
this
after
few
minutes
will
be
deployed
and
apply
it
to
your
cluster.
So
you
can
play
with
it
real
yeah.
So
any
questions
so
far.
H
B
Next
step,
so
part
of
every
deployment
is
not
only
changing
the
code
and
adapting
trying
out
the
changes,
but
also
we
have
quite
a
nice
set
of
tests.
So
you
can
check
if
your
change
did
break
any
different
functionality,
which
is
good
for
as
a
regression
test,
but
also
we
in
most
cases
as
maintainers
require
that
every
added
functionality
or
every
fixed
functionality
should
be
covered,
at
least
partially
by
either
unit
tests,
component
tests,
e2a
test
or
integration
tests.
B
B
Maybe
I'll
go
further
with
the
component
test,
which
are
tests
are
available
only
for
the
lifecycle
operator
and
they're
testing,
a
single
controller
which
controls
a
single
resource
or
a
custom
resource
which
you
applied,
so
that's,
for
example,
Captain
app
workload,
instance
Captain
workload
or
whatever,
so
we're
testing
each
controller
as
its
own.
If
it
works
as
expected,
without
any
outer
interference
or
external
adaptations
from
other
controllers,
then
we
have
E3
tests,
which
checks
the
if
the
controllers
or
some
of
the
components
work
together
effectively.
B
We
do
not
have
that
many
e2e
tests,
but
we
were
like
to
improve
in
this
way
in
the
future
and
in
the
last
set
of
tests,
or
we
call
it
integration
tests
but
they're,
basically,
tests
from
the
user
perspective,
so
how
the
user
applies
manifests
to
the
cluster.
So
you
can
really
like
look
into
these
tests
s
tests,
which
are
upload
as
a
resources
which
are
applied
to
a
cluster
directly,
and
we
expect,
after
applying
these
resources
to
the
Clusters,
some
kind
of
behavior,
which
we
test,
that
if
this
behavior
is
correct,
the.
B
I
B
If
you
want,
you
can
go
through
the
tutorials
of
Google
and
let's
get
started,
how
actually
you're
able
to
run
these
tests.
So,
as
you
can
see,
we
have
multiple
entries.
I
will
start
from
there.
Integration
tests
in
the
main
make
main
make
file.
We
have
integration
test
entry,
which
will
run
all
the
integration
tests
for
all
the
components
we
have
two
ways
of
running
them:
make
run
integration
tests
or
make
run,
make
integration
test
local.
B
B
Yeah,
let's
take
a
look,
how
they
are
run,
so
the
easy
way
is
just
to
make
integration
tests
and
so
on.
The
tests
are
running.
Firstly,
environment
is
set
up
installed,
whatever
is
needed,
which
is
part
of
the
test
definition,
and
afterwards
this
around
this
is
very
good
to
run
these
tests
before
you
submit
the
pr
so
you're,
actually
certain
that
the
functionality
which
is
already
in
place
wasn't
broken
or
malformed
in
any
way,
yeah.
We
can
leave.
B
And
go
to
check
how
the
component
has
worked
here.
We
need
to
go,
for
example,
to
a
lifecycle
operator
make
file
which
is
not
the
main
make
file
in
the
Repository,
but
one
layer
in
so
this
one.
You
can
also
check
it
out
what
you
can
actually
configure
environmental
variables.
It's
interesting
and
but
most
interesting
part
is
that
now
you
want
to
run
component
tests.
So
it's
we
already
introduced
the
wrapper
for
this
as
well.
So
you
just.
B
B
B
Tests
so
make
it
to
a
test
and
just
give
it
a
go.
This
should
be
fairly
quick,
so
we
can
look
into
it.
Hopefully
they
will
pass
and,
as
you
can
see
they
passed,
we
have
only
two
tests
but
yeah.
We
will
try
to
improve
on
this
future
and
the
most
simple
test
unit
tests
which
test
desired
functions.
We
have
in
the
code
also,
we
have
a
dedicated
command
for
this
make
test
and
the
tests
are
running.
B
Good,
there
might
be
actually
use
cases
where
you
do
not
need
to
run
the
whole
test
Suite,
especially
for
the
unit
tests,
and
you
want
to
run
a
single
unit
test,
for
example,
for
the
control
for
controller.
So
I
do
not
know
what
IDs
do
you
use
for
your
development
I
personally
use
vs
code,
but
also
my
colleagues
use
different
options.
B
That's
totally
your
freedom,
but
vs
code
has
and
I
assume.
Most
of
the
modern
IDs
have
a
feature
of
running
a
single
unit
test
directly
in
the
ID.
So
you
just
click
on
it
and
the
test
is
run
whatever
you
want.
You
can
run
also
test
for
log
poll
directory,
but
I
guess
you'll
figure
it
out
in
your
own
ideas.
I
do
not
know
which,
especially
if
you
have
any
problems,
definitely
you
can
reach
out.
B
Yeah,
that's
in
most
cases
everything
what
I
wanted
to
show,
but
before
yeah
giving
back
to
sum
up
how
actually
we,
what
we
actually
do
do
before
submitting
a
PR
for
a
review.
Is
we
make
the
changes
in
the
code?
Of
course
we
try
to
try
them
out
manually,
for
example,
but
with
what
I
showed
how
to
deploy
your
chain.
Local
changes
into
your
cluster
and
afterwards
play
with
it
depends
on
your
use
case.
B
What
you
need
to
do
then
run
the
tests
locally,
so
unit
tests,
component
tests,
e2e
test
and
also
integration
tests-
you,
you
can
run
this
and
if
everything
is
green,
you
can
submit
the
PR,
but
in
this
case
also,
if
there,
if
it's
possible,
we
really
appreciate
if
every
PR
has
already
a
set
of
tests
which
are
testing
the
functionality
which
was
added
or
which
was
adapted
due
to
the
pr
description
and
yeah.
That's
probably
all
from
my
side.
Are
there
any
topics,
more
questions,
whatever.
G
D
B
D
A
D
J
B
D
Capture
the
answer,
that's
a
question.
Let
me
I
can
do
it
very
quickly.
The
assumption
is
that
most
people
are
actually
deploying
their
software
with
the
two
like
flux
or
Argo,
or
something
so,
and
that
does
a
wonderful
job
of
actually
deploying
the
software,
but
it
does
not
check
whether
your
environment
is
ready
for
the
software
and
going
to
pass.
It
does
not
run
tests
afterwards.
You
don't
get
a
lot
of
observability
data.
So
Captain
adds
this.
You
go
ahead
and
do
the
deployment
as
you've
already
done
it.
D
You
can
run
pre-deployment
tests
and
evaluations.
You
can
run
post
deployment,
tests
and
evaluations,
the
pre-deployment
make
sure
everything's
ready
and
you
can
Define
rather
than
raw
kubernetes.
You
have
a
set
of
workloads,
each
one
of
which
builds
a
microservice
or
something
for
a
captain.
You
can
define
a
captain
app
which
pulls
together
a
set
of
workloads
that
this
is
your
actual
application,
that
you're
deploying
and
then
you
can
do
pred
and
post
deployment
tasks
and
evaluations
on
that.
In
addition,
you
get
heightened
observability,
you
get.
D
We
use
open
Telemetry,
Dora
metrics,
which
is
a
special
set
of
Industry
metrics.
To
provide
information
like
the
the
cool
kids
call.
Let's
see
some
code
to
cloud
is
what
they
call
it.
It
will
Trace
everything
that
happened,
that
you
can
see
what
took
how
long
Etc
you
can
see
where
your
bottlenecks
are
in
your
delivery
and,
of
course,
metrics
Captain
certainly
supports
metrics,
but
Captain
metrics
can
come
from
multiple
types
of
data
sources
and
even
multiple
versions.
D
If
you've
got
a
big
cluster
and
you've
got
three
instances
of
Prometheus
running
and
two
of
dynatrace
and
a
couple
of
datadog
all
of
these
captive
metrics
can
pull
them
all
in
identify
them
all.
Make
queries
available
for
all
of
them
and
Report
information
on
all
of
those.
Some
together
set
the
high
points.
Andre
Flo
did
I
get
the
main
point
so
perfect.
J
A
Fantastic
does
anyone
else
have
any
other
questions
before
we
close
out
and
we'll
have
by
the
way
these
monthly
going
forward?
And
all
of
you
are
always
welcome
to
join
our
regular
Community
meetings
and
ask
any
questions
that
you
have
on
those
as
well.
So
we
have
one
a
week,
one
at
sort
of
North
America
time
zone
friendly
and
one
at
EU
time
zone
friendly.
A
All
right,
well,
thanks
everybody
for
being
here
today,
I
really
appreciate
it,
thanks
Andre
for
walking
through
that
and
again,
if
you
have
any
other
questions
everyone's
on
slack,
so
feel
free
to
join
that
slack
workspace
and
hit
us
up
there.
Otherwise,
we'll
we'll
see
on
the
next
one
thanks
so
much.
Okay,
thanks.