►
From YouTube: Deploy Freeze Workaround using Pipeline Schedules
Description
See the MVC here: https://gitlab.com/gitlab-org/gitlab/issues/24295
A
B
Today's
world
users
can
leverage
something
like
pipeline
schedules
to
set
a
time
frame
for
which
they
want
a
pipeline
to
run
so
a
user.
A
maintainer
on
a
project
can
say
that
I
want
my
pipeline
to
only
run
specific
time
frames
and,
as
a
result,
they
can
implement
that
schedule
to
run
on
a
reoccurring
basis
within
a
certain
time
zone.
A
So
sorry
I,
this
is
maybe
a
point
where
I
didn't
understand.
When
ice
I've
seen
I
know
that
you
can
schedule
a
pipeline,
I
thought
that
was
just
like
a
I
guess:
I
thought
of
that
use
as
like.
You
would
run
it
every
night
or
you
would
run
it
once
a
month,
but
you
could
also
use
to
say
like
run
this
pipeline,
every
two
minutes,
yeah.
A
B
Yeah,
so
that's
you
get
you
you're
forced
to
go
into
UI
and
set
up
your
pipeline,
so
you
can't
do
it
from
am
will
file
and
that's
something
that
our
users
are
really
looking
for
is
that
they
can
leverage
a
sustainable
yam
will
file
that
they
can
then
create
a
template
for
four
people,
then
to
use
across
multiple
repositories.
So
in
today's
world,
you'd
have
to
set
that
pipeline
for
many
projects.
B
If
you're
a
distributed
non,
mono
repo
use
case,
you
could
have
a
thousand
projects
that
you
would
then
have
to
then
implement
that
pipeline
schedule
for
in
the
front
end.
So
it
could
be
really
problematic
for
our
customers
and
users
that
have
lots
of
different
projects
and
are
very
distributed
with.
B
A
B
B
Again,
like
that,
the
manual
intervention
I
think,
if
you're
leveraging
merge
strains,
is
a
part
of
your
CI.
Then
you'll
always
keep
master
green.
So
in
a
program
in
a
true
progressive
delivery
use
case,
we
wouldn't
need
to
have
a
manual
intervention
there,
because
they
would
be
leveraging
something
like
weird
strains
to
keep
the
master
green,
but
in
cases
where
they
don't
have
true
progressive
delivery
and
people
are
actually
managing
the
schedules
and
monitoring
the
health
of
the
pipeline.
That
would
be
their
use
case.
Okay,.
A
B
A
B
I
think
so
too
I'm
talking
with
Sarah
and
monitoring
to
kind
of
figure
out.
How
do
we
implement
some
more
advanced,
just
alerting
when
it
comes
down
to
you
one
when
there
is
a
deployed
freeze,
but
also
like
preemptively,
whenever
we
notice
that
master
is
going
to
break
or
if
there's
something
a
little
bit
more
proactive,
that
we
can
model
and
get
lab
yeah.
B
B
Like
here's,
here's
one
use
case
where,
like
you,
could
recognize
a
p1
and
then
you
would
your
system
would
recognize
a
p1
and
then
it
would
deploy
freeze
until
the
p1
is
fixed.
So
that
would
then
be
like
a
force
swarming
until
the
peatones
fixed
and
then
you
resume
pipeline
yeah
schedules,
yeah
cool.
A
Yeah,
thank
you.
That's
awful!
So
just
so
I'm
clear,
the
thing
that
I
was
stuck
on
was
what
you
can
put
in
that
schedule.
A
new
pipeline
you
can
your
cron
syntax.
It
cannot
be
it's
not
like
exclusionary.
It
doesn't
say,
run
this
pipeline
all
the
time,
except
during
these
hours.
Right
it.
The
cron
syntax,
is
only
so
recurring
frequency
of
when
you
would
Ronson.
A
A
I
guess
you
get,
you
could
be
like
no
time.
I
was
trying
to
think
of
a
way
that
you
could
still
have
pipelines
run
on
a
on
your
merge
request,
but
not
let
your
deploy
jobs.
So
if
your
deploy
job
was
scheduled,
then
you
would
could
like
effectively
shut
it
down.
But
anyone
doing
feature
branch
work
would
still
get
all
of
their
pipelines
because
those
would
only
run
on
merge
requests,
yeah.
B
So
here's
one
other
example
like
say
that
you
have
a
merge
request
that
contains
dock
changes.
In
addition
to
you
code
changes
say
that
you
want
jobs
that
are
on
a
specific
branch
or
repo
to
always
run
on
a
different
schedule.
You
could
say
jobs
on
branch
only
on
the
schedule:
I,
don't
you
jobs
not
on
this
branch?
That
would
really
can
accept.
Okay,.