►
From YouTube: Keptn Developer Meeting - Sep 22, 2022
Description
News from the community, Keptn LTS and Keptn Lifecycle Controller. Also, demos of the recent features in Keptn.
Meeting notes: https://docs.google.com/document/d/1y7a6uaN8fwFJ7IRnvtxSfgz-OGFq6u7bKN6F7NDxKPg/edit
Learn more: https://keptn.sh
Get started with tutorials: https://tutorials.keptn.sh
Join us in Slack: https://slack.keptn.sh
Star us on Github: https://github.com/keptn/keptn
Follow us on Twitter: https://twitter.com/keptnProject
Sign up to our newsletter: https://bit.ly/KeptnNews
A
C
A
A
Agenda
if
you're
fine
I
will
just
start
with
the
news.
So
first
of
all,
Captain
Community
Day
is
confirmed,
it's
happening
25th
of
October
and
in
Detroit,
so
everyone
is
welcome
to
join.
If
you
are
going
to
kubecon,
we
have
a
few
topics
confirmed.
There
will
be
some
changes
later,
but
here
we
will
have
a
common
presentations
by
all
maintenance
about
the
state
of
the
project.
A
Then
I
will
have
a
workshop
for
newcomers
and
then
we'll
have
a
few
sessions,
summarizing
user
experience
by
Bread,
section
ND,
and
then
we
will
think
about
future
of
Captain.
So
we
have
two
topics:
one
is
what's
next
for
Captain,
do
you
thinking
date
operations
and
then
Thomas
was
going
to
present
the
captain
like
cycle
controller?
So
basically
what
we
are
discussing
today
and
later.
We
will
also
have
something
like
90
minutes,
one
conferences
and
discussions.
A
So
any
topics
you
would
like
to
add
here
just
suggest
and
you
will
be
able
to
adjust
it
in
the
audience
and
the
interests.
So
that's
coupling
community.
This
is
a
free
event,
just
make
sure
to
join
if
you're
going
to
keep
calm.
A
Okay.
So,
what's
next
Google
summer
of
code,
I
can
show
pre-results,
so
we
will
have
a
known
presentations
next
week,
but
the
summaries
that
three
projects
are
passed
so
by
username
my
nutrition
service
for
q6
Integrations
for
githubs,
with
flux
and
nargo,
and
also
rajiv's
project
for
a
new
documentation
site.
So
these
projects
are
passed.
We
will
have
presentations
next
week
and
stay
tuned
for
the
announcements.
A
We
will
also
be
doing
perspective
about
the
results
of
this
project
and
how
we
could
do
better,
because
my
perception,
for
example,
is
that
there
could
be
much
more
engagement.
Is
why
the
community,
but
basically
we
still
maintained
this
split
throughout
the
project,
so
we
have
developer
meetings.
We
have
Community
meetings
where
the
rest
of
the
people
participate.
So
maybe
we
need
to
rethink
our
framework
going
forward
so
that
we
do
no
longer
have
two
separate
sets
of
meetings
plus
it
can
reduce
the
number
of
meetings
which
is
also
good
yeah.
A
So
another
quick
topic
I
wanted
to
discuss
is
Captain.
Lts
is
basically
a
call
for
commands
or
a
question
whether
we
should
start
voting,
so
there
is
enhancement
proposal
for
Capital
volts
I.
Briefly
presented
it
on
the
previous
community
meeting,
so
I
wonder
whether
you
would
like
to
have
a
quick
presentation
and
overview
of
what's
inside
or
whether
you
would
like
to
just
discuss
any
open
questions.
You
may
have.
D
C
A
Yeah
so
I
didn't
prepare
slides
for
this
specific
meeting,
but
yeah
I'll
just
show
what
we
have
quickly.
So,
as
you
know,
many
projects
have
a
long-term
support
versions.
So
it's
from
java
to
parameters
Etc
and
the
idea
for
them
is
that
to
have
a
stable
release
line,
which
is
maintained
for
a
long
time.
Let's
say
one
year,
two
years:
five
years
with
back
parts
and
security
fixes,
so
it's
quite
valuable
for
users
if
they
don't
have
new
features.
A
So
they
can
stay
on
this
version
and
basically
update,
is
needed
and
have
confidence
about
compatibility
so
for
Captain
they
will
break
in
changes.
I
believe
almost
every
release
in
the
recent
year
I
mean
every
minor
release.
Opening
so,
and
we
got
quite
some
feedback
from
users
that
they
would
actually
like
to
have
something
more
stable,
so
Capital
CS
could
address
it
by
providing
a
stable
version
which
you
can
just
use,
which
probably
doesn't
receive
new
features,
but
at
the
same
time
it's
relatively
stable
maintained
and
they
can
just
use
it.
A
So
the
scope
for
that.
If
you
take
a
look
at
the
proposal
easily
just
Captain
core,
but
basically
a
number
of
essential
components
that
users
would
utilize,
so
it's,
of
course,
all
services
like
Bridge,
it's
CLI,
it's
all
installation
and
help
charts
are
being
used
also
a
number
of
services.
A
They
are
not
generally
consider
the
part
of
Captain
core,
but
from
user
perspective
they
are
super
important
and
then
I
have
a
list
of
a
few
services.
So
basically
everything
we
have
in
Captain
Captain,
but
there's
a
lot
of
utility
services
there,
like
let's
say
like
house,
you
cannot
really
use
Captain
without
it,
but
also
a
number
of
external
services
and
for
them
so
the
least
I
currently
proposes
parameters,
job
executive,
Service,
also
Benefit
Service.
A
We've
got
information
that
the
team
would
be
interested
to
keep
maintaining
it
and
I'm
currently
discussing
the
simple
data
talk.
So
this
is
basically
a
short
list
of
services,
at
least
the
initial
release,
and
basically
they
would
have
the
same
release
cycle
as
Captain
core
and
companions.
So
we
maintain
it
as
a
package
for
some
for
some
time
and
they
receive
all
the
necessary
updates
and
security
fixes.
A
Regarding
the
time
which
is
quite
important,
so
the
proposal
for
this
LCS
line
is
to
commit
to
six
months
initially
why
it's
just
six
months.
Firstly,
because
it's
our
first
experiment,
we
need
to
see
what
the
users
would
be
adopting
it
at
all.
Whether
there
is
some
value
for
users
and
also
then
we
can
decide
whether
we
can
extend
it
or
not.
A
So
it's
not
the
mandatory
that
we
stop
it
just
six
months,
but
we
basically
keep
it
going
if
we
decide
to
do
so,
based
on
demand
based
on
vendors
using
caption,
because
we
have
captain
in
dinar
trees,
we
have
Captain
and
cartel
platform
Ops
by
KERO,
Tech
and
other
also
service
teams
providing
it.
So
we
can
collaborate
with
them
and
see
what
would
be
the
timeline,
but
the
proposal
is
to
commit
to
six
months
initially
and
I
also
propose
to
actually
call
it
Captain
1.0.
A
You
know
for
that.
Well,
it
doesn't
apply
many
changes
in
terms
of
the
release
line
Etc,
it's
just
a
major
release.
We
wanted
to
do
it
last
year
after
original
the
incubation
stage,
so
the
information
stage
took
some
time,
but
now
I
think
it
could
be
a
good
time
to
just
call
the
next
release,
which
is
0,
20,
I,
guess
just
call
it
1.0
and
probably
press
it
with
it
foreign.
A
A
So
some
other
changes,
I
proposed,
is
basically
yeah
release
cartons.
So,
given
that
many
people
start
working
on
lifecycle,
controller
Etc,
we
don't
commit
to
monthly
releases
anymore
I
need
the
foil
chairs
most
recent
Branch.
So
we
basically
release
on
demand
when
the
security
fixes
Etc
and
I-
guess
that's
it.
A
A
That
is
a
number
of
open
questions
for
which
I
have
answers,
but
yeah.
So
my
question
to
the
team
is
whether
it
looks
okay
with
you
or
whether
you
would
like
to
see
something
different
over.
It
makes
sense
to
start
this.
E
E
B
Can
see
the
dot
19.0
is
the
latest
carbon
version.
The
latest
data
Talk
service
version
would
also
be
this
year,
so
my
question
would
be:
are
we
doing
something
similar
in
the
other
services
and
do
we
need
to
do
something
similar
in
those
Services?
I
saw
dynatories
I'm,
not
sure.
If
Prometheus
was
there,
do
we
need
to
change
that?
No.
A
Streak
needs
so
the
proposal
doesn't
set
specific
version.
It
came
up
for
services,
it's
a
rather
web
policy.
So
let's
say
we
have
OTS
with
recommended
versions
for
services.
You
update
in
the
documentation
my
help,
charts
Etc
and
then,
if
there
is
a
need
to
update
a
service,
basically
the
same
policy
would
apply.
So
if
you
have
major
features,
Etc,
probably
it's
not
for
LCS,
but
we
can
have
a
another
release
with
back
ports
and
I
think
integrated
with
LTS
just
for
stability
purposes,
so
basically
for
services.
It
would
be
the
same
approach.
B
Okay-
and
my
next
question
was:
when
do
you
plan
to
release
0.20?
C
That's
a
tough
call.
We
first
need
to
make
sure
that
the
code
base
is
clean
enough
and
as
soon
as
we
are
ready,
we
will
do
this
release.
So
I
cannot
give
you
a
timeline
details,
but
you
can
follow
as
soon
as
all
the
bugs
have
been
fixed.
B
Let's
see
I
have
the
reason.
I
was
asking,
because
I
think
we
might
need
to
do
some
work
around
the
docs
engine
and
make
it.
You
know,
make
it
good
enough
that
we
can
also
use
it
for
one
doctor
at
least
so
so.
A
For
one
to
two
I'm,
not
sure
if
we
should
use
the
new
docs
engine,
why?
Because
we
basically
follow
the
same
format
as
before,
and
the
documentation
will
build
some
more
Frozen
in
time
for
the
LTS.
So
there
could
be
some
updates.
Some
fixes
clarifications,
but
there
wouldn't
be
major
updates
and
it
would
be
relaxed.
We
definitely
needed
a
new
docs
engine
for
the
new
documentation
we
create
it's.
A
developer
guide
has
been
wanted.
A
A
If
we
can
kind
of
deliver
it
on
time,
then
I
think
we
can
just
stick
with
Hugo.
E
B
A
new
docs
engine,
because
we
this
would
be
the
first
time
we
are
going
to
actually
use
a
docs
engine
in
production,
so
I
was
a
little
I
had
my
concerns.
So
if
you're
not
using
it
I
think
that
makes
sense,
we
can
use
it
for
the
next
LDS
release
or
start
using
it
in
general,
except
for
the
LTS.
Please
yeah.
A
I'm
not
using
it
for
Captain
one
definitely
saves
some
time.
It
actually
opens
many
questions
open,
like
support
for
search
Etc
but
yeah.
This
is
something
we
can
figure
out
later,
but
at
least
we
won't
be
blocked
with
moving
over
too
much
content
for
the
LTS
and
for
the
next
releases
we
will
be
able
to
basically
be
even
more
radical
with
reworking
the
documentation.
E
Yeah,
so
after
V1
is
released,
we
have
we
have
the
notion
of
upgrades,
but
I
haven't
seen
anything
about
patches
but
I
assume
with
when
we're
reissuing.
Every
month,
most
people
didn't
bother
to
patch
an
old
one,
although
unless
we
went
like
I
think
we
have
18.2
or
something
like
that,
do
we
have
a
do
patches
work
is
that
if
we
have
or
if
we
uncover
a
really
bad
functional
bug
or
something
that
we
have
to
patch
yeah,
will
we
go
to
like
1.1?
A
Yes,
we
will
be
using
patches
and
actually
we
have
history
of
it.
So
if
you
take
a
look
at
my
screen,
we
release
the
patches
for
16.2
171
Etc.
So
there
you
go
a
number
of
web
ports
to
some
extent.
We
could
already
call
it
an
LCS.
It's
just
no
policy,
not
no
commitment,
Etc.
So
right
now,
as
a
user,
I
kind
of
expect
that
for
version
0.16,
there
would
be
Dot
3
release
with
additional
patches.
A
E
A
E
E
Is
that
that's
just
I'm
talking
about
just
the
process,
not
even
the
not
you
know,
assuming
that
we
don't
have
anything
they
have
to
actually
know
as
a
user,
that
they
have
to
change
anything,
but
so
it'll
just
be
another
upgrade
per
se
yeah.
Thank
you!
Well,
I'm!
So
glad
you
have
your
camera
on.
So
I
can
see
you
shaking
your
head
and
nodding
your
head.
F
Of
what
kind
of
patch
we're
doing?
Basically
right.
E
A
I'm
tempted
to
say
yes
to
reduce
the
number
of
workload,
there
can
be
some
not
technical
reasons
to
release
earlier,
for
example,
an
unsolicated
cubecon
or
something
like
that,
but
yeah
I'm
not
too
committed
to
release
just
for
non-marketing
reasons.
So
at
keep
on,
we
can
say
it's
coming
and
that's
it
so
so.
B
A
Yeah,
basically,
if
zero
to
20
is
the
version
We
Target,
we
have
let's
say
about
one
month,
one
month
and
a
half
until
it's
done
and
basically
we
can
just
call
it
1.0.
We
can
agree
on
that
start
preparing
the
documentation
right
for
that,
so
that
there
won't
be
a
no.
There
won't
be
any
additional
overhead
when
we
release.
A
A
D
C
Else
I
asked
Thomas
since
he's
the
main
technical
driver
for
this
topic
to
give
us
an
overview
about
the
architecture
how
it
works
and
the
general
purposes
of
this
new
project
that
we
started.
D
D
Okay,
so
we
have
a
new
repository
for
the
app
for
the
flex
life
sector,
and
what
we
want
to
achieve
in
captain
in
the
future
is
that
we
get
more
into
get
more
into
the
real
deployment
lifecycle
of
an
application,
so,
for
instance,
to
have
our
to
have
our
components
on
the
Q
latest
cluster
and
to
deal
with
resources
directly.
D
D
The
lifecycle
controller
by
itself
is
a
completely
new
and
more
or
less
independent
component
of
Captain
and
at
the
moment,
in
a
prototyping
or
playground
phase,
and
one
of
the
goals
of
this
of
this
life
cycle
controller
is
to
be
at
first
working,
observing
other
capitals
at
the
moment.
So
you
must
be
able
to
deploy
some
whatever
you
want
so
such
as
deployments
stateful
set
Steven
sets
and
so
on
and
Captain
Hooks
in
inside
into
all
of
this
and
tries
to
and
runs
pre
and
post
deployment.
D
Checks
gets
keeps
track
about
the
application
State
and
also
does
some
post
deployment
checks.
After
everything
is
finished,.
D
D
This
will
hit
the
kubernetes
API
and
there
we
are,
we
are
listening.
We
are
intercepting
the
thing,
the
requests
with
our
mutating
map
book
and
try
to
find
out
if
the
object
has
some
annotations,
which
Captain
can
deal
with.
So,
for
instance,
you
have
to
tell
that
we
have
the
tail
cap,
the
life
cycle
controller
at
some
point
to
which
workout
it
belongs
to
which
application
it
will
belong
and
which
checks
it
should.
D
It
should
run,
therefore-
and
if
some
of
these
annotations
exist
in
especially
the
record
annotation,
then
our
mutating
web
hook
will
add
our
custom
scheduler
for
this
or
schedule
extension
I
will
tell
you
later
what
this,
what
this
means
and
it
will
create
workload,
objects,
but
also
application
objects
if
they
are
not
annotated.
D
Our
scheduler
is
there
to
intercept
the
the
deployment
the
port
schedule
room
in
a
in
a
way
that
we
that
we
are
able
to
run
pre-deployment
checks
before
the
port
is
scheduled.
So,
for
instance,
you
can
check
you
will
be
able
to
check
if
there
are
open
problems
in
your
observical
solution
before
you
are
scheduling
the
port.
D
This
could
also
be
dependency
checks
in
the
future.
This
could
be
scheduled.
This
could
be
scheduled
deployment
and
so
on.
So
this
enables
us
a
lot
of
of
possibilities.
D
In
the
meanwhile,
everything
will
be
will
be
checked
after
everything
is
okay,
then
the
ports
will
get
scheduled
and
after
we
find
out
that
the
workload
is
successfully
deployed.
So,
for
instance,
all
of
the
parts
of
our
of
our
deployment
are
ready.
Then
we
can
start
doing
post
deployment
checks
and
this
behaves
almost
the
same
as
pre-deployment.
D
So
we
can
also
Define
always
Define
some
actions
and
afterwards
say
everything
is
okay.
Well,
something
is
not
okay.
What
the
livestock
controller
will
not
do.
Is
it
won't
take
actions
on
its
own,
so,
for
instance,
if
a
pre-deployment
check
will
fail,
it
will
send
an
event,
but
it
will
not
try
to
reconcile
this
without
without
the
an
action
of
the
user,
and
this
has
a
good
reason
because,
with
the
lifecycle
controller,
we
we.
D
In
any
way,
so
we
won't
do
anything
which
interferes
with
github's
principles,
for
instance,
if
we
would,
if
we
would
try
to
roll
back,
if
a
deployment
would
fail
directly
on
the
cast
of
the
github's
controller
would
try
it.
I
would
always
try
to
get
to
the
to
the
to
the
to
the
to
its
desired
State
and
therefore
the
things
which
does
would
interfere
with
the
things
with
Jackie
tops
controller
does
so,
yes,
it
will
be
able
to
create
actions
which
manipulate
the
git
repository.
D
D
So
at
the
moment
we
are
also
trying
to
find
out
how
to
into
how
to
hook
in
with
with
some
tooling,
for
pre
and
post
deployment
checks.
At
the
moment
there
are
some.
There
are
two
approaches.
The
first
one
will
be
that
you
that
you
will
be
enabled
you
will
be
enabled
to
write
typescript
functions,
which
you
can
hook
in
and
the
second
one
will
be
that
you
can
can
add.
Containers
such
as
the
cubesatel
container
or
whatever,
to
execute
your
tasks.
D
D
Therefore,
what
you
see
in
the
in
this
repository
at
the
moment
is
is
a
prototype
and
we
plan
to
be
able
to
present
everything
at
least
until
kubecon
and
yes,
we
are
always
open
for
for
your
for
your
for
your
input
and
if
you
have
some
ideas
or
if
you
want
to
participate
in
all
of
the
in
all
of
the
discussions,
there
is
a
select
channel
for
the
app
lifecycle
working
group,
just
join
it
and
yes,
I
hope
this
will
be,
will
will
get
you
get
get
you
all
further
with
this
I
think
I
give
back
to
Germany.
C
Yeah
I
want
only
12
few
words
on
that.
You
might
have
seen
in
the
architecture
diagram
that
Thomas
showed
that
there
is
open
Telemetry
here
and
there.
One
cool
thing
of
this
prototype
is
also
will
allow
you
to
have
a
full
obserability
of
your
deployment
cycle
and
also
the
durametrics
out
of
the
box
in
this
way.
C
C
B
I'm
just
trying
to
understand
what
the
crds
mean
so,
where
I
the
point
I'm
confused
about,
is
you
said
it's
an
extension
right
of
the
captain.
Installation
I'm
still
trying
to
figure
out
how
the
lifecycle
controller
fits
into
the
captain
ecosystem
and
that
an
extension
of
that
question
is
how
does
the
crds
the
custom
resources
that
we
see
in
architecture
diagram
how
those
relate
to
the
existing
Captain
ecosystem
or
the
captain
installation.
D
So
should
I
should
I
take
this
over
please
yeah.
So
at
the
moment,
the
livestock
controller,
as
I
said
in
the
beginning,
is
a
completely
separated
project.
So
there
is
no
real
relationship
between
what
we
know
from
the
captain
control
plane
at
the
moment
and
the
lifecycle
controller
and
also
the
you
might.
You
might
have
seen
in
the
diagram
that
there
are
no
no
entities
which
are
currently
currently
available
in
Captain
D1,
for
instance,
in
the
capital
lifecycle
controller,
there
is
no
concept
of
a
project.
D
D
At
the
moment,
you
can
think
about
the
captain,
lifecycle,
controller
and
cabinets.
You
totally
separated
projects
and
the
kept
lifecycle
controller
with
the
correct,
correct
function
or
with
a
with
a
with
a
certain
task,
will
be,
might
be
able
to
run
evaluations
in
Captain
E1.
D
So
you
can.
You
can
link
them
at
some
point
in
time,
but
the
lifecycle
controller
does
not
is
is
not
integrating
in
Captain
V1
at
the
moment.
A
Yeah
to
speak
about
Integrations,
Etc
yeah,
you
remember.
We
had
a
lot
of
discussions
about
generalizing
Captain
events
to
the
CD
events
standard.
They
will
see
discussions
about
having
unified
deployment
statuses,
which
could
be
both
Cloud
events
or
crds,
depending
on
the
architecture
chosen.
I.
Think,
basically,
life
cycle
controller
could
be
one
of
a
reference
implementations
for
all
open,
but
the
standards
themselves
could
be
shared
between
Captain
services
and
Integrations,
based
on
adoption.
A
So
it's
still
a
big
question
when
and
how
it
happens,
because
scientists
like
CD
events,
definitely
desperately
need
some
adoption
to
become
relevant
on
the
market.
But
yeah
I
think
that
this
research
and
fully
event-based
system
could
be
actually
a
good
source
of
feedback
for
other
projects.
We're
working
on
in
Captain.
B
I
think
it
gave
me
more
clarity.
I
still
have
some
confusion
to
be
honest,
but
what
I'll
do
is
I'll
go
with
the
repo
once
again
and
then
maybe
we
can
talk
in
the
slack
Channel
I
can
come
with
a
couple
of
questions.
One
last
question
I
had
for
Giovanni
is
Giovanni.
When
the
answer
to
my
question,
what
does
the
Manifest
include?
B
As
you
said,
the
Manifest
will
include
the
deployment
of
your
application.
So
by
this
I'm
understanding
you
mean
the
application
that
we
want
to
deploy.
Yeah.
C
C
D
Welcome
one
thing:
I
also
forgot
during
my
presentation,
is
using
using
the
lifecycle
controller.
We
in
the
in
the
easiest
way
we
won't
need.
We
won't
introduce
new
workload
customer
resources,
so
we
will
use
what
steering
kubernetes
such
as
deployment,
State,
full
sets
and
so
on,
and
only
for
more
sophisticated
use
cases
you
will
need.
You
will
need
the
custom
resource
definitions
we
have
in
capital
the
rest,
so
the
custom
resource
and
resource
definitions
kept
users
internally,
such
as
the
workload
itself,
are
also
generated
by
our
controllers.
D
So
there
is
nothing
new
for
the
users.
Yes,
there
will
be
the
resources
on
the
cluster.
Obviously,
but
we
try
to
keep
this
as
easy
as
easy
for
the
end
user
and
as
transparent
as
possible.
B
Do
we
have
any
talk
around
the
app
I
know?
We
have
the
life
cycle
working
group.
Do
we
have
any
other
extra
documentation
that
we
can
go
over
to
understand.
C
C
A
Sorry
yeah,
so
what
I
said
that
the
force
this
documentation
could
be
also
source
for
the
new
documentation
engine,
so
I
guess
taking
this
project.
Another
set
repositories
like
Captain
Advanced,
spec
Etc.
This
is
what
we
can
use
for.
A
Experiments
and
yeah
I
think
that
the
liquidation
can
be
improved
over
time
right
inside
the
repository,
so
I
wouldn't
expect
the
creation
of
a
new
documentation
site
of
when
you
know
the
communication
repository
of
a
separate
spec
repository,
at
least
for
now,
but
yeah
right
now.
We
just
starts,
in
my
opinion,.
C
We
have
a
new
question
in
the
chat.
What's
the
difference
between
the
captain
gitops
operator
and
the
lifecycle
controller,
the
captain
gitops
operator
was
to
configure
Captain
via
aquito
operator
life
cycle
controller
instead
wants
to
build
on
an
existing
githubs
operator
that
you
already
have
installed,
because
you're
already
deploying
your
application.
We
are,
for
instance,
Argo
City
or
flux,
and
the
lifecycle
controller
lives
next
to
it
and
try
to
interact
with
the
current
operator
to
do
something.
Before
and
after
the
operator
takes
place
and
deploy
your
application.
C
C
G
Yeah,
hopefully,
do
everything
with
good
yeah,
so
other
than
working
on
the
captain.
Life
cycle
controller
I
managed
to
work
on
a
few
things.
The
first
one
is
regarding
the
resource
Service,
where
we
have
a
small
I,
wouldn't
say
it
back,
but
I
would
say
it
was
a
missing
feature.
G
The
thing
was
when
the
user
was
creating
a
new
project
from
with
an
uninitialized
git
repository,
it
automatically
determined
the
default
branch
which
will
be,
which
previously
was
the
master.
So
basically
we
add
a
feature
that
this
name
of
the
main
branch
will
be
configurable
via
Helm
values
So.
G
Currently,
if
the
user
wants
to
create
a
new
project
with
an
unissued
uninitialized
git
Repository
and
wants
to
have
a
different
main
branch
name
as
Western,
he
just
sets
the
helm
value
during
the
resource
service
installation
to
defaulty
set
to
master
to
whatever
he
wants,
for
example,
Main
and
afterwards,
the
resource
service
values
this
name
as
the
name
of
the
main
branch
for
the
project
and
for
all
other
projects
which
we
will,
which
will
have
an
initialized
repositories.
If
the
repository
is
initialized,
the
name
of
the
main
branch
is
already.
G
Another
another
issue
was
a
performance
Improvement
Also
regarding
rehearsal
service.
Previously,
when
accessing
it,
the
outer
authentication
methods
was
computed
for
basically
every
git
action
so
get
fetch
kit,
clone,
git,
push
get
pulled,
and
in
most
of
the
cases
we
have
multiplicate
actions
for
for
one
Captain,
API
request.
G
So
we
actually
moved
this
computation
of
the
of
the
authentication
methods
more
to
the
manager
where
it's
out,
where
it's
computed
only
once
per
API
request,
which
kind
of
improves
the
performance
as
the
logic
does
not
need
to
be
executed
multiple
times
so
for
each
get
action
once,
but
only
for
one
API
request.
It
started
in
a
context
and
are
used
from
the
context
whenever
it's
needed
and
the
last
thing
was
basically
a
missing
functionality
in
the
CLI,
where
we
didn't
support,
adding
risk
stage,
service
or
project
resources,
but
just
the
service
resources.
G
Therefore,
we
added
the
functionality
to
which
is
the
same
as
when
using
the
API
to
be
able
to
add
one
or
multiple
project
resources,
one
or
multiple
service
resources
and
one
or
multiple
stage
resources.
So
this
logic
is
basically
here:
the
CLI
docs
are
updated,
so
you
can
a
nice
example
can
be
found
in
the
code
with
typing
CLI
at
resource
help,
for
example,
here
when
I
think
the
resources
to
the
stage
adding
resources
to
a
single
stage.
D
E
E
What
I've
done
here
is
I
extracted
the
unit
testing
stage,
as
well
as
the
docker,
build
and
push
stage
from
the
GI
Pipeline
and
on
the
other
two
and
extracted
extracted
it
into
a
reusable
secret,
workflow
So
within
those
pipelines.
Now
we
can
reuse
this
new
workflow
and
just
pass
the
required
arguments
into
the
new
workflow
here.
E
E
This
was
inspired
by
the
vietnamian
charts,
so
we
now
have
the
option
to
set
different
presets
for
services.
For
instance,
we
have
a
part
Affinity
presets
and
anti-infinity
presets,
which
can
have
a
value
of
soft
and
hard.
E
Those
values
can
be
overwritten
by
default
values
down
there
in
the
values
to
yaml
in
the
comment
section.
So
every
setting
this
pin
set
here
is
a
default
behavior
for
all
those
services
and
if
a
specific
preset
is
set
for
a
single
service,
for
instance,
this
will
override
the
default
behavior
for
this
service.
At
this
point,
so
we
have
presets
for
pod
affinity
and
anti-affinity,
for
instance,
if
you
Define
the
default
behavior
for
let's
say
pod
anti-affinity.
E
E
Same
goes
for
node
Affinity
setting
here
and
tolerations,
but
if
a
user,
for
instance,
wants
to
have
a
more
specific
setting,
there's
also
a
Affinity
option
for
every
for
the
default
Behavior
as
well
for
the
specific
services,
so
the
Affinity
option
will,
if
the
Affinity
option
is
set,
it
will
ignore
all
those
settings
from
above
regarding
the
Pod
affinities
or
node
affinities
and
as
well
as
from
for
from
the
settings
before
this
here
is,
for
instance,
the
default
setting
in
the
comment
section.
E
If
there
is
a
option,
Set
Affinity
option
set
in
a
specific
service,
this
will
also
ignore
the
default
settings
and
there's
also
another
option
for
tolerations
for
future
health
charts
as
well
yeah,
that's
also
about
it.
Are
there
any
questions
regarding
there.
G
F
Since
we
are
already
quite
far
with
with
respect
to
time,
I
will
make
it
quick
and
just
discuss
the
three
issues
I
was
working
on
in
last
week.
The
first
one
is
also
has
to
do
with
the
resource
service
return
specific
error
when
creating
a
project
with
an
on
a
with
an
initialized
repository,
as
you
maybe
know,
to
create
a
project.
A
good
repository,
the
Upstream
repository
needs
to
be
completely
uninitialized,
meaning
that
it
is
not
allowed
to
have
any
content
or
commit
there.
F
The
problem
previously
was
when
you're,
using
the
CLI,
for
example,
you're
getting
in
this
case.
Such
a
response
is
starting
to
create
project
error.
Create
project
was
unsuccessful.
Project
already
exists,
yeah,
that's
kind
of
true,
but
the
error
message
didn't
told
or
didn't
tell
you
that.
F
The
real
cause
for
this
is
just
that
the
Upstream
repository
is
basically
already
initialized
and
that's
the
reason
why
it
fails
and
with
this
pull
request
here,
I
just
made
a
couple
of
changes
here
and
there
in
the
resource
service
that
the
resources
itself
already
gives
you
back
an
error
that
contains
the
message
about.
What's
what
went
wrong
in
this
case,
it
will
print
out
something
similar
like
this
error.
F
F
Yeah
that
came
up
I,
think
in
one
of
the
last
Community
meetings
and
users
are
regularly
confused
about
this.
Now
it
should
be
a
little
bit
easier
with
the
current
version
of
Captain
D1.
F
Okay
next
thing
also
see
live.
F
This
was
a
basically
a
feature
request
by
Adam.
He
noticed
that
when
he
was
using
the
can
trigger
sequence
command,
it
was
basically
not
able
to
provide
the
payload
event
payload
with
custom
data
for
his
use
case,
and
you
know
I
just
extended
that
command
trigger
sequence,
with
a
minus
minus
data
option
where
you
can
use
the
following
format
to
set
Customs
so
for
the
user
custom
data
into
the
events
emitted
by
the
CLI,
for
example.
F
Here
we
want
to
trigger
a
my
sequence
in
this
and
that
project
stage
service,
blah
blah
I
can
set
minus
minus
data,
and
then
you
have
a
kind
of
dot
separated
format
where
you
can
say
Okay,
test
dot
strategy,
so
the
key
so
to
say
equals
the
value
direct.
And
the
next
thing
you
want
to
say
set
is
evaluation,
dot
time
frame
equals
another
value,
and
this
will
result
in
the
following
event:
payload,
you
have
to
regular
Capital
event
structure
here,
but
also
in
the
data
section
of
this
event.
F
You
would
have
exactly
what
you
put
there,
for
example,
evaluation
time
frame
your
data
evaluation
time
frame,
and
then
your
value
and
the
same
for
the
other
thing.
So
basically,
you
can
provide
a
commissary
separated
list
of
custom.
F
First,
that
will
be
merged
so
to
say
into
the
outgoing
Captain
event.
Data
section
and
last
thing
so
just
interrupt
when
you
have
questions
I
will
just
go
on
is
about
go
utils,
they
go
SDK.
F
F
So
the
request
here
was
that
this
should
be
kind
of
provided
by
the
go
SDK.
If
you're,
if
you're
using
the
osdk
to
develop
your
integration,
then
you
can
just
use
it
by
the
way
you
can
also
use
it
if
you're
not
using
a
go
sdks
just
living
in
go
utils,
but
here
in
that
case,
if
you
are
implementing
a
service
that
needs
to
download
the
SLI
resources,
what
you
do
typically
in
your
event,
handling
function.
Execute
you
just
need
to
grab
the
relevant
API.
F
So
at
that
point
you
have
a
slide
output
instance
where
you
can
just
say:
okay,
please
I
want
to
have
the
SLI
for
this
project
that
stage
and
that
service
and
it
lives
on
the
under
this
sub
directory,
for
example,
Prometheus
SLI,
Dot
yummer,
and
then
you
get
back
the
usual
I
think
it's
a
it's
a
map
from
string
to
interface
or
something
like
that
where
you
can
then
read
your
slis
from
so
very
easy
to
use
and
reuse
for
upcoming
Integrations,
and
that's
already
it
from
my
site.
If
there
are
no
questions,
stop
sharing.
F
A
Not
for
me,
so
thanks
everyone
for
your
time
today.
So
what
is
our
plan
next
week?
We
have
Community
meetings
common
time
and
there
will
be
two
or
three
presentations
for
Google
summer
of
good
projects,
so
just
stay
tuned
for
the
announcements
and
for
life
cycle
controller,
as
I
mentioned.
If
you're
going
to
kubecon,
it's
a
good
opportunity
to
discuss
things,
but
since
almost
nobody
from
this
call
is
going
to
kubecon
I,
guess
it's
just
Thomas
yeah.
A
A
Okay,
I
will
get
it
organized
and
I
will
send
out
doodle
most
likely
it
will
be
a
big
week
after
so.