Get rid of Travis CI from the docs (apache#8488)

BREEZE.rst

@@ -336,7 +336,7 @@ Choosing a Breeze Environment
 
 You can use additional ``breeze`` flags to customize your environment. For example, you can specify a Python
 version to use, backend and a container environment for testing. With Breeze, you can recreate the same
-environments as we have in matrix builds in Travis CI.
+environments as we have in matrix builds in the CI.
 
 For example, you can choose to run Python 3.6 tests with MySQL as backend and in the Docker environment as
 follows:

CONTRIBUTING.rst

@@ -132,12 +132,10 @@ these guidelines:
 -   Include tests, either as doctests, unit tests, or both, to your pull
     request.
 
-    The airflow repo uses `Travis CI <https://travis-ci.org/apache/airflow>`__ to
+    The airflow repo uses `Github Actions <https://help.github.com/en/actions>`__ to
     run the tests and `codecov <https://codecov.io/gh/apache/airflow>`__ to track
-    coverage. You can set up both for free on your fork (see
-    `Travis CI Testing Framework <TESTING.rst#travis-ci-testing-framework>`__ usage guidelines).
-    It will help you make sure you do not break the build with your PR and
-    that you help increase coverage.
+    coverage. You can set up both for free on your fork. It will help you make sure you do not
+    break the build with your PR and that you help increase coverage.
 
 -   Follow our project's `Coding style and best practices`_.
 
@@ -279,8 +277,8 @@ Benefits:
     where all these services are available and can be used by tests
     automatically.
 
--   Breeze environment is almost the same as used in `Travis CI <https://travis-ci.com/>`__ automated builds.
-    So, if the tests run in your Breeze environment, they will work in Travis CI as well.
+-   Breeze environment is almost the same as used in the CI automated builds.
+    So, if the tests run in your Breeze environment, they will work in the CI as well.
 
 Limitations:
 
@@ -308,7 +306,7 @@ There are a number of extras that can be specified when installing Airflow. Thos
 extras can be specified after the usual pip install - for example
 ``pip install -e .[gcp]``. For development purpose there is a ``devel`` extra that
 installs all development dependencies. There is also ``devel_ci`` that installs
-all dependencies needed in CI envioronment.
+all dependencies needed in the CI environment.
 
 This is the full list of those extras:
 
@@ -387,7 +385,7 @@ There are different set of fixed requirements for different python major/minor v
 use the right requirements file for the right python version.
 
 The ``requirements-python<PYTHON_MAJOR_MINOR_VERSION>.txt`` file MUST be regenerated every time after
-the ``setup.py`` is updated. This is checked automatically in Travis CI build. There are separate
+the ``setup.py`` is updated. This is checked automatically in the CI build. There are separate
 jobs for each python version that checks if the requirements should be updated.
 
 If they are not updated, you should regenerate the requirements locally using Breeze as described below.
@@ -475,7 +473,7 @@ Static code checks
 We check our code quality via static code checks. See
 `STATIC_CODE_CHECKS.rst <STATIC_CODE_CHECKS.rst>`_ for details.
 
-Your code must pass all the static code checks in Travis CI in order to be eligible for Code Review.
+Your code must pass all the static code checks in the CI in order to be eligible for Code Review.
 The easiest way to make sure your code is good before pushing is to use pre-commit checks locally
 as described in the static code checks documentation.
 
@@ -530,7 +528,7 @@ We support the following types of tests:
   and `local virtualenv <LOCAL_VIRTUALENV.rst>`_.
 
 * **Integration tests** are available in the Breeze development environment
-  that is also used for Airflow Travis CI tests. Integration test are special tests that require
+  that is also used for Airflow's CI tests. Integration test are special tests that require
   additional services running, such as Postgres, Mysql, Kerberos, etc.
 
 * **System tests** are automatic tests that use external systems like
@@ -676,8 +674,7 @@ In general, your contribution includes the following stages:
 2. Create a `local virtualenv <LOCAL_VIRTUALENV.rst>`_,
    initialize the `Breeze environment <BREEZE.rst>`__, and
    install `pre-commit framework <STATIC_CODE_CHECKS.rst#pre-commit-hooks>`__.
-   If you want to add more changes in the future, set up your own `Travis CI
-   fork <https://github.com/PolideaInternal/airflow/blob/more-gsod-improvements/TESTING.rst#travis-ci-testing-framework>`__.
+   If you want to add more changes in the future, set up your fork and enable Github Actions.
 
 3. Join `devlist <https://lists.apache.org/[email protected]>`__
    and set up a `Slack account <https://apache-airflow-slack.herokuapp.com>`__.
@@ -859,7 +856,7 @@ Later on
    for example: ``git rebase 5abce471e0690c6b8d06ca25685b0845c5fd270f --onto apache/master``
 
 6. If you have no conflicts - that's cool. You rebased. You can now run ``git push --force-with-lease`` to
-   push your changes to your repository. That should trigger the build in CI if you have a
+   push your changes to your repository. That should trigger the build in our CI if you have a
    Pull Request opened already.
 
 7. While rebasing you might have conflicts. Read carefully what git tells you when it prints information

IMAGES.rst

@@ -121,7 +121,7 @@ url.
 Technical details of Airflow images
 ===================================
 
-The CI image is used by Breeze as shell image but it is also used during CI builds on Travis.
+The CI image is used by Breeze as shell image but it is also used during CI build.
 The image is single segment image that contains Airflow installation with "all" dependencies installed.
 It is optimised for rebuild speed (``AIRFLOW_CONTAINER_CI_OPTIMISED_BUILD`` flag set to "true").
 It installs PIP dependencies from the current branch first - so that any changes in setup.py do not trigger

STATIC_CODE_CHECKS.rst

@@ -364,7 +364,7 @@ Running Static Code Checks via Scripts from the Host
 ....................................................
 
 You can trigger the static checks from the host environment, without entering the Docker container. To do
-this, run the following scripts (the same is done in Travis CI):
+this, run the following scripts (the same is done in the CI builds):
 
 * `<scripts/ci/ci_check_license.sh>`_ - checks the licenses.
 * `<scripts/ci/ci_docs.sh>`_ - checks that documentation can be built without warnings.

TESTING.rst

@@ -407,71 +407,6 @@ can speed up the collection of tests by running:
 
     pytest --runtime kubernetes tests/runtime
 
-Travis CI Testing Framework
-===========================
-
-The airflow test suite is based on Travis CI framework as running all of the tests
-locally requires significant setup. You can set up Travis CI in your fork of
-Airflow by following the
-`Travis CI Getting Started guide <https://docs.travis-ci.com/user/getting-started/>`__.
-
-Consider using Travis CI framework if you submit multiple pull requests
-and want to speed up your builds.
-
-There are two different options available for running Travis CI, and they are
-set up on GitHub as separate components:
-
--   **Travis CI GitHub App** (new version)
--   **Travis CI GitHub Services** (legacy version)
-
-Travis CI GitHub App (new version)
-----------------------------------
-
-1.  Once `installed <https://github.com/apps/travis-ci/installations/new/permissions?target_id=47426163>`__,
-    configure the Travis CI GitHub App at
-    `Configure Travis CI <https://github.com/settings/installations>`__.
-
-2.  Set repository access to either "All repositories" for convenience, or "Only
-    select repositories" and choose ``USERNAME/airflow`` in the drop-down menu.
-
-3.   Access Travis CI for your fork at `<https://travis-ci.com/USERNAME/airflow>`__.
-
-Travis CI GitHub Services (legacy version)
-------------------------------------------
-
-**NOTE:** The apache/airflow project is still using the legacy version.
-
-Travis CI GitHub Services version uses an Authorized OAuth App.
-
-1.  Once installed, configure the Travis CI Authorized OAuth App at
-    `Travis CI OAuth APP <https://github.com/settings/connections/applications/88c5b97de2dbfc50f3ac>`__.
-
-2.  If you are a GitHub admin, click the **Grant** button next to your
-    organization; otherwise, click the **Request** button. For the Travis CI
-    Authorized OAuth App, you may have to grant access to the forked
-    ``ORGANIZATION/airflow`` repo even though it is public.
-
-3.  Access Travis CI for your fork at
-    `<https://travis-ci.org/ORGANIZATION/airflow>`_.
-
-Creating New Projects in Travis CI
-----------------------------------
-
-If you need to create a new project in Travis CI, use travis-ci.com for both
-private repos and open source.
-
-The travis-ci.org site for open source projects is now legacy and you should not use it.
-
-..
-    There is a second Authorized OAuth App available called **Travis CI for Open Source** used
-    for the legacy travis-ci.org service. Don't use it for new projects!
-
-More information:
-
--  `Open Source on travis-ci.com <https://docs.travis-ci.com/user/open-source-on-travis-ci-com/>`__.
--  `Legacy GitHub Services to GitHub Apps Migration Guide <https://docs.travis-ci.com/user/legacy-services-to-github-apps-migration-guide/>`__.
--  `Migrating Multiple Repositories to GitHub Apps Guide <https://docs.travis-ci.com/user/travis-migrate-to-apps-gem-guide/>`__.
-
 Airflow System Tests
 ====================
 

scripts/ci/ci_build_dockerhub.sh

@@ -17,7 +17,7 @@
 # under the License.
 
 # This is hook build used by DockerHub. We are also using it
-# on Travis CI to potentially rebuild (and refresh layers that
+# on CI to potentially rebuild (and refresh layers that
 # are not cached) Docker images that are used to run CI jobs
 export FORCE_ANSWER_TO_QUESTIONS="yes"