<commit_before># Dpl 2.0

Dpl 2.0 is the next major version of our deployment tooling, and is
a rewrite of the current codebase.

We are looking for contributors or subject matter experts to help us test
and improve all deployment providers/services.

The goal is to implement an automated test that can run on Travis CI and
deploys to the respective service.

## Automated tests

We have added automated integration tests for the providers/services we are
familiar with. These live in https://github.com/travis-ci/dpl/tree/dpl-2/.travis.
They make a deployment to the respective service (or in case of
Rubygems to a service running locally). The are currently triggered manually,
and may be run on a regular basis in the future (as a cron build).

A provider test consists of:

* A setup script that creates an application (or artifact) to deploy (or
  upload).
* A YAML config snippet that configures and triggers the deployment as part of
  a build on Travis CI.
* A test script that tests if the deployment was successful.

For example:

* [github_pages_prepare](https://github.com/travis-ci/dpl/blob/dpl-2/.travis/providers/github_pages_prepare)
  creates a minimal Git repository that serves an `index.html` on GitHub Pages in a temporary directory.
* [github_pages.yml](https://github.com/travis-ci/dpl/blob/dpl-2/.travis/providers/github_pages.yml)
  configures the build to use Dpl 2.0 to deploy this repository to GitHub Pages.
* [github_pages_test](https://github.com/travis-ci/dpl/blob/dpl-2/.travis/providers/github_pages_test)
  tests if the deployment was successful.

The tests can be run on Travis CI individually, or combined, by triggering a
build via our API, using the script [.travis/trigger](https://github.com/travis-ci/dpl/blob/dpl-2/.travis/trigger).
This takes a provider name as an argument, and requires a Travis CI API token.

For example, this triggers a build that executes the GitHub Pages test on
Travis CI:

```
.travis/trigger github_pages --token [token]
```

The token can also be set as an environment variable:

```
export TRAVIS_API_TOKEN=[token]
.travis/trigger github_pages
```

The `trigger` script accepts multiple provider names as arguments. If no
arguments are given then tests for all providers will be run.

## How to contribute a test

Fork this repository, work off the branch [dpl-2](https://github.com/travis-ci/dpl/pull/1003) (not the master branch).

Go to your Travis CI account page, sync your account, and enable the repository.

Implement a provider test.

In the build config YAML snippet make sure to use the branch of your fork for the
deployment tooling, and allow the deployment to run on your branch:

```
deploy:
  - provider: [name]
    edge:
      source: [your-login]/dpl
      branch: dpl-2
    on:
      branch: [your-branch]
```

Ideally use credentials for an isolated account on the service you are deploying to.
This is generally good practice, and way you can hand things off to someone else.

In order to get things working encrypt the credentials against your fork, and
add them to the build config YAML snippet. If you are in the root directory
of your fork then this command should do the trick:

```
travis encrypt password=[password]
```

If you do not have the `travis` CLI installed you can install it using:

```
gem install travis
```

When you add encrypted credentials to the build config YAML snippet also add a comment
that allows others to identify the account used. E.g:

```
deploy:
  - provider: pages
    github_token:
      # personal access token with repo scope on the account [name]<commit_msg>use yaml markup<commit_after># Dpl 2.0

Dpl 2.0 is the next major version of our deployment tooling, and is
a rewrite of the current codebase.

We are looking for contributors or subject matter experts to help us test
and improve all deployment providers/services.

The goal is to implement an automated test that can run on Travis CI and
deploys to the respective service.

## Automated tests

We have added automated integration tests for the providers/services we are
familiar with. These live in https://github.com/travis-ci/dpl/tree/dpl-2/.travis.
They make a deployment to the respective service (or in case of
Rubygems to a service running locally). The are currently triggered manually,
and may be run on a regular basis in the future (as a cron build).

A provider test consists of:

* A setup script that creates an application (or artifact) to deploy (or
  upload).
* A YAML config snippet that configures and triggers the deployment as part of
  a build on Travis CI.
* A test script that tests if the deployment was successful.

For example:

* [github_pages_prepare](https://github.com/travis-ci/dpl/blob/dpl-2/.travis/providers/github_pages_prepare)
  creates a minimal Git repository that serves an `index.html` on GitHub Pages in a temporary directory.
* [github_pages.yml](https://github.com/travis-ci/dpl/blob/dpl-2/.travis/providers/github_pages.yml)
  configures the build to use Dpl 2.0 to deploy this repository to GitHub Pages.
* [github_pages_test](https://github.com/travis-ci/dpl/blob/dpl-2/.travis/providers/github_pages_test)
  tests if the deployment was successful.

The tests can be run on Travis CI individually, or combined, by triggering a
build via our API, using the script [.travis/trigger](https://github.com/travis-ci/dpl/blob/dpl-2/.travis/trigger).
This takes a provider name as an argument, and requires a Travis CI API token.

For example, this triggers a build that executes the GitHub Pages test on
Travis CI:

```
.travis/trigger github_pages --token [token]
```

The token can also be set as an environment variable:

```
export TRAVIS_API_TOKEN=[token]
.travis/trigger github_pages
```

The `trigger` script accepts multiple provider names as arguments. If no
arguments are given then tests for all providers will be run.

## How to contribute a test

Fork this repository, work off the branch [dpl-2](https://github.com/travis-ci/dpl/pull/1003) (not the master branch).

Go to your Travis CI account page, sync your account, and enable the repository.

Implement a provider test.

In the build config YAML snippet make sure to use the branch of your fork for the
deployment tooling, and allow the deployment to run on your branch:

```yaml
deploy:
  - provider: [name]
    edge:
      source: [your-login]/dpl
      branch: dpl-2
    on:
      branch: [your-branch]
```

Ideally use credentials for an isolated account on the service you are deploying to.
This is generally good practice, and way you can hand things off to someone else.

In order to get things working encrypt the credentials against your fork, and
add them to the build config YAML snippet. If you are in the root directory
of your fork then this command should do the trick:

```
travis encrypt password=[password]
```

If you do not have the `travis` CLI installed you can install it using:

```
gem install travis
```

When you add encrypted credentials to the build config YAML snippet also add a comment
that allows others to identify the account used. E.g:

```yaml
deploy:
  - provider: pages
    github_token:
      # personal access token with repo scope on the account [name]
{'fraction_non_alphanumeric': 0.07085301472631286, 'fraction_numerical': 0.004723534315087524, 'mean_word_length': 4.0448493342676946, 'pattern_counts': {'":': 0, '<': 3, '<?xml version=': 0, '>': 3, 'https://': 12, 'lorem ipsum': 0, 'www.': 0, 'xml': 0}, 'pii_count': 0, 'substrings_counts': 0, 'word_list_counts': {'cursed_substrings.json': 0, 'profanity_word_list.json': 0, 'sexual_word_list.json': 0, 'zh_pornsignals.json': 0}}
{'dir': 'git-commits-cleaned', 'id': '7440013', 'n_tokens_mistral': 2104, 'n_tokens_neox': 2015, 'n_words': 993}