Importing template/boilerplate code - prefered way to communicate this to Dolos

[rien]

Question: how should Dolos accept template/boilerplate code that is to be ignored? (Especially in the web view)

Context

With PR #1524 we will introduce the ability to add a template file to the Dolos analysis. Any code fragments / fingerprints matching with this template file will be ignored. For example:

The class definition and constructor are ignored, but the actual implementation itself not. In this example, only a few lines in the hash function match, but since the other lines are template code, there is still 59% similarity.

In addition, the ability is added to automatically detect code to ignore if fingerprints occur in a high fraction (or absolute count) of the total analyzed files.

As of PR #1524 this will be passed through a command-line parameter --ignore <path>. However, there is no way to communicate this directly through the UI of the web view.

Options

The question is thus how we want to accept this in the web view. I can think of a few options:

• A special field in the info.csv (for example template) which is only true for one entry with the template file
• A special designated file name template.{ext}, ignore.{ext}, boilerplate.{ext} that can be added to any ZIP-file, info.csv or list of files to be analyzed.
• Explicitly uploading an additional file through the web UI. This could be combined with an overhaul of the upload form to accept individual files (Allow uploading individual files in the Web UI upload form #1534)

In addition, we could also allow the option to enable automatic template code detection, or even make this the only option available.

[jorg-vr]

Personal preference from the three options would be template.{ext}

If there is a need to give it a specific nomenclature in the info.csv, we might as well use that as a file name.

From the Dodona perspective, there is no immediate need for the individual file uploads.

[mikaelGusse]

We would prefer the info.csv solution for our use case here at Aalto. In exercises that have multiple files this template.{ext} would possibly cause some issues and not be able to support having multiple template files as easily. Thus the info.csv would be more futureproof in this case even though multi-file submissions are not yet supported. Perhaps both solutions could coexist so that if the info.csv does not have it defined, then it would use the template.{ext} if it can find one.