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

Support labeling based on size of change #486

Open
dfandrich opened this issue Jan 20, 2023 · 9 comments
Open

Support labeling based on size of change #486

dfandrich opened this issue Jan 20, 2023 · 9 comments
Labels
feature request New feature or request to improve the current logic needs eyes

Comments

@dfandrich
Copy link
Contributor

I would like to add a label in certain cases based on files changed, but only if the commit changes fewer than N files in total. Anything more than N and the change is likely a global refactor and adding the specific label won't add any value.

@dfandrich dfandrich added feature request New feature or request to improve the current logic needs triage labels Jan 20, 2023
@panticmilos
Copy link
Contributor

hi @dfandrich, thank you for the report, we will take a look at it.

@akutz
Copy link

akutz commented Jan 29, 2023

Mentioned in vmware-tanzu/vm-operator#50 (review) (this was not added automatically for some reason)

@jw-maynard
Copy link

@panticmilos and @MaksimZhukov I'm working on a PR for this in my personal fork right now but I currently have a breaking change with the way the config is written. I basically put the existing config under a top level section name labels and added a new optional section called sizes.

Obviously there are other options for handling this:

  • a separate config file in the .github dir
  • an additional optional input to the action
  • some code to check if there is a labels top level item in the config and if not, fall back to the previous parsing

Do you guys have a preference?

jw-maynard#2

@jw-maynard
Copy link

@panticmilos and @MaksimZhukov I'm working on a PR for this in my personal fork right now but I currently have a breaking change with the way the config is written. I basically put the existing config under a top level section name labels and added a new optional section called sizes.

Obviously there are other options for handling this:

  • a separate config file in the .github dir
  • an additional optional input to the action
  • some code to check if there is a labels top level item in the config and if not, fall back to the previous parsing

Do you guys have a preference?

jw-maynard#2

So I just noticed there is a v5 WIP with breaking changes in it so maybe I'll just work off of that branch

@lucacome
Copy link

Any chance we can get some traction on this @MaksimZhukov ? 🙏

@MattMencel
Copy link

I've been using this Labeler Action alongside https://github.com/pascalgn/size-label-action with good success.

@lucacome
Copy link

It'd be nice to just use one Action instead of two, since there's already a PR open in this repo for the same functionality...

@austinpray-mixpanel
Copy link

I just tacked https://github.com/pascalgn/size-label-action as the next step in the labeler workflow. It's instant so there's basically no cost to having two steps in the labeler job.

name: Labeler
on: [pull_request]

jobs:
  label:
    timeout-minutes: 15
    runs-on: ubuntu-latest
    permissions:
      contents: read
      pull-requests: write
    steps:
    - uses: actions/labeler@v5
      with:
        repo-token: '${{ secrets.GITHUB_TOKEN }}'
        configuration-path: .github/labeler.yaml
    - name: size-label
      uses: "pascalgn/size-label-action@v0.5.2"
      env:
        # See https://github.com/pascalgn/size-label-action
        GITHUB_TOKEN: "${{ secrets.GITHUB_TOKEN }}"
        IGNORED: |-
          package-lock.json

@dfandrich
Copy link
Contributor Author

Using a separate action to set separate size labels would only work to satisfy this if #129 were also implemented.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature request New feature or request to improve the current logic needs eyes
Projects
None yet
Development

No branches or pull requests

8 participants