breaking: Clearer feature flags

[cicdguy]

Addresses comments from #45 (comment)

Hi @emmanuelsdias -are you able to test these new features on your workflows? You can use the branch instead of the version tag (breaking/clearer-feature-flags)

Once we test this on our end and if it looks good on your end, we can create a major release out of this (since the "legacy" feature flags will be retained in the older major release).

[github-actions]

✅ All contributors have signed the CLA
_{Posted by the CLA Assistant Lite bot.}

[github-actions]

Code Coverage Summary (test-no-branch.xml)

Filename                          Stmts    Miss  Cover    Missing
------------------------------  -------  ------  -------  ---------
Main.java                            11       0  100.00%
search/BinarySearch.java             12       1  91.67%   24
search/ISortedArraySearch.java        0       0  100.00%
search/LinearSearch.java              7       2  71.43%   19-24
TOTAL                                30       3  90.00%

Diff against main

Filename      Stmts    Miss  Cover
----------  -------  ------  --------
TOTAL             0       0  +100.00%

Results for commit: 5409dc6

Minimum allowed coverage is 90%

♻️ This comment has been updated with latest results

[github-actions]

Code Coverage Summary (togglable report)

Details

Filename                  Stmts    Miss  Cover    Missing
----------------------  -------  ------  -------  ---------
togglable_test_file.py       20       3  85.00%   6, 11, 17
TOTAL                        20       3  85.00%

Results for commit: 5409dc6

Minimum allowed coverage is 80%

♻️ This comment has been updated with latest results

[github-actions]

Code Coverage Summary (test-missing-lines.xml) without detailed coverage

Results for commit: 5409dc6

Minimum allowed coverage is 50%

♻️ This comment has been updated with latest results

[github-actions]

Code Coverage Summary (test-no-branch.xml) without detailed coverage

Diff against main

Filename      Stmts    Miss  Cover
----------  -------  ------  --------
TOTAL             0       0  +100.00%

Results for commit: 5409dc6

Minimum allowed coverage is 90%

♻️ This comment has been updated with latest results

[github-actions]

Code Coverage Summary (comprehensive test)

Details

Filename                    Stmts    Miss  Cover    Missing
------------------------  -------  ------  -------  ------------
file1_high_coverage.py         10       1  90.00%   9
file2_medium_coverage.py       10       4  60.00%   3-4, 7-8
file3_low_coverage.py          10       7  30.00%   2-4, 6-8, 10
TOTAL                          30      12  75.00%

Results for commit: 5409dc6

Minimum allowed coverage is 70%

♻️ This comment has been updated with latest results

[github-actions]

Code Coverage Summary (test-missing-lines.xml)

Filename                Stmts    Miss  Cover    Missing
--------------------  -------  ------  -------  ---------------
all_lines_covered.py       10       0  100.00%
miss_at_start.py           10       2  80.00%   1-3
miss_at_end.py             10       2  80.00%   9-10
single_line_gaps.py        10       3  70.00%   3, 5, 9
multi_line_gaps.py         10       7  30.00%   4-5, 7-9, 15-18
unsorted_lines.py          10       5  50.00%   4, 3, 8-9, 6
no_lines.py                 0       0  0.00%
single_line.py              1       1  0.00%    4
TOTAL                      61      20  51.25%

Results for commit: 5409dc6

Minimum allowed coverage is 50%

♻️ This comment has been updated with latest results

[cicdguy]

I have read the CLA Document and I hereby sign the CLA

[emmanuelsdias]

I'll test this later tonight, I'll update here once it's done. Thanks a lot!

[emmanuelsdias]

Hey @cicdguy, sorry for the wait. I've tested the changes and found a small bug. When extracting the overall coverage rate, we're parsing it from the last value from a line such as:

TOTAL  794  264  66.75%

However, since we're directly parsing it from the truncated rate (66.75%), small changes (<0.01%) will appear to have the same coverage between base and feature branches. Ideally we should be computing it as 1-(264/794), so that there's greater precision when comparing rates.

That way, even an untested one-liner PR gets caught in the coverage-rate-reduction-failure flag, despite not representing a >0.01% decrease.

[cicdguy]

@emmanuelsdias Thanks again for the wonderful suggestions! If all the testing looks good on your end, I will merge this and create a major release. Let me know :)

[emmanuelsdias]

LGTM, thanks a lot!