When a student hands in a commit as a delivery, the commit can be in two states: Still building or finished.
The build of the final commit can change the outcome of the check.
So we check once when the delivery is made, and again when a commit that has been handed in finishes building. (Would there be any better way to combine these events?)
Plus this might bee more specific to SKT than a general rule / rubric.
Right now it would simply fail silently because it can't find the corresponding mastery, but we might want to seperate this more cleanly
Also walking the commits like this is a query for every parent and might be quite slow.
Coverage decreased (-0.008%) to 56.15% when pulling 82334427e40a834295e0f43298909959f78b73ec on LiamClark:build-rubric into b5c3e4cbbdb8c522852c871121c03ae687eec021 on devhub-tud:master.
Potential problems with this implementation:
When a student hands in a commit as a delivery, the commit can be in two states: Still building or finished.
The build of the final commit can change the outcome of the check. So we check once when the delivery is made, and again when a commit that has been handed in finishes building. (Would there be any better way to combine these events?)
Plus this might bee more specific to SKT than a general rule / rubric. Right now it would simply fail silently because it can't find the corresponding mastery, but we might want to seperate this more cleanly
Also walking the commits like this is a query for every parent and might be quite slow.