Skip to content

Commit

Permalink
chore: Fix Linter Errors across the repository (#589)
Browse files Browse the repository at this point in the history 
* chore: Add Github action step to allow linting of notebooks

* Add validate all codebase

* chore: Ran prettier

* Update package.json files

* Ran google-java-format

* Fixed Dockerfile hadolint error

* Fix type ignore lint error

* Update Licenses/Copyright lines

* Add additional License Headers

* Fix flake8 errors
  • Loading branch information
@holtskinner
holtskinner committed Jun 23, 2023
1 parent 99cc4f3 commit 4c97b06
Show file tree
Hide file tree
Showing 119 changed files with 231,270 additions and 230,988 deletions.
246 changes: 122 additions & 124 deletions .github/CONTRIBUTING.md
View file
Original file line number Diff line number Diff line change
Expand Up @@ -33,12 +33,12 @@ This project follows

Samples in this repository are expected to:

* Adhere to best practices
* Be up to date
* Demonstrate a clear Document AI use-case or integration
* Have a clear focus and goal
* Have owners that respond to issues and questions
* Pass tests (if present)
- Adhere to best practices
- Be up to date
- Demonstrate a clear Document AI use-case or integration
- Have a clear focus and goal
- Have owners that respond to issues and questions
- Pass tests (if present)

Samples repeatedly failing to meet this criteria will be moved or removed.

Expand All @@ -55,155 +55,153 @@ request and assign it to `@GoogleCloudPlatform/ml-apis`

1. Determine the name for your sample.

Generally the name of your sample should be a few words that briefly
describe, the purpose or function of your sample code. For example:
`pdf-splitter-python`. Here are a few guidelines:
Generally the name of your sample should be a few words that briefly
describe, the purpose or function of your sample code. For example:
`pdf-splitter-python`. Here are a few guidelines:

* Do not include `Document AI`, `documentai`, `document-ai` or `docai` in
the name of your sample
* The name of your sample must be hyphenated and only contain letters,
numbers, and hyphens.
* If the sample is primarily one language the name for your sample must
end in `-language-name` e.g. `-nodejs`, `-python`, etc.
- Do not include `Document AI`, `documentai`, `document-ai` or `docai` in
the name of your sample
- The name of your sample must be hyphenated and only contain letters,
numbers, and hyphens.
- If the sample is primarily one language the name for your sample must
end in `-language-name` e.g. `-nodejs`, `-python`, etc.

1. Create a new folder in the root of the repository or in the community folders

To add a new samples to this repository you must add a new folder to either the
root of the repository or in the `community` folder. The name of the folder must
correspond to the name of your sample.
To add a new samples to this repository you must add a new folder to either the
root of the repository or in the `community` folder. The name of the folder must
correspond to the name of your sample.

1. Create a README.md for your sample

Each sample must have its own README.md file in the root of the sample
folder. This sample must include:
Each sample must have its own README.md file in the root of the sample
folder. This sample must include:

* The name of the sample
* A description of what the sample does
* Detailed instructions on how to setup and run the sample
* [Community samples only] Add the following disclaimer to your sample's
README.md file:
- The name of the sample
- A description of what the sample does
- Detailed instructions on how to setup and run the sample
- [Community samples only] Add the following disclaimer to your sample's
README.md file:

```text
## Disclaimer
This community sample is not officially maintained by Google.
```
```text
## Disclaimer
This community sample is not officially maintained by Google.
```

* Detail instructions on how to run tests (if present)
- Detail instructions on how to run tests (if present)

1. Update the repository's README with a link to your sample

Edit the repository's README.md file to with the name of your sample, a link to
the sample repository and a brief description. If your sample is in the
`community` folder add your sample's name, link and description to the
"Community" section of the repository's README.md.
Edit the repository's README.md file to with the name of your sample, a link to
the sample repository and a brief description. If your sample is in the
`community` folder add your sample's name, link and description to the
"Community" section of the repository's README.md.

1. Format and lint your code

This repository uses a tool from GitHub called [super-linter](https://GitHub.com/GitHub/super-linter) that
formats and lints code in multiple languages. This helps ensure consistency and prevents common issues.
This repository uses a tool from GitHub called [super-linter](https://GitHub.com/GitHub/super-linter) that
formats and lints code in multiple languages. This helps ensure consistency and prevents common issues.

For Python, use [black](https://GitHub.com/psf/black) to format your code.
Linting checks with flake8, isort, pylint, and mypy will also be performed.
For Python, use [black](https://GitHub.com/psf/black) to format your code.
Linting checks with flake8, isort, pylint, and mypy will also be performed.

1. [non-community samples only] Setup testing and GitHub Actions

This step is not required for samples located in the `community` folder. All
samples in the root of the repository must have tests and those tests must be
setup to run on new pull requests that edit files in your sample folder.

1. Create a GitHub Actions YAML configuration file for your sample To add
enable testing for your sample create a new YAML file in the
`.GitHub/workflows` folder of this repository with the name of your sample
with the `.yaml` file extension. For example:
`.GitHub/workflows/pdf-splitter-python.yaml`

1. Configure when your tests run

Use GitHub Action's triggers to run your tests on a pull request for the
`main` branch and use `path` config to scope your tests to run only on
pull requests that change your sample's code. For example:

```yaml
name: PDF Splitter Python Sample
on:
push:
branches:
- main
paths:
- "pdf-splitter-python/**"
...
```

See
[GitHub's Actions trigger documentation](https://docs.GitHub.com/en/actions/using-workflows/triggering-a-workflow)
for more information.

1. Connect your tests to GitHub Actions Use GitHub Actions' `jobs` feature
to define a test environment and run your tests. For example:

```yaml
...
jobs:
unit:
runs-on: ubuntu-latest
defaults:
run:
working-directory: ./pdf-splitter-python
strategy:
matrix:
python: ["3.7", "3.8", "3.9", "3.10"]
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Setup Python
uses: actions/setup-python@v3
with:
python-version: ${{ matrix.python }}
- name: Install requirements.txt
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- name: Install pylint
run: |
python -m pip install --upgrade pip
pip install pylint
- name: Analyze code with pylint
run: |
pylint $(git ls-files '*.py')
- name: Run unit tests
run: |
python main_test.py
```

See
[GitHub's Actions job documentation](https://docs.GitHub.com/en/actions/using-jobs/using-jobs-in-a-workflow)
for more information.
This step is not required for samples located in the `community` folder. All
samples in the root of the repository must have tests and those tests must be
setup to run on new pull requests that edit files in your sample folder.

1. Create a GitHub Actions YAML configuration file for your sample To add
enable testing for your sample create a new YAML file in the
`.GitHub/workflows` folder of this repository with the name of your sample
with the `.yaml` file extension. For example:
`.GitHub/workflows/pdf-splitter-python.yaml`

1. Configure when your tests run

Use GitHub Action's triggers to run your tests on a pull request for the
`main` branch and use `path` config to scope your tests to run only on
pull requests that change your sample's code. For example:

```yaml
name: PDF Splitter Python Sample
on:
push:
branches:
- main
paths:
- "pdf-splitter-python/**"
```

See
[GitHub's Actions trigger documentation](https://docs.GitHub.com/en/actions/using-workflows/triggering-a-workflow)
for more information.

1. Connect your tests to GitHub Actions Use GitHub Actions' `jobs` feature
to define a test environment and run your tests. For example:

```yaml
---
jobs:
unit:
runs-on: ubuntu-latest
defaults:
run:
working-directory: ./pdf-splitter-python
strategy:
matrix:
python: ["3.7", "3.8", "3.9", "3.10"]
steps:
- name: Checkout
uses: actions/checkout@v2
- name: Setup Python
uses: actions/setup-python@v3
with:
python-version: ${{ matrix.python }}
- name: Install requirements.txt
run: |
python -m pip install --upgrade pip
pip install -r requirements.txt
- name: Install pylint
run: |
python -m pip install --upgrade pip
pip install pylint
- name: Analyze code with pylint
run: |
pylint $(git ls-files '*.py')
- name: Run unit tests
run: |
python main_test.py
```

See
[GitHub's Actions job documentation](https://docs.GitHub.com/en/actions/using-jobs/using-jobs-in-a-workflow)
for more information.

1. Add a code owners entry for your sample

Add an entry in the `.GitHub/CODEOWNERS` file (`community/CODEOWNERS` for
community samples) for your sample folder and add the GitHub usernames of
the owners. Please include a comment indicating the owner of the sample. For
example:
Add an entry in the `.GitHub/CODEOWNERS` file (`community/CODEOWNERS` for
community samples) for your sample folder and add the GitHub usernames of
the owners. Please include a comment indicating the owner of the sample. For
example:

```text
# @matthewayne is the default owner for PDF splitter sample changes
/pdf-splitter-python/ @matthewayne
```
```text
# @matthewayne is the default owner for PDF splitter sample changes
/pdf-splitter-python/ @matthewayne
```

1. Start a review for your sample

1. Before submitting for review, create your Pull Request as a draft so that the linter can run before alerting reviewers.
1. Before submitting for review, create your Pull Request as a draft so that the linter can run before alerting reviewers.

[Create a pull request](https://docs.GitHub.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)
and add
[@GoogleCloudPlatform/ml-apis](https://GitHub.com/orgs/GoogleCloudPlatform/teams/ml-apis)
as a reviewer
[Create a pull request](https://docs.GitHub.com/en/pull-requests/collaborating-with-pull-requests/proposing-changes-to-your-work-with-pull-requests/creating-a-pull-request)
and add
[@GoogleCloudPlatform/ml-apis](https://GitHub.com/orgs/GoogleCloudPlatform/teams/ml-apis)
as a reviewer


### Code Quality Checks

All code samples in this project are checked for formatting and style, to ensure a consistent experience.
All code samples in this project are checked for formatting and style, to ensure a consistent experience.
To test prior to submitting a pull request, you can follow these steps for Python.

From a command-line terminal, install the code analysis tools:
Expand Down
9 changes: 4 additions & 5 deletions .github/auto-approve.yml
View file
Original file line number Diff line number Diff line change
@@ -1,7 +1,6 @@
rules:
# Option 5: incoming PRs from renovate-bot
- author: "renovate-bot"

# Option 5: incoming PRs from renovate-bot
- author: "renovate-bot"

# Title for PRs from renovate-bot MUST start with `fix(deps):` or `chore(deps)"`.
title: "^(fix|chore)\\(deps\\):"
# Title for PRs from renovate-bot MUST start with `fix(deps):` or `chore(deps)"`.
title: "^(fix|chore)\\(deps\\):"
12 changes: 3 additions & 9 deletions .github/linters/.jscpd.json
View file
Original file line number Diff line number Diff line change
@@ -1,12 +1,6 @@
{
"threshold": 0,
"reporters": [
"consoleFull"
],
"ignore": [
"**/__snapshots__/**",
"**/*_test.py",
"**/*.md"
],
"reporters": ["consoleFull"],
"ignore": ["**/__snapshots__/**", "**/*_test.py", "**/*.md"],
"absolute": true
}
}
Loading

0 comments on commit 4c97b06

Please sign in to comment.