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

GitHub Action fails #3953

Closed
huhlim opened this issue Oct 17, 2023 · 5 comments · Fixed by #3957
Closed

GitHub Action fails #3953

huhlim opened this issue Oct 17, 2023 · 5 comments · Fixed by #3957
Labels
T: bug Something isn't working

Comments

@huhlim
Copy link

huhlim commented Oct 17, 2023

Describe the bug
GitHub Action fails with the latest version, 23.10.0. If I specify a version (e.g., 23.9.0), it works fine.
I have been using the GitHub Action snippet as described on this page.

To Reproduce

For example, take this code:

name: Lint

on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: psf/black@stable
        with:
          options: "--check --verbose"

The resulting error is:
The GitHub Action raises an error.
스크린샷 2023-10-17 오후 5 40 45

Expected behavior
If I specify a black version like this, it works fine.

name: Lint

on: [push, pull_request]

jobs:
  lint:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v3
      - uses: psf/black@23.9.1
        with:
          options: "--check --verbose"

Environment

  • Black's version: psf/black@stable (or 23.10.0)
  • OS and Python version: GitHub Action

Additional context

@huhlim huhlim added the T: bug Something isn't working label Oct 17, 2023
@jtkmckenna
Copy link

jtkmckenna commented Oct 18, 2023

I came here to report the same issue. It seems just a bug where its not generating the 'black summary'. Seems to be exiting the CI early when the black executable (correclty identifies issues and) returns a non-zero exit code

@haraldger
Copy link

I have the same issue. Workaround is specifying an earlier release " uses: psf/black@23.9.1 " as described in OP.

@kiyoon kiyoon mentioned this issue Oct 19, 2023
3 tasks
@AlexMapley
Copy link

AlexMapley commented Oct 19, 2023

Same issue here, I pinned to psf/black@23.9.1 though and that works for me too

@ThomasWaldmann
Copy link

@M3gar00
Copy link

M3gar00 commented Oct 20, 2023

We've been blocked by the same issue. Pinning to psf/black@2.9.1 worked for us too.

hkeeler added a commit to cfpb/regtech-data-validator that referenced this issue Oct 20, 2023
…#60)

Grab bag of tune-up in prep for open-sourcing this repo.

1. Restructure repo to be more compliant with modern Python projects.
    1. Move `tests` out to top-level directory.
    2. Rename `src/validator` to `regtech_data_validator`.
2. Consolidate external datasource code and data to `data` dir.
    1. Move `config.py` settings into their respective scripts, and file
        paths are now passed in as CLI args instead.
3. Move processed CSV files into the project itself. This allows for
    simpler data lookups via package name via `importlib.resources`.
    This allowed the removal of the `ROOT_PATH` Python path logic in all of
    the `__init__.py`s.
4. Refactor `global_data.py` to load data only once where module is
    first imported.
5. Refactor `SBLCheck`'s
    1. `warning: bool` for a more explicit `severity`, backed by an enum
        that only allows `ERROR` and `WARNING`.
        1. Several of the warning-level validations were not setting
            `warning=True`, and were thus defaulting to `False`. This will prevent
            that. I also fixed all these instances.
        2. Removes the need for translation to `severity` when building JSON
            output.
    2. Use explicit args in the constructor, and pass all shared args on to
        parent class. This removes the need for the arg `name`/`id` error handling. 
6. Switch CLI output from Python dict to JSON.
7. Rollback `black` version used in linting Action due to bug in latest version.
    -  psf/black#3953

**Note:** Some of the files that I both moved _and_ changed seem to now
show as having deleted the old file and created a new one. I'm not sure
why it's doing this. I did the moves and changes in separate commits,
which usually prevents this, but doesn't seem to be the case here.
Perhaps there's just so much change in some that git considers it a
whole new file? 🤷 It's kind of annoying, especially if it results in
losing git history for those files.
jcadam14 pushed a commit to cfpb/regtech-data-validator that referenced this issue May 3, 2024
…#60)

Grab bag of tune-up in prep for open-sourcing this repo.

1. Restructure repo to be more compliant with modern Python projects.
    1. Move `tests` out to top-level directory.
    2. Rename `src/validator` to `regtech_data_validator`.
2. Consolidate external datasource code and data to `data` dir.
    1. Move `config.py` settings into their respective scripts, and file
        paths are now passed in as CLI args instead.
3. Move processed CSV files into the project itself. This allows for
    simpler data lookups via package name via `importlib.resources`.
    This allowed the removal of the `ROOT_PATH` Python path logic in all of
    the `__init__.py`s.
4. Refactor `global_data.py` to load data only once where module is
    first imported.
5. Refactor `SBLCheck`'s
    1. `warning: bool` for a more explicit `severity`, backed by an enum
        that only allows `ERROR` and `WARNING`.
        1. Several of the warning-level validations were not setting
            `warning=True`, and were thus defaulting to `False`. This will prevent
            that. I also fixed all these instances.
        2. Removes the need for translation to `severity` when building JSON
            output.
    2. Use explicit args in the constructor, and pass all shared args on to
        parent class. This removes the need for the arg `name`/`id` error handling. 
6. Switch CLI output from Python dict to JSON.
7. Rollback `black` version used in linting Action due to bug in latest version.
    -  psf/black#3953

**Note:** Some of the files that I both moved _and_ changed seem to now
show as having deleted the old file and created a new one. I'm not sure
why it's doing this. I did the moves and changes in separate commits,
which usually prevents this, but doesn't seem to be the case here.
Perhaps there's just so much change in some that git considers it a
whole new file? 🤷 It's kind of annoying, especially if it results in
losing git history for those files.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: bug Something isn't working
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants