successCommentCondition not able to check PR labels

[shahzebrizvi16]

I am trying to limit the success comments to only PRs which have not been released on a specific channel already. I am doing this by setting the successCommentCondition to check if a PR has the respective "released on @<channel>" label already or not. If it does then success commenting should be skipped.

In a nutshell, I am trying to avoid this on PRs:

I tried doing it the way specified in the README.md file but after testing it I realized that it might be incorrect. This is because within the Pull Request GitHub API response, the "labels" key is an array of objects which is why the loadash method -.includes would not work there.

So instead I tried to set the successCommentCondition this way using the loadash method -.some after locally testing with a sample API response:

    [
      "@semantic-release/github",
      {
        successCommentCondition:
          "<% return !issue.labels?.some((label) => { return label.name === ('released on @beta'); }) %>"
      }
    ],

The snippet above still did not work. My PRs with the label released on @beta are still getting commented on if I back-merge the main branch tags to the beta branch.

Can I please get some guidance on this, is it my syntax or is this potentially a bug with the plugin?

Thanks!

[babblebey]

Yea @shahzebrizvi16

Thanks for reporting this issue, but we sort of deviated from that format to making the label into a simple array with just their names, meaning we've got

 "labels": ["bug"]

...instead of..

 "labels": [
    {
      "id": 208045946,
      "node_id": "MDU6TGFiZWwyMDgwNDU5NDY=",
      "url": "https://api.github.com/repos/octocat/Hello-World/labels/bug",
      "name": "bug",
      "description": "Something isn't working",
      "color": "f29513",
      "default": true
    }
  ]

and this like didn't exactly make it look like it is in the Pull Request GitHub API response truthfully 😞. I did that

So, if you were to have used what was on the documentation example, that would have worked, hence if your config was

"<% return !issue.labels?includes('released on @beta')) %>"

Yea, that would've worked!

But considering the fact that we had stated in the same documentation example that you should use the Pull Request GitHub API response, so we really are supposed to model exactly after that.

So, we will fix that for sure 👍

[babblebey]

A fix which corrects that API to work exactly has we've resolved as expected has been included in the PR #916

Thanks @shahzebrizvi16

[shahzebrizvi16]

Ah so I was not going crazy 😆! But Wow you addressed that very quickly. I think your fix makes sense to keep it consistent otherwise you would have had to separately specify how labels are handled. For the time being your solution made sense so no worries. It's great to see the fix part of the release.
Thank you for looking in to it @babblebey !!

[shahzebrizvi16]

Also the reason I started looking in to the alternative loadash method is because the original suggestion did not work for me. I just tried it again and it is still commenting on my PR.

Here is how I have it on the release configuration now:

Here it is commenting on the PR:

I am wondering if has to do with the way the labels were being manipulated.

[shahzebrizvi16]

Hey any updates on this?

[babblebey]

in a bit 😉

[github-actions]

🎉 This issue has been resolved in version 11.0.0 🎉

The release is available on:

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

Your semantic-release bot 📦🚀