implementing forge trace

[stschiff]

This PR implements a Forge Trace, which addresses #251.

The implementation is radically simple:

• Every forge output which writes Janno, adds a new column "ForgeTrace" which lists for each sample the name and the package version that the sample came from.
• If ForgeTrace already exists, a new trace is appended with ;.
• There is no special rule for one-package forges, so even subsetting packages results in a ForgeTrace.

What do you think?
The package is not hard to review, the only relevant changes are in Forge.hs. But of course there are tons of Forge Test packages, which all had to be updated for the golden tests to pass.

[codecov]

Codecov Report

❌ Patch coverage is 68.75000% with 5 lines in your changes missing coverage. Please review.
✅ Project coverage is 52.32%. Comparing base (e07f6c7) to head (608b3ce).
⚠️ Report is 2 commits behind head on master.

Files with missing lines	Patch %	Lines
...Poseidon/CLI/Trident/OptparseApplicativeParsers.hs	0.00%	3 Missing ⚠️
src/Poseidon/CLI/Trident/Forge.hs	84.61%	2 Missing ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #397      +/-   ##
==========================================
+ Coverage   52.28%   52.32%   +0.03%     
==========================================
  Files          37       37              
  Lines        6049     6064      +15     
  Branches      648      648              
==========================================
+ Hits         3163     3173      +10     
- Misses       2238     2243       +5     
  Partials      648      648              

☔ View full report in Codecov by Harness.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:

• ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

[stschiff]

I thought some more about it and decided to rename the new column to SourcePackage to make it a bit more tool-agnostic.

[nevrome]

Thanks for looking into this! @TCLamnidis will be happy to hear that this will be added soon. I just have three comments:

1. I think adding/updating this new column should not be the default, but a forge option. We could call it --trace or --docSourcePac or something like this. To illustrate why I would find this annoying as a default behaviour: I recently prepared the patched versions of the AADR v66 packages. There I wanted a minimal diff to keep things human-readable. A new column would have been very irritating in this context.
2. SourcePackage does not fit with the usual column naming scheme in Pascal_Snake_Case. Maybe we should go with Source_Package.
3. Maybe we should add a more complex test case where a package with the Source_Package column gets forged a second time, to see the concatenation in action. Maybe even from two different source packages.

[stschiff]

Yes to all! One advantage of fixing 1) is that the golden tests won't all get updated. I'll get to it.

[stschiff]

Done. Can you check again @nevrome ? Thanks

[nevrome]

Great! I tested it and found it working 👍.

There is a detail I think could be improved: When you merge a package A that already has a Source_Package column with a package B that does not, then the samples from B seem to get an extra n/a entry in the output package C. So these samples would be traced in C with n/a;XXXX_Package-X.X.X and not as expected with XXXX_Package-X.X.X. I'm not sure why this happens, but it is probably not the intended behaviour.

Beyond that I found the command line documentation a bit unclear. We also don't use Janno but .janno file, usually, but that is a matter of taste.

Finally, the feature should also be added to the release changelog text. When this is merged we can make a new trident release.

[stschiff]

OK, agreed to all three points, will get them done. Thanks.