Add documentation create/update community providers (apache#15061)

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>`_

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
 '''''''''''''''''''''''''''''''
@@ -245,7 +250,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)
@@ -299,6 +304,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.
@@ -326,3 +337,4 @@ Content
 
     Packages <packages-ref>
     Operators and hooks <operators-and-hooks-ref/index>
+    Howto create and update community providers <howto/create-update-providers>