@gr2m done!

Hmm sorry some of the tests are failing, from the looks of it, it is most likely related to #857. Could you have a look? I'm sorry this is probably unrelated to your changes, I don't have time to look into it myself. Let us know if you don't have time either and we will get back to it another time

Hmm sorry some of the tests are failing, from the looks of it, it is most likely related to #857. Could you have a look? I'm sorry this is probably unrelated to your changes, I don't have time to look into it myself. Let us know if you don't have time either and we will get back to it another time

Totally, maybe not today, but definitely this week.

@gr2m it now works on my machine!

Hi @kristof-mattei, kindly resolve the conflict 😉

Hey @kristof-mattei, thank you for sticking to this.

This PR was blocked by the work going on in the PR #874, hence we haven't gotten to this yet.... the PR deprecates the ability of setting successComment to false, introducing successCommentCondition in its place.... It merges soon though 😉

But, in the mean time, kindly confirm my understanding of this feature by answering the question below...

1. Noting the introduction of the new successCommentCondition (in feat: allow conditional skip on success and fail comments #874) which accepts condition via config that results to a boolean value declaring whether both successComment and releasedLabel is added to issues/PRs.... Does this feature separate the releasedLabel from this condition??
2. If this seperate the releasedLabel from the successCommentCondition, Are we gonna be looking to introduce a similar config property releasedLabelCondition to accept dictated conditions under which a release label is added to issues/PRs??

🤔

@babblebey

long overdue...

Noting the introduction of the new successCommentCondition (in #874) which accepts condition via config that results to a boolean value declaring whether both successComment and releasedLabel is added to issues/PRs.... Does this feature separate the releasedLabel from this condition??

Yes, it does

If this seperate the releasedLabel from the successCommentCondition, Are we gonna be looking to introduce a similar config property releasedLabelCondition to accept dictated conditions under which a release label is added to issues/PRs??

If that is what the team wants, yes.

Well noted @kristof-mattei,

Now, I've got this question for @semantic-release/github @semantic-release/maintainers

This feature in wip suggests implementing separate conditions for allowing/disallowing releaseLabel addition to release associatedPRs and relatedIssues; this isolates the condition that controls this action from the successCommentCondition.

Is this something we want?

Cc: @semantic-release/gitlab

Sorry for the late reply @babblebey

Is this something we want?

The github plugin does have the possibility to add release labels, the gitlab plugin does not have that (yet). As it is a slidely different feature then commenting on issues, it makes sense to also control it separately.

2. If this seperate the releasedLabel from the successCommentCondition, Are we gonna be looking to introduce a similar config property releasedLabelCondition to accept dictated conditions under which a release label is added to issues/PRs??

I would vote for aligning it on your latest changes with successCommentCondition to also name it releasedLabelCondition.

And nice feature @kristof-mattei, thanks for working on that.