►
From YouTube: 2022-04-06 Delivery team weekly APAC/EMEA
Description
No description was provided for this meeting.
If this is YOUR meeting, an easy way to fix this is to add a description to your video, wherever mtngs.io found it (probably YouTube).
A
So
I'm
so
graham
said
he
may
be
a
little
bit
late.
So
how
about
should
we
order
these
reuben?
Do
you
want
to
kick
us
off.
B
Okay,
so
I
recently
created
a
new
slack
app
and
we
can
use
that
to
replace
our
existing
legacy
integration.
So
the
what
we
currently
use
is
git
lab
chat,
ops,
which
is
a
legacy
integration
and
it's
deprecated.
B
So
one
thing
that
we'll
need
to
replace
is
the
web
hooks
web
hooks
can
be
replaced
with
the
with
using
the
chat.post
message
api
because
it's
the
same
thing
you
hit
the
web
hook,
a
message
gets
posted.
You
hit
the
chat,
dot,
post
message,
api,
a
message
get
posted
to
slack.
B
So
if,
if
no
one
outside
release
tools
is
using
the
web
hook,
then
we
could
just
eliminate
the
use
of
web
hooks
and
and
use
the
api
for
everything,
but
I'm
not
sure
if
anyone
outside
the
release
tools
is
using
the
web
book.
So
maybe
we
should
just
replace
it
with
the
new
slack
app
and
then
worry
about
that
separately.
C
Oh
yeah,
I
was
going
to
ask
a
question
here
because
I'm
not
really
familiar
with
how
these
things
got
integrated.
C
So
when
we're
talking
about
the
the
new
application
and
all
those
tokens,
we
are
just
talking
about
our
shadows,
applica
repository
on
ops
right.
So
it's
only
when
a
user
writes
something
in
slack
that
wants
to
trigger
shadows.
It
is
not
the
other
way
around.
B
So
there
are
it's
a
little
confusing
because
the
bot
itself
is
named
chatops
and
the
chat
ops
command
that
we
run
is
also
chat
ops.
So
what
I'm
looking
to
replace
right
now
is
the
token
that
we
use
to
post
messages
that
release
tools
uses
to
post
messages
to
slack
not
the
chat,
slash
command,
yeah.
Eventually,
we
could
replace
that
also,
but
that's
separate.
C
C
A
follow-up
question,
which
is,
if
I
understood
then,
when
we
want
to
write
a
slack
message
from
release
tools.
Let's
say
from
something
that
is
it's
a
pipeline
job,
not
not
something
just
started
as
a
chat.
Ups
command
right.
We
have
an
api
integration
of
some
sort,
and
this
is
the
thing
that
we
are
changing
so
this
this
right
now
this
is
using
the
legacy.
Integration
is
using
web
hooks
on
slack,
not
git
lab
web
books.
C
B
C
C
If
we
are
the
only
user,
then
the
usage
should
drop
and
we
see
okay,
one
week
time
after
that,
we
moved
from
thousands
of
call
a
week
to
zero,
say:
okay,
fine,
we
can
remove
it
and
we
can
still
broadcast
this
information
a
bit
more
verbally
right,
because
no
one
is
I
mean
if
this
has
been
duplicated,
it
will
be
removed,
no
matter
what
so
we
just
say:
let's
do
our
stuff.
Let's
make
sure
that
everything
is
fine.
Then
we
can
see.
We
are
planning
to
remove
this
because
of
the
application.
C
B
Yeah
good
point
yeah
we
could
replace
ours
and
then
check
if
any
metrics
are
available
to
see
if
it's
still
being
used.
Yeah.
D
I
also
have
a
question,
so
we
have
a
new
slack
app,
which
is
called
chat
ops.
So
this
is
just
something
we
created
new
and
slack
right.
Did
we
do
this
or
who
do
did
this?
D
I
I
created
this
lack
of
yeah,
but
we
only
use
it
to
send
messages
from
release
tools
to
slack
right.
We
don't
use
it
to
enter
a
chat
up,
command
and
slack
and
then
to
cause
any
action
or.
B
D
It
maybe
because
if
it's
named
shadows,
it's
super
confusing,
because
we
have
chat
ups
being
used
by
entering
something
in
slack
and
then
causing
actions
right,
but
just
real
chat.
Ups,
I
think,
and
now
we
have
an
app
which
is
called
shadows,
which
we
intend
to
use,
sending
messages
from
our
application
into
slack,
but
not
to
trigger
actions
via
slack
right.
So
now
you
could
rename
it.
So
it's
not
that
confusing.
B
Yeah
yeah
definitely
I
realized
after
I
named
the
app.
Hopefully
I
can
rename
it
without
without
an
access
request,
but
yeah.
We
should
rename
it
yeah.
D
Yeah,
I
don't
have
a
good
name
for
it,
but
I
think
that
wouldn't
really
stools
up
yeah,
something
like
that.
Maybe.
A
Do
you
want
to
create
an
epic
as
well?
Maybe
we've
been
around
sort
of
replacing
chat,
ups
or
whatever,
like
you
want
to
sort
of
categorize
this,
as
so
that
we
can
have
it
makes
it
a
bit
more
visible,
but
also
any
issues
like
this
one
like.
How
do
we
deprecate
like?
Do
we
have
metrics
and
all
of
those
sorts
of
things
we
can
just
gather,
as
if
issues
against
an
epic.
B
Yeah
yeah
make
sense
I'll
open
an
epic.
B
Okay,
so
the
next
one
is
the
next
one
is
pretty
simple:
we
currently
for
the
chat.postmessage
api.
We
use
a
slack
token
variable.
It's
set.
You
can
see
it.
It's
set
in
in
the
ops
mirror
of
release
tools
under
ci
cd
settings,
ci
cd
variables,
so
we
just
replace
that
token
with
a
token
from
the
new
app,
and
that
should
work
that
should
be
a
drop-in
replacement.
B
And
the
last
point
is:
the
last
point
is
about
the
slash
commands,
so
we
currently
have
the
chat,
ops
command,
which
goes
to
the
chat,
ops,
repo.
Would
it
be
beneficial
for
us
to
have
another
slash
command
which
goes
directly
to
release
tools,
so
we
could
possibly
use
this
new
app
for
that.
A
I
mean
we
probably
do
because
I
think
so
the
motivation
behind
this
is
that
our
I
guess
we
want
to
make
sure
we
don't
get
deprecated
right,
like
that's
the
the
key
thing
so
I
think
like.
If,
if
there
are
things
we
have
to
move
for
that,
let's,
let's
plan
those.
If
there
are
things
that
having
done
those
pieces,
make
it
a
little
bit
tidier,
we
can
I'd
say,
get
an
issue
and
we
can
review
those
afterwards.
B
Yeah,
I
was
thinking
of
we
have
an
issue
where
we
have
an
issue
for
creating
a
coordinator
pipeline
using
a
chat,
ops
command.
Now
I
don't
remember
what
is
the
blocker
there?
I
remember
that
there
is
some
blocker,
so
I
I
don't
know
if
having
a
slash
command
which
goes
directly
to
release
tools,
will
help
with
that
as
well.
So
I
wanted
to
ask
if
anyone
remember.
C
Oh,
it
should
be
unrelated
the
problem
there
is
that
there's
no
way
to
externally
trigger
a
coordinated
pipeline,
just
because
it's
designed
to
run
on
tags.
So
the
the
there's,
the
extra
complexity
it's
more
than
this
is
just
like.
How
can
we
rerun
a
coordinated
pipeline
from
attack
that
already
exists,
and
and
and
it
was
framed
as
shadows
driven
deployment
just
because
before
we
could
run
a
chat
ups
deployment
giving
and
a
rail
of
environment.
C
Yeah-
that
being
said
back
to
your
to
your
point,
I
know
that,
for
I
don't
know,
if
it's
one
of
the
reason-
because
I
wasn't
involved
back
then-
but
one
of
the
things
that
we
have
in
place
in
the
in
the
link
between
chat
ups
and
release
tools
being
a
triggered
pipeline
instead
of
a
newsletter
command,
was
that
there
are
some.
C
There
are
some
restrictions
around
who
can
run
certain
tasks
and
these
things
I
don't
remember
if
we
call
this
rake
without-
or
things
like
that,
so
I
don't
know
if
it
was
just
something
like
we
already
have
chat
ups
we
are,
there
are
some
libraries
that
we
brought
for
the
chat
ups
project,
so
we
just
want
to
reuse
them
and
then
trigger
and
don't
have
to
re-implement
everything
on
release
tools,
or
there
are
other
reasons
behind
this.
But
this
is
something
to
to
keep
in
mind.
C
B
Okay,
okay,
but
it
does
seem
like
some
commands
could
be
simplified
because
currently
some
commands
that
go
to
chat
ups,
don't
have
all
the
like:
the
library,
the
classes
and
all
that
we
have
and
release
tools.
A
Awesome,
graham,
you
have
a
next
point.
E
E
Of
scattered
issues
and
a
lot
of
ideas,
especially
for
myself,
I've
put
a
lot
of
tickets
in
about,
like
let's
do
x,
to
make
the
get
lab
com
repo
better.
But
taking
a
step
back,
I've
tried
to
change
the
approach
for
this
to
make
it
more
trying
to
identify
the
problems
before
proposing
a
solution
to
tackle
them.
So
I'm
sure
everyone's
interested
in
this,
I'm
sure
everyone
probably
has
opinions.
E
So
I
I've
put
an
issue
there
that
just
try
and
capture
all
the
problems
we
have
with
the
kate's
workloads,
gitlab
com,
repo,
specifically
the
tanker
deployments,
the
gitlab
helm
files
repos.
Those
are
kind
of
out
of
scope,
I'm
more
interested
in
just
the
get
lab
com
repo.
Specifically.
What
are
all
the
problems?
We
have,
what
are
the
the
frustrations?
We
have
it's
not
completely
fresh
that
fleshed
out,
yet
I
will
continue
to
try
and
iterate
on
it
over
the
coming
days.
E
If
you
know
of
incidents
or
issues
that
are
related
to
any
of
these
points
feel
free
to
drop
them
in
any
other
problems.
You
have
just
everything
you
can
think
of:
let's
get
it
all
together
in
one
issue:
we're
tracking
and
keeping
focused
on,
and
then
we
can
kind
of
use
that
to
define
a
solution
or
an
epic,
or
you
know
some
improvements
coming
out
of
that,
and
I
I
I
have
pretty
strong
ideas
as
to
what
I
want
to
do
to
how
to
fix
those
things.
A
Awesome
thanks
for
putting
this
together.
Graham-
and
this
is
super
timely
q2
starts
in
three
weeks,
so
over
the
next
few
weeks,
we
will
be
figuring
out
like
what
do
we
want
to
work
on
in
q2
which
problems
we
want
to
solve.
So
I
think
this
could
be
a
really
great
problem
for
us
to
for
us
to
consider
as
one
of
our
q20krs
we.
A
A
Awesome
is
there
any
other
stuff
that
anyone
wants
to
discuss
or
anything
around
release,
management,
mttp
or
any
other
topics.