Skip to content

Add unlock functionality for reopened issues and PRs in locker workflow #119003

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom
Open
wants to merge 4 commits into
base: main
Choose a base branch
from
Open

Add unlock functionality for reopened issues and PRs in locker workflow #119003

wants to merge 4 commits into from
+27 −3

Conversation

Copilot
Copy link
Contributor

@Copilot Copilot AI commented Aug 22, 2025 •
edited
Loading

This PR enhances the .github/workflows/locker.yml workflow to automatically unlock issues and pull requests when they are reopened, addressing the need to make previously locked items accessible again when discussion resumes.

Changes Made

New Event Triggers

  • Added issues.reopened trigger to detect when closed issues are reopened
  • Added pull_request_target.reopened trigger to detect when closed PRs are reopened

Enhanced Job Logic

  • Lock job (renamed from main for clarity):

    • Added condition to prevent execution on reopened events: github.event_name != 'issues' && github.event_name != 'pull_request_target'
    • Preserves existing functionality for scheduled runs and manual dispatch

  • New unlock job:

    • Only executes when issues or PRs are reopened: github.event.action == 'reopened'
    • Uses actions/github-script@v7 with GitHub REST API to unlock items
    • Handles both issues and pull requests with a single step (since GitHub treats PRs as issues in the API)
    • Only unlocks if the item is actually locked: github.event.issue.locked == true

Workflow Behavior

  • Before: Issues/PRs remained locked after being reopened, preventing further discussion
  • After: Issues/PRs are automatically unlocked when reopened, allowing immediate participation

Technical Implementation

The unlock functionality uses the GitHub Issues API (which also handles PRs) through actions/github-script@v7:

await github.rest.issues.unlock({
  issue_number: context.issue.number,
  owner: context.repo.owner,
  repo: context.repo.repo,
});

This ensures that when maintainers or contributors reopen issues or PRs for continued discussion, they won't encounter locked conversation threads that prevent community engagement.

Fixes the workflow gap where reopened items remained inaccessible for comments despite being active again.

✨ Let Copilot coding agent set things up for you — coding agent works faster and does higher quality work when set up for your repo.

@github-actions github-actions bot added the needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners label Aug 22, 2025
@Copilot @akoeplinger
Add unlock functionality for reopened issues and PRs in locker.yml wo…
c389c70 
…rkflow

Co-authored-by: akoeplinger <1376924+akoeplinger@users.noreply.github.com>
@Copilot Copilot AI changed the title [WIP] change .github/workflows/locker.yml so that it unlocks an issue or pr when it is reopened. make sure we don't run the existing job which locks issues in that case Add unlock functionality for reopened issues and PRs in locker workflow Aug 22, 2025
@Copilot Copilot AI requested a review from akoeplinger August 22, 2025 14:59
Copilot finished work on behalf of akoeplinger August 22, 2025 14:59
@akoeplinger
Copy link
Member

@copilot you don't need to have a separate step for pull requests since they're treated as issues by GitHub already.

Use code like this to unlock the pr/issue:

    - name: Unlock if issue/PR is locked
      uses: actions/github-script@v7
      if: ${{ github.event.issue.locked == true }}
      with:
        script: |
          console.log(`Unlocking locked issue/PR #${context.issue.number}.`);
          await github.rest.issues.unlock({
            issue_number: context.issue.number,
            owner: context.repo.owner,
            repo: context.repo.repo,
          });

@akoeplinger
Copy link
Member

@copilot oh and use the pull_request_target event

@Copilot @akoeplinger
Update locker workflow to use pull_request_target and simplify unlock…
8e5c754 
… logic

Co-authored-by: akoeplinger <1376924+akoeplinger@users.noreply.github.com>
@Copilot Copilot SWE Agent
Copy link
Contributor Author

Copilot AI commented Aug 22, 2025

@copilot oh and use the pull_request_target event

Updated the workflow to use pull_request_target event and consolidated the unlock logic using actions/github-script@v7 with the locked condition check as suggested. The implementation now uses a single step that works for both issues and PRs since GitHub treats them the same in the API. (8e5c754)

Copilot finished work on behalf of akoeplinger August 22, 2025 15:59
@akoeplinger akoeplinger marked this pull request as ready for review August 22, 2025 16:15
@Copilot Copilot AI review requested due to automatic review settings August 22, 2025 16:15
@akoeplinger akoeplinger requested review from jeffhandley and a team as code owners August 22, 2025 16:15
@akoeplinger
Copy link
Member

/ba-g only change to a GitHub Action so no AzDO builds got triggered

Copilot
Copilot AI reviewed Aug 22, 2025
View reviewed changes
Copy link
Contributor

@Copilot Copilot AI left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Pull Request Overview

This PR enhances the GitHub Actions locker workflow to automatically unlock issues and pull requests when they are reopened, ensuring that previously locked conversations become accessible again when discussion resumes.

Key changes:

  • Added event triggers for issues.reopened and pull_request_target.reopened
  • Split workflow into separate lock and unlock jobs with appropriate conditions
  • Implemented unlock functionality using GitHub REST API

@akoeplinger @Copilot
Update .github/workflows/locker.yml
87cbb33 
Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
@akoeplinger
Copy link
Member

/ba-g only change to a GitHub Action so no AzDO builds got triggered

@akoeplinger akoeplinger added area-Infrastructure and removed needs-area-label An area label is needed to ensure this gets routed to the appropriate area owners labels Aug 22, 2025
@dotnet-policy-service Dotnet Policy Service
Copy link
Contributor

Tagging subscribers to this area: @dotnet/runtime-infrastructure
See info in area-owners.md if you want to be subscribed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

Copilot code review Copilot Copilot left review comments

@jeffhandley jeffhandley Awaiting requested review from jeffhandley jeffhandley is a code owner

+1 more reviewer

@akoeplinger akoeplinger akoeplinger approved these changes

Reviewers whose approvals may not affect merge requirements

At least 1 approving review is required to merge this pull request.

Assignees

@akoeplinger akoeplinger

Copilot code review Copilot

Labels
area-Infrastructure
Projects
Runtime Infra
Status: No status
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@Copilot @akoeplinger