This page documents the contributor workflow for the doocs/leetcode repository, covering the automated quality gates, CI/CD pipelines, and pull request requirements that ensure code consistency across 12+ programming languages and maintain the integrity of 3,700+ problem solutions.
Related pages: CI/CD and Deployment (page 2.4), Code Formatting System (page 6.2), Pull Request Lifecycle (page 7.3)
The repository enforces a rigorous automated workflow that validates contributions at multiple stages before they reach the main branch:
Diagram: Complete Development Workflow with Automated Gates
Sources: .github/workflows/deploy.yml1-132 .github/workflows/black-lint.yml1-36 .github/workflows/pr-checker.yml1-106 .husky/pre-commit1-4 .husky/commit-msg1-4 package.json15-19
The repository uses Husky (version 9.0.1) to manage Git hooks that enforce quality standards before code reaches the remote repository. The hook system is initialized through package.json2-3 with the prepare script "prepare": "husky".
Diagram: Pre-commit Hook Execution Flow
Sources: package.json2-3 package.json10 .husky/pre-commit1-4 .husky/commit-msg1-4 package.json6-7
The pre-commit hook at .husky/pre-commit3 executes:
This invokes lint-staged, which applies different formatters to staged files based on their extensions.
The package.json15-19 configuration defines the lint-staged object that maps file patterns to formatter commands:
| File Pattern | Command | Tool Version | Purpose |
|---|---|---|---|
*.{js,ts,php,sql,md} | prettier --write | prettier@3.3.2 | Format JS/TS/PHP/SQL/Markdown |
*.py | black -S | black@24.3.0 | Format Python (skip string norm) |
*.rs | rustfmt | System rustfmt | Format Rust code |
Notable omissions: C, C++, Java, and Go files are not formatted by pre-commit hooks. These languages are validated by GitHub Actions CI workflows instead:
DoozyX/clang-format-lint-action@v0.17gofmt formatting expected (not enforced)Sources: package.json15-19 package.json12 requirements.txt1 .github/workflows/clang-format-lint.yml33-37
The commit-msg hook at .husky/commit-msg3 executes:
This enforces AngularJS Git Commit Message Conventions through @commitlint/cli@19.3.0 with @commitlint/config-conventional@19.2.2 (package.json6-7).
Valid commit types:
| Type | Scope | Example | Usage |
|---|---|---|---|
feat: | Solutions | feat: add/update solution(s) to lc problem(s): No.0001 | New or updated solutions |
fix: | Bugs | fix: correct time complexity in No.0125 | Bug fixes |
chore: | Tooling | chore: update black to 24.3.0 | Maintenance tasks |
docs: | Documentation | docs: improve README for binary search | Documentation only |
style: | Formatting | style: format Python files with black | Code style changes |
refactor: | Code | refactor: simplify hash table solution | Code refactoring |
The .github/workflows/pr-checker.yml66-70 workflow posts these examples for external contributors:
feat: add/update solution(s) to lc problem(s): No.xxxx
fix: xxxx
chore: xxx
Sources: package.json6-7 .husky/commit-msg1-4 .github/workflows/pr-checker.yml39-70
The .prettierrc1-22 file defines formatting rules for JavaScript, TypeScript, PHP, SQL, and Markdown:
Key settings:
prettier-plugin-sql-cst for SQL, @prettier/plugin-php for PHPSources: .prettierrc1-22 package.json8-13
Python files use Black with the -S flag (package.json17), which preserves the repository's existing string quote style rather than normalizing to double quotes.
The requirements.txt1 specifies black==24.3.0 as the exact version dependency.
Sources: requirements.txt1 package.json17
The .editorconfig1 file provides IDE-level defaults that complement the automated formatters, ensuring consistent indentation and line endings across all file types.
Sources: .editorconfig1
The repository uses GitHub Actions for continuous integration and deployment. Workflows are organized by function and trigger conditions.
Diagram: Black Linting Workflow Execution
Workflow configuration:
-S (.github/workflows/black-lint.yml35) - skips string normalization to preserve existing quote stylesgroup: ${{github.workflow}} - ${{github.ref}} with cancel-in-progress: trueSources: .github/workflows/black-lint.yml1-36
Diagram: Clang-Format Linting Workflow
Workflow configuration:
. (repository root) (.github/workflows/clang-format-lint.yml35)c,cpp,java (.github/workflows/clang-format-lint.yml36)Sources: .github/workflows/clang-format-lint.yml1-37
The main deployment workflow builds and publishes the documentation site to leetcode.doocs.org via GitHub Pages.
Triggers:
Concurrency: .github/workflows/deploy.yml17-19 uses group: ${{ github.workflow }} - ${{ github.ref }} with cancel-in-progress: true
Diagram: Deploy Workflow - Build and Publish Pipeline
Key workflow steps:
Dual branch checkout (.github/workflows/deploy.yml25-35): Checks out both main and docs branches, then syncs docs branch content into the working directory.
Content preprocessing (.github/workflows/deploy.yml38-42): Uses rsync to merge docs branch files, then moves contest README files to the docs directories.
Dependency installation (.github/workflows/deploy.yml70-75): Installs Python dependencies from requirements.txt1-2 mkdocs-material with imaging support, and pngquant for image optimization.
Build pipeline (.github/workflows/deploy.yml80-84):
main.pymkdocs.ymlmkdocs-en.ymlCommitter cache persistence (.github/workflows/deploy.yml89-112): Commits .git-committers-cache.json back to the docs branch to maintain git-committers plugin state between builds.
Artifact handling (.github/workflows/deploy.yml114-124): Compresses the site directory and uploads as an artifact for the deploy job.
GitHub Pages deployment (.github/workflows/deploy.yml126-153): A separate job with pages: write permission deploys the artifact to GitHub Pages.
Concurrency control (.github/workflows/deploy.yml17-19): Uses group: ${{ github.workflow }} - ${{ github.ref }} to ensure only one deployment runs per branch, with cancel-in-progress: true.
Key implementation details:
| Step | Command/Action | Purpose |
|---|---|---|
| Dual checkout | actions/checkout@v4 (main + docs) | Merge documentation from docs branch |
| rsync sync | rsync -a --remove-source-files | Copy docs branch content to working dir |
| File moves | mv solution/CONTEST_README*.md docs/ | Relocate contest files for mkdocs |
| Python deps | pip install -r requirements.txt | Install black@24.3.0, Requests@2.32.4 |
| MkDocs deps | pip install "mkdocs-material[imaging]" | Install documentation generator |
| Image tools | apt-get install -y pngquant | Enable image optimization |
| Preprocessing | python3 main.py | Generate README indexes and metadata |
| Chinese build | mkdocs build -f mkdocs.yml | Build Chinese documentation site |
| English build | mkdocs build -f mkdocs-en.yml | Build English documentation site |
| CNAME | echo "leetcode.doocs.org" > ./site/CNAME | Configure custom domain |
| Cache commit | Git push to docs branch | Persist git-committers plugin cache |
| Artifact | actions/upload-pages-artifact@v3 | Package site directory for deployment |
| Deploy | actions/deploy-pages@v4 | Publish to GitHub Pages |
Sources: .github/workflows/deploy.yml1-132 requirements.txt1-2 .github/workflows/deploy.yml38-42 .github/workflows/deploy.yml80-84 .github/workflows/deploy.yml89-112
Diagram: Image Compression Workflow
The .github/workflows/compress.yml1-55 workflow automatically optimizes images using calibreapp/image-actions. It runs:
Conditional behavior (.github/workflows/compress.yml44):
Configuration details:
doocs/leetcode and restricts forkscalibreapp/image-actions@main (.github/workflows/compress.yml40)DOOCS_BOT_ACTION_TOKEN (.github/workflows/compress.yml42) for git operationsgithub.event_name != 'pull_request' (.github/workflows/compress.yml47-49)Sources: .github/workflows/compress.yml1-55 .github/workflows/compress.yml22-24 .github/workflows/compress.yml40-55
Workflow configuration:
| Property | Value | Source |
|---|---|---|
| File | .github/workflows/starcharts.yml | .github/workflows/starcharts.yml1 |
| Schedule | 0 0/12 * * * (every 12 hours) | .github/workflows/starcharts.yml5 |
| Manual trigger | workflow_dispatch | .github/workflows/starcharts.yml6 |
| Action | MaoLongLong/actions-starcharts@main | .github/workflows/starcharts.yml14 |
| Output file | images/starcharts.svg | .github/workflows/starcharts.yml17 |
| Commit message | chore: auto update starcharts | .github/workflows/starcharts.yml18 |
| Token | DOOCS_BOT_ACTION_TOKEN | .github/workflows/starcharts.yml16 |
| Stars threshold | STARS_CHANGE secret | .github/workflows/starcharts.yml19 |
| Repository check | github.repository == 'doocs/leetcode' | .github/workflows/starcharts.yml12 |
The workflow updates images/starcharts.svg1 which currently shows 35,140 stars (images/starcharts.svg1). The SVG contains a complete star history graph rendered with 1024x400 dimensions.
Sources: .github/workflows/starcharts.yml1-20 images/starcharts.svg1
When a contributor opens a PR, the .github/workflows/pr-checker.yml1-106 workflow evaluates team membership and posts bilingual contribution guidelines for external contributors.
Diagram: PR Checker Workflow - Team Membership Gate
Key features:
Team membership check (.github/workflows/pr-checker.yml78-90): Queries the GitHub API to determine if the PR author is a member of the doocs/leetcode-algorithm team.
Conditional commenting (.github/workflows/pr-checker.yml89-99): Only posts guidelines for non-team members to avoid spamming core contributors.
Bilingual guidelines (.github/workflows/pr-checker.yml24-76): The comment includes both Chinese and English versions of the contribution rules.
Guidelines content summary:
Implementation details:
The workflow uses actions/github-script@v5 (.github/workflows/pr-checker.yml19) to execute JavaScript that:
const PR_OPENER = process.env.PR_OPENER (.github/workflows/pr-checker.yml23)checkTeamMembership() (.github/workflows/pr-checker.yml78)github.request('GET /orgs/{org}/teams/{team_slug}/members', ...) (.github/workflows/pr-checker.yml80-86)teamMemberships.some(member => member.login === PR_OPENER) (.github/workflows/pr-checker.yml88)github.rest.issues.createComment(...) (.github/workflows/pr-checker.yml94-99)Sources: .github/workflows/pr-checker.yml1-106 .github/workflows/pr-checker.yml19-99
The .github/workflows/pr-add-label.yml1-26 workflow automatically adds labels to PRs based on team membership.
Diagram: PR Auto-Labeling Workflow
Configuration:
actionv/pr-label-action@master (.github/workflows/pr-add-label.yml20)DOOCS_BOT_ACTION_TOKEN (.github/workflows/pr-add-label.yml22)doocs (.github/workflows/pr-add-label.yml24)leetcode-algorithm (.github/workflows/pr-add-label.yml25)pull-requests: write (.github/workflows/pr-add-label.yml11)Sources: .github/workflows/pr-add-label.yml1-26 .github/workflows/pr-add-label.yml20-25
To merge a PR, the following conditions must be satisfied:
The deployment workflow automatically triggers after merge, rebuilding and publishing the documentation site.
Sources: .github/workflows/deploy.yml6-15 .github/workflows/black-lint.yml1-36 .github/workflows/clang-format-lint.yml1-37
The repository enforces strict commit message formatting following AngularJS Git Commit Message Conventions. The .github/workflows/pr-checker.yml39-42 workflow documents the expected patterns:
Commit message format:
| Type | Scope | Example Message | When to Use |
|---|---|---|---|
feat: | Solutions | feat: add/update solution(s) to lc problem(s): No.0001 | Adding new problem solutions or updating existing ones |
feat: | Solutions | feat: add Python solution to lc problem: No.0125 | Adding solution in new language |
fix: | Bugs | fix: correct time complexity in No.0125 README | Fixing errors in solutions or documentation |
chore: | Tooling | chore: update black to 24.3.0 in requirements.txt | Dependency updates, tooling changes |
chore: | Assets | chore: auto compress images | Automated maintenance tasks |
docs: | Documentation | docs: improve binary search template explanation | Documentation-only improvements |
style: | Formatting | style: format Python files with black | Code style/formatting fixes |
refactor: | Code | refactor: simplify hash table solution in No.0001 | Code restructuring without behavior change |
The commitlint configuration (package.json6-7) uses @commitlint/config-conventional which enforces this format locally before push.
Sources: .github/workflows/pr-checker.yml39-42 package.json6-7
Contributors must format code according to language-specific standards before submission:
Diagram: Language-Specific Formatting Tools
Formatting tool reference table:
| Language | Pre-commit | CI Validation | Tool | Configuration File | Key Settings |
|---|---|---|---|---|---|
| JavaScript | ✓ | - | prettier@3.3.2 | .prettierrc | tabWidth: 4, singleQuote: true |
| TypeScript | ✓ | - | prettier@3.3.2 | .prettierrc | tabWidth: 4, singleQuote: true |
| PHP | ✓ | - | prettier@3.3.2 + @prettier/plugin-php@0.22.2 | .prettierrc | phpVersion: "8.1", braceStyle: "1tbs" |
| SQL | ✓ | - | prettier@3.3.2 + prettier-plugin-sql-cst@0.11.5 | .prettierrc | sqlKeywordCase: "upper" |
| Markdown | ✓ | - | prettier@3.3.2 | .prettierrc | printWidth: 100 |
| Python | ✓ | ✓ | black@24.3.0 | requirements.txt | Flag: -S (skip string norm) |
| Rust | ✓ | - | rustfmt | System | Default Rust formatting |
| C | - | ✓ | clang-format v16 | Implicit | Default LLVM style |
| C++ | - | ✓ | clang-format v16 | Implicit | Default LLVM style |
| Java | - | ✓ | clang-format v16 | Implicit | Default LLVM style |
| Go | - | - | gofmt (manual) | - | Standard Go formatting |
Critical implementation notes:
Python -S flag: Preserves existing quote styles (single vs double quotes) to maintain consistency across 3,700+ problem solutions (package.json17)
SQL uppercase keywords: Enforces SELECT, FROM, WHERE instead of lowercase (.prettierrc13)
C/C++/Java workflow-only validation: These files are validated but not auto-fixed. Contributors must manually format or wait for CI failures (.github/workflows/clang-format-lint.yml35-37)
Go manual formatting: No automated enforcement. Contributors expected to run gofmt before committing
Sources: .prettierrc1-22 package.json8-13 package.json15-19 requirements.txt1 .github/workflows/black-lint.yml35 .github/workflows/clang-format-lint.yml35-37
When adding a new problem solution, contributors must follow the repository's directory structure conventions. Based on the example files provided:
Required file structure per problem:
| File | Purpose | Requirements | Example Reference |
|---|---|---|---|
| README.md | Chinese problem description and solutions | Front matter with difficulty, tags, edit_urlProblem description in Chinese Solution explanations Code snippets for all languages | solution/1800-1899/1873.Calculate Special Bonus/README.md1-106 |
| README_EN.md | English problem description and solutions | Same structure as README.md No Chinese characters in code comments All text translated to English | solution/1800-1899/1873.Calculate Special Bonus/README_EN.md1-106 |
| Solution.xxx | Source code implementation | One file per language Must be properly formatted Follow language-specific conventions | solution/1800-1899/1873.Calculate Special Bonus/Solution.sql1-7 |
Front matter format example:
Solution file naming conventions:
| Language | Filename | Example |
|---|---|---|
| Python | Solution.py | solution/1700-1799/1716.Calculate Money in Leetcode Bank/Solution.py1-7 |
| Java | Solution.java | solution/1700-1799/1716.Calculate Money in Leetcode Bank/Solution.java1-9 |
| C++ | Solution.cpp | solution/1700-1799/1716.Calculate Money in Leetcode Bank/Solution.cpp1-10 |
| Go | Solution.go | solution/1700-1799/1716.Calculate Money in Leetcode Bank/Solution.go1-7 |
| TypeScript | Solution.ts | solution/1700-1799/1716.Calculate Money in Leetcode Bank/Solution.ts1-8 |
| SQL | Solution.sql | solution/1400-1499/1484.Group Sold Products By The Date/Solution.sql1-8 |
Coding style requirements:
From .github/workflows/pr-checker.yml47-48:
"编码风格(比如变量、函数的命名),尽量跟项目已有代码保持一致"
"The coding style (such as the naming of variables and functions) should be as consistent as possible with the existing code in the project."
Consistency guidelines:
camelCase for Java, snake_case for Python)Sources: .github/workflows/pr-checker.yml46-76 solution/1800-1899/1873.Calculate Special Bonus/README.md1-106 solution/1800-1899/1873.Calculate Special Bonus/Solution.sql1-7 .editorconfig1-23
To configure a local development environment that matches the CI/CD pipeline:
Step 1: Clone the repository
Step 2: Install Node.js dependencies
Installed packages (package.json5-14):
| Package | Version | Purpose |
|---|---|---|
@commitlint/cli | 19.3.0 | Commit message validation |
@commitlint/config-conventional | 19.2.2 | AngularJS commit rules |
@prettier/plugin-php | 0.22.2 | PHP formatting support |
clang-format | 1.8.0 | C/C++/Java formatting |
husky | 9.0.1 | Git hooks manager |
lint-staged | 15.2.7 | Pre-commit file processor |
prettier | 3.3.2 | JS/TS/PHP/SQL/MD formatter |
prettier-plugin-sql-cst | 0.11.5 | SQL formatting support |
Step 3: Install Python dependencies
Installed packages (requirements.txt1-2):
black==24.3.0 - Python code formatterRequests==2.32.4 - HTTP library (used by spider scripts)Step 4: Enable Husky Git hooks
This executes the prepare script (package.json3) which runs husky, initializing hooks in .husky/pre-commit1-4 and .husky/commit-msg1-4
Step 5: Verify formatter installation
Step 6: Configure editor integration (optional)
The repository includes .editorconfig1-23 with IDE-compatible settings:
| Setting | Value | Applies To |
|---|---|---|
indent_style | space | All files except Go |
indent_size | 4 | Most files |
indent_size | 2 | *.{yml,yaml} |
indent_style | tab | *.go |
charset | utf-8 | All files |
trim_trailing_whitespace | true | All files except Markdown |
insert_final_newline | true | All files |
Step 7: Test commit hooks
Sources: package.json2-14 requirements.txt1-2 .husky/pre-commit1-4 .husky/commit-msg1-4 .editorconfig1-23
The following table summarizes when each workflow runs:
| Workflow | Push to main | Pull Request | Schedule | Manual | Paths |
|---|---|---|---|---|---|
| deploy.yml | ✓ | - | - | ✓ | solution/**, lcs/**, lcp/**, lcof2/**, lcof/**, lcci/**, basic/** |
| black-lint.yml | ✓ | ✓ | - | - | Same as deploy.yml |
| clang-format-lint.yml | ✓ | ✓ | - | - | Same as deploy.yml |
| compress.yml | ✓ | ✓ | ✓ (Sun 23:00) | ✓ | **.jpg, **.jpeg, **.png, **.webp |
| starcharts.yml | - | - | ✓ (Every 12h) | ✓ | N/A |
| pr-checker.yml | - | ✓ (opened) | - | - | N/A |
| pr-add-label.yml | - | ✓ (opened/edited/reopened/synchronize) | - | - | N/A |
Concurrency control: All workflows except starcharts use group: ${{github.workflow}} - ${{github.ref}} with cancel-in-progress: true to prevent redundant runs.
Sources: .github/workflows/deploy.yml3-19 .github/workflows/black-lint.yml3-25 .github/workflows/clang-format-lint.yml3-25 .github/workflows/compress.yml3-24 .github/workflows/starcharts.yml3-6 .github/workflows/pr-checker.yml3-9 .github/workflows/pr-add-label.yml3-5
Refresh this wiki
This wiki was recently refreshed. Please wait 2 days to refresh again.