Importing template/boilerplate code

[rien]

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.

Changes needed

• Lib:
  The most easy way to implement this, is to just add the template code through the info.csv. This would not require any other changes to make this work, but I think the additional changes below might be beneficial.

• Web:

  • update the upload form with an "advanced" section, where additional parameters can be specified like-M (maximum fingerprint percentage), the kgram size, window size, etc.
  • 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)
  • show whether a template was used (or one of the -m or -M options) on the overview page
  • show template code fragments in the compare view (covered in Improve comparison by highlighting code fragments better #1588)

• API: accept the extra advanced parameters and pass them to the Dolos container

[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.