Restore 2 weeks inactive label

[t-will-gillis]

Fixes #8176

What changes did you make?

• Saved the labelId for the bot-generated, new 2 weeks inactive label and replaced the labelId from the deleted label.
• Deleted the labelKey entry for "NEW-2WeeksInactive"
• Restored the color and the description from the deleted label back to the updated label (see screenshot of settings under "Screenshots" below)

Why did you make the changes (we will use this info to test)?

• Restored the original label settings and the new labelId to the previous labelKey for 2 weeks inactive
• This was needed because a dev deleted an important label. When the bot recreated the label, the new label had as incorrect labelKey and settings

CodeQL Alerts

After the PR has been submitted and the resulting GitHub actions/checks have been completed, developers should check the PR for CodeQL alert annotations.

Check the PR's comments. If present on your PR, the CodeQL alert looks similar as shown

Please let us know that you have checked for CodeQL alerts. Please do not dismiss alerts.

• I have checked this PR for CodeQL alerts and none were found.
• I found CodeQL alert(s), and (select one):
  • I have resolved the CodeQL alert(s) as noted
  • I believe the CodeQL alert(s) is a false positive (Merge Team will evaluate)
  • I have followed the Instructions below, but I am still stuck (Merge Team will evaluate)

Instructions for resolving CodeQL alerts

If CodeQL alert/annotations appear, refer to How to Resolve CodeQL alerts.

In general, CodeQL alerts should be resolved prior to PR reviews and merging

Screenshots

• No visual changes to website

Restored label settings

[github-actions]

Want to review this pull request? Take a look at this documentation for a step by step guide!

---

From your project repository, check out a new branch and test the changes.

git checkout -b t-will-gillis-labels-maintenance-8176 gh-pages
git pull https://github.com/t-will-gillis/website.git labels-maintenance-8176

[ryanfkeller]

Hi @t-will-gillis,

Your changes to label-directory.json and to HFLA Repo Labels make sense to me for solving the linked issue of restoring the "2 weeks inactive" label back to its previous state! Thanks also for including a screenshot of the label settings. I approve.

I'm new to GH Actions, so could I double check with you my understanding of what all happened to cause this issue and how you went about solving it? If I traced things correctly...

1. Someone accidentally deleted the "2 weeks inactive" label on GH, triggering the GH Action to set that label's ID to 999s in label-directory.json to indicate it needs review.
2. Someone tried to correct the issue by re-adding a new "2 weeks inactive" label on GH, which triggered the GH Action again. However, the JS script it calls is designed to auto-generate the labelKey for new labels based on the description. This meant that label-directory.json wound up with a new auto-genned entry "New-2WeeksInactive" that had the ID for the new GH label, while still keeping the original "statusInactive2" with the invalid ID.
3. You manually updated label-directory.json to give the original "statusInactive2" the new valid ID that links to the new GH label (since the old one is deleted). Then you deleted the extraneous auto-genned entry.
4. You then updated the label color (and description?) on GH. This triggered a GH Action, but since you didn't change the label name, the triggered script didn't re-modify label-directory.json.

Is that pretty much right? Thanks!

[t-will-gillis]

Hey @ryanfkeller thank you for the review and the comments. I will try not to go into too much detail here- feel free to ask for additional information. Also, if you would like to learn more about GHAs or do an issue, there are some you could work on.

We created the "Update Label Directory" GHA among other reasons because when someone deletes a label it is also deleted from all issues with that label.

1. Yes, this is what the automation does. The id is reset to 9999999999 because the previous id is no longer valid and when the label is recreated it will be a different id.
2. In this case, the person who deleted the label was unaware and they likely meant to un-label their issue instead of deleting it (it is too bad GitHub does not prevent accidental changes like this.) It was the bot that regenerated the label when the "Schedule Friday" GHA ran. "Schedule Friday" adds a note and the label to issues that are idle, and since the label was gone it was regenerated.
3. yes, correct
4. yes, correct

There is an issue #7769 to add to the "Update Label Directory" workflow so that when there is an accidental deletion like this, we are notified and given a list of which issues were un-labeled during the deletion. Only certain labels are regenerated, and the rest we need to add back manually.

Thanks again and hope this helps!

[kdaca19xx]

Availability: after 1pm (pacific)
ETA: 6/13

[hoanhua14]

Hi @t-will-gillis ,
Thank you for the clarification in the comment, it helps me understand HfLA's workflow better. I've approved the PR, thank you!

[kdaca19xx]

Things Done Well

• The pull request done with the correct branch.
• There's a linked issue. I understood it way better after reading ryanfkeller's post and t-will-gillis' response to them, so a huge thanks to the two of you.
• The changes in the Files Changed tab look good.

Suggestions

n/a