Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We鈥檒l occasionally send you account related emails.

Already on GitHub? Sign in to your account

log-output: true not logging output #40

Closed
alessbell opened this issue Feb 13, 2023 · 5 comments
Closed

log-output: true not logging output #40

alessbell opened this issue Feb 13, 2023 · 5 comments

Comments

@alessbell
Copy link

Hi there, thanks for your work on this action! We've been using it in the https://github.com/apollographql/apollo-client repo and it locked a bunch of PRs and issues off the bat 馃檹

After a few hours though, I noticed it hit a plateau of around ~10% of existing closed issues and PRs. I've tried using exclude-issue-created-after/exclude-pr-created-after to limit the number that were being initially fetched, then set process-only: 'issues' and finally turned on log output, but I'm not seeing any output (example run). Would appreciate any guidance here, thanks!

@alessbell
Copy link
Author

After running the script locally, I can see the search returning valid PRs + issues that still need to be locked. I have to assume on CI the search is returning nothing for whatever reason since all logging statements seem to be inside the loop over results, so maybe even logging N issues and/or PRs were found before the loop would be helpful signal.

@alessbell
Copy link
Author

The issue turned out to be a GH label that contained whitespace 馃ゲ Looks like it needs to be passed with double quotation marks to the search endpoint to prevent this; as is, the search was returning no issues or PRs. I just removed the whitespace from the label and everything is back to normal. Closing, thanks!

@dessant
Copy link
Owner

dessant commented Dec 1, 2023

Hi @alessbell and @jameslamb, Lock Threads 5.0.1 now supports filtering by labels with spaces, putting the label name in nested quotes is no longer needed. Version 5 also locks closed discussions by default, so make sure to update the workflow to preserve the old behavior.

    steps:
      - uses: dessant/lock-threads@v5
        with:
          process-only: 'issues, prs'

@jameslamb
Copy link

Thanks for the fix and the @!

Should I still expect the nested quotes to work, though?

@dessant
Copy link
Owner

dessant commented Dec 16, 2023

@jameslamb, quotes around labels are stripped when the input parameters are parsed, so your configuration should continue working if you update to v5. Though I've only added quote stripping because I've noticed a couple of projects using nested quotes as a workaround in v4, and at some point it would be good to no longer preventively strip quotes, because it could cause unexpected issues.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants