Skip to content
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.

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

feat(actions): auto-label PRs that close issues. #27047

Closed
wants to merge 14 commits into from
50 changes: 49 additions & 1 deletion .github/workflows/labeler.yml
Original file line number Diff line number Diff line change
@@ -1,13 +1,20 @@
name: "Pull Request Labeler"
on:
- pull_request_target
pull_request:
types: [opened, reopened, synchronize, edited]
# cancel previous workflow jobs for PRs
concurrency:
group: ${{ github.workflow }}-${{ github.event.pull_request.number || github.run_id }}
cancel-in-progress: true


jobs:
labeler:
permissions:
contents: read
pull-requests: write
runs-on: ubuntu-latest
if: ${{ github.event.action == 'opened' || github.event.action == 'reopened' || github.event.action == 'synchronize' }}
steps:
- uses: actions/labeler@v5
with:
Expand All @@ -19,3 +26,44 @@ jobs:
# run: |
# echo "Running translation scripts"
# # Generate .pot -> .po -> .json files

# This'll look at the PR body and add a label if it contains an issue-closing keyword
# it runs on every PR event, including "edited" since people tend to add "closes #123" in the PR body after opening it
label-auto-closing:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v2
Copy link
Member

Choose a reason for hiding this comment

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

Are you sure you need to checkout here?

- name: Log PR Edit
run: echo "PR was edited"
- name: Auto-label PRs
uses: actions/github-script@v7
with:
github-token: ${{secrets.GITHUB_TOKEN}}
Copy link
Member

Choose a reason for hiding this comment

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

don't think we have access to secrets when triggering by pull_request. it works on PRs that don't come from forks

Copy link
Member Author

Choose a reason for hiding this comment

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

I had read somewhere that the repo does provide a generated GITHUB_TOKEN with limited authority (tagging, commenting, etc) on forks, so this should work.

I can add a secrets check to skip the job if the secret is not available, but I think that secret always is.

Copy link
Member Author

Choose a reason for hiding this comment

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

I kinda want to merge it and test the theory. I can add the secret check to skip the action if it doesn't work.

Copy link
Member

@dpgaspar dpgaspar Feb 8, 2024

Choose a reason for hiding this comment

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

Copy link
Member Author

@rusackas rusackas Feb 8, 2024

Choose a reason for hiding this comment

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

Hmm... and I see the labeller action above the one I'm adding here has

   permissions:
      contents: read
      pull-requests: write

... but I'm (a) not sure if that job works on forks (maybe that's broken too?), or (b) if we can elevate the default permissions like that.

I'm not sure yet if there's a better approach here, or if there's a way to skip this action for forks if we can't make it work.

Copy link
Member

Choose a reason for hiding this comment

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

Curious to know if we are moving forward with this as I am planning to consider it for a long-term proposal to improve the management of the backlog

Copy link
Member Author

Choose a reason for hiding this comment

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

Well, I sure WANT to merge it, but I'm not sure how to proceed. Maybe @mistercrunch knows how to unblock this thing :P

Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Member

Choose a reason for hiding this comment

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

In that case, what happens is it will trigger the action that's defined on the main target repo's branch, and say if you do a checkout it would be the target's ref not the PR one. Does that work here? Actually do you need to checkout?

script: |
const closingKeywords = /\b(close|closes|closed|fix|fixes|fixed|resolve|resolves|resolved)\s*:? ?(?:#([0-9]+)|https:\/\/github\.com\/apache\/superset\/pull\/([0-9]+))/gi;
const prBody = context.payload.pull_request.body;
const issueNumbers = [...prBody.matchAll(closingKeywords)].map(match => match[0]);
const labelName = 'closes-issue';
console.log('PR body:', prBody);
if (issueNumbers.length > 0) {
console.log('Found an issue link! Labeling this PR');
console.log('issues', issueNumbers);
await github.rest.issues.addLabels({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.issue.number,
labels: [labelName]
});
} else {
console.log("No issue link found! Attempting to remove label");
try {
await github.rest.issues.removeLabel({
owner: context.repo.owner,
repo: context.repo.repo,
issue_number: context.payload.pull_request.number,
name: labelName
});
} catch {
console.log('No label was present to remove');
}
}
Loading