A collection of recurring tasks associated with Student Robotics' events.
Each file represents a single task, and will become a single ticket in a task tracking system.
Each task can be uniquely referred to through use of its task name. This
is the path to the file relative to the root of the repo and without the
.yaml extension. For example: comp/main.
Attributes on the tickets are represented by top level keys within the files,
with the addition of a dependencies key. Dependencies are specified using the
name of the task as described above.
Dependencies are allowed to overlap (i.e: several things can depend on some common task) and in such cases only a single instance of the common task will be created in the tracker. Dependencies are not allowed to be circular.
Tasks can either be created by hand, or by using the script at scripts/add.
The script will guide you through specifying the required attributes for a task.
When adding a task you should ensure the resulting hierarchy is still valid (see
below). If adding many tasks or otherwise working on the hierarchy for a while,
scripts/watch can be used to watch for changes and automatically run the
validation checks when changes appear.
Tasks are expected to either be root tasks or be depended upon by other tasks
(all the way up to a root). This can be checked using scripts/validate-reachability.py.
The set of possible priorities and components are primarily limited by support in the backend, though all are expected to support the same sets. The default backend (which prints to the console) can be used to do a dry-run of an import and thus detect any issues which might occur, either from circular dependencies or from unsupported components.
Both of these checks are combined by the scripts/validate script which can be
used to safely validate that a given tree of tasks meets expectations.
This check is performed on CI for each of the main task roots.
Tasks can be imported into a tracker using the Python 3.7+ script at
scripts/import.py. The dependencies for this script are recorded in
scripts/requirements.txt
By default the import will simply output information to the console, however it also supports creating tasks in either a Trac instance (though this is deprecated) or as issues on a GitHub repository.
For importing into a Trac instance, the instance will need to have the XML-RPC plugin available and you will need an account with permissions to read and write tickets through that API.
For importing into issues on a GitHub repo, their REST API v3
is used so you will need a Personal Access Token with permissions
to create issues on that repo. For public repositories, this is covered by the
repo:public_repo scope.