feat: allow conditional skip on success and fail comments

[babblebey]

This PR Intend to transfer the flow from https://github.com/semantic-release/gitlab/pull/730 to the github plugin. It introduces the new properties into the configuration option, which are used to perform the stated function.

• failCommentCondition - used to state the conditions by which the failComment is posted or not
• successCommentCondition - used to state the conditions by which the successComment is posted or not and where it is posted

Changes Made

• Added deprecation notice for failTitle, failComment and successComment set as false

Related Issue

Closes https://github.com/semantic-release/github/pull/360 Closes #359 Closes #666

Screencast/Screenshot

• Demo "successCommentCondition": false - Do not add Success comment to any Issue or PR

https://github.com/user-attachments/assets/63917a26-c71e-433b-9039-a667c37f43f1

• Demo "successCommentCondition": "<% return issue.pull_request; %>" - Add Success comment to only Pull Requests

https://github.com/user-attachments/assets/1f6b57fd-4b3b-4ca3-a4a6-cedde190f01c

• Demo "successCommentCondition": "<% return !issue.pull_request; %>" - Add Success comment to only Issues

https://github.com/user-attachments/assets/f392b1af-c2c6-4d9d-a4e3-dcd6f154ebf5

[babblebey]

Will you also add unit tests for success.js?

Yea, working on that 😉

[babblebey]

I'll investigate further though 🤞

@gr2m turns out the reason why the issue isn't getting seen is because of the owner/repo details in the url not matching the current repo details.

Quick background: I changed the repo name from sr to sr-github.

So the linked issue url is https://github.com/babblebey/sr/issues/11 instead of https://github.com/babblebey/sr-github/issues/11 ....and that was getting seen as though it was an issue linked to an external repo which was filtered out in the logic here https://github.com/semantic-release/github/blob/51ee80881bdf1c1f2b52e8130f46c6158a114bad/lib/success.js#L117-L120

[JonasSchubert]

Looking great!

and sorry for the late (or nearly no) response (moved to a new house without internet for 8 weeks...)

[babblebey]

New Commit

• Added new property type to the issue.user object... This was done to allow for more configuration ability.. hence patching a solution to https://github.com/semantic-release/github/issues/529 via configuration.

• Added test for cases where you don't want success Comment and labels added to PRs created by Bot e.g. dependabot etc.... this was easily done by configuring successCommentCondition as seen below

  successCommentCondition: "<% return !issue.user || issue.user.type !== 'Bot'; %>"
  // This adds comment/label to all issues (regardless of user) and pull request created by users (ignoring bots)
  

😉

[babblebey]

Convert PR to Draft

I have converted PR to draft for the following reason...

• Currently, when we fetch associatedPRs on commits, we get a sophisticated pull request object similar to that of the get-a-pull-request endpoint response object, which makes filtering more configurable in the successCommentCondition using properties like labels, user etc... BUT when we parse the body of the associatedPRs we get the related issue, but currently we only have an object with the number property for the issue its object, like so...

  // issue
  {
    number: 23
  }
  
  // pull_request
  {
    pull_request: true,
    number: 45,
    title: "some title",
    body: "body markdown content",
    // ......more properties
  }
  

  meaning we do not have any means of performing any filtering similar to how we'd do on pull requests with the successCommentCondition in the case of related issues to associatedPRs.

  Rightfully, the properties present on the associatedPRs pull request object should also be present in the related issue object too to enable consistency in filtering operation at configuring successCommentCondition.

Way Forward

Currently, we simply parse the associatedPRs body to get the related issue number only.... Moving forward, I will implement a collection for all these parsed issue numbers and leverage the GitHub Issue GraphQL API, make a call using fragments to get details for these issues with their number and build that object similar to that of the pull request's.

😉

[github-actions[bot]]

:tada: This issue has been resolved in version 10.3.0 :tada:

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot :package::rocket: