You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@airflow.apache.org by as...@apache.org on 2021/04/15 11:28:43 UTC
[airflow] 02/08: Add documentation create/update community
providers (#15061)
This is an automated email from the ASF dual-hosted git repository.
ash pushed a commit to branch v2-0-test
in repository https://gitbox.apache.org/repos/asf/airflow.git
commit cf3de8ff1b7c2f14deead56051f9c0253a13f00d
Author: Marcos Marx <ma...@users.noreply.github.com>
AuthorDate: Sat Apr 3 10:01:04 2021 -0300
Add documentation create/update community providers (#15061)
(cherry picked from commit 932f8c2e9360de6371031d4d71df00867a2776e6)
---
.../howto/create-update-providers.rst | 301 +++++++++++++++++++++
docs/apache-airflow-providers/index.rst | 14 +-
2 files changed, 314 insertions(+), 1 deletion(-)
diff --git a/docs/apache-airflow-providers/howto/create-update-providers.rst b/docs/apache-airflow-providers/howto/create-update-providers.rst
new file mode 100644
index 0000000..47ebb77
--- /dev/null
+++ b/docs/apache-airflow-providers/howto/create-update-providers.rst
@@ -0,0 +1,301 @@
+
+ .. 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.
+
+Community Providers
+===================
+
+.. contents:: :local:
+
+How-to creating a new community provider
+----------------------------------------
+
+This document gathers the necessary steps to create a new community provider and also guidelines for updating
+the existing ones. You should be aware that providers may have distinctions that may not be covered in
+this guide. The sequence described was designed to meet the most linear flow possible in order to develop a
+new provider.
+
+Another recommendation that will help you is to look for a provider that works similar to yours. That way it will
+help you to set up tests and other dependencies.
+
+First, you need to set up your local development environment. See `Contribution Quick Start <https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst>`_
+if you did not set up your local environment yet. We recommend using ``breeze`` to develop locally. This way you
+easily be able to have an environment more similar to the one executed by Github CI workflow.
+
+ .. code-block:: bash
+
+ ./breeze
+
+Using the code above you will set up Docker containers. These containers your local code to internal volumes.
+In this way, the changes made in your IDE are already applied to the code inside the container and tests can
+be carried out quickly.
+
+In this how-to guide our example provider name will be ``<NEW_PROVIDER>``.
+When you see this placeholder you must change for your provider name.
+
+
+Initial Code and Unit Tests
+^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+Most likely you have developed a version of the provider using some local customization and now you need to
+transfer this code to the Airflow project. Below is described all the initial code structure that
+the provider may need. Understand that not all providers will need all the components described in this structure.
+If you still have doubts about building your provider, we recommend that you read the initial provider guide and
+open a issue on Github so the community can help you.
+
+ .. code-block:: bash
+
+ airflow/
+ ├── providers/<NEW_PROVIDER>/
+ │ ├── __init__.py
+ │ ├── example_dags/
+ │ │ ├── __init__.py
+ │ │ └── example_<NEW_PROVIDER>.py
+ │ ├── hooks/
+ │ │ ├── __init__.py
+ │ │ └── <NEW_PROVIDER>.py
+ │ ├── operators/
+ │ │ ├── __init__.py
+ │ │ └── <NEW_PROVIDER>.py
+ │ ├── sensors/
+ │ │ ├── __init__.py
+ │ │ └── <NEW_PROVIDER>.py
+ │ └── transfers/
+ │ ├── __init__.py
+ │ └── <NEW_PROVIDER>.py
+ └── tests/providers/<NEW_PROVIDER>/
+ ├── __init__.py
+ ├── hooks/
+ │ ├── __init__.py
+ │ └── test_<NEW_PROVIDER>.py
+ ├── operators/
+ │ ├── __init__.py
+ │ ├── test_<NEW_PROVIDER>.py
+ │ └── test_<NEW_PROVIDER>_system.py
+ ├── sensors/
+ │ ├── __init__.py
+ │ └── test_<NEW_PROVIDER>.py
+ └── transfers/
+ ├── __init__.py
+ └── test_<NEW_PROVIDER>.py
+
+Considering that you have already transferred your provider's code to the above structure, it will now be necessary
+to create unit tests for each component you created. The example below I have already set up an environment using
+breeze and I'll run unit tests for my Hook.
+
+ .. code-block:: bash
+
+ root@fafd8d630e46:/opt/airflow# python -m pytest tests/providers/<NEW_PROVIDER>/hook/<NEW_PROVIDER>.py
+
+Update Airflow validation tests
+^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
+
+There are some tests that Airflow performs to ensure consistency that is related to the providers.
+
+ .. code-block:: bash
+
+ airflow/scripts/in_container/
+ └── run_install_and_test_provider_packages.sh
+ tests/core/
+ └── test_providers_manager.py
+
+Change expected number of providers, hooks and connections if needed in ``run_install_and_test_provider_packages.sh`` file.
+
+Add your provider information in the following variables in ``test_providers_manager.py``:
+
+- add your provider to ``ALL_PROVIDERS`` list;
+- add your provider into ``CONNECTIONS_LIST`` if your provider create a new connection type.
+
+
+Integration tests
+^^^^^^^^^^^^^^^^^
+
+See `Airflow Integration Tests <https://github.com/apache/airflow/blob/master/TESTING.rst#airflow-integration-tests>`_
+
+
+Documentation
+^^^^^^^^^^^^^
+
+An important part of building a new provider is the documentation.
+Some steps for documentation occurs automatically by ``pre-commit`` see `Installing pre-commit guide <https://github.com/apache/airflow/blob/master/CONTRIBUTORS_QUICK_START.rst#pre-commit>`_
+
+ .. code-block:: bash
+
+ airflow/
+ ├── INSTALL
+ ├── CONTRIBUTING.rst
+ ├── setup.py
+ ├── docs/
+ │ ├── spelling_wordlist.txt
+ │ ├── apache-airflow/
+ │ │ └── extra-packages-ref.rst
+ │ ├── integration-logos/<NEW_PROVIDER>/
+ │ │ └── <NEW_PROVIDER>.png
+ │ └── apache-airflow-providers-<NEW_PROVIDER>/
+ │ ├── index.rst
+ │ ├── commits.rst
+ │ ├── connections.rst
+ │ └── operators/
+ │ └── <NEW_PROVIDER>.rst
+ └── providers/
+ ├── dependencies.json
+ └── <NEW_PROVIDER>/
+ ├── provider.yaml
+ └── CHANGELOG.rst
+
+
+Files automatically updated by pre-commit:
+
+- ``airflow/providers/dependencies.json``
+- ``INSTALL``
+
+Files automatically created when the provider is released:
+
+- ``docs/apache-airflow-providers-<NEW_PROVIDER>/commits.rst``
+- ``/airflow/providers/<NEW_PROVIDER>/CHANGELOG``
+
+There is a chance that your provider's name is not a common English word.
+In this case is necessary to add it to the file ``docs/spelling_wordlist.txt``. This file begin with capitalized words and
+lowercase in the second block.
+
+ .. code-block:: bash
+
+ Namespace
+ Neo4j
+ Nextdoor
+ <NEW_PROVIDER> (new line)
+ Nones
+ NotFound
+ Nullable
+ ...
+ neo4j
+ neq
+ networkUri
+ <NEW_PROVIDER> (new line)
+ nginx
+ nobr
+ nodash
+
+Add your provider dependencies into **PROVIDER_REQUIREMENTS** variable in ``setup.py``. If your provider doesn't have
+any dependency add a empty list.
+
+ .. code-block:: python
+
+ PROVIDERS_REQUIREMENTS: Dict[str, List[str]] = {
+ ...
+ 'microsoft.winrm': winrm,
+ 'mongo': mongo,
+ 'mysql': mysql,
+ 'neo4j': neo4j,
+ '<NEW_PROVIDER>': [],
+ 'odbc': odbc,
+ ...
+ }
+
+In the ``CONTRIBUTING.rst`` adds:
+
+- your provider name in the list in the **Extras** section
+- your provider dependencies in the **Provider Packages** section table, only if your provider has external dependencies.
+
+In the ``docs/apache-airflow-providers-<NEW_PROVIDER>/connections.rst``:
+
+- add information how to configure connection for your provider.
+
+In the ``docs/apache-airflow-providers-<NEW_PROVIDER>/operators/<NEW_PROVIDER>.rst``:
+
+- add information how to use the Operator. It's important to add examples and additional information if your Operator has extra-parameters.
+
+ .. code-block:: RST
+
+ .. _howto/operator:NewProviderOperator:
+
+ NewProviderOperator
+ ===================
+
+ Use the :class:`~airflow.providers.<NEW_PROVIDER>.operators.NewProviderOperator` to do something
+ amazing with Airflow!
+
+ Using the Operator
+ ^^^^^^^^^^^^^^^^^^
+
+ The NewProviderOperator requires a ``connection_id`` and this other awesome parameter.
+ You can see an example below:
+
+ .. exampleinclude:: /../../airflow/providers/<NEW_PROVIDER>/example_dags/example_<NEW_PROVIDER>.py
+ :language: python
+ :start-after: [START howto_operator_<NEW_PROVIDER>]
+ :end-before: [END howto_operator_<NEW_PROVIDER>]
+
+
+In the ``docs/apache-airflow-providers-new_provider/index.rst``:
+
+- add all information of the purpose of your provider. It is recommended to check with another provider to help you complete this document as best as possible.
+
+In the ``airflow/providers/<NEW_PROVIDER>/provider.yaml`` add information of your provider:
+
+ .. code-block:: yaml
+
+ package-name: apache-airflow-providers-<NEW_PROVIDER>
+ name: <NEW_PROVIDER>
+ description: |
+ `<NEW_PROVIDER> <https://example.io/>`__
+ versions:
+ - 1.0.0
+
+ integrations:
+ - integration-name: <NEW_PROVIDER>
+ external-doc-url: https://www.example.io/
+ logo: /integration-logos/<NEW_PROVIDER>/<NEW_PROVIDER>.png
+ how-to-guide:
+ - /docs/apache-airflow-providers-<NEW_PROVIDER>/operators/<NEW_PROVIDER>.rst
+ tags: [service]
+
+ operators:
+ - integration-name: <NEW_PROVIDER>
+ python-modules:
+ - airflow.providers.<NEW_PROVIDER>.operators.<NEW_PROVIDER>
+
+ hooks:
+ - integration-name: <NEW_PROVIDER>
+ python-modules:
+ - airflow.providers.<NEW_PROVIDER>.hooks.<NEW_PROVIDER>
+
+ sensors:
+ - integration-name: <NEW_PROVIDER>
+ python-modules:
+ - airflow.providers.<NEW_PROVIDER>.sensors.<NEW_PROVIDER>
+
+ hook-class-names:
+ - airflow.providers.<NEW_PROVIDER>.hooks.<NEW_PROVIDER>.NewProviderHook
+
+You only need to add ``hook-class-names`` in case you have some hooks that have customized UI behavior.
+For more information see `Custom connection types <http://airflow.apache.org/docs/apache-airflow/stable/howto/connection.html#custom-connection-types>`_
+
+
+After changing and creating these files you can build the documentation locally. The two commands below will
+serve to accomplish this. The first will build your provider's documentation. The second will ensure that the
+main Airflow documentation that involves some steps with the providers is also working.
+
+ .. code-block:: bash
+
+ ./breeze build-docs -- --package-filter apache-airflow-providers-<NEW_PROVIDER>
+ ./breeze build-docs -- --package-filter apache-airflow
+
+How-to Update a community provider
+----------------------------------
+
+See `Provider packages versioning <https://github.com/apache/airflow/blob/master/dev/README_RELEASE_PROVIDER_PACKAGES.md#provider-packages-versioning>`_
diff --git a/docs/apache-airflow-providers/index.rst b/docs/apache-airflow-providers/index.rst
index 81e02fa..43c1687 100644
--- a/docs/apache-airflow-providers/index.rst
+++ b/docs/apache-airflow-providers/index.rst
@@ -54,6 +54,11 @@ provider packages are automatically documented in the release notes of every pro
Those are the same providers as for 2.0 but automatically back-ported to work for Airflow 1.10. The
last release of backport providers was done on March 17, 2021.
+Creating and maintaining community providers
+""""""""""""""""""""""""""""""""""""""""""""
+
+See :doc:`howto/create-update-providers` for more information.
+
Provider packages functionality
'''''''''''''''''''''''''''''''
@@ -242,7 +247,7 @@ Example ``myproviderpackage/somemodule.py``:
**How do provider packages work under the hood?**
-When running airflow with your provider package, there will be (at least) three components to your airflow installation:
+When running Airflow with your provider package, there will be (at least) three components to your airflow installation:
* The installation itself (for example, a ``venv`` where you installed airflow with ``pip install apache-airflow``)
together with the related files (e.g. ``dags`` folder)
@@ -296,6 +301,12 @@ The Community only accepts providers that are generic enough, are well documente
and with capabilities of being tested by people in the community. So we might not always be in the
position to accept such contributions.
+
+After you think that your provider matches the expected values above, you can read
+:doc:`howto/create-update-providers` to check all prerequisites for a new
+community Provider and discuss it at the `Devlist <http://airflow.apache.org/community/>`_.
+
+
However, in case you have your own, specific provider, which you can maintain on your own or by your
team, you are free to publish the providers in whatever form you find appropriate. The custom and
community-managed providers have exactly the same capabilities.
@@ -323,3 +334,4 @@ Content
Packages <packages-ref>
Operators and hooks <operators-and-hooks-ref/index>
+ Howto create and update community providers <howto/create-update-providers>