Differences

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

--- vcs:gitlab_roster_usage [2020/09/16 15:59] – [Internal Repo-based Configuration] chudler
+++ vcs:gitlab_roster_usage [2020/09/16 16:17] (current) – chudler
@@ Line 37: / Line 37: @@
 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.
+=====File Format=====
+Files must end in a ''YAML'' file-extension and be in a pre-determined directory. If you have created your own repository, as suggested above, just tell us where to fetch the files from. If we created it for you, the directory is named ''autorevcon.d'' at the root of your ''Admin'' repository, which is contained in the main Course Project.
+All structures must begin with a key that uniquely and globally identifies the course and offering that is currently being taught. The format of the key is opaque to the provisioner and is not parsed, and you are also not restricted to choosing from known keys. Therefore, you are able to create repositories that have no upstream datasource, for testing, future use, and other devices. The example below uses a familiar key structure intended for real courses.
 <code>
@@ Line 49: / Line 55: @@
 </code>
-An example to create course without any associated Registrar data is the same, but includes
+When your configuration is split across multiple files, merging takes place on the basis of the key. So, be sure to use the same key in different ''YAML'' files if your intention is to augment, and use //different keys// if you wish to have entirely different top-level projects created for you.
-more memberships
+An example to create another course without any associated Registrar data is the same as above, but includes more memberships
 <code>
@@ Line 69: / Line 76: @@
 </code>
-==Configuration Merging==
+As the example shows, the automations will consume this structure and map the groups of people ("tas", "students") into roles appropriate for use within Gitlab. Only these four groups are recognized at this time, and these are CNetIDs.
+===Configuration Merging===
 Techstaff will augment any configuration you provide with roster data from the University Registrar. The union of memberships is considered, and scalar values are overridden by your values.
 [[More Roster Configuration Examples]]