You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
* Consistent naming of transfer operators
Transfer operators have consistent names and are grouped in
the 'transfer' packages.
* fixup! Consistent naming of transfer operators
* Introduces 'transfers' packages.
Closes#9161 and #8620
* fixup! Introduces 'transfers' packages.
* fixup! fixup! Introduces 'transfers' packages.
* fixup! fixup! fixup! Introduces 'transfers' packages.
Copy file name to clipboardExpand all lines: CONTRIBUTING.rst
+66-2Lines changed: 66 additions & 2 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -542,8 +542,71 @@ We support the following types of tests:
542
542
543
543
For details on running different types of Airflow tests, see `TESTING.rst <TESTING.rst>`_.
544
544
545
+
546
+
Naming Conventions for provider packages
547
+
========================================
548
+
549
+
In Airflow 2.0 we standardized and enforced naming for provider packages, modules and classes.
550
+
those rules (introduced as AIP-21) were not only introduced but enforced using automated checks
551
+
that verify if the naming conventions are followed. Here is a brief summary of the rules, for
552
+
detailed discussion you can go to [AIP-21 Changes in import paths](https://cwiki.apache.org/confluence/display/AIRFLOW/AIP-21%3A+Changes+in+import+paths)
553
+
554
+
The rules are as follows:
555
+
556
+
* Provider packages are all placed in 'airflow.providers'
557
+
558
+
* Providers are usually direct sub-packages of the 'airflow.providers' package but in some cases they can be
559
+
further split into sub-packages (for example 'apache' package has 'cassandra', 'druid' ... providers ) out
560
+
of which several different provider packages are produced (apache.cassandra, apache.druid). This is
561
+
case when the providers are connected under common umbrella but very loosely coupled on the code level.
562
+
563
+
* In some cases the package can have sub-packages but they are all delivered as single provider
564
+
package (for example 'google' package contains 'ads', 'cloud' etc. sub-packages). This is in case
565
+
the providers are connected under common umbrella and they are also tightly coupled on the code level.
566
+
567
+
* Typical structure of provider package:
568
+
* example_dags -> example DAGs are stored here (used for documentation and System Tests)
569
+
* hooks -> hooks are stored here
570
+
* operators -> operators are stored here
571
+
* sensors -> sensors are stored here
572
+
* secrets -> secret backends are stored here
573
+
* transfers -> transfer operators are stored here
574
+
575
+
* Module names do not contain word "hooks" , "operators" etc. The right type comes from
576
+
the package. For example 'hooks.datastore' module contains DataStore hook and 'operators.datastore'
577
+
contains DataStore operators.
578
+
579
+
* Class names contain 'Operator', 'Hook', 'Sensor' - for example DataStoreHook, DataStoreExportOperator
580
+
581
+
* Operator name usually follows the convention: <Subject><Action><Entity>Operator
582
+
(BigQueryExecuteQueryOperator) is a good example
583
+
584
+
* Transfer Operators are those that actively push data from one service/provider and send it to another
585
+
service (might be for the same or another provider). This usually involves two hooks. The convention
586
+
for those <Source>To<Destination>Operator. They are not named *TransferOperator nor *Transfer.
587
+
588
+
* Operators that use external service to perform transfer (for example CloudDataTransferService operators
589
+
are not placed in "transfers" package and do not have to follow the naming convention for
590
+
transfer operators.
591
+
592
+
* It is often debatable where to put transfer operators but we agreed to the following criteria:
593
+
594
+
* We use "maintainability" of the operators as the main criteria - so the transfer operator
595
+
should be kept at the provider which has highest "interest" in the transfer operator
596
+
597
+
* For Cloud Providers or Service providers that usually means that the transfer operators
598
+
should land at the "target" side of the transfer
599
+
600
+
* Secret Backend name follows the convention: <SecretEngine>Backend.
601
+
602
+
* Tests are grouped in parallel packages under "tests.providers" top level package. Module name is usually
603
+
"test_<object_to_test>.py',
604
+
605
+
* System tests (not yet fully automated but allowing to run e2e testing of partucular provider) are
606
+
named with _system.py suffix.
607
+
545
608
Metadata Database Updates
546
-
==============================
609
+
=========================
547
610
548
611
When developing features, you may need to persist information to the metadata
549
612
database. Airflow has `Alembic <https://github.com/sqlalchemy/alembic>`__ built-in
@@ -623,7 +686,7 @@ could get a reproducible build. See the `Yarn docs
623
686
624
687
625
688
Generate Bundled Files with yarn
626
-
----------------------------------
689
+
--------------------------------
627
690
628
691
To parse and generate bundled files for Airflow, run either of the following
629
692
commands:
@@ -910,6 +973,7 @@ You can join the channels via links at the `Airflow Community page <https://airf
910
973
* The deprecated `JIRA issues <https://issues.apache.org/jira/projects/AIRFLOW/issues/AIRFLOW-4470?filter=allopenissues>`_ for:
911
974
* checking out old but still valuable issues that are not on Github yet
912
975
* mentioning the JIRA issue number in the title of the related PR you would like to open on Github
976
+
913
977
**IMPORTANT**
914
978
We don't create new issues on JIRA anymore. The reason we still look at JIRA issues is that there are valuable tickets inside of it. However, each new PR should be created on `Github issues <https://github.com/apache/airflow/issues>`_ as stated in `Contribution Workflow Example <https://github.com/apache/airflow/blob/master/CONTRIBUTING.rst#contribution-workflow-example>`_
0 commit comments