Merge https://github.com/jaraco/skeleton

README.rst

@@ -3,6 +3,9 @@
 
 .. image:: https://img.shields.io/pypi/pyversions/pip-run.svg
 
+.. image:: https://dev.azure.com/jaraco/pip-run/_apis/build/status/jaraco.pip-run?branchName=master
+   :target: https://dev.azure.com/jaraco/pip-run/_build/latest?definitionId=1&branchName=master
+
 .. image:: https://img.shields.io/travis/jaraco/pip-run/master.svg
    :target: https://travis-ci.org/jaraco/pip-run
 
@@ -16,9 +19,6 @@
 .. image:: https://readthedocs.org/projects/pip-run/badge/?version=latest
    :target: https://pip-run.readthedocs.io/en/latest/?badge=latest
 
-.. image:: https://dev.azure.com/jaraco/pip-run/_apis/build/status/jaraco.pip-run?branchName=master
-   :target: https://dev.azure.com/jaraco/pip-run/_build/latest?definitionId=1&branchName=master
-
 ``pip-run`` provides on-demand temporary package installation
 for a single interpreter run.
 

azure-pipelines.yml

@@ -1,7 +1,6 @@
-# Python package
-# Create and test a Python package on multiple Python versions.
-# Add steps that analyze code, save the dist with the build record, publish to a PyPI-compatible index, and more:
-# https://docs.microsoft.com/azure/devops/pipelines/languages/python
+# Create the project in Azure with:
+# az project create --name $name --organization https://dev.azure.com/$org/ --visibility public
+# then configure the pipelines (through web UI)
 
 trigger:
   branches:

skeleton.md

@@ -103,23 +103,47 @@ Relies a .flake8 file to correct some default behaviors:
 
 ## Continuous Integration
 
-The project is pre-configured to run tests in [Travis-CI](https://travis-ci.org) (.travis.yml). Any new project must be enabled either through their web site or with the `travis enable` command.
+The project is pre-configured to run tests through multiple CI providers.
+
+### Azure Pipelines
+
+[Azure Pipelines](https://azure.microsoft.com/en-us/services/devops/pipelines/) are the preferred provider as they provide free, fast, multi-platform services. See azure-pipelines.yml for more details.
+
+Features include:
+
+- test against multiple Python versions
+- run on Ubuntu Bionic
+
+### Travis CI
+
+[Travis-CI](https://travis-ci.org) is configured through .travis.yml. Any new project must be enabled either through their web site or with the `travis enable` command.
 
 Features include:
-- test against Python 2 and 3
+- test against 3
 - run on Ubuntu Xenial
 - correct for broken IPv6
 
-Also provided is a minimal template for running under Appveyor (Windows).
+### Appveyor
+
+A minimal template for running under Appveyor (Windows) is provided.
 
 ### Continuous Deployments
 
-In addition to running tests, an additional deploy stage is configured to automatically release tagged commits to PyPI using [API tokens](https://pypi.org/help/#apitoken). The release process expects an authorized token to be configured with Travis as the TWINE_PASSWORD environment variable. After the Travis project is created, configure the token through the web UI or with a command like the following (bash syntax):
+In addition to running tests, an additional deploy stage is configured to automatically release tagged commits to PyPI using [API tokens](https://pypi.org/help/#apitoken). The release process expects an authorized token to be configured with Azure as the `Azure secrets` variable group. This variable group needs to be created only once per organization. For example:
 
 ```
-TWINE_PASSWORD={token} travis env copy TWINE_PASSWORD
+# create a resource group if none exists
+az group create --name main --location eastus2
+# create the vault (try different names until something works)
+az keyvault create --name secrets007 --resource-group main
+# create the secret
+az keyvault secret set --vault-name secrets007 --name PyPI-token --value $token
 ```
 
+Then, in the web UI for the project's Pipelines Library, create the `Azure secrets` variable group referencing the key vault name.
+
+For more details, see [this blog entry](https://blog.jaraco.com/configuring-azure-pipelines-with-secets/).
+
 ## Building Documentation
 
 Documentation is automatically built by [Read the Docs](https://readthedocs.org) when the project is registered with it, by way of the .readthedocs.yml file. To test the docs build manually, a tox env may be invoked as `tox -e docs`. Both techniques rely on the dependencies declared in `setup.cfg/options.extras_require.docs`.