27ed20403e
## What Consolidates the Vale linting job from PR #65973 into the existing Reviewdog workflow. This adds Vale as a second documentation linting job alongside MarkdownLint, both using the same reviewdog reporter for consistency. Related to #65973 ## How **Workflow Changes** (`.github/workflows/reviewdog.yml`): - Updated workflow comments to reflect that both MarkdownLint and Vale run on docs - Added a new `vale` job that runs after the `markdownlint` job - Configured Vale to use `github-pr-review` reporter (matching MarkdownLint's configuration) - Uses `filter_mode: added` to only lint newly added content - Uses `fail_on_error: false` to keep Vale checks non-blocking **Vale Configuration Changes** (`docusaurus/vale.ini`): - Changed `MinAlertLevel` from `suggestion` to `warning` - This scopes Vale to only report warnings and errors, excluding suggestions ## Review guide 1. **`.github/workflows/reviewdog.yml`** - Review the Vale job configuration: - Verify the `errata-ai/vale-action` parameters are correct - Confirm `github-pr-review` is the appropriate reporter (changed from `github-pr-check` in the original PR #65973) - Check that `filter_mode: added` and `fail_on_error: false` are the desired settings 2. **`docusaurus/vale.ini`** - Review the MinAlertLevel change: - Confirm `MinAlertLevel = warning` is the desired behavior (excludes suggestions, only shows warnings and errors) - Note: The `airbyte.punctuation = NO` rule was already removed in master, so no changes needed there ## User Impact **Positive:** - Documentation PRs will now receive automated Vale linting feedback alongside MarkdownLint - Both linters use the same reporter type for consistent PR annotations - Vale will only flag warnings and errors, reducing noise from suggestions **Neutral:** - This supersedes the separate Vale workflow from PR #65973, which can be closed once this is merged - No impact to existing MarkdownLint checks ## Can this PR be safely reverted and rolled back? - [x] YES 💚 This only adds a new linting job to the Reviewdog workflow. Reverting would simply remove the Vale checks without affecting the existing MarkdownLint job or any other workflows. --- **Session Details:** - Requested by: Ian Alton (ian.alton@airbyte.io) - Link to Devin run: https://app.devin.ai/sessions/7993d1cba2464b48bbababe88bda0671 --------- Co-authored-by: Devin AI <158243242+devin-ai-integration[bot]@users.noreply.github.com> Co-authored-by: ian.alton@airbyte.io <ian.alton@airbyte.io>
description
| description |
|---|
| We love contributions to Airbyte, big or small. |
Contributing to Airbyte
Thank you for your interest in contributing! Contributions are very welcome.
We appreciate first time contributors and we are happy help you get started. Join our community Slack and feel free to reach out with questions in #dev-and-contribuions channel.
Everyone interacting in Slack, codebases, mailing lists, events, or any other Airbyte activities is expected to follow the Code of Conduct. Please review it before getting started.
Code Contributions
Most of the issues that are open for contributions are tagged with good first issue or help-welcome.
If you see an issue that isn't tagged that you're interested in, post a comment with your approach, and we'd be happy to assign it to you. If you submit a fix isn't linked to an issue you're assigned there is chance it won't be accepted. You can ping @marcosmarxm who is responsible for Community Code Contributions.
Here are the areas that we love seeing contributions to:
- Bug fixes, features, and enhancements to existing API source connectors.
- New API sources built with the Connector Builder.
- New streams and features for existing connectors in Connector Builder: error backoff, pagination, incremental syncs, etc.
- Migrating existing sources from Python to the Connector Builder.
- Bug fixes, features, and enhancements to the following database sources: Postgres, MySQL, MSSQL.
- Bug fixes to the following destinations: BigQuery, Snowflake, Redshift, S3, and Postgres.
- Helm Charts features, bug fixes, and other platform bug fixes.
Please be aware that contributions to Airbyte Connectors may take some time to review, as they can affect many users. We appreciate your patience and encourage you to include as much information as possible to assist reviewers. Please add examples, use cases, documentation links, and more.
:::warning Airbyte is undergoing a major revamp of the shared core Java destinations codebase, with plans to release a new CDK in April 2025. We are actively working on improving usability, speed (through asynchronous loading), and implementing Typing and Deduplication (Destinations V2). We're not actively reviewing/accepting new Java connectors for now. :::
The usual workflow of code contribution is:
- Fork the Airbyte repository.
- Clone the repository locally.
- Create a branch for your feature/bug fix with the format
{YOUR_USERNAME}/{FEATURE/BUG}(e.g.jdoe/source-stock-api-stream-fix) - Make and commit changes.
- Push your local branch to your fork.
- Submit a Pull Request so that we can review your changes.
- Link an existing Issue that does not include the
needs triagelabel to your Pull Request. Pull requests without an issue attached take longer to review. - Write a PR title and description that follows the Pull Request Handbook.
- An Airbyte maintainer will trigger the CI tests for you and review the code.
- Review and respond to feedback and questions by Airbyte maintainers.
- Merge the contribution.
You can check the status of your contribution in this Github Project. It will provide you what Sprint your contribution was assigned and when you can expect a review.
:::warning Do not submit a pull request using the master branch from your forked repository. The team will not be able to run integration tests and your pull request will be closed. :::
Guidelines to common code contributions:
Documentation
We welcome pull requests that fix typos or enhance the grammar and structure of our documentation! Check the Updating Documentation guide for details on submitting documentation changes.
The following highlights from the Google developer documentation style guide are helpful for new writers:
- Be conversational and friendly without being frivolous
- Use second person
- Use active voice
- Put conditional clauses before instructions
- Put UI elements in bold
- Write inclusive documentation
- Don't pre-announce anything in documentation
Guideline for visuals: Use links to videos instead of screenshots (Reason: Users are more forgiving of outdated videos than screenshots).
For examples of good connector docs, see the Salesforce source connector doc and Snowflake destination connector doc
Community Content
We welcome contributions as new tutorials / showcases / articles, or as enhancements to any of the existing guides on our tutorials page. Head to this repo dedicated to community content: Write for the Community.
Feel free to submit a pull request in this repo, if you have something to add even if it's not related to anything mentioned above.
Engage with the Community
Another crucial way to contribute is by reporting bugs and helping other users in the community. You're welcome to join the Community Slack. Refer to our Issues and Feature Requests guide to learn about the best ways to report bugs.