►
From YouTube: Keptn Developer Meeting - April 21, 2022
Description
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
Good
morning,
everyone
so
today
is
april
21st
and,
as
usual,
we
have
the
developer
meeting.
A
A
Okay,
so
regarding
our
news,
so
the
first
big
news
that
captain
incubation
we
started
the
public
comment
period,
so
just
to
explain
what
it
means.
Starting
from
now,
everyone
in
the
community
has
two
weeks
to
comment
on
the
proposal
and
if
there
is
no
negative
comments,
etc,
we
can
proceed
with
the
incubating
stage,
so
the
toc
can
make
a
decision.
A
So
thanks
a
lot
to
everyone
who
was
involved
in
reviews,
discussions
and,
of
course,
features
roadmap
and
everything
that
we
needed
to
provide
in
the
due
diligence
document,
because
yeah,
the
fact
that
we
are
considered
incubation
is
of
course,
a
result
of
all
the
work
put
in
captain
in
the
recent
years
and
yeah
thanks
everyone.
A
So
if
you
want
to
review
et
cetera,
there
is
still
some
time
but
yeah
generally,
we
just
wait
for
the
wider
community,
so
the
talk-up
delivery
has
already
reviewed.
We
did
two
presentations
for
them.
I
in
the
recent
quarter
there
was
a
discussion
and
gentry
view
of
the
due
diligence
document.
So
now
we
wait
just
for
the
tvc
and
whoever
else
wants
to
participate
so
congrats
and
yeah
at
cubecon.
A
I
believe
that
there
will
be
some
celebration
and
hopefully
we
will
be
able
to
have
something
else
later
this
year,
so
maybe
in
austria,
who
knows
so
it's
something
I'm
about
working
on.
A
Okay,
another
news,
so
google
summer
of
code
on
tuesday
the
application
period
was
over.
So
what
I
can
share.
We
got
15
proposals
from
potential
contributors
for
a
number
of
projects,
including
major
ones,
be
posted
aligned
with
the
captain
roadmap.
A
So
it's
a
good
number
for
us
this
year,
most
likely
we'll
have
so.
The
moonshot
is
something
like
four
pro
four
projects,
because
we
are
the
first
year
organization
and
usually
they
just
give
two
slots-
maybe
three
slots,
but
not
more.
Let's
see
how
many
we
so
currently
all
mentors
will
be
reviewing
the
proposals
and
we
will
come
up
with
mentorship
teams
etc,
and
I
might
be
reaching
to
a
few
contributors
just
to
find
the
extra
mentors
for
projects
when
we
need,
for
example,
special,
end
expertise
and
captain
in
integrations.
A
And
yeah,
so
we
have
a
discussion
for
cap
70
today,
but
thomas
is
a
bit
late,
so
he
is
currently
looking
for
the
meeting
booth.
So
we
decided
to
put
it
to
the
end
of
the
agenda
and
we
can
press
it
with
the
demos
and
the
first
one.
Is
florence.
B
You
should
see
my
screen
now
yeah
and
I'm
here
myself,
so
I
have
to
turn
down
the
volume.
So
you
know
the
drill
by
now.
If
there
are
any
questions,
I'm
happy
to
answer
them
after
I've
presented
my
issues
right.
So
the
first
pull
request
I
want
to
show
you
was
a
little
fix
for
the
shipyard
controller,
slash
configuration
service.
B
So
basically,
what
we
discovered
was
that
when
a
service
was
to
be
deleted
by
the
shipyard
controllers
api,
then
in
one
case
we
found
a
scenario
where
the
directory
representing
that
service
was
already
gone
from
the
configuration
service
or
from
the
upstream
git
repository
and
that
led
to
a
state
where
yeah,
basically,
the
mongodb
collection,
with
all
the
project.
Information
still
had
the
service
in
there,
because
the
shipyard
controller
didn't
proceed
with
deleting
the
service,
but,
on
the
other
hand,
in
the
git
repository
the
service.
B
B
We
try
to
delete
the
service
directory
from
the
configuration
service
or
configuration
store,
as
it's
called
here
and
then
now
we
do
the
distinction
if
we
get
an
error
from
the
configuration
service,
but
that
error
is
a
service
not
found,
because
it's
not
there
anymore,
then
in
that
case,
we'll
still
proceed
with
deleting
the
service
from
the
from
the
database,
and
then
we
end
up
with
a
consistent
state
again,
but
in
any
other
era
cases
we
keep
the
previous
behavior.
We
had
and
do
not
proceed
with
deleting
it
all
right.
B
B
So
when
an
event
is
pulled
right
before
it's
killed,
then
it
might
end
up
in
an
inconsistent
state
and
to
avoid
that
we
made
the
following
pull
requests
which,
by
the
way,
needs
a
review
still.
So
basically,
what
did
I
do
here?
So
when
I
receive
the
the
sig
term
signal
in
the
shipyard
controller,
this
will
then
immediately
invoke
the
cancel
function
for
the,
which
will
then
be
propagated
to
the
to
the
periodically
running
components.
B
So
it's
actually
the
nuts
connection
that
regularly
pulse
events,
but
also
the
sequence
and
event
dispatcher.
So
those
will
then
immediately
get
the
information.
Okay,
we've
received
the
sick
term.
Please
do
not
attempt
to
do
any
new
posts
or
any
dispatching
in
order
to
to
yeah
not
have
the
situation
where
anything
is
incompletely
processed
and
then
eventually,
once
the
new
instance
of
the
shipyard
controller
is
up
and
running.
B
B
So
basically,
we
added
the
insecure
skip
tls
option,
so
this
was
actually
provided
previously
with
a
different
name
that
was
specific
to
to
the
ssh
feature
actually,
but
since
of
course,
you
might
also
want
to
be
able
to
skip
the
tls
certificate,
verification
for
https
communication
as
well.
B
That
has
been
renamed
properly
to
kind
of
reflect,
the
this
option
being
a
general
for
both
https
and
ssh
and
now
with
the
resource
service.
If
you
want
to
connect
to
upstream
repository
that
has
a
self-signed
certificate,
for
example,
you
can
now
do
so
by
setting
this
option
to
true
when
updating
the
project's
upstream
credentials
all
right,
I
think
that's
all
from
my
side.
So
now
I
will
turn
up
my
volume
again
and
if
there
are
any
questions,
please
go
ahead.
C
That's
the
one
okay,
so
I
also
have
one
pull
request
to
show
off
today.
It's
about
upgrading
our
mongodb
to
the
latest
or
yeah
to
a
more
current
version.
Actually.
C
So
the
v11
actually
refers
to
the
helm,
chart
version
of
not
the
actual
mongodb
version.
In
this
case
this
was
a
major
bump
in
the
versions,
but
only
for
the
chart
itself
and
not
for
for
mongodb,
so
it
shouldn't
have
any
big
influence
on
on
captain
itself.
C
We
had
to
change
a
few
other
things.
As
you
can
see.
We
updated
the
air
gap
helper
script
here,
to
be
able
to
still
work
with
that.
So,
as
you
can
see,
the
new
actual
mongodb
version
was
bumped
from
449
to
413
yeah,
and
there
were
some
some
other
updates
where
the
mongodb
chart
that
we
are
using
here,
actually
changed.
C
C
So
there
was
some
slight
changes
in
in
our
chart
as
a
result
of
of
this
upgrade,
but
it
will
be
fine
now
yeah
same
with
the
passwords
as
well.
So
the
secrets
here
have
a
different
value
inside
now,
a
different
key,
actually
different,
key
same
value
so
yeah.
C
This
pr
was
quick
in
implementation
and
slow
in
testing,
since
we
have
so
many
options
in
our
help,
chart
and
different
installation
methods,
with
the
cri
and
and
with
the
hound
chart
directly
and
stuff
like
that.
C
D
Thomas
is
here,
and
he
has
a
conflict
at
10,
hence
we
jumped
in
and
and
added
this
item
to
the
agenda.
Now
I'm
can
start
first
of
all,
sharing
my
screen
and
then
talk
about
the
cap70,
which
is
an
old
one.
I
think
you
cannot
see
the
screen.
I
think
I
discussed
it
or
mentioned
it
already
couple
couple
weeks
ago,
where
I
announced
that
we
are
planning
to
work
on
the
feature
of
adding
and
removing
stages
to
and
from
a
project
and
well.
D
This
is
the
basic
idea
and
a
request
from
the
community
for
a
long
time
now,
and
it's
really
straightforward
and
what
the
title
already
says:
it's
about
adding
a
new
stage
to
an
already
existing
project.
Here
I
have
an
example
where
I
have
my
dev
hardening
and
two
prod
environments,
and
with
this
new
feature,
it
should
then
be
possible
that
we
create
a
new
stage,
for
example,
in
between
depth
and
hardening.
D
D
Well,
the
the
basic
idea
is,
I
think,
pretty
straightforward,
but
what
happened
in
the
last
couple
of
weeks
is
a
discussion
around
this
topic
and
actually
a
discussion
about
the
way
we
as
kept
now
using
the
internal
git
repository
and
here,
with
the
help
of
andreas
giovanni
and
and
marcus
luckner.
D
We
have
created
a
comparison
overview
of
the
two
approaches
that
can
be
applied
and
on
the
one
hand,
we
have
the
current
branch
based
on
way
of
storing
artifacts.
In
the
repository
and
on
the
other
side,
we
have
the
folder-based
way
of
storing
artifacts.
D
I
know
that
in
the
resource
service
we
already
have
an
implementation
available
that
allows
us
to
to
switch
to
a
folder
based
structure,
but
with
this
comparison
overview,
we
want
to
make
sure
that
we
are
really
heading
towards
the
right
direction
and
yeah
explain
the
disadvantages
and
advantages
of
both
approaches
so
that
we
can
then
conclude
a
meaningful
opinion
and
then
also
have
some
ways
of
argumenting
the
decision
we
made
and
please
take
a
look
at
this
table.
D
It
clearly
shows
that
the
branch-based
structure
of
storing
configuration
has
disadvantages
and,
in
defect,
will
block
us
for
adding
new
use
cases.
On
top
of
that,
and
at
the
end,
it
will
become
more
challenging
when
we
stay
with
the
current
way
of
storing
configuration,
and
we,
when
we
don't
do
the
switch
over
to
the
folder
based
structure.
D
For
example,
we
see
it
and
also
in
other
tools
like
customize,
or
help
that
the
folder
based
way
of
storing
configuration
is
already
kind
of
future
proven
so
to
say,
and
also
shows
trus
value,
as
customize
is
doing
it.
This
way,
as
well
as
helm,
also
allows
to
structure
a
helm
charts
based
on
folders
and
at
the
end,
it
also
gives
us
a
possibility
that
we
can
start
to
think
of
actually
replacing
git
as
artifact
store
by
another
storage
like
a
blob,
storage
or
or
also
yeah
a
file
storage.
D
Because
then
we
are
not
relying
on
git,
git,
tooling
anymore,
and
just
use
basic
functionalities
like
creating
a
folder
deleting
a
folder
moving
files
around,
and
this
would,
as
I
said
before,
help
us
to
also
then
think
about
new
use
cases.
We
can
build
on
top
of
of
this
approach
then,
and
what
we
at
the
end
concluded
was
the
decision
that
adding
and
removing
stages
requires
the
switch
to
the
new
model.
It
will.
D
All
right
so
far
is
everything
clear
or
are
there
already
questions
regarding
cap
70.
A
D
About
the
timeline,
I
can't
I
can't
say
when
it
will
be
available,
because
what
we
currently
have
in
the
box
or
in
implant
or
are
working
on
is
all
about
the
zero
downtime
upgrade
capabilities
as
they
have
had
prior
and
will
be
finished
or
need
will
be
finished
first
and
once
that
is
done,
we
can
start
to
think
of
working
on
that
topic,
but
updates
on
the
timeline
I
can
give
here
in
a
couple
of
of
weeks
when
it
comes
to
implementation,
yeah.
A
A
D
Totally
agree:
we
had
this
discussion
yeah
the
last
week
in
the
last
week,
but
now
I'm
also
thinking
of
splitting
this
cap
in
in
two
or
actually
three
parts,
because
thomas
also
brought
up
a
very
interesting
point.
Yeah
in
this
comment
and
in
the
in
the
discussions
with
thomas,
we
then
summarized
it
yeah
this
way
and
thomas,
are
you
on
the
call.
F
F
So
when
you
think
of
continuous
delivery
or
delivery
in
general,
you
don't
want
to
deal
with
keep
commits
of
the
upstream
repository,
because
you
don't
you
you
as
a
developer,
you
don't
know
them
and
the
only
thing
you
want
to
do
as
a
developer
is
you
want
to
deliver
a
particular
version
of
your
service,
and
this
is
a
thing
which
cannot
be
achieved
by
our
current
resource
service
and
also
not
via
our
current
configuration
service.
F
So
captain
itself
needs
to
get
get
some
kind
of
awareness
of
versions
that
we
can
say.
Yes,
we
want
to
deliver
the
service.
One
other
service,
let's
say
kept
a
webhook
service
in
the
version
0.1
on
the
stage
dev,
and
therefore
we
need
to
rethink
our
kit
architect
approach
in
the
upstream
repository,
because
the
thing
we
are
doing
there
is
not
gitobs.
F
So
the
repository
there
doesn't
have
so
the
master
of
the
repository
or
the
main
branch
of
this
doesn't
have
to
be
the
source
of
truth.
So,
in
my
opinion,
the
upstream
repository
is
more
an
artifact
store,
then
then,
and
then
a
keyboard
repository
and
therefore
we
need
some
version
of
avionics
there
and
we
need
to
store
the
artifacts
version,
but
otherwise
need
to
need
to
be
able
to
retrieve
the
the
artifacts
in
a
in
a
versioned
way.
F
F
We
need
to
rethink
in
another
enhancement
proposal,
but
it's
also,
in
my
opinion,
it's
a
prerequisite
for
adding
or
removing
stages
to
approach
it
to
a
project
to
clarify
this,
because
currently
we
are
building
our
data
structure
based
on
keep
on
on
the
git
repository,
not
on
how
to
meet
the
data
or
database
entries,
and
I
think
currently,
this
blog
exactly.
This
fact
blocks
us
from
implementing
the
stages.
And
therefore,
I
think
this
is
the
prerequisite
for
everything.
D
Thanks
thomas
for
adding
your
thoughts
on
that
topic,
yeah,
as
said
before,
this
is
now
or
turned
out
to
be
now
a
bigger
chunk
of
work
which
needs
to
be
split
into
different
parts.
The
one
part
is
switching
to
a
folder
based
approach,
then
allowing
or
bringing
in
version
awareness
for
artifacts
and
then
last
but
not
least,
implementing
the
capability
of
adding
and
removing
a
stage,
and
I
would
now
proceed.
D
If
there
are
no
urgent
questions
on
that
topic,.
G
A
Topic,
I
sent
a
follow-up
message
to
slack
about
github's
deep
dive,
so
I
suggest
doing
a
kind
of
public
meeting
for
github's
working
group
and
I
can
help
with
hosting
creator.
I
mean
job
separator
working
group.
Does
it
fire
work
for
you,
johannes
and
thomas
yes,
yeah,
okay,
so
sometime
next
week
or
more
time?
D
H
Okay,
so
let's
go
to
the
bridge
side.
The
first
issue
that
was
bring
up
the
gearwork
was
the
subscription
page
there.
We
have
the
filter
for
stages,
services,
stations
and
services,
and
the
problem
was
that
this
one
was
not
updated,
so
only
on
the
refresh,
so
it
was
rather
a
feature
than
a
fix
so
that
we
add
the
polling
here.
So
if
we
add
new
new
service
now,
let's
call
it,
for
example,.
H
H
If
not,
I
will
go
to
the
next
one.
This
was
also
a
fix,
for
you
know
incorrect
selected
stage
in
the
sequence
screen.
So
this
was
that
one.
So
if
you
are
in
a
specific
sequence
and
selected
an
event,
then
yeah
also
a
deep
link
is
adjusted,
but
on
refresh
there
was
a
program
that
then
the
wrong
stage.
It
was
always
the
latest.
The
last
stage
was
selected
instead
of
the
of
the
right
stage.
So
if
you
refresh
now
right
stage
is
selected
and
the
right
event
is
expanded.
H
H
I
guess,
and
now,
if
you
select
a
stage
for
example
hardening,
then
you
only
see
the
sequences
that
are
defined
in
the
harding
stage
holding
stage
and
if
you
then
select
for
example,
production,
then
yeah,
you
see
there
is
no
custom
sequence
for
production,
but
yeah
only
the
ones
that
are
that
are
refined
for
the
specific
stage
and,
as
you
can
see,
this
selection
drop
down
is
also
moved
here.
Previously.
It
was
on
the
next
page
and
yeah.
H
This
is
now
moved
here,
so
the
next
page
just
contains
the
labels,
and
that's
it
maybe
another
thing
to
mention
here,
just
a
small
change
for
the
evaluation.
H
We
switched
the
order
of
start
at
and
time
frame
here,
because
it
was
a
bit
yeah,
not
aligned
with
the
start
and
end
time,
because
start
was
on
the
right
side
and
for
start
and
end
time
it
was
in
the
left
side
and
now
it
is
aligned
to
be
on
the
same
side
yeah.
That
was
that
feature.
H
The
next
one
was
the
sequence
screen
with
the
waiting
state.
So
previously,
the
waiting
state
was
just
guessed
more
likely
by
the
front
end,
and
now
the
correct
state
waiting
set
is
considered
for
waiting
and
also
for
the
status.
The
waiting
status
is
added
here.
So,
if
example,
for
example,
a
trigger
new
sequence.
H
H
G
I
would
have
a
question:
yes:
do
we
still
have
here
the
paging,
so,
for
example,
if
the
20
events
which
you
are
showing
doesn't
contain
the
integrating
event.
G
H
I
I
It
was
kind
of
a
bigger
change,
but
we
actually
support
will
support
also
the
old
versioning,
so
the
alpha
one,
the
config
version,
the
main
difference
before
between
the
alpha
and
the
beta
beta
versions
are
within
the
requests
object
where,
in
the
alpha
version,
as
you
can
see,
we,
the
curl
commands,
which
should
be
executed
by
the
webhook
service
on
some
kind
of
event,
are
defined
just
as
a
string,
but
in
the
new
beta1
version
they
are
defined
as
an
object
where
you
can
define
the
url
method,
headers
and
some
other
stuffs,
which
you
can
see
in
the
in
the
sticket.
G
I
Some
headers
payloads
and
options
where
the
required
parameters
are
just
the
url
and
the
method.
I
As
I
said,
we
will
support
both
versions
for
some
time
and
but
I
think,
in
couple
of
months
we
will
get.
We
won't
support
the
alpha
one
versions
anymore.
The
reason
why
the
beta1
version
was
implemented
is
due
to
to
make
it
easier
for
the
user
to
create
the
curl
requests
and
also
for
us
to
make
the
parsing
and
evaluation
of
the
call
requests
much
more
effective
and
convenient
so
yeah.
The
second
issue
was
fixing
the
mongodb
connection
issues.
I
We
experienced
some
connection
issues
yeah
due
to
reaching
the
max
pool
size
of
the
connections
where
the
new
connections
were
not
created
and
that
led
to
not
able
to
connect
to
the
mongodb
database,
which
was
actually
the
knife
of
service,
as
with
captain
cannot
work
with
a
database.
I
The
problem
was
mainly
in
the
shipyard
where
actually,
the
connection
to
the
mongodb
is
handled
as
a
singleton
instance,
and
we
were
also.
The
first
problem
was
that
we
were
missing
blocking
of
the
mutex
of
the
connection,
so
actually
multiple
threads
were
able
to
access
the
singleton
instance
at
once
and
try
to
connect
which,
which
resulted
to
the
unexpected
behavior.
I
That
was
the
first
piece
of
the
problem.
The
second
piece
was
when,
due
to
some
reason,
the
connection
was
dead
and
the
instance
tried
to
reconnect.
We
were
missing
a
disconnection
before
the
reconnection
to
the
mongodb
database.
I
That
was
the
second
problem
and
also
the
third
problem
was
that,
after
connecting
to
to
the
mongodb
database,
we
were
not
checking
if
the
connection
is
live
or
we
we
experienced
some
kind
of
problem,
so
it
was
necessary
to
ping
the
existing
connections
after
connecting
the
client
to
the
database,
so
the
ping
was
necessary
and
if
the
ping
failed,
we
should
return
an
error.
We
now
return
an
error
and
if
the
ping
succeeded,
so
we
now
know
that
the
connection
is
live
and
valid.
I
Then
we
just
we
just
the
connection
is
established
and
the
user
can
work
or
the
service
can
work
with
the
connection.
I
Yeah,
actually,
that's
everything
from
my
site
in
the
last
two
weeks.
Are
there
any
questions.
J
Maybe
not
as
a
for
a
question
but
more
for
a
clarification
to
the
community.
We
wanted
to
backport
this
all
in
all
version
14,
13
and
12.,
but
there
were
some
issues
with
github
in
releasing
the
images.
So
we
were
not
able
to
do
that
and
we
will
do
that
as
soon
as
possible.
K
Thank
you
very
much.
Yeah,
I'm
going
to
present
sample
requests
for
the
bridge
that
I
did.
J
J
First,
one
was
about
insufficient
permissions
or
that
he
will
be
redirected
for
login
and
the
second
one
was
a
generic
request,
failed
with
that's
code,
error,
message
and
yeah
that
was
aligned
here
so
that
the
error
message
is
just
displayed
once
and
also
made
sure
yeah
that
for
multiple
calls,
the
401
is
just
displayed
1
and
the
user
is
then
redirected
to
the
login
page
correctly.
J
Yeah
that
the
first
one,
the
second
one
is,
we
format
the
date
time
for
triggering
a
sequence
now
in
a
user-friendly
way.
So
previously,
when
the
user
selected
for
triggering
a
sequence,
an
evaluation
sequence,
the
start
and
end
state,
the
date
input
would
use
the
local
time.
J
But
then
the
displayed
value
would
be
a
utc
date
format,
which
is
also
then
sent
to
the
api,
and
this
is
now
fixed
so
that
on
the
user
side,
you
see
your
local
time
in
the
input
field
and
to
the
api,
we
still
send
the
correct
utc
value.
E
J
Old
screenshot
that
will
update
that
one.
This
is
the
updated
version
since
with
the
selection,
you
can
also
select
the
seconds,
so
we
also
display
the
seconds
okay
there.
Thank
you,
yeah
you're,
welcome
and
the
third
pr
I'm
going
to
present
is
rendering
html
in
notifications.
J
Actually,
this
was
already
supported
and
we
dropped
that
with
the
oauth
error
handling,
because
yeah
we
thought
that
we
are
not
rendering
any
html
in
notifications
actually,
but
there
are
still
some
cases
where
we
might
get
an
response
from
the
server,
for
example,
with
html
content,
and
therefore
we
edit
the
support
for
rendering
that
correctly
again
and
what
we
also
did
is
actually
we
sanitize
and
that's
the
actual
part
of
this
feature.
J
We
sanitize
the
content
with
security
context,
html
yeah,
just
to
make
sure
that
no
scripts
are
injected
there
or
things
like
that.
E
Things
the
first
one
is:
I
worked
on
the
cleaning
up
the
resource
service.
We
had
a
few
problems
from
klaus
regarding
endpoints,
so
at
the
beginning
we
had
that
deleting
was
not
possible
anymore,
because
we
were
not
properly
escaping
the
slash
in
the
path
of
the
resource.
This
is
now
working
fine
and
the
delete
is
returning.
A
200
code
project
also
was
not
project
stage
and
service
endpoint
were
not
returning
any
metadata.
E
I
know
metadata
was
wrongly
formatted
which
was
fixed,
and
then
it
was
not
returning
metadata
after
post
and
put
which
now
it
is
returned
with
the
current
version,
which
is
exactly
the
same
as
the
commit
id
and
the
branching
is
currently
not
having
metadata,
but
we
are
gonna
deprecate.
The
branching
and
the
url
is
already
containing
the
information,
so
that
is
kept
also.
We
are
returning
now
metadata
for
full
resources,
which
was
faulty
before
we
had
all
of
the
metadata
resources
empty.
E
Finally,
there
was
a
change
in
the
post-delete
input
of
the
api
that
now
are
again
deprecated
and
what
else
yeah
there
was
an
end
point
which
was
under
the
wrong
research
that
was
moved
and,
finally,
we
are
not
returning
a
500
status
but
of
400
in
case
of
wrong
git
credential,
so
yeah,
that's
it
for
this
one,
and
also
about
the
resource
service.
There
was
another
one
which
is
concerning
the
user.
E
So,
basically
recently
we
had
a
change
in
the
cli
and
in
the
bridge
where
we
can
add
a
github
stream
repository
without
the
user.
If
we
are
using
a
token
on
http
and
the
resource
service
was
failing
because
it
didn't
have
any
default
user.
This
was
a
fairly
simple
change.
It
was
just
adding
a
default
user
and
that
will
work
fine
with
what
already
have
and
then
finally,
on
fix
in
our
integration
tasks,
there
were
two
integration
tests,
sometimes
randomly
failing.
E
One
of
them
was
the
url
provisioning,
and
that
is
because,
during
the
url
provisioning
tasks,
we
were
deleting
the
shipyard
pods
a
couple
of
time
and
we
were
not
waiting
for
it
to
be
back
up.
E
So
sometimes
we
could
have
some
timing
issue
and
another
test
that
was
fixed
in
this
pr
was
the
git
commit
id
in
here
we
were
sending
at
the
same
time
a
start
event
and
the
finished
event
from
sli,
and
this
we
know
that
right
now,
shipyard
may
not
handle
this
properly
if
the
finished
event
arrives
before
the
started
event.
So
for
now
this
was
fixed
with
a
simple
slip
and
yeah.
That's
it
probably
from
this
pr.
A
Yeah,
so
there
was
a
question
in
help,
but
yeah
I
missed
that
because
of
g-shock
deadlines.
So
the
question
was
about
handling
the
events
on
the
receiver
side.
A
I
mean
due
to
whatever
reason
sla
provider
for
datadog
doesn't
subscribe
to
the
desired
events.
So
if
somebody
is
familiar
with
how
slide
providers
work,
what
are
the
epa
eyes,
defaults,
etc?
It
would
be
nice
if
you
could
comment
there
on
slack.
L
That
is
one
and
other
one
is
I'm.
I'm
testing
out
data
operator,
sorry
talk
service
with
captain,
so
any
user
feedback
or
if
someone
would
like
to
try
it
out.
I
think
that
would
be
a
great
help
to.
L
It
out
locally,
but
I
want
I
wanted
to
try
it
out
with
a
http
metric
http
response
time
metric,
but
it's
not
working
for
some
reason
locally
I
reached
out
to
datadog
and
I
haven't
received
any
response
from
them.
So
the
only
way
I
guess
to
do
it
would
be
to
try
it
out
in
a
live
cluster,
and
I
don't
want
to
create
a
live
cluster
if
I
could
help
it.
So
this
is
like
more
of
a
request.
L
If
someone
has
a
live
class
running
really
help
me
to
try
it
out
or
just
try
it
out
on
your
local
laptop,
because
it
might
just
be
that
my
machine
is
broken.
So
if
anybody
has
time,
I
really
appreciate
it
and
that's
all
from
me.
Thank
you.
A
A
Maybe
later
we
could
discuss
about
how
we
could
make
demos
more
visible
because
yeah,
maybe
we
could
just
let's
say
every
time
we
do
a
major
release
as
a
0-15.
A
Maybe
we
could
record
the
demos
of
key
features
we
deliver.
Maybe
it's
a
separate
session
or
maybe
as
a
developer
meeting
or
I
could
just
go
and
truncate
these
videos
from
the
recordings
and
prepare
a
new
video,
because
I
think
that
it
would
be
really
nice
to
highlight
what's
happening
in
the
captain
project.
We
have
a
lot
of
great
demos
here,
but
yeah
until
we
get
channel
membership
and
we
can
highlight
particular
demos
on
youtube.
A
It's
very
hard
to
discover
particular
future
presentations.
A
So,
let's
take
a
look
speaking
of
zero
fifteen.
What
is
eta
for
that.
A
So
maybe
it's
something
we
could
try
together.
So
if
you
want
to
highlight
particular
features
deliverables.
A
Okay,
oh,
I
can
just
at
times
times
and
point
to
existing
videos
but
yeah.
Currently
we
are
just
very
limited
by
youtube
functionality.
If
you
get
maybe
a
10-fold
more
followers,
it
will
be
much
easier
but
yeah.
Let's
keep
working
on
that.