►
Description
A best practice way to implement scheduled and on demand tasks in a GitLab pipeline (.gitlab-ci.yml file).
Guided Explorations are examples that are maintained to be working and directly usable by anyone!
https://gitlab.com/guided-explorations/gitlab-ci-yml-tips-tricks-and-hacks/scheduled-and-on-demand-tasks
A
A
You
know,
I
understand
how
to
build
a
gitlab,
ci
yaml
and
have
a
pipeline,
but
I'd
also
like
to
have
some
scheduled
tasks
in
there
that
only
run
on
a
schedule
or
I'd
like
to
cause
the
pipeline
to
be
executed
with
just
a
few
jobs,
not
all
of
the
jobs,
so
normally,
as
folks
start
looking
around
and
trying
to
understand.
Well,
what
exactly
can
I
start
doing
here
to
control
this?
A
They
end
up
finding
out
that
we
have
the
ci
pipeline
source
variable
and
they
see
that
oh
there's
a
lot
of
different
details
here
and
look
at
here
schedule
and
web
and
of
course,
schedule
controls
whether
the
scheduled
jobs
are
have
been
used
to
trigger
this
pipeline
and
web
controls.
Whether
someone
has
gone
in
and
pushed
run
pipeline,
so
it
starts
to
become
natural
to
think
about
using
those
in
order
to
create
these
capabilities.
A
However,
as
you
go
down
that
path,
it
starts
to
get
more
complicated
and,
as
we
go
through
this
guided
exploration,
I'll
give
you
some
ideas.
Why
much
of
what
I
cover
in
the
video
is
right
here
in
the
readme
of
the
guided
exploration
as
well.
So,
instead
of
talking
through
this
detail,
I'm
just
gonna
walk
you
through
it.
So
the
proposal
and
the
way
that
I've
implemented
here
is
to
instead
of
using
pipeline
source,
just
use
a
custom
variable
that
names
the
task
or
task
set
that
you'd
like
to
use.
A
If
we
go
in
here,
oops
sorry
gotta
go
into
the
ammo.
If
we
go
into
the
ammo
we'll
skip
forward
some
of
the
top
stuff
just
to
get
an
idea
here.
So
we
have
a
task
called
security
scan
and
all
we
do
is
say
rules
if
target
task
name
equals
task.
Security
scan
in
this
case
we're
not
really
implementing
the
tasks.
So
we
just
say:
hey
thanks
for
running
this
job
now,
one
of
the
requirements
that
ends
up
coming
up
is:
okay,
that's
well
and
good.
A
We
have
a
task
that
has
two
stages,
some
sort
of
setup
task
and
then
some
sort
of
actual
work
task.
So
we
just
simply
give
it
the
same
task
name
and
then
that
way,
when
we
run
it
both
of
these
will
run
now
as
soon
as
you
do
that
someone's
going
to
say
well
oops,
they
run
at
the
same
time
unless
I
give
them
a
stage.
A
I
think
that's,
basically,
all
the
tasks
scenarios
now
as
soon
as
you
do
this.
You
run
into
the
scenario
that,
as
soon
as
we
say,
we
have
inclusive
logic,
we're
going
to
notice
that
any
job
that
doesn't
have
inclusive
or
exclusive
logic
will
also
run.
So
if
this
has
got
a
regular
pipeline
in
this
file
as
well,
then
every
time
you
run
a
task,
it's
also
going
to
run
the
regular
pipeline,
which
is
not
what
we
want
to
do
so
by
using
a
simple
task
name.
A
We
can
also
simplify,
knocking
out
everything
else
in
the
pipeline,
and
in
this
case
I've
used
a
yaml
anchor
because
we're
going
to
have
to
add
it
to
every
last
job.
That's
not
a
task
job,
so
at
the
top
of
our
code.
Here
we
have
that
yaml
anchor,
the
the
main
secret
is
just
to
say
if
the
task
name
exists,
don't
run
this.
A
This
other
little
secret,
though,
helps
us
prevent
these
tasks
running
by
themselves
in
certain
scenarios,
mainly
auto
devops,
but
that
also
helps
you
as
well.
So
this
is
going
to
be
added
to
every
task
or
every
job.
That's
not
part
of
a
task.
You
can
also
see
here
that
I
have
the
stages
that
are
special
for
tasks
identified
and
separated
from
my
other
stages,
to
see
this
in
action,
we'll
go
down
to
schedules
and
we
have
several
schedules.
So
one
is
the
multi-job
task.
A
Another
one
is
all
tasks
that
are
supposed
to
run
at
2
am,
and
then
we
have
this
chrome
security
task,
so
I'm
just
going
to
hit
play
on
one
of
these,
so
we're
going
to
go,
take
a
look
at
that
running
and
actually
just
go
to
pipelines.
So
we
can
see
the
complete
set
here.
So
you
can
see
that
this
is
running.
We
click
in
and
we
see
that
the
two
jobs
are
supposed
to
run
at
2
am
are
all
that
are
running
if
we
open
them.
A
Let's
pick
up
one
that
is,
and
of
course
the
other
interesting
thing
about
doing
it.
This
way
is
any
scheduled.
Task
can
also
be
an
on-demand
task.
So
if
we
want
to
run
everything
from
2
am
we
could
actually
do
that
as
a
regular
task?
We
don't
have
to
use
the
scheduler
so
on
this
one
we'll
just
say:
grab
this
task
name
and
we'll
go
into
pipelines.