mirror of
https://github.com/apache/superset.git
synced 2026-05-23 00:36:01 +00:00
Previously docusaurus.config.ts had `onBrokenLinks: 'warn'`, so broken
internal links produced advisory warnings during build but didn't gate
merges. Tightening to `throw` surfaces every broken internal route at
build time. Three classes of issue fell out:
1. Stale `/docs/...` and `/docs/6.0.0/...` references in the 6.0.0
versioned snapshot. The user-facing docs section was renamed
`docs` → `user-docs` (routeBasePath) at some point after 6.0.0 was
cut, but the snapshot's links still pointed at the old prefix. The
live site redirects /docs/* → /user-docs/* at runtime, but
Docusaurus's onBrokenLinks checker doesn't honor redirects.
Bulk-rewrote /docs/* → /user-docs/* across the snapshot (and one
/docs/api → /developer-docs/api).
2. Bare-relative MDX links like `[Label](./mcp)` (no .md/.mdx
extension). Docusaurus renders an absolute href in SSR HTML, so
static crawlers see correct links — BUT React Router's `<Link>`
component on the client side resolves the bare path relative to
the current URL on click, so when the page URL has a trailing
slash (e.g. /extensions/overview/), `./mcp` becomes
/extensions/overview/mcp (404). This is exactly the broken-flow a
user reported on /developer-docs/extensions/overview/. Added the
`.md`/`.mdx` extension to all 44 such links across 17 files; this
makes Docusaurus resolve them to the canonical doc URL at the
<Link> level, so SPA navigation works regardless of trailing slash.
3. Miscellaneous content fixes:
- 4 `/configuration/feature-flags` references in 6.0.0 snapshot
pointed at a page that doesn't exist in that version (the
dedicated feature-flags page was added later). Repointed to the
`#feature-flags` anchor inside `configuring-superset.mdx`.
- 3 references to `superset-core/src/superset_core/rest_api/decorators.py`
in extensions docs were rendered as relative URLs, resolving to
/developer-docs/extensions/superset-core/... (404). Converted to
absolute GitHub URLs.
- 1 `/storybook/?path=...` link in extensions/components/index.mdx
pointed at a non-existent route. Repointed to the existing
`/developer-docs/testing/storybook` page that explains how to
run Storybook locally.
- 4 unclosed-paren markdown links in 6.0.0 installation-methods.mdx
(pre-existing source bugs).
Build now passes with `onBrokenLinks: 'throw'`. Note that
`onBrokenAnchors` is still `'warn'` (default); a separate effort
should tighten that and fix the surviving anchor warnings (currently
~60 instances of `/community#superset-community-calendar`).
322 lines
7.1 KiB
Markdown
322 lines
7.1 KiB
Markdown
---
|
|
title: Submitting Pull Requests
|
|
sidebar_position: 3
|
|
---
|
|
|
|
<!--
|
|
Licensed to the Apache Software Foundation (ASF) under one
|
|
or more contributor license agreements. See the NOTICE file
|
|
distributed with this work for additional information
|
|
regarding copyright ownership. The ASF licenses this file
|
|
to you under the Apache License, Version 2.0 (the
|
|
"License"); you may not use this file except in compliance
|
|
with the License. You may obtain a copy of the License at
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
Unless required by applicable law or agreed to in writing,
|
|
software distributed under the License is distributed on an
|
|
"AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
|
|
KIND, either express or implied. See the License for the
|
|
specific language governing permissions and limitations
|
|
under the License.
|
|
-->
|
|
|
|
# Submitting Pull Requests
|
|
|
|
Learn how to create and submit high-quality pull requests to Apache Superset.
|
|
|
|
## Before You Start
|
|
|
|
### Prerequisites
|
|
- [ ] Development environment is set up
|
|
- [ ] You've forked and cloned the repository
|
|
- [ ] You've read the [contributing overview](./overview.md)
|
|
- [ ] You've found or created an issue to work on
|
|
|
|
### PR Readiness Checklist
|
|
- [ ] Code follows [coding guidelines](../guidelines/design-guidelines)
|
|
- [ ] Tests are passing locally
|
|
- [ ] Linting passes (`pre-commit run --all-files`)
|
|
- [ ] Documentation is updated if needed
|
|
|
|
## Creating Your Pull Request
|
|
|
|
### 1. Create a Feature Branch
|
|
|
|
```bash
|
|
# Update your fork
|
|
git fetch upstream
|
|
git checkout master
|
|
git merge upstream/master
|
|
git push origin master
|
|
|
|
# Create feature branch
|
|
git checkout -b feature/your-feature-name
|
|
```
|
|
|
|
### 2. Make Your Changes
|
|
|
|
```bash
|
|
# Make changes
|
|
edit files...
|
|
|
|
# Run tests
|
|
pytest tests/unit_tests/
|
|
cd superset-frontend && npm run test
|
|
|
|
# Run linting
|
|
pre-commit run --all-files
|
|
|
|
# Commit with conventional format
|
|
git add .
|
|
git commit -m "feat(dashboard): add new filter component"
|
|
```
|
|
|
|
### 3. PR Title Format
|
|
|
|
Follow [Conventional Commits](https://www.conventionalcommits.org/):
|
|
|
|
```
|
|
type(scope): description
|
|
```
|
|
|
|
**Types:**
|
|
- `feat`: New feature
|
|
- `fix`: Bug fix
|
|
- `docs`: Documentation only
|
|
- `style`: Code style (formatting, semicolons, etc.)
|
|
- `refactor`: Code refactoring
|
|
- `perf`: Performance improvement
|
|
- `test`: Adding tests
|
|
- `chore`: Maintenance tasks
|
|
- `ci`: CI/CD changes
|
|
- `build`: Build system changes
|
|
- `revert`: Reverting changes
|
|
|
|
**Scopes:**
|
|
- `dashboard`: Dashboard functionality
|
|
- `sqllab`: SQL Lab features
|
|
- `explore`: Chart explorer
|
|
- `chart`: Visualization components
|
|
- `api`: REST API endpoints
|
|
- `db`: Database connections
|
|
- `security`: Security features
|
|
- `config`: Configuration
|
|
|
|
**Examples:**
|
|
```
|
|
feat(sqllab): add query cost estimation
|
|
fix(dashboard): resolve filter cascading issue
|
|
docs(api): update REST endpoint documentation
|
|
refactor(explore): simplify chart controls logic
|
|
perf(dashboard): optimize chart loading
|
|
```
|
|
|
|
### 4. PR Description Template
|
|
|
|
Use the template from `.github/PULL_REQUEST_TEMPLATE.md`:
|
|
|
|
```markdown
|
|
### SUMMARY
|
|
Brief description of changes and motivation.
|
|
|
|
### BEFORE/AFTER SCREENSHOTS OR ANIMATED GIF
|
|
[Required for UI changes]
|
|
|
|
### TESTING INSTRUCTIONS
|
|
1. Step-by-step instructions
|
|
2. How to verify the fix/feature
|
|
3. Any specific test scenarios
|
|
|
|
### ADDITIONAL INFORMATION
|
|
- [ ] Has associated issue: #12345
|
|
- [ ] Required feature flags:
|
|
- [ ] API changes:
|
|
- [ ] DB migration required:
|
|
|
|
### CHECKLIST
|
|
- [ ] CI checks pass
|
|
- [ ] Tests added/updated
|
|
- [ ] Documentation updated
|
|
- [ ] PR title follows conventions
|
|
```
|
|
|
|
### 5. Submit the PR
|
|
|
|
```bash
|
|
# Push to your fork
|
|
git push origin feature/your-feature-name
|
|
|
|
# Create PR via GitHub CLI
|
|
gh pr create --title "feat(sqllab): add query cost estimation" \
|
|
--body-file .github/PULL_REQUEST_TEMPLATE.md
|
|
|
|
# Or use the GitHub web interface
|
|
```
|
|
|
|
## PR Best Practices
|
|
|
|
### Keep PRs Focused
|
|
- One feature/fix per PR
|
|
- Break large changes into smaller PRs
|
|
- Separate refactoring from feature changes
|
|
|
|
### Write Good Commit Messages
|
|
```bash
|
|
# Good
|
|
git commit -m "fix(dashboard): prevent duplicate API calls when filters change"
|
|
|
|
# Bad
|
|
git commit -m "fix bug"
|
|
git commit -m "updates"
|
|
```
|
|
|
|
### Include Tests
|
|
```python
|
|
# Backend test example
|
|
def test_new_feature():
|
|
"""Test that new feature works correctly."""
|
|
result = new_feature_function()
|
|
assert result == expected_value
|
|
```
|
|
|
|
```typescript
|
|
// Frontend test example
|
|
test('renders new component', () => {
|
|
const { getByText } = render(<NewComponent />);
|
|
expect(getByText('Expected Text')).toBeInTheDocument();
|
|
});
|
|
```
|
|
|
|
### Add Screenshots for UI Changes
|
|
```markdown
|
|
### Before
|
|

|
|
|
|
### After
|
|

|
|
```
|
|
|
|
### Update Documentation
|
|
- Update relevant docs in `/docs` directory
|
|
- Add docstrings to new functions/classes
|
|
- Update UPDATING.md for breaking changes
|
|
|
|
## CI Checks
|
|
|
|
### Required Checks
|
|
All PRs must pass:
|
|
- `Python Tests` - Backend unit/integration tests
|
|
- `Frontend Tests` - JavaScript/TypeScript tests
|
|
- `Linting` - Code style checks
|
|
- `Type Checking` - MyPy and TypeScript
|
|
- `License Check` - Apache license headers
|
|
- `Documentation Build` - Docs compile successfully
|
|
|
|
### Common CI Failures
|
|
|
|
#### Python Test Failures
|
|
```bash
|
|
# Run locally to debug
|
|
pytest tests/unit_tests/ -v
|
|
pytest tests/integration_tests/ -v
|
|
```
|
|
|
|
#### Frontend Test Failures
|
|
```bash
|
|
cd superset-frontend
|
|
npm run test -- --coverage
|
|
```
|
|
|
|
#### Linting Failures
|
|
```bash
|
|
# Auto-fix many issues
|
|
pre-commit run --all-files
|
|
|
|
# Manual fixes may be needed for:
|
|
# - MyPy type errors
|
|
# - Complex ESLint issues
|
|
# - License headers
|
|
```
|
|
|
|
## Responding to Reviews
|
|
|
|
### Address Feedback Promptly
|
|
```bash
|
|
# Make requested changes
|
|
edit files...
|
|
|
|
# Add commits (don't amend during review)
|
|
git add .
|
|
git commit -m "fix: address review feedback"
|
|
git push origin feature/your-feature-name
|
|
```
|
|
|
|
### Request Re-review
|
|
- Click "Re-request review" after addressing feedback
|
|
- Comment on resolved discussions
|
|
- Thank reviewers for their time
|
|
|
|
### Handling Conflicts
|
|
```bash
|
|
# Update your branch
|
|
git fetch upstream
|
|
git rebase upstream/master
|
|
|
|
# Resolve conflicts
|
|
edit conflicted files...
|
|
git add .
|
|
git rebase --continue
|
|
|
|
# Force push (only to your feature branch!)
|
|
git push --force-with-lease origin feature/your-feature-name
|
|
```
|
|
|
|
## After Merge
|
|
|
|
### Clean Up
|
|
```bash
|
|
# Delete local branch
|
|
git checkout master
|
|
git branch -d feature/your-feature-name
|
|
|
|
# Delete remote branch
|
|
git push origin --delete feature/your-feature-name
|
|
|
|
# Update your fork
|
|
git fetch upstream
|
|
git merge upstream/master
|
|
git push origin master
|
|
```
|
|
|
|
### Follow Up
|
|
- Monitor for any issues reported
|
|
- Help with documentation if needed
|
|
- Consider related improvements
|
|
|
|
## Tips for Success
|
|
|
|
### Do
|
|
- ✅ Keep PRs small and focused
|
|
- ✅ Write descriptive PR titles and descriptions
|
|
- ✅ Include tests for new functionality
|
|
- ✅ Respond to feedback constructively
|
|
- ✅ Update documentation
|
|
- ✅ Be patient with the review process
|
|
|
|
### Don't
|
|
- ❌ Submit PRs with failing tests
|
|
- ❌ Include unrelated changes
|
|
- ❌ Force push to master
|
|
- ❌ Ignore CI failures
|
|
- ❌ Skip the PR template
|
|
|
|
## Getting Help
|
|
|
|
- **Slack**: Ask in #development or #beginners
|
|
- **GitHub**: Tag @apache/superset-committers for attention
|
|
- **Mailing List**: dev@superset.apache.org
|
|
|
|
Next: [Understanding code review process](./code-review.md)
|