Add message option

[nicolocastro89]

🚨 IMPORTANT: Please do not create a Pull Request without creating an issue first.

Any change needs to be discussed before proceeding. Failure to do so may result in the rejection of
the pull request.

Description

My attempt to address this issue. This PR adds optional inputs to the github action which allows users to specify a success and failure message to post in place of the default one.
The issue mentioned having the label in the message, this makes it a bit more flexible by allowing the label and the message to be added.

Fixes # (issue)

#2656

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

Screenshots/Sandbox (if appropriate/relevant):

Adding links to sandbox or providing screenshots can help us understand more about this PR and take
action on it as appropriate

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can
reproduce. Please also list any relevant details for your test configuration

• Unit tests for both messages

Test Environment:

• OS:
• @graphql-inspector/...:
• NodeJS:

Checklist:

• I have followed the
  CONTRIBUTING doc and the
  style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes
• Any dependent changes have been merged and published in downstream modules

Further comments

If this is a relatively large or complex change, kick off the discussion by explaining why you chose
the solution you did and what alternatives you considered, etc...

[nicolocastro89]

Updated the docs copy-paste typo

[jdolle]

Thank you for your contribution.
I'd like to understand why this approach is preferred over including the labels at the end of the success/error messages. As is, I don't see how it resolves the issue.

[jdolle]

Rather than allow custom titles, should we instead mention this approveLabel and similarly a failure label within the success/failure messages?

[nicolocastro89]

That is also an option. I imagined not everyone has the same requirements regarding the message. Just like nobody required the labels in the message up until now there might be other needs; maybe someone wants to include a link to how the organisation handles breaking changes. This results in a non breaking change with added flexibility. Similarly to how the labels themselves are inputs.

[nicolocastro89]

definitely a possible approach would be to allow parameters in the response ( for example writing If these changes are expected you can used {approvedLabels} to bypass the check but that seemed overkill.