ER: Augment "Update Label Directory" workflow for accidental deletions

[t-will-gillis]

Emergent Requirement - Problem

A couple of days ago, a dev removed a well-used label (role missing) from the repo. Removing the label from the repo caused the label to be removed from any issue previously using the label.
Among the concerns:

• We do not know which issues were affected
• We also were not explicitly warned that this happened

We need the "Update Label Directory" (ULD) workflow to flag us whenever a label is deleted and make a list of which issues are affected (because the now-deleted label is removed from the issue)

Issue you discovered this emergent requirement in

• Add 'Leadership Option' to Issue Template for CoP Information Update #7077

Date discovered

Discussed in the 11/25 dev meeting

Did you have to do something temporarily

• YES
• NO

Who was involved

@ExperimentsInHonesty @JessicaLucindaCheng @t-will-gillis

What happens if this is not addressed

Depending on which label gets deleted, we might not be able to reconstruct from which of the issues the label was removed.

Resources

Recommended Action Items

• Make a new issue
• Discuss with team
• Let a Team Lead know

Potential solutions [draft]

• The solutions that follow involve GitHub Actions, and possibly GraphQL. These might be too much for one issue, and/or might even be too complicated to justify implementing in full.

• The minimum solution is to notify us one way or another that a <SPECIFIC LABEL> was deleted, and that this resulted in that label being removed from a <LIST OF ISSUES>:

  • The solution should have the initial trigger covered by the first job of the update-label-directory.yml workflow, whenever the event is a label deletion.
  • If a label was deleted, another workflow could be called. One way that might work is to insert this as the first job in the update-label-directory.yml workflow:

    jobs:
        # Check if deleted label was in-use. If so, deletion likely a mistake & label needs restoring
        Check-For-Issues-Unlabeled-After-Deletion:
        if: ${{ github.repository == 'hackforla/website' && github.event.action == 'deleted'  }}
        uses: ./.github/workflows/check-for-issues-unlabeled-after-deletion.yml
    
        # If a label was edited, created, or deleted, update label directory
        Update-Label-Directory:  
    

  • Then, create the new file check-for-issues-unlabeled-after-deletion.yml

    • It might look like this:

      Possible check-for-issues-unlabeled-after-deletion.yml

      name: Check for Issues Unlabeled After Deletion
      
      on:
          workflow_call:
          
      jobs:
          Get-Recently-Unlabeled-Issues:
          runs-on: ubuntu-latest
          steps:
              - uses: actions/checkout@v4
              - name: Get recently unlabeled issues
              id: get-recently-unlabeled-issues
              uses: actions/github-script@v7
              with:
                  github-token: ${{ secrets.HACKFORLA_GRAPHQL_TOKEN }}
                  script: |
                  const script = require('./github-actions/utils/get-recently-unlabeled-issues.js')
                  const issueList = script({g: github, c: context})
                  return issueList
      

  • The file get-recently-unlabeled-issues.js should:

    • Create a list of each issue affected by the label removal by checking for issues that were unlabeled within the last five minutes (or other short timeframe) after label deletion.

    • Side note: when a label is deleted, the "Actions" workflow logs document each issue that was unlabeled (see screenshot details):

    • Details

      

    • This shows that it is possible to create a list of affected issues through an API call that checks for issues that a.) have been unlabeled and b.) that had this happen within the last 5 +/- minutes (i.e. since a set time earlier than now), and/or c.) other matches to keep the search small.

    • (Comment: It probably is a bad idea to add another trigger that listens for unlabeled issues, because we add and remove issue labels constantly and we wouldn't want these workflows to be triggered by the unlabeled action, instead it should only be triggered by the action of a label being deleted.)

    • Here is a graphQL query you could start with (but feel free to come up with a better one). Check out GitHubExplorer also to test:

      Possible get-recently-unlabeled-issues.yml

      let fiveMinutesAgo = new Date();
      fiveMinutesAgo.setMinutes(fiveMinutesAgo.getMinutes() - 5);
      
      const query = `query ($owner: String!, $repo: String!, $since: DateTime!) {
        repository(owner: $owner, name: $repo) {
          issues(first: 100, orderBy: {field: UPDATED_AT, direction: DESC}, filterBy: { since: $since }) {
            nodes {
              number
              timelineItems(itemTypes: [UNLABELED_EVENT], first: 10) {
                nodes {
                  ... on UnlabeledEvent {
                    createdAt
                    label {
                      name
                    }
                  }
                }
              }
            }
          }
        }
      }`;
      
      const variables = {
        owner: context.repo.owner,
        repo: context.repo.repo,
        since: fiveMinutesAgo
      };
      

• In the end, we want to notify product and merge team that:

  • <SPECIFIC LABEL> was deleted, and
  • this caused <LIST OF ISSUES> to be unlabeled

• Talk with the team to decide how we want to be notified, for example: a.) by adding a comment to the Monday agenda (see the "Schedule Monthly" workflow)? b.) by opening an issue with flags for ready for product and ready for dev lead and the note: "This label was recently deleted."? c.) something else?

Comments only- things that are not included in this ER:

• This ER purposefully does not include functionality to "undo" the label deletion by automatically recreating the label and reapplying it to the effected issues.

[HackforLABot]

Hi @t-will-gillis, we notice that you are assigned to an issue that you authored. Please remember to add the Draft label to this issue while you are working on it.