jessfraz / branch-cleanup-action Goto Github PK

Currently Github Actions support YAML workflow format. I guess README should be updated with YAML example.

Hey, @jessfraz

Thanks for pioneering GitHub Actions and for this routine-simplifier Action particularly. It's super exciting to see how everything evolves.

I'm trying to integrate this action into one workflow, seems working

But I'm lilbit confused with running it on any occasion around PR:

Is ther any receipt how GitHub action could be selectively run only after PR was merged?

I think this is separate case from #6 and arguably it could be more common.

Let's say we have branch master, feature-x and feature-y (branched from feature-x).

And we have the following pull requests:

• PR 1:
  Base: master
  Head: feature-x

• PR 2:
  Base: feature-x
  Head: feature-y

Then if we merge PR 1 first before merging PR 2 and before changing the base on PR 2, GitHub does not show you the "Delete branch" option in the UI on PR 1.

However, this GitHub action does not check for that and through the API manages to delete the branch.

This results in closing PR 2 and if you then force-push into feature-y, you can change the base to master, but GitHub does not allow even reopening this PR again after it was force-pushed.

My suggestion is to follow the GitHub UI and do not delete a branch when it is a base branch for another PR, even if the PR where this branch is the head of the PR is merged.

I believe we could check this through a GitHub API call. I could try submitting a patch, but I wanted to get some feedback first.

I am not a lawyer, but I wanted to copy some of your code for my own action and spotted no license. Is this intentionally?

Thanks for this great action.

Situation:

• PR 100 sitting there with a few commits on feature/100.
• PR 101 on branch feature/101 that was branched from the HEAD of feature/100 and added a commit. The base of PR101 is set to the feature/100 branch so you can see the additional commit separately. The intention is to merge PR 100 to develop first, then change PR 101 to base: develop and review/merge PR 101 later.

PR 100 is merged and this action fires. The feature/100 branch's ref is deleted.

PR 101 gets closed as a side-effect. In PR 101, I see this in the timeline:

I've poked around and cannot see anything in the GitHub REST API that will tell me that there's another branch in the repo branched off this branch (or another PR based on such a branch, or another PR with this branch as a branch base). In the GitHub UI there's some detection of this situation because in the PR 100 screen, the "Delete Branch" button does not show while PR 101 is sitting there with feature/100 as the base branch.

I'm not even sure there's a solution to this. Perhaps a mention in the README that it's expected behaviour?

Any other ideas?

Hi, it might be worth noting in the README that GitHub has a native feature for this now.

If engineers delete a branch manually when merging a PR, this action still fires and then eventually throws an error, which then fails the commit-status.

Already have image (with digest): gcr.io/github-actions-images/action-runner:latest
DEBUG -> action: closed merged: true
Deleting branch ref fb/react-apollo-hooks for owner taskrabbit/tr_client...
curl: (22) The requested URL returned error: 422 Unprocessable Entity

### FAILED Cleanup Branch 23:20:13Z (26.459s)

Ideally, if the branch is already deleted we shouldn't throw an error.

Proposal: Interpret HTTP-422 as "branch already deleted" in this case?

I think Github changed something when they launched an update this week.

This action was working great in our main workflow for a few weeks, until Monday (2019-03-12) when they launched the UI updates to indicate an Action had "Declined" to run. Then this action started terminating other things in the same workflow.

Workaround was to shift this to a different Workflow, but I'm not sure if that will scale cleanly if we add other conditional actions!

Hey there! I'm new to GitHub actions, so if this is incorrect at all, I apologize!

Here's the issue I'm seeing. I've got a repo that I'd like to use this with. We have a large team working on this project and many people are leaving stale branches around. Anyhow, I went ahead and created a GitHub workflow as defined below (using the new yaml syntax):

name: Delete PR Branches on Merge

on: pull_request
jobs:
  cleanup:
    name: Cleanup
    runs-on: ubuntu-latest

    steps:
    - uses: jessfraz/branch-cleanup-action@master
      env:
        GITHUB_TOKEN: ${{ secrets.GITHUB_TOKEN }}
        NO_BRANCH_DELETED_EXIT_CODE: 0

When I open a new pull request on this repo, this workflow runs and exits without doing anything (since the PR hasn't been merged).

When I merge the PR, however, this workflow doesn't run because it's only running on pull_request, and GitHub doesn't consider a merged PR to be a pull_request event, apparently. I wonder if this behavior has changed since this was first built?

Anyhow: I can't seem to find a way to get this to run. Am I way off, or did GitHub change the way that the pull_request event works?

In the script the head repository is used to determine which branch is the default branch and should not be deleted.

However if the PR is made from a fork the head repo will point to the fork and thus the default branch could be different.

It might tie in with #19

Say for example the PR was closed accidentally, then before the action completes it's opened again. What happens?

Currently the action skips deleting the default branch for a repository. However, with GitHub protected branches functionality, multiple branches could be protected and not allowed to be deleted.

If they are protected, the action would attempt deleting them and would fail. Could we instead get a list of all protected branches and not attempt to delete them?