Adds label ''status: included-in-next-release" by default

[benwinding]

Hey guys,

It's weird this seems to the label status: included-in-next-release to my PR by default. How do I prevent that? (it's not applicable to me)

Details:

• The PR in question: edit README benwinding/firecache#2
• The Workflow file: https://github.com/benwinding/firecache/blob/07a28443abbb8b9d5a550872585547edcc7447d3/.github/workflows/deploy.yml#L38-L44
• The Workflow Run: https://github.com/benwinding/firecache/runs/593964258

The PR:
benwinding/firecache#2

The run
https://github.com/benwinding/firecache/runs/593964258
Looks like this is where the defaults are added?

How can I stop that?

Thanks for open-sourcing your project, works really well 👌

Cheers,
Ben

[benwinding]

Looks like this is the culprit.

github-actions/communicate-on-pull-request-released/action.yml

Lines 11 to 13 in d0c340c

	pr-label-to-remove:
	description: 'The label to remove when a pull request is released'
	default: 'status: included-in-next-release'

Should I just pass in nothing to this parameter?
Maybe pr-label-to-add: ''

[mollyIV]

Hello @benwinding 👋

Unfortunately, there's no way to skip adding the label for now. If you set pr-label-to-add: '', you'd get the error:

##[error]Validation Failed: {"value":"","resource":"Label","field":"name","code":"invalid"}
##[debug]Docker Action run completed with exit code 1
##[debug]Finishing: Communicate on PR merged

However, I think that making adding / removing labels optional for this action could be a great addition. The implementation should be fairly simple - we'd need to check if a label to add has any value:

// main.ts 

export async function run() {
...

  const labelToAdd = core.getInput('pr-label-to-add');
    if (labelToAdd) {
      await addLabels(client, prNumber, [labelToAdd]);
  }

...

We could apply similar logic for a pr-label-to-remove.

Would you like to give the implementation a try? 😊

[benwinding]

Hi @mollyIV,

Thanks for getting back to me, yes that sounds like a reasonable approach.

Would you like to give the implementation a try?

How should I go about trying that implementation? Should I fork this repo and try it like that?

Cheers,
Ben

[janpio]

Yes, forking and then creating a PR to this repository would be the way to go.