Multiple exempt-pr-label where labels have spaces

[brianeclow]

I would like to have two labels to exclude this action. From the examples I could find, a comma separated quoted string appears to be the correct way. However, most of our labels have spaces, unlike the examples. The following represents our configuration, however, it still triggered the action and closed a PR with both labels.

• Did I miss some additional configuration?
• Could a better example be provided?

---
name: "Close Stale Pull Requests"
on:
  schedule:
  - cron: "0 0 * * *"

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/stale@v3
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        stale-pr-label: 'stale'
        exempt-pr-label: 'work in progress,Do Not Merge'

[arirawr]

I have also been having issues with our labels, which have spaces. A better example would be great!

[brianeclow]

Any word on this?
This has become a point of contention.

[stephenbawks]

Also came here looking to see how to handle Labels with white space and special characters. We typically have Labels that are descriptive and easy to read.

Examples:

Priority: Medium
Status: Work In Progress
Type: Bug

[bacongobbler]

Hmm... I was unable to reproduce this issue using the unit tests provided. I'm not sure if this is isolated for PR labels or not. But for reference, there's the unit test that covers this case:

stale/__tests__/main.test.ts

Lines 496 to 516 in e976731

	test('exempt issue labels will not be marked stale (multi issue label with spaces)', async () => {
	const TestIssueList: Issue[] = [
	generateIssue(1, 'My first issue', '2020-01-01T17:00:00Z', false, ['Cool'])
	];
	const opts = {...DefaultProcessorOptions};
	opts.exemptIssueLabels = 'Exempt, Cool, None';
	const processor = new IssueProcessor(
	opts,
	async p => (p == 1 ? TestIssueList : []),
	async (num, dt) => [],
	async (issue, label) => new Date().toDateString()
	);
	// process our fake issue list
	await processor.processIssues(1);
	expect(processor.staleIssues.length).toEqual(0);
	expect(processor.closedIssues.length).toEqual(0);
	});

I modified the test case to add a label called Keep Open, and found that the test results were OK:

