Large development teams develop a lot of features. During the lifetime of a repo, the amount of stale branches can grow and snowball. This could be regulated with team rules about what to do with branches after the merge and who should delete them.  But as with any manual operation, sometimes someone forgets about it. So once per month or two you should review staled branches and delete them. My Automation Engineer mind always tries to automate each routine operation like this. So I've configured a cron action that cleans old branches using a pattern. I’ve used an already existing solution from where you can setup the branches to be removed using regexp. Let’s look at the configuration and describe the key moments: beatlabs name: CLEAR OLD BRANCHES

on:
  schedule:
    - cron: "0 0 * * 1"
jobs:
  cleaning:
    name: Cleanup old branches
    runs-on: ubuntu-latest
    steps:
      - name: checkout
        uses: actions/checkout@v2
      - name: clean
        uses: beatlabs/delete-old-branches-action@v0.0.6
        with:
          repo_token: ${{ secrets.GH_TOKEN }}
          date: '2 month ago'
          dry_run: false
          delete_tags: false
          minimum_tags: 5
          extra_protected_branch_regex: master.*|main|develop|^release.*|.*_p$ First of all, let’s set up a trigger when action should be executed. It might be a push, merge, or any other. In my mind, this action is something like general cleaning so I’ve set up its execution by crone once per week every Monday. To configure an appropriate crone for you I can advise a great resource: https://crontab.guru on:
  schedule:
    - cron: "0 0 * * 1" After that, define Cleaning Job with steps: checkout clean is pretty straightforward with it executes fetch repository. There is no need for any additional configuration. Checkout actions/checkout@v2 action has a few important options: Clean with rights for interactions with the repository. token repo_token: ${{ secrets.GH_TOKEN }} - limitation period (current example will look for branches older than 2 months). date date: '2 month ago' - regular expression for protected branches. extra_protected_branch_regex This example excludes: master, develop, branches which start with “release“ and finish with “_p“ from the cleaning list. extra_protected_branch_regex: master|develop|^release.*|.*_p$ -  executes an action in safe mode. After you test that everything is fine, switch to false. But for more safety, I recommend first trying action in the test repository. dry_run And before the first run in a real repository make sure that you have a backup in case something goes wrong because of a mistake. dry_run: false Once you’ve completed setup, enjoy cleaning and forget about routine manual management of staled branches.

Fetch

Routine

AWS Parameters Store for Test Automation Project

Nominated for 2022 - HackerNoon Contributor of the Year - Git

Nominated for 2022 - HackerNoon Contributor of the Year - Github

Too Long; Didn't Read

Make resilience your competitive advantage

Clean Stale branches with Github Actions

About Author

Comments

TOPICS

THIS ARTICLE WAS FEATURED IN

Related Stories

Untitled Story

Migrating Appium Tests to Sauce Labs

Git Branches

Top Differences Between Tags and Branches In Git You Must Know

3 Easy Steps to Change Main Git Branch on Heroku

15 Essential GitHub Repos for Web Developers in 2021

Migrating Appium Tests to Sauce Labs

Git Branches

Top Differences Between Tags and Branches In Git You Must Know

3 Easy Steps to Change Main Git Branch on Heroku

15 Essential GitHub Repos for Web Developers in 2021

Light-Mode

Classic

Newspaper

Dark-Mode

Neon Noir

Minty

HN StartUps