#238 metrics grouping for report generation

[Raleksan]

Adding groups for metrics for report, idea #238.

[Raleksan]

@yegor256

I have completed work on the first version of the metrics grouping.

Currently, groups are defined within the metrics generators in the following format:

METRIC_NAME METRIC_NUMBER [GROUP_NAME] METRIC_DESCRIPTION

If a metric does not belong to any group, the [] must be omitted.

To implement grouping, I made changes to steps/report.sh:

• It automatically finds all existing groups, including one labeled "Ungrouped Metrics."
• It generates structured-list-of-metrics.tex using a predefined template.
• It removes [GROUP_NAME] from the .tex file.
• It overwrites the original list-of-metrics.tex.

Current metrics view from report

[yegor256]

@Raleksan what's the point of placing empty lines so often? Read this please: https://www.yegor256.com/2014/11/03/empty-line-code-smell.html

[Raleksan]

@yegor256

I read the article and I think your point makes sense.

My style is from hardware development (our code usually looks like that), and structuring through spaces is our code style.

I will pay more attention to this point.

[yegor256]

@Raleksan looks very good! Please, check the reports of our CI workflows. Also, see my comment above.

[Raleksan]

@yegor256

I think it's all for steps/report.sh.

Now it's worth thinking about tests, but I was unable to come up with something appropriate that wouldn't require me to implement similar logic from script but inside a test now. Any ideas?

p.s. Sorry for unclear commit history and several force push. I was a little in rage to shellcheck until I remembered that I have it in local Docker container.

[yegor256]

@Raleksan in this PR, you didn't change the output of any metrics-generating scripts. Maybe it's worth doing that, in order to make sure your grouping works correctly?

[Raleksan]

@yegor256

I implemented a test for metrics grouping.

The process works as follows:

• A script for testing metrics is created.
• The steps/report.sh script is executed.
• The report.pdf is converted to report.txt.
• All test groups are verified for existence.
• Each metric is checked to ensure it is placed within the correct group.

[yegor256]

@Raleksan this is pretty dangerous. The file may easily be committed to the repository, since you create in inside the "live" part of the code base (which is a bad practice).

[Raleksan]

@yegor256

I can implement several solutions, could you please tell me which one is better:

• Delete group_test.sh after running steps/report.sh for this test
• Add group_test.sh to .gitignore.
• Add the test metrics to the directory with the metrics already generated while steps/report.sh is running. This method will require tools like inotify to control the deletion and creation of the temp directory.

[yegor256]

@Raleksan I would do it differently. In the report.sh I would say something like this (at the beginning):

if [ -z "LOCAL_METRICS" ]; then
  LOCAL_METRICS=${LOCAL}/metrics
fi

Then, in the test, I would call it like this:

LOCAL_METRIC=your-test-directory "${LOCAL}/steps/report.sh"

Thus, you will fool the script, but won't hurt it.

[Raleksan]

@yegor256

There was no such feature, but I added it and used it for testing purposes.

[yegor256]

@Raleksan thanks!