feat: implement error notification as pr comment

lampajr commented 7 months ago

Thank you for submitting this pull request

fixes https://github.com/kiegroup/git-backporting/issues/123

Description

Implement an optional notification mechanism on the original pull request for error tracking.

If enabled, the tool will create a new comment in the original PR (the one you tried to backport) with some infos of the error that occurred.

This is going to introduce other two inputs:

[x] enable error notification, disabled by default
[ ] (optional) comment body, with a custom {{error}} placeholder that can be replaced by the actual error.

How Has This Been Tested?

Checklist

[x] Tests added if applicable.
[x] Documentation updated if applicable.

Merge criteria:

[x] The commits and have meaningful messages; the author will squash them after approval or will ask to merge with squash.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work

Note: dist/cli/index.js and dist/gha/index.js are automatically generated by git hooks and gh workflows.

First time here?

This project follows [git conventional commits](https://gist.github.com/qoomon/5dfcdf8eec66a051ecd85625518cfd13) pattern, therefore the commits should have the following format: ``` (): empty separator line empty separator line ``` Where the type must be one of `[build, chore, ci, docs, feat, fix, perf, refactor, revert, style, test]` > **NOTE**: if you are still in a `work in progress` branch and you want to push your changes remotely, consider adding `--no-verify` for both `commit` and `push`, e.g., `git push origin --no-verify` - this could become useful to push changes where there are still tests failures. Once the pull request is ready, please `amend` the commit and force-push it to keep following the adopted git commit standard.

How to prepare for a new release?

There is no need to manually update `package.json` version and `CHANGELOG.md` information. This process has been automated in [Prepare Release](./workflows/prepare-release.yml) *Github* workflow. Therefore whenever enough changes are merged into the `main` branch, one of the maintainers will trigger this workflow that will automatically update `version` and `changelog` based on the commits on the git tree. More details can be found in [package release](https://github.com/kiegroup/git-backporting/blob/main/README.md#package-release) section of the README.

github-actions[bot] commented 7 months ago

Coverage report

St.^{:grey_question:}	Category	Percentage	Covered / Total
🟢	Statements	89.67% (-1.62% 🔻)	495/552
🟢	Branches	86.24% (+0.05% 🔼)	188/218
🟢	Functions	87.4% (-1.03% 🔻)	111/127
🟢	Lines	89.53% (-1.7% 🔻)	479/535

Show new covered files 🐣

|

St.^{:grey_question:}

| File | Statements | Branches | Functions | Lines | | :-: | :- | :- | :- | :- | :- | | 🟢 |

`...` / runner-util.ts

| 100% | 100% | 100% | 100% |

Show files with reduced coverage 🔻

|

St.^{:grey_question:}

| File | Statements | Branches | Functions | Lines | | :-: | :- | :- | :- | :- | :- | | 🟢 |

`...` / console-logger-service.ts

|

85.71% (-6.59% 🔻)

| 100% |

80% (-8.89% 🔻)

|

85.71% (-6.59% 🔻)

| | 🟢 |

`...` / github-client.ts

|

86.36% (-1.36% 🔻)

|

66.67% (-4.76% 🔻)

|

66.67% (+2.38% 🔼)

|

86.15% (-1.35% 🔻)

| | 🟢 |

`...` / gitlab-client.ts

|

84.78% (-9.19% 🔻)

|

75% (-6.82% 🔻)

|

88% (-3.67% 🔻)

|

84.09% (-9.58% 🔻)

|

Test suite run success

187 tests passing in 17 suites.

Report generated by 🧪jest coverage report action from 8b0412b1110044e554b9029e7f5b19158885f4ee

lampajr commented 7 months ago

Status update:

Added new cli argument --enable-err-notification to enable this new feature
Set default error message Backporting failed: {{error}} where {{error}} gets replaced by the actual exception msg

Open points:

I don't really like the default comment message I set right now, any feedback is welcome
Make the comment message configurable, I think this is a good thing but it can be done in a followup PR

TODOs:

[ ] Implement the Gitlab client
[ ] Update documentation
[ ] Try e2e / manual tests

lampajr commented 7 months ago

@earl-warren fyi

lampajr commented 7 months ago

One tiny change otherwise looks great.

Thanks, copy&paste issue lol

I need to drop for today, but I plan to finalize this tomorrow :rocket:

lampajr commented 7 months ago

Open points:

* I don't really like the default comment message I set right now, any feedback is welcome

As first implementation let's go with Backporting failed: ${{error}}

* Make the comment message configurable, I think this is a good thing but it can be done in a followup PR

Will create separate issue to make the comment body configurable through templating

TODOs:

[x] Implement the Gitlab client
[x] Update documentation
[ ] Try e2e / manual tests

Still need to try some real examples, did not have time to setup ad hoc test but will do asap.

lampajr commented 7 months ago

Ok I was able to test it with some real examples, e.g., https://github.com/lampajr/backporting-example/pull/66#issuecomment-2048379252

With latest two commits:

Disable the comment if dry-run is enabled
Updated the default comment to "The backport to failed. Check the latest run for more details."

I decided to remove the error from the comment as it could become very huge if the conflicts are many, e.g., https://github.com/lampajr/backporting-example/pull/66#issuecomment-2048357951

lampajr commented 7 months ago

@earl-warren If you want to take a further look the PR is ready, otherwise I will go and merge!

PS: don't feel obligated, you already did a lot!!!

kiegroup / git-backporting