The DEFAULT_COMMENT_MARKER serves as the unique identifier for PR comments, essential for determining which PR comment to update in replace mode. However, this approach becomes problematic when reporting multiple NYC code coverage results. Currently, each subsequent report overwrites the previous one, compelling users to opt for the new mode. This mode, while effective, can lead to an overload of comments in pull requests, a situation particularly cumbersome in monolithic architectures where, for example, ten services might generate ten new comments with each pipeline run. To mitigate this issue, making the comment marker customizable would be beneficial. By allowing each instantiation to define its own marker, we can utilize the replace mode more effectively, eliminating the risk of overwriting incorrect comments.
The DEFAULT_COMMENT_MARKER serves as the unique identifier for PR comments, essential for determining which PR comment to update in
replace
mode. However, this approach becomes problematic when reporting multiple NYC code coverage results. Currently, each subsequent report overwrites the previous one, compelling users to opt for thenew
mode. This mode, while effective, can lead to an overload of comments in pull requests, a situation particularly cumbersome in monolithic architectures where, for example, ten services might generate ten new comments with each pipeline run. To mitigate this issue, making the comment marker customizable would be beneficial. By allowing each instantiation to define its own marker, we can utilize thereplace
mode more effectively, eliminating the risk of overwriting incorrect comments.