Support the expression of task dependencies

[gkapfham]

There are several circumstances in which it would be useful to express dependencies between the tasks in a gatorgrader.yml file. For instance, a program might write graphics to the file system and thus a check would be whether or not that program runs without error and/or produces the write console output. However, a direct follow-on of this task would involve checking the file system to ensure that the images exist in the expected directory.

Since the current version of the plugin runs in the checks in parallel and in a non-deterministic fashion, it is not possible currently to ensure that the image check passes because it is run after the check that executes the command and confirms that it worked without error. See what I mean?

Is it possible to easily express dependencies between the checks?

[Michionlion]

It's not very possible -- I would suggest adding such a check as a GatorGrader check. If we were to add it to GatorGradle, it would probably be in the form of a multi-command single "check" option, which executed all the checks it contained in sequence.

[gkapfham]

Hi @Michionlion can you give an example of what this might look like in a check? Right now, I'm not sure I understand if you are suggesting a "check" that expresses a dependency or that, overall, checks can express dependencies.

My mental model is that GatorGradle is like a "Makefile" and GatorGrader is like one of the commands that are run in the Makefile. Since you express the dependencies in the Makefile, I think of dependency expression as fitting more into GatorGradle than into GatorGrader.

Can you give me a few more insights into what you are thinking in your previous response?

[Michionlion]

I'm think that you have most of it right -- except that dealing with dependencies that were specified would be difficult, and require implementing some kind of scheduling algorithm to ensure checks were run in the correct order. The alternative I mentioned is simply a way to express a "list of checks" as a single entity, which would run sequentially; there could be multiple of these entities, alongside normal checks, to ensure that checks were run in the correct order. This would basically shift the scheduling algorithm to the human creating the gatorgrader.yml file.

[gkapfham]

Okay, so, @Michionlion I think that you are suggesting there there be a "list of checks" plugin-in in GatorGrader that then runs all of the specified tasks in a sequential fashion? So, the person creating the gatorgrader.yml file will specify a check called RunSequentialChecks and then somehow specify all of the checks of which the containing check is comprised?

I'm not sure how to implement this, but I think that I understand your idea! Thanks! Let me know if there is something that I am overlooking, okay?

[Michionlion]

Actually, I was suggesting that GatorGradle would be the thing implementing RunSequentialChecks, and it would be a part of the parsing of the config file. I think that would probably be simpler, but your interpretation would also work, and likely be useful in other ways -- it may be getting too close to a more complicated GatorGrader interface however.