Add action specific debugging option

[ktbarrett]

I need to debug the stale action in cocotb since it's no longer working and I'm not getting any error or warning messages. I saw in the README that the recommendation for debugging this action is to set the ACTIONS_STEP_DEBUG secret to true. However, that has a global effect; I don't want debugging output on my other workflows. It also requires participation by the owner, since I don't have access to the secrets. I think it would be beneficial if there was a way to enable debugging this action alone, without resorting to ACTIONS_STEP_DEBUG.

I don't know much about how actions are written, and I understand there is a chicken and egg problem here with debug logs occurring before the configuration is parsed. I'm only interested in debugging the action's decision making process, which I would expect occurs after configuration processing. I am not as interested in the rest of the debug information.

[C0ZEN]

I am not sure that this is possible. 😞

The logs are currently provided by the @actions/core dependency which require like you said @ktbarrett this configuration to display the logs.

So basically, any other dependencies using the same dependency require this and if you enable the log, you do it for all of them.
We could add a custom option to fine thune the logs AFTER that this option has been set to still have more control over the way to log but I think it's still a mandatory step to do that and it will not meet your needs since you will still see the other logs.

[ktbarrett]

I see. After looking into the code I see the logging is really just generating logging commands to run, which are consumed by the runner. Secrets are the only way to communicate with the runner. I guess that means the only way this could be accomplished is by having a configuration option to decide to use info over debug logs in this codebase. That might be a good amount of work.

[C0ZEN]

@ktbarrett may I suggest you to wait until the next release?
It will help a little due to improvements regarding the logs and also some changes regarding special characters that are inside the labels (and in your case you use labels with ":" and "?" which may be in cause).

[ktbarrett]

may I suggest you to wait until the next release?

I might wait longer than that seeing as I don't know JS/TS 😄

and in your case you use labels with ":" and "?" which may be in cause

This was going to be a follow on question. We have gotten this action to work with :, but I think it stopped after we made a change that added status:close?. Trial and error requires we make commits on master, so I'd rather know exactly what the issue is before proceeding.

Thanks for your responses! Feel free to do what you would like with this issue.

[C0ZEN]

@ktbarrett
I meant to wait until the next release to try once again to debug the stale action on your project.
If there is a fix/feature to be made I am willing to provide a PR to help but right now like I said I do not see what can be done regarding the enhancement of the logs.
I can confirm that it seems to me that your issue is related to this one #173 and the next release should have a fix for it.

[ktbarrett]

I did use the ACTIONS_STEP_DEBUG secret to turn on debug prints and didn't really get much of anything =/ And neither v3.0.15 or v3.0.16 have resolved the problem. Is there anything else I can do?

[C0ZEN]

@ktbarrett could you try to update the config as follow:

• debug-only: true (so that it will not call the GitHub API)
• operations-per-run: 100 (it will process way more issues/prs)

And change the cron to:

• cron: "00 * * * *" (to start it each hour so that you will be able to debug it sooner)

[ktbarrett]

Maybe that's a misconception of mine. Is operations-per-run the number of PR or issues checked, regardless if an action occurs? Or is it the maximum number of actions done? I set it low because the first couple days I got 100 notifications.

[C0ZEN]

@ktbarrett each time the stale workflow needs to interact with the GitHub API it will consume one operation.
This option was made to avoid being kicked by GitHub due to an excessive amount of API calls in a short period of time.
If you keep debug-only: true this option should not cause trouble.
The default value of operations-per-run is 30 so maybe once you finished the debug put it to 30 instead of 5?

[ktbarrett]

The issue was that only-issues was assumed to apply stale to any of the labels, while the option really means all of the labels must match. After switching to any-of-labels it works. Thanks @C0ZEN!

[C0ZEN]

@ktbarrett nice to see that's settle. Indeed some other users recently has the issue as well and the option was confusing. The documentation was updated to solve this and the option any-of-labels was created ;)