~/code/stale ><> git diff
diff --git a/__tests__/main.test.ts b/__tests__/main.test.ts
index ed6d67f..f5a2939 100644
--- a/__tests__/main.test.ts
+++ b/__tests__/main.test.ts
@@ -495,11 +495,11 @@ test('exempt issue labels will not be marked stale', async () => {
 
 test('exempt issue labels will not be marked stale (multi issue label with spaces)', async () => {
   const TestIssueList: Issue[] = [
-    generateIssue(1, 'My first issue', '2020-01-01T17:00:00Z', false, ['Cool'])
+    generateIssue(1, 'My first issue', '2020-01-01T17:00:00Z', false, ['Keep Open'])
   ];
 
   const opts = {...DefaultProcessorOptions};
-  opts.exemptIssueLabels = 'Exempt, Cool, None';
+  opts.exemptIssueLabels = 'Exempt, Cool, None,Keep Open';
 
   const processor = new IssueProcessor(
     opts,

~/code/stale ><> npm test
Test Suites: 1 passed, 1 total
Tests:       31 passed, 31 total
Snapshots:   0 total
Time:        0.515s, estimated 1s
Ran all test suites.

So either this issue has been fixed, or the unit tests are presenting a false positive.

[stephenbawks]

I managed to make this work by just using the ASCII code for a space.

stale-issue-label: 'Status%3A%20Abandoned'

Translated my label which is 'Status: Abadonded'

[brianeclow]

The specific failing case is multiple labels with spaces, a test with this label set would be more accurate.

generateIssue(1, 'My first issue', '2020-01-01T17:00:00Z', false, ['Keep Open', 'Magic Door'])

opts.exemptIssueLabels = 'Exempt, Cool, None, Keep Open, Magic Door';

[bacongobbler]

I tried that as well. The tests still passed.

><> git diff
diff --git a/__tests__/main.test.ts b/__tests__/main.test.ts
index ed6d67f..5a2481f 100644
--- a/__tests__/main.test.ts
+++ b/__tests__/main.test.ts
@@ -495,11 +495,11 @@ test('exempt issue labels will not be marked stale', async () => {
 
 test('exempt issue labels will not be marked stale (multi issue label with spaces)', async () => {
   const TestIssueList: Issue[] = [
-    generateIssue(1, 'My first issue', '2020-01-01T17:00:00Z', false, ['Cool'])
+    generateIssue(1, 'My first issue', '2020-01-01T17:00:00Z', false, ['Keep Open', 'Magic Door'])
   ];
 
   const opts = {...DefaultProcessorOptions};
-  opts.exemptIssueLabels = 'Exempt, Cool, None';
+  opts.exemptIssueLabels = 'Exempt, Cool, None, Keep Open, Magic Door';
 
   const processor = new IssueProcessor(
     opts,

><> npm test
...
Test Suites: 1 passed, 1 total
Tests:       31 passed, 31 total
Snapshots:   0 total
Time:        0.518s, estimated 2s
Ran all test suites.

@stephenbawks may be onto something, though. It's possible that the labels are being passed along to the github action in their URL-encoded form.

[brianeclow]

Yes, that has potential, however, it fails the ease of use category. 😆

This also begs the question, why would one label with spaces be ok, while two labels with spaces not be ok? My original setup only, which I have reverted to using, has work in progress as the only exempt label. And the stale action adheres to the ignore.

[brianeclow]

I stand corrected, it is now failing with a single label. Adding the encoding, as a stop gap.

[brianeclow]

I added %20 in place of the spaces a month ago, and it is still marking PRs with exception labels that contain spaces as stale. @stephenbawks were you able to have the ASCII replacement work for the exempt-pr-label option?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[C0ZEN]

Commented to avoid stale ;)

[brianeclow]

I was on vacation when my reminder went off for this. 😆
Is there any update?

[C0ZEN]

@hross you assigned this one to you but I wish to help on this one.
If this is ok with you I will provide a PR tomorrow.
Also could you give me the right to push?

[github-actions]

This issue is stale because it has been open 30 days with no activity. Remove stale label or comment or this will be closed in 5 days

[brianeclow]

Any update?

[C0ZEN]

@brianeclow might want to check if anything is alright.

[brianeclow]

Nope, still broken... And now, with more fun.
The file:

name: "Close Stale Pull Requests"
on:
  schedule:
  - cron: "0 0 * * *"
  workflow_dispatch:

jobs:
  stale:
    runs-on: ubuntu-latest
    steps:
    - uses: actions/stale@v3
      with:
        repo-token: ${{ secrets.GITHUB_TOKEN }}
        stale-pr-message: 'This Pull Request has been open for 2 days with no activity, if no additional activity is detected, it will be closed in 1 day.'
        days-before-stale: 2
        days-before-close: 1
        stale-pr-label: 'stale'
        exempt-pr-label: 'work in progress'

It marked the PR as stale after two days, and closed it after 2 days. The label was applied.
So, spaces in exempt-pr-label was not solved, and it is now only following days-before-stale count for closing.

[bacongobbler]

You need to upgrade to v3.0.14.

[brianeclow]

So, using actions/stale@v3 does not keep me floating at the most current revision of version 3? This is the SOP for all other Actions.

[bacongobbler]

hmm... When it was first released, v3 was not updated to the new version. That seems to have changed and it's now pointing at the same commit as v3.0.14. Disregard.

[brianeclow]

I am re-running the test with the above listed workflow.

[brianeclow]

This is still running against PR's. Looks like the fix was for only issues. Can this be re-opened?

[brianeclow]

However, it is looking like, the timing is off. It now is ignoring difference between:

        days-before-stale: 2
        days-before-close: 1

And it is closing the PR at 2 days instead of 1.

[brianeclow]

This is still a problem.

[agiudiceandrea]

Has this issue actually been fixed? If yes, what is the correct way to specify two (or more) labels containing spaces for the exempt-pr-label config option with stale@v5?