This can be achieved with the following [configuration in the action](https://docs.github.com/en/actions/reference/workflow-syntax-for-github-actions#permissions) if the permissions are restricted:
This action performs some API calls to GitHub to fetch or close issues and pull requests, set or update labels, add comments, delete branches, etc.
These operations are made in a very short period of time — because the action is very fast to run — and can be numerous based on your project action configuration and the quantity of issues and pull requests within it.
GitHub has a [rate limit](https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting) and if reached will block these API calls for one hour (or API calls from other actions using the same user (a.k.a.: the github-token from the [repo-token](#repo-token) option)).
This option helps you to stay within the GitHub rate limits, as you can use this option to limit the number of operations for a single run.
_Purpose:_
This option aims to limit the number of operations made with the GitHub API to avoid reaching the [rate limit](https://docs.github.com/en/rest/overview/resources-in-the-rest-api#rate-limiting).
Based on your project, your GitHub business plan and the date of the cron job you set for this action, you can increase this limit to a higher number.
If you are not sure which is the right value for you or if the default value is good enough, you could enable the logs and look at the end of the stale action.
If you reached the limit, you will see a warning message in the logs, telling you that you should increase the number of operations.
If you choose not to increase the limit, you might end up with unprocessed issues or pull requests after a stale action run.
When [debugging](#Debugging), you can set it to a much higher number like `1000` since there will be fewer operations made with the GitHub API.
Only the [actor](#repo-token) and the batch of issues (100 per batch) will consume the operations.
Default value: `30`
#### labels-to-add-when-unstale
A comma delimited list of labels to add when a stale issue or pull request receives activity and has the [stale-issue-label](#stale-issue-label) or [stale-pr-label](#stale-pr-label) removed from it.
Default value: unset
#### labels-to-remove-when-unstale
A comma delimited list of labels to remove when a stale issue or pull request receives activity and has the [stale-issue-label](#stale-issue-label) or [stale-pr-label](#stale-pr-label) removed from it.
Warning: each label results in a unique API call which can drastically consume the limit of [operations-per-run](#operations-per-run).
Default value: unset
Required Permission: `pull-requests: write`
#### debug-only
Run the stale workflow as dry-run.
No GitHub API calls that can alter your issues and pull requests will happen.
Useful to debug or when you want to configure the stale workflow safely.
Default value: `false`
#### ascending
Change the order used to fetch the issues and pull requests from GitHub:
-`true` is for ascending.
-`false` is for descending.
It can be useful if your repository is processing so many issues and pull requests that you reach the [operations-per-run](#operations-per-run) limit.
Based on the order, you could prefer to focus on the new content or on the old content of your repository.
Default value: `false`
#### start-date
The start date is used to ignore the issues and pull requests created before the start date.
Particularly useful when you wish to add this stale workflow on an existing repository and only wish to stale the new issues and pull requests.
If set, the date must be formatted following the `ISO 8601` or `RFC 2822` standard.
Default value: unset
#### delete-branch
If set to `true`, the stale workflow will automatically delete the GitHub branches related to the pull requests automatically closed by the stale workflow.
Default value: `false`
Required Permission: `pull-requests: write`
#### enable-statistics
Collects and display statistics at the end of the stale workflow logs to get a summary of what happened during the run.
This option is only useful if the debug output secret `ACTIONS_STEP_DEBUG` is set to `true` in your repository to display the logs.
The idle number of days before marking the issues as stale (by adding a label).
The issues will be marked as stale if the last update (based on [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `updated_at`) is older than the idle number of days.
It means that any updates made, or any comments added to the issues will restart the counter of days before marking as stale.
However, if you wish to ignore this behaviour so that the creation date (based on [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `created_at`) only matters, you can disable the [ignore-issue-updates](#ignore-issue-updates) option.
You can fine tune which issues should be marked as stale based on the milestones, the assignees, the creation date and the missing/present labels from these options:
The idle number of days before closing the stale issues (due to the stale label).
The issues will be closed if the last update (based on [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `updated_at`) is older than the idle number of days.
Automatically remove the stale label when the issues are updated (based on [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `updated_at`) or commented.
The option [days-before-issue-stale](#days-before-issue-stale) will define the number of days before considering the issues or the pull requests as stale.
In most cases, the purpose of this action is to only stale when necessary so if any update occurs or if a comment is added to them, the counter will restart.
Nonetheless, if you don't care about this, and you prefer to stick to this number of days no matter the update, you can enable this option.
Instead of comparing the number of days based on the [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `updated_at`, it will be based on the [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `created_at`.
The idle number of days before marking the pull requests as stale (by adding a label).
The pull requests will be marked as stale if the last update (based on [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `updated_at`) is older than the idle number of days.
It means that any updates made, or any comments added to the pull requests will restart the counter of days before marking as stale.
However, if you wish to ignore this behaviour so that the creation date (based on [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `created_at`) only matters, you can disable the [ignore-pr-updates](#ignore-pr-updates) option.
You can fine tune which pull requests should be marked as stale based on the milestones, the assignees, the creation date and the missing/present labels from these options:
The idle number of days before closing the stale pull requests (due to the stale label).
The pull requests will be closed if the last update (based on [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `updated_at`) is older than the idle number of days.
Since adding the stale label will alter the last update date, we can calculate the number of days from this date.
Automatically remove the stale label when the pull requests are updated (based on [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `updated_at`) or commented.
If set to `true`, the pull requests currently in draft will not be marked as stale automatically.
⚠️ This option consume one operation per pull request to process because we need to fetch the pull request with the GitHub API to know if it's a draft one or not.
In most cases, the purpose of this action is to only stale when necessary so if any update occurs or if a comment is added to them, the counter will restart.
Nonetheless, if you don't care about this, and you prefer to stick to this number of days no matter the update, you can enable this option.
Instead of comparing the number of days based on the [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `updated_at`, it will be based on the [GitHub issue](https://docs.github.com/en/rest/reference/issues) field `created_at`.
stale-issue-message: '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.'
stale-issue-message: '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.'
stale-pr-message: 'This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.'
stale-issue-message: '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.'
stale-pr-message: 'This PR is stale because it has been open 45 days with no activity. Remove stale label or comment or this will be closed in 10 days.'
If the logs are enabled, you can also enable the statistics log which will be visible at the end of the logs once all issues were processed.
This is very helpful to have a quick understanding of the whole stale workflow.
Set `enable-statistics` to `true` in your workflow configuration file.
**Dry-run:**
You can run this action in debug only mode (no actions will be taken on your issues and pull requests) by passing `debug-only` to `true` as an argument to the action.
**More operations:**
You can increase the maximum number of operations per run by passing `operations-per-run` to `1000` for example which will help you to handle more operations in a single stale workflow run.
If the `debug-only` option is enabled, this is very helpful because the workflow will (almost) never reach the GitHub API rate, and you will be able to deep-dive into the logs.
**Job frequency:**
You could change the cron job frequency in the stale workflow to run the stale workflow more often.
