From 2fd43d4d376092786589d5f03afbc19ce3975997 Mon Sep 17 00:00:00 2001 From: Alexandre Girard Date: Mon, 15 Aug 2022 10:03:37 -0700 Subject: [PATCH] Make config-based docs accessible through direct link (#15662) * fix broken links * include config-based * throw on broken links * fix link * reset --- .../config-based/overview.md | 2 +- .../config-based/tutorial/5-incremental-reads.md | 4 ++-- .../config-based/tutorial/6-testing.md | 2 +- .../config-based/yaml-structure.md | 2 +- .../contributing-to-airbyte/gradle-cheatsheet.md | 16 +++++++++------- docusaurus/docusaurus.config.js | 1 - 6 files changed, 14 insertions(+), 13 deletions(-) diff --git a/docs/connector-development/config-based/overview.md b/docs/connector-development/config-based/overview.md index 0a9350d43c051..61060860f6256 100644 --- a/docs/connector-development/config-based/overview.md +++ b/docs/connector-development/config-based/overview.md @@ -3,7 +3,7 @@ :warning: This framework is in alpha stage. Support is not in production and is available only to select users. :warning: The goal of this document is to give enough technical specifics to understand how config-based connectors work. -When you're ready to start building a connector, you can start with [the tutorial](../../../config-based/tutorial/0-getting-started.md) or dive into the [reference documentation](https://airbyte-cdk.readthedocs.io/en/latest/api/airbyte_cdk.sources.declarative.html) +When you're ready to start building a connector, you can start with [the tutorial](./tutorial/0-getting-started.md) or dive into the [reference documentation](https://airbyte-cdk.readthedocs.io/en/latest/api/airbyte_cdk.sources.declarative.html) ## Overview diff --git a/docs/connector-development/config-based/tutorial/5-incremental-reads.md b/docs/connector-development/config-based/tutorial/5-incremental-reads.md index 70164c4dab942..02ff578e6432b 100644 --- a/docs/connector-development/config-based/tutorial/5-incremental-reads.md +++ b/docs/connector-development/config-based/tutorial/5-incremental-reads.md @@ -90,7 +90,7 @@ The connector will now always read data for the start date, which is not exactly Instead, we would like to iterate over all the dates between the start_date and today and read data for each day. We can do this by adding a `DatetimeStreamSlicer` to the connector definition, and update the `path` to point to the stream_slice's `start_date`: -More details on the stream slicers can be found [here](./link-to-stream-slicers.md) +More details on the stream slicers can be found [here](../stream-slicers.md) Let's first define a stream slicer at the top level of the connector definition: @@ -298,4 +298,4 @@ Next, we'll run the [Source Acceptance Tests suite to ensure the connector invar - [Incremental reads](../../cdk-python/incremental-stream.md) - [Stream slicers](../stream-slicers.md) -- [Stream slices](../cdk-python/stream-slices.md) \ No newline at end of file +- [Stream slices](../../cdk-python/stream-slices.md) \ No newline at end of file diff --git a/docs/connector-development/config-based/tutorial/6-testing.md b/docs/connector-development/config-based/tutorial/6-testing.md index 90129993c5ac2..c0970a0af0742 100644 --- a/docs/connector-development/config-based/tutorial/6-testing.md +++ b/docs/connector-development/config-based/tutorial/6-testing.md @@ -39,7 +39,7 @@ $ python -m pytest integration_tests -p integration_tests.acceptance Next, we'll add the connector to the [Airbyte platform](https://docs.airbyte.com/connector-development/tutorials/cdk-tutorial-python-http/use-connector-in-airbyte). -See your [Contributiong guide]() on how to get started releasing your connector. +See your [Contributiong guide](../../../contributing-to-airbyte/README.md) on how to get started releasing your connector. ## Read more: diff --git a/docs/connector-development/config-based/yaml-structure.md b/docs/connector-development/config-based/yaml-structure.md index d81da3a3c0d9a..623d06a908328 100644 --- a/docs/connector-development/config-based/yaml-structure.md +++ b/docs/connector-development/config-based/yaml-structure.md @@ -137,7 +137,7 @@ In this example, outer.inner.k2 will evaluate to "MyKey is MyValue" Strings can contain references to previously defined values. The parser will dereference these values to produce a complete ConnectionDefinition -References can be defined using a *ref() string. +References can be defined using a "*ref({arg})" string. ```yaml key: 1234 diff --git a/docs/contributing-to-airbyte/gradle-cheatsheet.md b/docs/contributing-to-airbyte/gradle-cheatsheet.md index 12c050b235503..c15cb8deb469e 100644 --- a/docs/contributing-to-airbyte/gradle-cheatsheet.md +++ b/docs/contributing-to-airbyte/gradle-cheatsheet.md @@ -13,6 +13,7 @@ We have 3 ways of slicing our builds: In our CI we run **Build Platform** and **Build Connectors Base**. Then separately, on a regular cadence, we build each connector and run its integration tests. We split Build Platform and Build Connectors Base from each other for a few reasons: + 1. The tech stacks are very different. The Platform is almost entirely Java. Because of differing needs around separating environments, the Platform build can be optimized separately from the Connectors one. 2. We want to the iteration cycles of people working on connectors or the platform faster _and_ independent. e.g. Before this change someone working on a Platform feature needs to run formatting on the entire codebase \(including connectors\). This led to a lot of cosmetic build failures that obfuscated actually problems. Ideally a failure on the connectors side should not block progress on the platform side. 3. The lifecycles are different. One can safely release the Platform even if parts of Connectors Base is failing \(and vice versa\). @@ -101,18 +102,18 @@ We split Acceptance Tests into 2 different test suites: * Platform Acceptance Tests: These tests are a coarse test to sanity check that each major feature in the platform. They are run with the following command: `SUB_BUILD=PLATFORM ./gradlew :airbyte-tests:acceptanceTests`. These tests expect to find a local version of Airbyte running. For testing the docker version start Airbyte locally. For an example, see the [acceptance_test script](../../tools/bin/acceptance_test.sh) that is used by the CI. For Kubernetes, see the [accetance_test_kube script](../../tools/bin/acceptance_test_kube.sh) that is used by the CI. * Migration Acceptance Tests: These tests make sure the end-to-end process of migrating from one version of Airbyte to the next works. These tests are run with the following command: `SUB_BUILD=PLATFORM ./gradlew :airbyte-tests:automaticMigrationAcceptanceTest --scan`. These tests do not expect there to be a separate deployment of Airbyte running. -These tests currently all live in [airbyte-tests](../.././airbyte-tests) +These tests currently all live in [airbyte-tests](https://github.com/airbytehq/airbyte/airbyte-tests) **Frontend Acceptance Tests** -These are acceptance tests for the frontend. They are run with +These are acceptance tests for the frontend. They are run with ```shell SUB_BUILD=PLATFORM ./gradlew --no-daemon :airbyte-webapp-e2e-tests:e2etest ``` -Like the Platform Acceptance Tests, they expect Airbyte to be running locally. See the [script](https://github.com/airbytehq/airbyte/blob/master/tools/bin/e2e_test.sh) that is used by the CI. +Like the Platform Acceptance Tests, they expect Airbyte to be running locally. See the [script](https://github.com/airbytehq/airbyte/blob/master/tools/bin/e2e_test.sh) that is used by the CI. -These tests currently all live in [airbyte-webapp-e2e-tests](../.././airbyte-webapp-e2e-tests) +These tests currently all live in [airbyte-webapp-e2e-tests](https://github.com/airbytehq/airbyte/airbyte-webapp-e2e-tests) **Future Work** @@ -124,11 +125,12 @@ Our story around "integration testing" or "E2E testing" is a little ambiguous. O All connectors, regardless of implementation language, implement the following interface to allow uniformity in the build system when run from CI: -**Build connector, run unit tests, and build Docker image**: +**Build connector, run unit tests, and build Docker image**: ```shell ./gradlew :airbyte-integrations:connectors::build ``` -**Run integration tests**: + +**Run integration tests**: ```shell ./gradlew :airbyte-integrations:connectors::integrationTest ``` @@ -139,7 +141,7 @@ The ideal end state for a Python connector developer is that they shouldn't have We're almost there, but today there is only one Gradle command that's needed when developing in Python, used for formatting code. -**Formatting python module**: +**Formatting python module**: ```shell ./gradlew :airbyte-integrations:connectors::airbytePythonFormat ``` diff --git a/docusaurus/docusaurus.config.js b/docusaurus/docusaurus.config.js index 38619eb9d7aa7..4a35a5220b907 100644 --- a/docusaurus/docusaurus.config.js +++ b/docusaurus/docusaurus.config.js @@ -62,7 +62,6 @@ const config = { sidebarPath: require.resolve('./sidebars.js'), editUrl: 'https://github.com/airbytehq/airbyte/blob/master/docs', path: '../docs', - exclude: ['**/connector-development/config-based/**'] }, blog: false, theme: {