2017-01-18 22:45:53 +03:00
|
|
|
Periodic Taskgraphs
|
|
|
|
===================
|
|
|
|
|
|
|
|
The cron functionality allows in-tree scheduling of task graphs that run
|
|
|
|
periodically, instead of on a push.
|
|
|
|
|
2017-01-31 22:49:18 +03:00
|
|
|
Cron.yml
|
|
|
|
--------
|
|
|
|
|
|
|
|
In the root of the Gecko directory, you will find `.cron.yml`. This defines
|
|
|
|
the periodic tasks ("cron jobs") run for Gecko. Each specifies a name, what to
|
|
|
|
do, and some parameters to determine when the cron job should occur.
|
|
|
|
|
2020-07-08 21:41:17 +03:00
|
|
|
See `the scema <https://hg.mozilla.org/ci/ci-admin/file/default/build-decision/src/build_decision/cron/schema.yml>`_
|
2020-07-07 19:04:00 +03:00
|
|
|
for details on the format and meaning of this file.
|
2017-01-31 22:49:18 +03:00
|
|
|
|
2017-01-18 22:45:53 +03:00
|
|
|
How It Works
|
|
|
|
------------
|
|
|
|
|
2020-01-24 18:52:50 +03:00
|
|
|
The `TaskCluster Hooks Service <https://firefox-ci-tc.services.mozilla.com/hooks>`_
|
|
|
|
has a hook configured for each repository supporting periodic task graphs. The
|
|
|
|
hook runs every 15 minutes, and the resulting task is referred to as a "cron task".
|
2020-07-07 19:04:00 +03:00
|
|
|
That cron task runs the `build-decision
|
2020-07-08 21:41:17 +03:00
|
|
|
<https://hg.mozilla.org/ci/ci-admin/file/default/build-decision>`_ image in a
|
2020-07-07 19:04:00 +03:00
|
|
|
checkout of the Gecko source tree.
|
2017-01-18 22:45:53 +03:00
|
|
|
|
2020-07-07 19:04:00 +03:00
|
|
|
The task reads ``.cron.yml``, then consults the current time (actually the time
|
|
|
|
the cron task was created, rounded down to the nearest 15 minutes) and creates
|
|
|
|
tasks for any cron jobs scheduled at that time.
|
2017-01-18 22:45:53 +03:00
|
|
|
|
2017-07-12 20:56:02 +03:00
|
|
|
Each cron job in ``.cron.yml`` specifies a ``job.type``, corresponding to a
|
2017-01-18 22:45:53 +03:00
|
|
|
function responsible for creating TaskCluster tasks when the job runs.
|
|
|
|
|
2018-04-17 09:42:23 +03:00
|
|
|
Describing Time
|
|
|
|
---------------
|
|
|
|
|
|
|
|
This cron implementation understands the following directives when
|
|
|
|
describing when to run:
|
|
|
|
|
|
|
|
* ``minute``: The minute in which to run, must be in 15 minute increments (see above)
|
|
|
|
* ``hour``: The hour of the day in which to run, in 24 hour time.
|
|
|
|
* ``day``: The day of the month as an integer, such as `1`, `16`. Be cautious above `28`, remember February.
|
|
|
|
* ``weekday``: The day of the week, `Monday`, `Tuesday`, etc. Full length ISO compliant words.
|
|
|
|
|
|
|
|
Setting both 'day' and 'weekday' will result in a cron job that won't run very often,
|
|
|
|
and so is undesirable.
|
|
|
|
|
|
|
|
*Examples*
|
|
|
|
|
|
|
|
.. code-block:: yaml
|
|
|
|
|
|
|
|
# Never
|
|
|
|
when: []
|
|
|
|
|
|
|
|
# 4 AM and 4 PM, on the hour, every day.
|
|
|
|
when:
|
|
|
|
- {hour: 16, minute: 0}
|
|
|
|
- {hour: 4, minute: 0}
|
|
|
|
|
|
|
|
# The same as above, on a single line
|
|
|
|
when: [{hour: 16, minute: 0}, {hour: 4, minute: 0}]
|
|
|
|
|
|
|
|
# 4 AM on the second day of every month.
|
|
|
|
when:
|
|
|
|
- {day: 2, hour: 4, minute: 0}
|
|
|
|
|
|
|
|
# Mondays and Thursdays at 10 AM
|
|
|
|
when:
|
|
|
|
- {weekday: 'Monday', hour: 10, minute: 0}
|
|
|
|
- {weekday: 'Thursday', hour: 10, minute: 0}
|
|
|
|
|
2019-09-17 17:23:55 +03:00
|
|
|
.. note::
|
|
|
|
|
|
|
|
Times are expressed in UTC (Coordinated Universal Time)
|
|
|
|
|
2018-04-17 09:42:23 +03:00
|
|
|
|
2017-01-18 22:45:53 +03:00
|
|
|
Decision Tasks
|
|
|
|
..............
|
|
|
|
|
2017-07-12 20:56:02 +03:00
|
|
|
For ``job.type`` "decision-task", tasks are created based on
|
2017-01-18 22:45:53 +03:00
|
|
|
``.taskcluster.yml`` just like the decision tasks that result from a push to a
|
|
|
|
repository. They run with a distinct ``taskGroupId``, and are free to create
|
|
|
|
additional tasks comprising a task graph.
|
|
|
|
|
|
|
|
Scopes
|
|
|
|
------
|
|
|
|
|
|
|
|
The cron task runs with the sum of all cron job scopes for the given repo. For
|
|
|
|
example, for the "sequoia" project, the scope would be
|
|
|
|
``assume:repo:hg.mozilla.org/projects/sequoia:cron:*``. Each cron job creates
|
|
|
|
tasks with scopes for that particular job, by name. For example, the
|
|
|
|
``check-frob`` cron job on that repo would run with
|
|
|
|
``assume:repo:hg.mozilla.org/projects/sequoia:cron:check-frob``.
|
|
|
|
|
|
|
|
.. important::
|
|
|
|
|
|
|
|
The individual cron scopes are a useful check to ensure that a job is not
|
|
|
|
accidentally doing something it should not, but cannot actually *prevent* a
|
|
|
|
job from using any of the scopes afforded to the cron task itself (the
|
|
|
|
``..cron:*`` scope). This is simply because the cron task runs arbitrary
|
|
|
|
code from the repo, and that code can be easily modified to create tasks
|
2018-01-26 14:50:07 +03:00
|
|
|
with any scopes that it possesses.
|