►
From YouTube: 2021-05-06 - Single Pipeline Status Update
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
All
right
so
thank
you
and
for
joining
this
meeting.
So
the
purpose
of
this
meeting
is
to
define
what
are
going
to
be
the
next
steps
for
the
pipeline
phase
2
and
just
to
summarize
the
current
state
that
it
is
well.
We
have
some
items
that
are
technically
ready
to
be
moved
like
the
q,
a
the
slack
notifications
and
release
tracking
and
at
the
same
time
we
can
now
refactor
the
release
tools
pipeline
to
use
rich
jobs.
The
analysis
made
by
proverbs
shows
that
the
bridge
jobs
fit
our
purposes
so
yeah.
A
So
with
those
two
options
about
moving
items
or
refactor,
I
wanted
to
touch
base
with
you
all
to
see
what
should
we
do
next
and
I
left
some
possible
next
steps
like,
should
we
refactor
to
use
to
stream
with
a
factor?
But
we
have
to
use,
read
jobs
and
delay
everything
else
until
we
have
those,
or
should
we
start
moving
and
refactor
at
the
same
time,
or
should
we
forget
about
the
rate,
jobs
and
just
continue
doing
this
so
or
something
else?
What
do
you
all.
B
There
were
there's
downsides
to
moving
the
jobs
without
having
this
bridge
for
based
on
what
we
were
chatting
about
last
week,
robert,
where
it
will
actually
maybe
not
lose
functionality,
but
some
of
the
timings
will
change
around
the
order
of
events
which
feels
like
it
could
be
confusing,
particularly
the
qa
test
that
we
wouldn't
want
to
report
a
pipeline
as
completed
and
then
be
running.
The
tests
afterwards.
D
On
that
point,
because
we
you
mentioned
it
so
qa
right
now,
we
are
already
practicing
active
weighting.
It
happens
in
deployer
instead
of
release
tools,
but
on
the
cost
spaces.
If
we
move
the
bulk
of
the
trigger
and
weight
together
into
release
tools,
there's
no
cost
implication
and
there
will
be
no
delay
as
well
in
that
sense,
because,
basically,
you
trigger
and
start
waiting.
D
I'm
talking
about
qa,
yeah
yeah
other
things
we
want
to
move,
for
instance,
release
tracking
there's
nothing
to
trigger
here,
because
release
tracking
is
already
deployer
triggering
release
tools.
D
C
C
Yeah,
ideally,
it
would
completely
eliminate
the
the
delayed
jobs
and
release
tools,
because
it
would
just
I
guess,
essentially
the
bridge
that
would
replace
those
delayed.
D
C
D
So
I
I
agree
because
if
we
think
if
we
look
at
timing,
so
it's
the
sixth
twenty
second,
we
will
roll
out
the
something
that
should
include
that
thing
unless
they
realize
that
it's
completely
broken
and
just
removed,
or
something
like
that.
In
the
meantime,
it
should
be
there.
So
then
we
can
enable
the
feature
flags
and
we're
good.
D
So
if
we
will
be
able
to
start
testing
on
the
22nd,
I
mean
I
don't
think
we
are
that
far
away
right,
because
we
need
to
start
figure
out
what
we
want
to
do
code,
the
implementation
with
environment
feature
flag
or
whatever,
so
that
we
can
flip
it
over
for
testing
yeah.
D
Probably
we
are,
I
mean
it's
it's
right
time
for
start
doing
this
on
a
more
general
approach
about
what
is
worth
moving
first,
what
is
worth
moving
later,
and
things
like
that,
so,
as
I
said,
qa
is
kind
of
if
we
move
and
we
have
the
new
didn't
br
the
delayed
yeah.
A
D
If
we
move
and
we
had
a
bridge
job
working
in
place,
not
only
we
move
it,
but
we
also
save
ci
minutes
and
we
get
a
better
implementation.
So
maybe
it's
worth
to
start
thinking
about
this.
Maybe
if
we
have
time
we
can
implement
this,
but
we
as
well,
we
we
we
have
the
the
environment
available
that
we're
using
for
flipping
things
that
we
can
use
to
to
enable
or
not
the
new,
the
new
qa,
but
the
things
that
I'm
I'm
more
interested
into.
D
This
is
that
right
now
we
are
tracking
release
completion,
so
our
deployment
is
complete
after
qa
is
successful,
which
I
think
is
is
broke.
It's
a
broken
mental
model
because
once
the
the
software
is
running
on
the
on
the
environment,
the
deployment
is
successful
in
terms
of
I'm
rolling
out
something
then
it's
broken,
but
this
is
the
package
that
is
broken
right
so
and
this
also
so,
if
we
start
removing
things,
we
can
reorganize
them
to
to
better
serve
our
needs
right,
because
then
we
know
the
deployment
is
completed
and
we
can
start
qa.
D
B
Yes,
I
think
there's
probably
some
future
like,
so
I
think
if
we
think
about
this
workers
set
ourselves
up
well
to
be
able
to
make
changes
but
yeah.
I
agree
kind
of
robert.
We
chatted
about
this.
I
don't
know-
maybe
it's
two
weeks
ago
about
whether
almost
this
release
tracking
job
is
doing
two
jobs
and
it's
sort
of
reporting
on
the
the
deployment
itself
completed,
and
it
was
also
kind
of
reporting
on
it's
all
been
successful
and
the
tests
have
all
completed
as
well,
which
perhaps
is
slightly
different.
B
That
might
become
more
important
as
we
try
and
track
deployment
slo
as
well
mira,
because
that's
almost
what
we've
been
talking
about
is
what's
the
end
of
the
pipeline.
Is
it
before
the
tests
or
after
the
tests,
but
just
in
terms
of
like
next
steps,
then
we
so
we
actually
probably
won't
get
through
masses
before
the
22nd.
B
So
it
sounds
like
we
definitely
want
to
do.
Get
all
the
bridge
jobs
work
completed
so
that
we're
ready
to
start
like
testing
that
as
soon
as
we
can
after
the
22nd
but
robert,
if
you're
out
until
sort
of
like
late
next
week,
mary
you've
potentially
got
some
time
out.
Unlessio
you're
release
managing
like
that
sounds
like
let's
focus
on
that.
B
We
also
have
rollbacks,
which
we
all
have
to
focus
on.
We
have
production
tests
next
week,
so
we
roll
backs
then
bridge
jobs,
and
then
it
sounds
like
if
we
have
time
beyond
that,
then
maybe
we
start
doing
the
qa
triggers,
but
we
may
not
even
get
that
far.
B
But
there's
probably
what
I
think
I'll
do,
because
I
think
we've
had
quite
a
lot
of
things
around
this.
Is
I'm
going
to
open
up
an
epic
around
like
well
I'll,
open
up
an
epic,
but
it
kind
of
links
into
release
velocity,
but
it's
sort
of
a
pipeline
improvements
or
something
like
that,
so
we
have
the
one
already
about.
When
do
we
run
the
prepared
jobs
that
sound
like
there's
some
here
that
we
could
put
into
that?
I
think,
as
we
start
tracking
deployment
slo.
B
In
fact,
skelec
was
chatting
to
you
robert
just
yesterday,
I
think
was
it
yesterday,
no
tuesday
about
the
italy
deploy
and
how
we
roll
out.
I
think
all
of
those
things
are
the
same
sort
of
style
which
are
there
are
ways
we
could
improve
the
pipeline
and
maybe
we
just
start
dropping
those
in
somewhere
and
then
we
can.
We
can
actually
plan
some
work
for
that
stuff.
B
C
D
Because
there's
also
yeah,
because
now
that
we
mentioned
there's
also
something
we
should
keep
in
mind,
which
is
I'm
sorry
to
put
things
on
this,
but
basically
right
now
when
we
do
a
deployment
from
chat
ups,
it
goes
straight
into
the
deployer.
D
So
now
that
we
are
putting
more
control
and
more
things
around
release
tools,
I'm
expecting
that
we
will
end
up
rewiring
the
trigger
to
release
tools
and
right
now
we
can't
do
that,
because
release
tools
doesn't
have
the
ability
to
to
say
just
deploy
and
production,
because
the
pipeline
is
almost
there
right,
you
can
go
in.
You
can
just
this
is
the
package
I
want
to
deploy
again,
because
you
can
provide
information
about
what's
the
package,
but
we
still
had.
D
D
B
So
for
the
like
bridge
jobs
task,
then
what
what's
the
kind
of
scope
of
that
task
like?
Is
there
a
task
before
that
to
break
up
the
the
ci
config
files
or
or
how
does
what
does
this
task
actually
look
like?
I.
A
B
Great
stuff
and
myra,
would
you
mind
updating
somewhere,
epic
and
adding
an
issue?
And
just
so
we
have
that
we
have
this
stuff
visible
somewhere.
Yes,.
A
Well,
if
anyone
has
anything
else
to
say,
or
should
we
just
end,
the
call.