`v0.5.0`

[tuunit]

contains: feat: add direct urls for comments #98 bugfix: release url generation #100 feat: add pagination support #101

has been tested here:

MAX_LINES: 125 https://github.com/tuunit/github-activity-testing/actions/runs/5215667001 https://github.com/tuunit/github-activity-testing/tree/8aea49f4045b28a9af35e027511de03ca0672b80

MAX_LINES: 5 https://github.com/tuunit/github-activity-testing/tree/108a03b9615ed203fd40090858038dd0cb8bf697 https://github.com/tuunit/github-activity-testing/actions/runs/5215708948

[jamesgeorge007]

@tuunit, for features/enhancements, let's ensure it is discussed before going ahead with the implementation. This would give us the time to hear from the community as well. Also, it'd be easier to review PRs individually :)

Since this involves a major refactor, shall we make a patch release to get #100 out?

[tuunit]

@jamesgeorge007 no problem I can just cherry pick the commit for the fix and create into another branch and create branch. I'll check your other comments later :)

[tuunit]

There're a few edge cases to be considered.

1. Exiting early if there are no changes to be made.
2. If there're empty lines after the <!--START_SECTION:activity--> comment. This is handled if the <!--END_SECTION:activity--> comment is present. If it's not the case and if the line after the <!--START_SECTION:activity--> comment is empty, let's show a message conveying the <!--END_SECTION:activity--> comment was not found, and it will be inserted towards the end. Also, empty lines were found after the <!--START_SECTION:activity--> comment and will be replaced by the activity events.

Regarding the edge cases:

1. The new implementation always replaces everything between the start and end section comment and tries to commit and push it. In my opinion, we should not try to do any kind of "change detection". Git is the sophisticated change detection tool of choice and therefore should deal with this. No new commit or push will be happening if there wasn't any change. Additionally, this eliminates any logic necessary to deal with changes to the MAX_LINES and other parameters as we will always have a clean slate by removing all the previous messages.
2. As for empty lines between the start and end section comment, this will be dealt with by the new logic as well as they will always be deleted. For empty lines after the start comment without an end comment. They might be intentionally by the user and therefore will be kept with the new implementation.

[tuunit]

@jamesgeorge007 I hope my explanations help to understand the new logic. I know it is a "major" change but I hope it leads to more stability 😊

[jamesgeorge007]

1. The new implementation always replaces everything between the start and end section comment and tries to commit and push it. In my opinion, we should not try to do any kind of "change detection". Git is the sophisticated change detection tool of choice and therefore should deal with this. No new commit or push will be happening if there wasn't any change. Additionally, this eliminates any logic necessary to deal with changes to the MAX_LINES and other parameters as we will always have a clean slate by removing all the previous messages.

I concur. But, we used to exit early and log an appropriate message previously. Isn't it better to keep the behavior? We could even leverage Git to check for changes made during the workflow run instead of comparing the contents manually.

2. As for empty lines between the start and end section comment, this will be dealt with by the new logic as well as they will always be deleted. For empty lines after the start comment without an end comment. They might be intentionally by the user and therefore will be kept with the new implementation.

https://github.com/jamesgeorge007/github-activity-readme/pull/102#discussion_r1257512846