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.

Sign up for GitHub

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

docs: Fix bullet point formatting in CI contributing guide #14117

Merged
merged 1 commit into from
Jan 31, 2024
Merged

docs: Fix bullet point formatting in CI contributing guide #14117

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
16 changes: 8 additions & 8 deletions docs/development/contributing/ci.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -6,11 +6,11 @@ Polars uses GitHub Actions as its continuous integration (CI) tool. The setup is

Overall, the CI suite aims to achieve the following:

• Enforce code correctness by running automated tests.
• Enforce code quality by running automated linting checks.
• Enforce code performance by running benchmark tests.
• Enforce that code is properly documented.
• Allow maintainers to easily publish new releases.
- Enforce code correctness by running automated tests.
- Enforce code quality by running automated linting checks.
- Enforce code performance by running benchmark tests.
- Enforce that code is properly documented.
- Allow maintainers to easily publish new releases.

We rely on a wide range of tools to achieve this for both the Rust and the Python code base, and thus a lot of checks are triggered on each pull request.

Expand All @@ -20,9 +20,9 @@ It's entirely possible that you submit a relatively trivial fix that subsequentl

The CI setup is designed with the following requirements in mind:

• Get feedback on each step individually. We want to avoid our test job being cancelled because a linting check failed, only to find out later that we also have a failing test.
• Get feedback on each check as quickly as possible. We want to be able to iterate quickly if it turns out our code does not pass some of the checks.
• Only run checks when they need to be run. A change to the Rust code does not warrant a linting check of the Python code, for example.
- Get feedback on each step individually. We want to avoid our test job being cancelled because a linting check failed, only to find out later that we also have a failing test.
- Get feedback on each check as quickly as possible. We want to be able to iterate quickly if it turns out our code does not pass some of the checks.
- Only run checks when they need to be run. A change to the Rust code does not warrant a linting check of the Python code, for example.

This results in a modular setup with many separate workflows and jobs that rely heavily on caching.

Expand Down
Loading