Split out the summary table into 2 tables

[zkoppert]

Addresses part of #144

Proposed Changes

Split out the summary table into 2 tables in order to improve readability

Readiness Checklist

Author/Contributor

• If documentation is needed for this change, has that been included in this pull request
• run make lint and fix any issues that you have introduced
• run make test and ensure you have test coverage for the lines you are introducing

Reviewer

• Label as either bug, documentation, enhancement, infrastructure, or breaking

[spier]

If I were to set all of these configurations to TRUE, should the first table still be generated?
HIDE_TIME_TO_FIRST_RESPONSE, HIDE_TIME_TO_CLOSE, HIDE_TIME_TO_ANSWER

[spier]

I confirmed it locally. If I set these configurations:

LABELS_TO_MEASURE = ""
HIDE_TIME_TO_FIRST_RESPONSE = TRUE
HIDE_TIME_TO_CLOSE = TRUE
HIDE_TIME_TO_ANSWER = TRUE

Then the 1st table would have no data other than the headline. Not if this would even render correctly in GFM. Testing here:

resulting markdown code:

| Metric | Average | Median | 90th percentile |
| --- | --- | --- | ---: |

rendered example:

Metric	Average	Median	90th percentile

[spier]

Would be good to prevent possible generation of an empty table. See comment here: #148 (comment)

[spier]

Maybe before doing any of this, one would have to check if the 1st stable will contain any data?

Something along the lines of this:

    if "Time to first response" in columns \
        or "Time to close" in columns \
        or "Time to answer" in columns \
        or labels:

[spier]

I did a quick test locally, and confirmed that this would indeed prevent the generation of the 1st table in this scenario.

I also confirmed that if at least one of these columns exists, the 1st table will be generated.

However we should probably add a real test case for this.

[zkoppert]

I'm on it! Thanks @spier!

[zkoppert]

Check out 3da633e

[zkoppert]

Shifted the logic you suggested for the labels a bit since there is a corner case where there are labels but a user has marked HIDE_LABELS_COLUMN as True.

[spier]

I didn't test this again now but given that you implemented a somewhat similar logic to what I tried previously, and you also added a test case, I am sure this is good :)

[spier]

I don't fully get why this tests for "is False", even though the config variable can be "set to any value" to hide these metrics? I guess it is somehow tied to the "hide_label_metrics=False" in row 81 but I don't fully get that either :)

Btw is this way of handling ENV config variables a Python way of doing things? (I don't know Python that well)

[zkoppert]

hide_label_metrics is False is another way of saying that the variable is not set. That is a python type thing from what I can tell.