Create stale.yml workflow to label stale PRs

[nil-is-all]

The behavior is:

• If a PR is not labeled stale, after 60 days inactivity label the PR as stale and comment about it.
• If a PR is labeled stale, after 30 days inactivity close the PR.
• high priority and no-stale PRs are exempt.

[pytorch-bot]

🔗 Helpful Links

🧪 See artifacts and rendered test results at hud.pytorch.org/pr/pytorch/executorch/13565

• 📄 Preview Python docs built from this PR

Note: Links to docs will display an error until the docs builds have been completed.

❌ 1 New Failure, 1 Pending

As of commit 743c01e with merge base 335de46 ():

NEW FAILURE - The following job has failed:

• Build documentation / build (buck2) / Build doc (gh)
  At least one of the pre-conditions you specified did not hold

This comment was automatically generated by Dr. CI and updates every 15 minutes.

[github-actions]

This PR needs a release notes: label

If your change should be included in the release notes (i.e. would users of this library care about this change?), please use a label starting with release notes:. This helps us keep track and include your important work in the next release notes.

To add a label, you can comment to pytorchbot, for example
@pytorchbot label "release notes: none"

For more information, see
https://github.com/pytorch/pytorch/wiki/PyTorch-AutoLabel-Bot#why-categorize-for-release-notes-and-how-does-it-work.

[GregoryComer]

Thanks. Looks good to me.

[GregoryComer]

@nil-is-all Actually, I have one thought. Can you change the cron schedule to run daily? That way, if it errors out, it won't spam. Once we know it's running successfully, we can bump it up to hourly.

[nil-is-all]

@nil-is-all Actually, I have one thought. Can you change the cron schedule to run daily? That way, if it errors out, it won't spam. Once we know it's running successfully, we can bump it up to hourly.

Done, changed it to hourly now.

[GregoryComer]

Thanks. Thinking through it, out of an abundance of caution, can you also comment out the sections that update PRs? That will let us validate the behavior before it starts actually labeling or closing issues. I'll check the logs for the workflow run, and once it looks good, we can put up another PR to enable the actual behavior.

Specifically, lines 96-101, 107-112, and 115-120. It looks like you can either prefix each line with // or surround the block with /* */.