Use Cases - GitHubClassroomTestCMPUT229/service GitHub Wiki
Use Cases
001
Setup Classroom
Title: Setup Classroom
Primary Actor: Course Instructor
Scope: GitHub Organization
Level: User
Preconditions:
The organization exists on GitHub.
Trigger: The instructor clones this repo to their computer.
Basic Flow:
Navigate to the directory where the repo is cloned.
Start the setup by typing "setup.sh".
This will initialize a virtual environment for Python that can be used to safely install new Python packages without introducing conflicts with the existing Python install.
The script then activates the virtual environment & installs the dependencies listed in requirements.txt.
After installing, the script deactivates the virtual environment.
The token must be issued for an account that has the authority to perform operations within the organization.
Token Permissions:
Full control of repos
Full control of orgs and teams
Full control of user public keys
Update all user data
Delete repositories
Write the token to the file "git.token".
The .gitignore file should ignore all files matching *.token, keeping the token from being added to the repo and accidentally shared.
Activate the virtual environment by typing "venv source/bin/activate".
The prompt should display (venv) or some similar indication that the environment is active.
Set the default classroom for the manager by typing "classroom_manager.py -o <Org_Name>"
Deactivate the virtual environment by typing "deactivate".
Success Guarantees:
The classroom_manager.py script has access to the organization.
002
Setup Teams
Title: Setup Teams
Primary Actor: Course Instructor
Scope: GitHub Organization
Level: User
Preconditions:
Use Case 001, Setup Classroom, has been successful.
Students taking the course are registered as members of the organization.
Students have formed their teams if they are to do so.
Students have notified the teaching team about their teams' memberships.
Class list is in ./class/class.txt
Teams list is in ./class/teams.txt
Trigger:
Instructor sets the teams by typing "classroom_manager.py -t".
Basic Flow:
The script parses the class.txt and teams.txt files to create the teams.
Students may be in more than one group.
Students not identified as a team-member in any team in teams.txt are defaulted to being in teams on their own.
Team names are generated within the set_teams() method in classroom_manager.py.
Once the team structure of the classroom has been determined, the structure is written to team_defs.json as JSON.
After determining the structure of the teams, the manager creates the teams within the GitHub Organization, and assigns the identified members of the organization to the teams.
Once the teams are formed on GitHub, the structure of the teams is written to team_defs.csv as comma separated values.
Success Guarantees:
The teams described by class.txt and teams.txt are formed within the GitHub Organization.
The structure is described locally as JSON and CSV
The repository used to hold the starter code exists within the organization.
Trigger:
The instructor distributes the repo by typing "classroom_manager.py -r <Repo_Name> -s"
Basic Flow:
The default repo is set to the repo identified by <Repo_Name>.
The list of teams is obtained from the GitHub Organization.
A local clone of the instructor's starter code repo is made.
For each team apart from the Students team, a remote clone of the starter code is made.
First, a new, empty repo is made for the team and named following the convention "<team_name>_<lab_name>"
Then, the remote for the base code is set to the url for this new repo.
The starter code from the base repo is pushed to the new, empty repo.
An early failure in pushing the code may be due to lag time due to the automated nature of the process. If the push fails, a five second wait is made before trying to push one more time.
Success Guarantees:
Each team apart from Students will have a private copy of the starter code in a repo.
All members of each team have the authority to access their repos.
!TODO The submissions for <Lab_Name> are moved to ./marker/<Lab_Name>/ !TODO
!TODO The submission files are identified according to the convention <Team_Name>.s !TODO
!TODO The submission will be in ./marker/<Lab_Name>/<Team_Name>/
Trigger:
The instructor types "classroom_manager.py -m"
Basic Flow:
The manager uses a modified version of spim-grader to mark the submissions.
The grader gathers a set of inputs to be used as test cases from a file identified according to the convention ./marker/test_cases/<Lab_Name>
For each input, the grader spawns a subprocess running the SPIM simulator and passes that input to the process.
The output of the simulator is recorded in a file identified according to the convention ./marker/outputs/<Team_Name>
If the simulator hangs for more than 5 seconds, the process is terminated and an according message is recorded.
Each output file is compared against the expected outputs for the lab. The expectations are recorded in a file identified according to the convention ./marker/expectations/<Lab_Name>
The result of each comparison is written to written to a file identified according to the convention ./marker/results/<Team_Name>.
If each comparison matches, then the test suite is said to have passed.
Success Guarantees:
The outputs of each team's submission are written to ./marker/outputs/<Team_Name>
The graded files are written to ./marker/results/<Team_Name>
Create a summary file, CSV, team name, pass/fail (%), which cases failed