Skip to main content

Workflow Runs

Course Settings → Workflow Runs is where you look when autograding stops behaving. It reports the GitHub Actions runs that Pawtograder has seen on the course’s student repositories, how long they queued and ran, and the grading errors those runs produced. The entry is instructor-only, and its route is manage/workflow-runs. Unlike almost every other Course Settings entry, it does not sit under manage/course/.

Three tabs

A sidebar on the left of the Workflow Management wrapper switches between: On a narrow screen the sidebar collapses into a Select workflow page dropdown.

A run is not a submission, and not a grader result

These three are separate records, and confusing them is the main way this page gets misread. A workflow run is one execution of one GitHub Actions workflow on one repository. Pawtograder records it from GitHub’s webhook and keys it by run ID, attempt number and course. Any workflow in a student repository is recorded, not only the autograder, so a repository with its own CI will show runs here that have nothing to do with grading. Runs on repositories Pawtograder does not track, such as handout and solution repositories, are never attributed to a course and never appear. A submission is the graded artifact inside Pawtograder. A grader result is the score attached to a submission. A workflow run can finish without producing either, and that gap is exactly what the Grading Errors tab exists to surface. The Student and Assignment values on a run come from the repository the run belongs to, not from the run itself. A group repository identifies a group rather than a single profile, so its runs show a dash in Student.

Overview

Five cards cover Last hour, Today, This week, This month and All time. Each shows Total Runs, Errors, Avg Queue Time and Avg Run Time, plus an Error Rate once there is at least one run. The two timing figures change color as they grow: queue time turns orange above one minute and red above five, and run time turns orange above two minutes and red above ten.
The Overview tab with the Overview, Workflow Runs and Grading Errors sidebar entries and five statistics cards for Last hour, Today, This week, This month and All time, each giving total runs, errors, average queue time and average run time, with an error rate on the cards that have runs
Errors is not the number of runs that failed. It counts the grading-error records described under The Grading Errors tab that were created during the period, independently of whether any individual run succeeded or failed. Error Rate divides that error count by the number of runs in the same window, so it is a ratio between two separately counted things rather than the share of runs that failed.
The statistics window is clamped to six months, so All time means the last six months.

The Workflow Runs tab

This tab lists the 1000 most recently requested runs for the course, newest first. It updates in real time, and the refresh button in the top-right corner reloads it on demand. The count under the table reads N Workflow Runs Total.
The Workflow Runs tab listing four recorded runs with their Run ID, Student, Assignment, Triggered By, Commit, Status, Timeline, Run number, Queue Time and Run Time, every row reading Completed, and a filter control under most headers
Every column except Timeline, Queue Time and Run Time has a multi-select filter in its header, so you can narrow to one student, one assignment, one commit or one status.
Status is derived from timestamps alone: Completed when a completion time has arrived, In Progress when a start time has, Requested when only the request has, and Unknown when none has. It does not read the run’s conclusion, so a run that failed on GitHub still reads Completed here. To find failures, use the Grading Errors tab or open the run on GitHub.
Because rows are built from webhook deliveries, a run that GitHub never reported as completed sits at In Progress indefinitely rather than moving to a failure state.

The Grading Errors tab

This tab is the failure view. Each row is one recorded grading error, newest first, and when there are none the tab says so. Type comes from the error record, and the filter offers User Visible Error, Security Error, Config Error and Unknown. Visibility says whether the student can read the error: a public error is visible to the student on their own submission, while a private one is staff-only. Errors raised by a security check or by an unexpected internal failure are recorded as private. Instructors and graders see every error either way. Clear All Filters resets the header filters, and the text beside it reads Showing X of Y errors, where X is the number of error rows on the page you are looking at and Y is the size of the whole filtered result set.

What a failed run means, and what you can do

The case you will meet most often is a run that finished without producing a grader result. When that happens Pawtograder records an error reading “The grading container failed to terminate cleanly. This may indicate that the grading script ran out of memory or encountered an unexpected error. Please contact your instructor for assistance.”, and writes a grader result with a score of zero so the submission is not left blank. The student sees that message, because it is a public error on their own submission. From a row on the Grading Errors tab you can:
  • Open the run on GitHub through the CI link and read the Actions log, which is where the real cause lives.
  • Open the affected submission through the Submission link.
  • Open the repository or the exact commit through the Repository link.
To make a corrected grader apply to work already submitted, use the assignment’s Rerun Autograder page. Reruns create a new autograder result on the existing submission rather than a new submission, and once GitHub accepts them the queued runs appear on the Workflow Runs tab. See Rerunning the Autograder for the grader-version choices a rerun offers, and Test Insights for launching a regrade from a failing test.

Where the runs come from

The autograder is a workflow file, .github/workflows/grade.yml, that lives in each student repository. Pushes to that repository trigger it according to its own on: block, and the run it starts is what shows up on this page. See Autograding for how the workflow is triggered and what it does. Because each student repository holds its own copy, a repository whose copy is missing or out of date behaves differently from the rest of the class. The CLI’s repos sync-grade-workflow pushes the handout’s copy to student repositories in bulk.

Who can see it

The Course Settings entry is instructor-only, so graders do not see Workflow Runs in their menu. Access behind that menu is not uniform, though: the list of individual runs is visible to instructors only, while grading errors and the statistics behind the Overview are visible to graders as well. A grader who opens the URL directly gets an Overview and a Grading Errors tab that work, and a Workflow Runs tab with nothing in it. See Course Settings for the rest of the menu’s visibility rules.

The dashboard summary

The instructor dashboard carries a Workflow Runs Summary block that is a condensed version of the Overview. Two cards, Last Hour and Last 24 Hours, each show Total Runs, Avg Queue Time, Avg Run Time and Error Rate, with a badge giving the period’s error count, and both card titles link here. Underneath, when either window has errors, a Recent Errors card lists the five newest errors in the course with the error name, when it happened, and the student or group and assignment it belongs to. Its View All badge opens the Grading Errors tab. When both windows are clean, that card is replaced by a single line confirming no errors in the last 24 hours. See Instructor Dashboard for the rest of the dashboard.