wearerequired / lint-action

✨ GitHub Action for detecting and auto-fixing lint errors
MIT License
569 stars 137 forks source link

auto_fix: true fails when there are no changes to commit #140

Open brennanwilkes opened 3 years ago

brennanwilkes commented 3 years ago

  Verifying setup for ESLint…
  Verified ESLint setup
  Will use ESLint to check the files with extensions js
  Linting and auto-fixing files in /home/runner/work/***/*** with ESLint…
  ESLint found 6 errors (failure)
  Changes found with Git
  Committing changes
  Error: Error: Command failed: git commit -am "Fix code style issues with ESLint"
  /home/runner/work/_actions/wearerequired/lint-action/v1/dist/index.js:1108
    throw new Error(`Exiting because of unhandled promise rejection`);
    ^

  Error: Exiting because of unhandled promise rejection
      at process.<anonymous> (/home/runner/work/_actions/wearerequired/lint-action/v1/dist/index.js:1108:8)
      at process.emit (events.js:210:5)
      at processPromiseRejections (internal/process/promises.js:201:33)
      at processTicksAndRejections (internal/process/task_queues.js:94:32)```
ocean90 commented 3 years ago

Hi, thanks for the report. That's odd since changes were detected. Can you provide more details about your setup please?

ghost commented 3 years ago

I see the same issue on a number of our repos using Swiftlint as the linter.

ghost commented 3 years ago

@brennanwilkes FWIW, I had success seeing that my runner actually had a modified file outside the linter directory which caused this error for me.

Enabling debug as described here: https://docs.github.com/en/actions/managing-workflow-runs/enabling-debug-logging showed me the file and I was able to git rm and gitignore the file since it was only an "unneeded" file

wh1t3h47 commented 3 years ago

The same thing happens with my setup: https://github.com/wh1t3h47/teste-desenvolvimento-web/runs/3198622148 It detects changes when there are none

wh1t3h47 commented 3 years ago

Hello, I enabled debugging as described by @ghost (thank you a lot!) So I found out the issue with my repository, the problem is that yarn.lock is modified when lint-action runs, so it detects a change, but it fails to commit. I think the action writes to the file, but doesn't change anything in its content...

A possible workaround for this is enabling an empty commit, I know you can pass that option to git - I used to do it when I needed to test pre-commit hooks, as they lint the code and remove my change when I add some spaces to the code.

In my case, what I did was just remove the yarn lockfile before linting (using the yml file), I don't know if this holds any consequence, but I don't think so, as the action shouldn't be messing with dependencies, only having them installed to run.

My suggestion is that you add in the example a workflow that checks for lockfiles (npm, yarn) and unstages them before commiting, this would help people that may have issues with the lint-action

AnthonyLzq commented 2 years ago

@wh1t3h47, thank you so much for your suggestion, I have added that to my workflow and everything works like a charm. For those who are interested in a possible approach, here is my lint.yml:

name: Lint

on: [push, pull_request]

jobs:
  run-linters:
    name: Run linters
    runs-on: ubuntu-latest

    steps:
      - name: Check out Git repository
        uses: actions/checkout@v2

      - name: Set up Node.js
        uses: actions/setup-node@v1
        with:
          node-version: 16.x

      - name: Install Node.js dependencies
        run: npm install

      - name: Revert changes into the package-lock.json file
        run: git checkout -- package-lock.json

      - name: Run linters
        uses: wearerequired/lint-action@v1
        with:
          auto_fix: true
          eslint: true
          eslint_dir: lib
          eslint_extensions: js
apgapg commented 2 years ago

@AnthonyLzq Can we just do git reset --hard just after npm i step and before linter step?

AnthonyLzq commented 2 years ago

Wait, I don't think so, since you haven't commit yet. Git checkout or restore will return to the previous state of your package-lock.json file.