Differences

This shows you the differences between two versions of the page.

--- vcs:gitlab_roster_usage [2020/09/16 15:40] – [Controlling The Rosters] chudler
+++ vcs:gitlab_roster_usage [2020/09/16 15:59] – [Internal Repo-based Configuration] chudler
@@ Line 28: / Line 28: @@
 The overall automation tool is controlled by Techstaff. It must be enabled **before** you can modify the provisioner's behavior. However, online customization of repository and project details are available to instructors and other course staff after Techstaff has set the tool to work for you.
-====Internal Repo-based Configuration====
+=====Repo-based Customizations=====
-Before establishing any repositories, the system can be optionally configured to read data that is published in **your own** secure Gitlab repository. Note that the automations can only read from certain known Gitlab servers.
+Before the automations creates the first repository, it can be configured to read data that is published in **your own** secure Gitlab repository. Such a repository should be created by you at [[ https://proj.cs.uchicago.edu]]. This project should exist before your course starts, in its own namespace with limited access. It will probably exist after the course ends, and you can use it to capture the list of TAs as it changes over time, along with other metadata, and course artifacts. It is also possible to control multiple simultaneous course instances through this single "master" repository.
-Every hour, the automations bot will checkout the head of your ''main'' or other nominated branch and scan a directory for ''YAML'' files containing course and enrollment data.
+Every hour, the automations bot will checkout the head of your ''main'', or other nominated branch, and scan a directory for ''YAML'' files. It expects to find course and enrollment data in a particular format. Configuration found there is merged with upstream sources to form the execution plan against the Gitlab API. The tool will use your configuration data and the UC official roster data to build project and repository structures for one, or multiple courses.
-Because of Roster Config Merging, you typically only need to //augment// the Registrar's enrollment data. You are able to add and drop students, and elevate or modify other roles. See [[More Roster Configuration Examples | Advanced Usage]].
+Because of the aforementioned Roster Config Merging, you should expect to merely //augment// the Registrar's enrollment data. You are able to add and drop students, and elevate or modify other roles. As there is no other datasource at this time, you *must* add TAs to this file, for example. See [[More Roster Configuration Examples | Advanced Usage]].
-It is also possible to specify partial information, or split data across multiple files in your repository. All configuration files are merged with others having the same course identifier.
+It is also possible to specify partial information, or split data across multiple files in your repository. All configuration files are merged with others having the same course identifier. For a [contrived] example, one may wish to modify parameters of the repositories on a per-student basis. This structure is easier to maintain if one file is created for each student, instead of placing all data into one ''YAML'' file.
 <code>