With OSS Credits, you can build only over public repositories. | | **Build job limits** | Very high.
The Free Plan assigned automatically upon sign-up has a limit of 20 concurrent jobs. The paid usage-based plans start from a 40 concurrent jobs limit. | -#### Credit costs associated with Usage-based Plans +#### Usage-based Plans Credit Costs 1. User license cost: by default, credits per each unique user triggering a build or a specific rate charged in arrears at the end of the month. See the [Usage - user licenses](#usage---user-licenses) section for more details. 2. Build job duration costs: For more details, see [Usage—Credits](#usage---credits). @@ -116,22 +115,22 @@ The Usage-based pricing system charges Travis CI users and Travis CI organizatio | Build Job: Linux - gpu-medium VM size | 230 credits / min | 230 credits / min | | Build Job: Linux - gpu-xlarge VM size | 890 credits / min | 890 credits / min | -### Usage-based Plan - How to obtain? +### Subscribe to a Usage-based Plan 1. Sign in to Travis CI with a [Version Control System of your choice](/user/onboarding/). 2. Navigate to the [Plans](https://app.travis-ci.com/account/plan) and have your billing and contact details filled in correctly. 3. Select an available Usage-based Plan or contact [Travis CI support](mailto:support@travis-ci.com) requesting a Usage-based Plan for larger options. -### Usage-based Plan - How it works +### How it works Usage-based pricing is a model using credits. It may include a user-license allowance and credit pool. Usage-based pricing features very high concurrent build jobs soft limits. In other words, users and organizations can run as many build jobs in Travis CI as they want simultaneously, meaning that all builds are executed as soon as possible. The final cost is flexible and closely related to the actual usage of the system, allowing you to downscale or upscale as per your needs. -All credit charges are deducted from a credit pool associated with an Usage-based plan assigned to Travis CI User or Organization, which is an 'owner' of a VCS repository enabled in Travis CI. +All credit charges are deducted from a credit pool associated with a Usage-based plan assigned to the Travis CI User or Organization, which is an 'owner' of a VCS repository enabled in Travis CI. -All unique user triggering build counting is tracked against an Usage-based plan assigned to Travis CI User or Organization, which is an 'owner' of a VCS repository enabled in Travis CI. +All unique user triggering build counting is tracked against a Usage-based plan assigned to the Travis CI User or Organization, which is an 'owner' of a VCS repository enabled in Travis CI. -> The Usage-based pricing model bills based on minutes used (via credits) and the number of unique users trigerring those builds (via user licenses). Users subscribe to a plan that allocates a pool of credits to be used towards build minutes and pricing for a specific number of user licenses. The credits are deducted from the user's credit balance as they are used in the Travis CI service. +> The Usage-based pricing model bills based on minutes used (via credits) and the number of unique users triggering those builds (via user licenses). Users subscribe to a plan that allocates a pool of credits to be used towards build minutes and pricing for a specific number of user licenses. The credits are deducted from the user's credit balance as they are used in the Travis CI service. Unique users triggering builds within a billing period will constitute a number of actual user licenses used out of allowed pool. If the user-license pool is exceeded by new unique user triggering build, credits for this extra usage will be deducted from available credit pool. In custom cases, instead of charge in credits, user licenses will be tracked within month and will be charged at the end of the billing period, according to the rates of their selected plan. @@ -154,17 +153,17 @@ Triggering builds is only possible if a user has a positive credit balance. To g ### Monthly Usage-based Plans -Monthly Usage-based plans are subscriptions, granting a specific credit pool each month and (optionally) user-license allowance included in the price. Once these allowances are depleted, the credits may be refilled via manual purchase of credits package or [auto-refilled](/user/billing-autorefill/) and spent on builds and additional user-licenes. +Monthly Usage-based plans are subscriptions, granting a specific credit pool each month and (optionally) user-license allowance included in the price. Once these allowances are depleted, the credits may be refilled via the manual purchase of a credits package or [auto-refilled](/user/billing-autorefill/) and spent on builds and additional user-licenes. Consumed user-license count is reset each month. If not stated or set otherwise, the Monthly Usage-based plan is renewed automatically. -#### Selecting a Plan +#### Select a Plan Subscribe to one of our monthly plans to get your credits and continue building. Once you select a plan, your credits and your bill will be available at the start of the following month. -#### Canceling my Monthly Subscription +#### Cancel a Monthly Subscription Users can cancel their current subscription anytime they like; simply use the Cancel Subscription button on the [Plan page](https://app.travis-ci.com/account/plan). Press the Cancel button to notify support of your desire to cancel your plan, and the Travis Support team will contact you soon with details regarding your cancellation. @@ -172,14 +171,14 @@ Once users request cancellation, the remaining credits will be retained until th ### Annual Usage-based Plans -Annual Usage-based plans are a subscription, granting specific credit pool each year and (optionally) user-license allowance per each month included in the price. Once these allowances are depleted, the credits may be refilled via manual purchase of credits package or [auto-refilled](/user/billing-autorefill/) and spent on builds and additional user-licenes. +Annual Usage-based plans are a subscription, granting specific credit pool each year and (optionally) user-license allowance per each month included in the price. Once these allowances are depleted, the credits may be refilled via the manual purchase of a credits package or [auto-refilled](/user/billing-autorefill/) and spent on builds and additional user-licenes. Consumed user-license count is reset each month during the annual plan duration. If not stated or set otherwise, the Annual Usage-based plan is renewed automatically. -#### Selecting a Plan +#### Select a Plan Travis CI Users/Organizations who subscribe to an Annual Plan are granted the subscription´s amount of credits over 12 months. From the moment of subscription, users can use the credits however they see best, without monthly allotments or limits. @@ -190,21 +189,21 @@ Users interested in Annual plans can select an annual plan on the [Plan page](ht ##### What if I ran out of credits before my annual contract elapses? -If users use up all their annual credits before the 12 months elapses, to get more credits, users either can keep auto-refilling their account or purchase additional credits allowance. If needed, please [contact Travis CI Customer Success](mailto:Customer.Success@travis-ci.com) to discuss details. +If users use up all their annual credits before the 12 months elapses, to get more credits, users can either keep auto-refilling their account or purchase additional credits allowance. If needed, please [contact Travis CI Customer Success](mailto:Customer.Success@travis-ci.com) to discuss details. -#### Canceling my Annual Subscription +#### Cancel an Annual Subscription Users on an Annual Plan must explicitly cancel their yearly subscription; otherwise, the plan renews automatically whenever the current cycle ends. Simply cancel your subscription using the Cancel Subscription button on the [Plan page](https://app.travis-ci.com/account/plan). Upon cancellation, users have the remaining time of the contract plus one extra month to use the remaining credits; otherwise, any remaining credits expire. Users cannot purchase new credits unless rejoining a monthly or annual subscription. Users have one year after canceling the subscription to view or save build data; after one year of cancellation, build data is removed from Travis CI. -### Changing Plans +### Switch Plans If you wish to switch from your monthly subscription to another plan with a different amount of credits, your new plan subscription will take effect at the start of the following month. And if you still run out of credits before the end of each month, try an annual plan, where you get an annual amount of credits for the price of 11 months. -### Usage - Credits +### Credits Usage Credits are purchased at your discretion as an 'addon' (if available in your plan) or via the Auto-Refill option. The Plan you are on determines what selection addons are available for you. Credit addons are paid in advance. Thus whenever you select or are assigned a Usage-based plan: @@ -285,8 +284,7 @@ The OSS credits are a separate pool of credits from regular credits, with separa Each new user who subscribes to the Free Trial Plan is automatically granted credits to use over a 14-day period. This one-time pool of credits is not renewable. This plan is meant to let you familiarize yourself with our usage-based plans as well as to try out other Travis CI features. - -### Usage - User Licenses +### User Licenses for Usage-based Plans User-licenses in Usage-based plans are consumed by [unique users triggering builds](#definitions) in the following order: @@ -298,21 +296,23 @@ The count of unique users triggering a build is tracked and reset monthly. Uniqu > If person A triggers a build, and person B triggers a build, the billing system will recognize 2 unique users. Now, if person A or B again triggers a build, the amount of unique users triggering remains 2 (assuming builds are triggered within the same month). Only when user C triggers a build within the same month the number of unique users triggering a build will be increased to 3. > -> By default, all users you've granted write rights to your repository are allowed to trigger a build. You may review Travis CI particular Repository page and manage which users are allowed to trigger the build in order to give you more control. +> By default, all users you've granted write rights to your repository are allowed to trigger a build. You may review Travis CI's particular Repository page and manage which users are allowed to trigger the build in order to give you more control. -#### Usage - User Licenses (Usage Plan with subscription) +### User Licenses for Usage-based Plan with subscription Usage-based plan with subscription charges you immediately upon build start for the new unique user triggering build within a month. Usage-based plans may have or may have not user-license allowance included in the price or available as a pool of user-licenses at a discounted credit cost. -##### Example 1: Credits, no user allowance included in price, user-license charge in credits, build with *n* build jobs +#### User License Example - Scenario 1 +This scenario is an example of a user with Credits. No user allowance is included in the price, and the user license is charged in credits. The user can build with *n* build jobs. > If a build is triggered, the system will check if this is a new, unique user-triggered build. If yes, a credit charge for the user license will be immediately deducted from the available credit pool upon the start of the build. > > The respective cost of build jobs execution in credits will be deducted from the available credit pool. -##### Example 2: Credits, user-license pool included in plan price, user-license charge in credits, build with *n* build jobs +#### User License Example - Scenario 2 +This scenario is an example of a user with Credits, a user-license pool included in the plan price, and the user license is charged in credits. The user can build with *n* build jobs. > If a build is triggered, the system will check if this is a new, unique user-triggering build. If yes, the system checks if consuming user-license exceeds user-license limit included: > @@ -321,26 +321,27 @@ Usage-based plans may have or may have not user-license allowance included in th > > The respective cost of build jobs execution in credits will be deducted from the available credit pool. -##### Example 3: Credits, pool of 3 discounted user-licenses included in the plan (e.g., *first 3 users for $XX*), user-license charge in credits, build with *n* build jobs +#### User License Example - Scenario 3 +This scenario is an example of a user with Credits, a pool of 3 discounted user licenses included in the plan (e.g., *first 3 users for $XX*), and the user license is charged in credits. The user can build with *n* build jobs. > Discounted user-license included in the plan means, in this example, that first three users cost e.g. 25K credits and after that each subsequent unique user triggering build costs $25k credits. > > If a build is triggered, the system will check if this is a new unique user triggering build. If yes, the system checks if the consuming user-license exceeds the pool of discounted user-license limit included in the plan: > > no - if this is 1st user out of first 3 discounted, a charge of e.g. 25k credits is deducted upon build start. If this is 2nd or 3rd unique user within a month, no credits are deducted from credit pool. -> yes - full user-license credits charge is deducted from available credit pool upon build start. +> yes - full user-license credits charge is deducted from the available credit pool upon build start. > > The respective cost of build jobs execution in credits will be deducted from the available credit pool. - -#### Usage - User Licenses (Usage Plan w/o subscription) +### User Licenses for Usage-based Plans without Subscription Usage-based plan w/o subscription charges you at the end of each month for the number of users who triggered the builds during this month. With every build started, Travis CI keeps track of how many unique users triggered a build within a current billing period. At the end of the month, the total amount is used to calculate the user license charge. -##### Example 1: Credits, user-licenses counted within a month and charged at the end of the period, build with *n* build jobs +#### User License without Subscription Example - Scenario 1 +This scenario is an example of a user with Credits, user licenses counted within a month and charged at the end of the period.The user can build with *n* build jobs. > If a build is triggered, the system will check if this is a new unique user triggering build and if any potential included user-license allowance are exceeded: > @@ -414,7 +415,7 @@ See [credit costs associated with usage-based plan](#credit-costs-associated-wit > * dist: [focal] # jammy to be added later, xenial EOL, bionic EOL. -## Getting Help +## Contact Support If you have any questions or issues with the new VCS, please see our [Billing FAQ](/user/billing-faq/) or email [support@travis-ci.com](mailto:support@travis-ci.com) for help. diff --git a/user/browserstack.md b/user/browserstack.md index 02b05d2f20b..b389caf74e4 100644 --- a/user/browserstack.md +++ b/user/browserstack.md @@ -1,5 +1,5 @@ --- -title: Using BrowserStack with Travis CI +title: Use BrowserStack with Travis CI layout: en --- @@ -11,7 +11,7 @@ like Selenium, Karma and others. This add-on automatically sets up [BrowserStack Local][local-testing] which allows you to test your private servers alongside public URLs, using the BrowserStack cloud. To do this it uses the [BrowserStackLocal binary][local-binary] for your build platform. [BrowserStack Local][local-testing] establishes a secure connection between your Travis build container/VM -and BrowserStack servers. Local Testing also has support for firewalls, proxies and Active Directory. +and BrowserStack servers. Local testing also supports firewalls, proxies, and Active Directory. Once the secure connection is setup, all URLs work out of the box, including your webserver, local folders, as well as URLs with HTTPS. @@ -31,7 +31,7 @@ URLs with HTTPS. [browserstack-android-app-travis]: https://github.com/browserstack/browserstack-android-sample-app/blob/master/.travis.yml -## Setting up BrowserStack +## Setup BrowserStack Please sign up for a BrowserStack account if you haven't already; it's [free][open-source-browserstack] for Open Source projects. Once you have signed up get your username and access key from @@ -79,7 +79,7 @@ The add-on will **ALWAYS** create a Local Identifier for each local connection t testing framework, the Local Identifier must be added to the Selenium capabilities. The Local Identifier is exposed as an environment variable `BROWSERSTACK_LOCAL_IDENTIFIER`. You can use it to set -the Selenium capability. See the following example which uses Ruby's [selenium-webdriver][browserstack-ruby-bindings]: +the Selenium capability. See the following example, which uses Ruby's [selenium-webdriver][browserstack-ruby-bindings]: ```ruby require 'rubygems' @@ -89,7 +89,7 @@ require 'selenium-webdriver' caps = Selenium::WebDriver::Remote::Capabilities.new caps['browserstack.local'] = 'true' caps['browserstack.localIdentifier'] = ENV['BROWSERSTACK_LOCAL_IDENTIFIER'] -# Add other capabilities like browser name, version and os name, version +# Add other capabilities like browser name, version, and os name, version ... driver = Selenium::WebDriver.for(:remote, @@ -123,14 +123,14 @@ Once the app is uploaded to the BrowserStack servers the resulting app id will b caps['app'] = ENV['BROWSERSTACK_APP_ID'] ``` -Checkout the BrowserStack Android Sample App [.travis.yml][browserstack-android-app-travis] file. +Check out the BrowserStack Android Sample App [.travis.yml][browserstack-android-app-travis] file. ## Additional Options ### Proxy -Local testing also allows you to set the proxy host, port, username and password +Local testing also allows you to set the proxy host, port, username, and password through which all urls will be resolved: ```yaml @@ -150,7 +150,7 @@ addons: Some other options that are supported by the add on are, -- **forcelocal**: If this is set to true then all network traffic will be resolved via the Travis CI container/VM. +- **forcelocal**: If this is set to true, then all network traffic will be resolved via the Travis CI container/VM. - **only**: restricts Local testing access to the specified local servers and/or folders. Sample usage, diff --git a/user/build-config-imports.md b/user/build-config-imports.md index f2844205959..cd0d4f91a91 100644 --- a/user/build-config-imports.md +++ b/user/build-config-imports.md @@ -1,5 +1,5 @@ --- -title: Importing Shared Build Configuration +title: Import Shared Build Configuration layout: en --- @@ -7,7 +7,7 @@ layout: en The main source of configuration for your build is the `.travis.yml` file stored in your repository. You can import shared configuration snippets into your `.travis.yml` or [API build request payload](https://docs.travis-ci.com/user/triggering-builds/), -to update your build configuration in multiple repositories making only one +to update your build configuration in multiple repositories, making only one change. Imported configs can themselves include other configs, making this feature very @@ -18,16 +18,16 @@ configuration snippets in total. > BETA The feature Build Config Imports is currently in beta. Please leave feedback on the [Community forum](https://travis-ci.community/c/early-releases). {: .beta } -## Opt-in +## The opt-in option -In order for this feature to be active you have to enable the feature +In order for this feature to be active, you have to enable the feature [Build Config Validation](/user/build-config-validation/) which will be rolled out to all users in the near future. You can enable Build Config Validation in your repository's settings, or by adding `version: ~> 1.0` to your `.travis.yml` file. -## Example +## Import Shared Build Configuration Example Instead of specifying which versions of Ruby to test against in multiple files across many repositories, you can define them in a shared snippet: @@ -102,7 +102,7 @@ present in the importing and an imported config, or in multiple imported configs You can customize this by specifying the merge mode used for each import. See below for more information on [merge modes](#merge-modes). -## Importing configs from the same repository +## Import configs from the same repository When importing configurations stored in the same repository as your `travis.yml`, you can omit the `
-### Encrypting your OAUTH tokens
+## Encrypt OAUTH tokens
It is recommended that you encrypt both OAUTH tokens using the Travis CI command line client by removing them from your `travis.yml` above and running the following commands:
diff --git a/user/deployment/npm.md b/user/deployment/npm.md
index d1877604f52..ac33a8b92c8 100644
--- a/user/deployment/npm.md
+++ b/user/deployment/npm.md
@@ -36,7 +36,7 @@ $ travis setup npm
Keep in mind that the above command has to run in your project directory, so
it can modify the `.travis.yml` for you.
-## NPM auth token
+## npm Auth token
Your NPM Auth Token can be obtained by:
@@ -91,7 +91,7 @@ deploy:
Builds triggered from Pull Requests will never trigger a release.
-## Releasing build artifacts
+## Release build artifacts
After your tests ran and before the release, Travis CI will clean up any additional files and changes you made.
@@ -111,7 +111,7 @@ reported when multiple attempts are made.
We recommend deploying from only one job with
[Conditional Releases with `on:`](/user/deployment/#conditional-releases-with-on).
-## Tagging releases
+## Tag releases
You can automatically add [npm distribution tags](https://docs.npmjs.com/getting-started/using-tags) with the `tag` option:
@@ -122,7 +122,7 @@ deploy:
```
{: data-file=".travis.yml"}
-## Note on `.gitignore`
+## The .gitignore method
Notice that `npm` deployment honors `.gitignore` if `.npmignore` does not exist.
This means that if your build creates artifacts in places listed in `.gitignore`,
@@ -136,7 +136,7 @@ If your `.gitignore` file matches something that your build creates, use
its content, or create (potentially empty) `.npmignore` file
to override it.
-## Running commands before and after deploy
+## Run Commands Before or After Deploy
Sometimes you want to run commands before or after deploying. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually deploying.
@@ -150,9 +150,9 @@ after_deploy:
```
{: data-file=".travis.yml"}
-## Troubleshooting "npm ERR! You need a paid account to perform this action."
+## Troubleshoot npm Error
-npm assumes that [scoped packages](https://docs.npmjs.com/misc/scope) are
+If you get the error message "npm ERR! You need a paid account to perform this action." is because npm assumes that [scoped packages](https://docs.npmjs.com/misc/scope) are
private by default. You can explicitly tell npm your package is a public package
and avoid this error by adding the following to your `package.json` file:
diff --git a/user/deployment/openshift.md b/user/deployment/openshift.md
index f46aedf79c6..b7596be23d6 100644
--- a/user/deployment/openshift.md
+++ b/user/deployment/openshift.md
@@ -30,7 +30,7 @@ Keep in mind that the above command has to run in your project directory, so it
To provide the best service possible, Travis CI has teamed up with OpenShift as a [partner](https://www.openshift.com/partners) and there is an official [Travis CI QuickStart](https://hub.openshift.com/quickstarts/26-travis-ci) to get you going.
-### Application to deploy
+## Deploy to Applications
By default, we will try to deploy to an application by the same name as the repository. For example, if you deploy an application from the GitHub repository [travis-ci/travis-chat](https://github.com/travis-ci/travis-chat) without explicitly specify the name of the application, Travis CI will try to deploy to an OpenShift app named *travis-chat*.
@@ -71,7 +71,7 @@ deploy:
```
{: data-file=".travis.yml"}
-### Branch to deploy from
+## Deploy Specific Branches
If you have branch specific options, as [shown above](#application-to-deploy), Travis CI will automatically figure out which branches to deploy from. Otherwise, it will only deploy from your **master** branch.
@@ -98,7 +98,7 @@ deploy:
Builds triggered from Pull Requests will never trigger a deploy.
-### Deploying build artifacts
+## Deploy build artifacts
After your tests ran and before the deploy, Travis CI will clean up any additional files and changes you made.
@@ -117,7 +117,7 @@ deploy:
You can deploy only when certain conditions are met.
See [Conditional Releases with `on:`](/user/deployment/#conditional-releases-with-on).
-### Note on `.gitignore`
+### The .gitignore method
As this deployment strategy relies on `git`, be mindful that the deployment will
honor `.gitignore`.
@@ -126,7 +126,7 @@ If your `.gitignore` file matches something that your build creates, use
[`before_deploy`](#running-commands-before-and-after-deploy) to change
its content.
-### Running commands before and after deploy
+## Run Commands Before or After Deploy
Sometimes you want to run commands before or after deploying. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually deploying.
@@ -140,7 +140,7 @@ after_deploy:
```
{: data-file=".travis.yml"}
-### Deployment branch
+### Deployment Branch
OpenShift can be configured to deploy from a branch different from the default `master` via `rhc app-configure --deployment-branch mybranch`.
diff --git a/user/deployment/opsworks.md b/user/deployment/opsworks.md
index e326cbcdebc..e0df10a8307 100644
--- a/user/deployment/opsworks.md
+++ b/user/deployment/opsworks.md
@@ -35,7 +35,7 @@ travis setup opsworks
Keep in mind that the above command has to run in your project directory, so it can modify the `.travis.yml` for you. Note that the `region` isn't generated by running `travis setup opsworks`.
-### Migrate the Database
+## Migrate the Database
If you want to migrate your rails database on travis to AWS OpsWorks, add the `migrate` option to your `.travis.yml`.
@@ -49,7 +49,7 @@ deploy:
```
{: data-file=".travis.yml"}
-### Branch to deploy from
+## Deployment Branch
By default, Travis CI will only deploy from your **master** branch.
@@ -80,7 +80,7 @@ deploy:
Builds triggered from Pull Requests will never trigger a deploy.
-### Deploying build artifacts
+## Deploy build artifacts
After your tests run and before the deploy stage, Travis CI will clean up any additional files and changes you made.
@@ -96,7 +96,7 @@ deploy:
```
{: data-file=".travis.yml"}
-### Waiting for Deployments
+## Waiting for Deployments
By default, the build will continue immediately after triggering an OpsWorks
deploy. To wait for the deploy to complete, use the **wait-until-deployed**
@@ -115,9 +115,9 @@ deploy:
Travis CI will wait up to 10 minutes for the deploy to complete, and log
whether it succeeded.
-### Updating App Settings after successful Deployments
+## Update App Settings
-By default the deploy from Travis CI triggers a deployment on OpsWorks but does not touch any other configuration. To also update the revision in App Settings use the **update-app-on-success** option. In addition you have to set the **wait-until-deployed** option:
+By default, the deployment from Travis CI triggers a deployment on OpsWorks but does not touch any other configuration. To also update the revision in App Settings use the **update-app-on-success** option. In addition, you have to set the **wait-until-deployed** option:
```yaml
deploy:
@@ -137,9 +137,9 @@ Travis CI will wait until the deployment returns successful and only then update
You can deploy only when certain conditions are met.
See [Conditional Releases with `on:`](/user/deployment/#conditional-releases-with-on).
-### Running commands before and after deploy
+### Run Commands Before or After Deploy
-Sometimes you want to run commands before or after deploying. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually deploying.
+Sometimes, you want to run commands before or after deploying. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually deploying.
```yaml
before_deploy: "echo 'ready?'"
diff --git a/user/deployment/packagecloud.md b/user/deployment/packagecloud.md
index f73274aeacc..24f12a47764 100644
--- a/user/deployment/packagecloud.md
+++ b/user/deployment/packagecloud.md
@@ -40,7 +40,7 @@ travis setup packagecloud
Keep in mind that the above command has to run in your project directory, so it can modify the `.travis.yml` for you.
-### Branch to release from
+### Release Branch
You can explicitly specify the branch to release from with the **on** option:
@@ -68,7 +68,7 @@ By default, Travis CI will only release from the **master** branch.
Builds triggered from Pull Requests will never trigger a release.
-### Releasing build artifacts
+### Release build artifacts
After your tests ran and before the release, Travis CI will clean up any additional files and changes you made.
@@ -105,17 +105,17 @@ deploy:
```
{: data-file=".travis.yml"}
-### A note about Debian source packages
+### Debian Source Packages
If the packagecloud provider finds any `.dsc` files, it will scan it and try to locate it's contents within
the `local-dir` directory. Ensure the source package and it's contents are output to the same directory for it to work.
-### Conditional releases
+## Conditional Releases
You can deploy only when certain conditions are met.
See [Conditional Releases with `on:`](/user/deployment/#conditional-releases-with-on).
-### Running commands before and after release
+## Run Commands Before or After Release
Sometimes you want to run commands before or after releasing a package. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually pushing a release.
diff --git a/user/deployment/pages.md b/user/deployment/pages.md
index eec774412d7..49d32f253db 100644
--- a/user/deployment/pages.md
+++ b/user/deployment/pages.md
@@ -31,7 +31,7 @@ deploy:
> all the files created during the build, which will probably delete what you are
> trying to upload.
-## Setting the GitHub token
+## Set the GitHub token
You'll need to generate a [personal access
token](https://help.github.com/articles/creating-an-access-token-for-command-line-use/)
@@ -42,11 +42,11 @@ settings](/user/environment-variables/#defining-variables-in-repository-settings
or via [encrypted variables in
`.travis.yml`](/user/environment-variables/#defining-encrypted-variables-in-travisyml).
-## Further configuration
+## Further configurations
-* `local_dir`: Directory to push to GitHub Pages, defaults to current directory.
+* `local_dir`: Directory to push to GitHub Pages, defaults to the current directory.
Can be specified as an absolute path or a relative path from the current directory.
-* `repo`: Repo slug, defaults to current repo. **Note:** The slug consists of username and repo name and is formatted like `user/repo-name`.
+* `repo`: Repo slug, defaults to the current repo. **Note:** The slug consists of username and repo name and is formatted like `user/repo-name`.
* `target_branch`: Branch to (force, see: `keep_history`) push `local_dir`
contents to, defaults to `gh-pages`.
* `keep_history`: Optional, create incremental commit instead of doing push
diff --git a/user/deployment/puppetforge.md b/user/deployment/puppetforge.md
index a841586dbe1..31e5122ed3b 100644
--- a/user/deployment/puppetforge.md
+++ b/user/deployment/puppetforge.md
@@ -22,7 +22,7 @@ deploy:
```
{: data-file=".travis.yml"}
-## Deploying to a custom forge
+## Deploy to a Custom Forge
To deploy to your own hosted Forge instance by adding it in the `url` key:
@@ -38,9 +38,9 @@ deploy:
```
{: data-file=".travis.yml"}
-## Running commands before and after deploy
+## Run Commands Before or After Deploy
-Sometimes you want to run commands before or after deploying. You can use
+Sometimes, you want to run commands before or after deploying. You can use
the `before_deploy` and `after_deploy` stages for this. These will only be
triggered if Travis CI is actually deploying.
diff --git a/user/deployment/pypi.md b/user/deployment/pypi.md
index b2abee30812..04a9cee7b69 100644
--- a/user/deployment/pypi.md
+++ b/user/deployment/pypi.md
@@ -1,5 +1,5 @@
---
-title: PyPI deployment
+title: PyPI Deployment
layout: en
deploy: v1
@@ -46,7 +46,7 @@ It is also possible, but not recommended, to use PyPI user and password, instead
> Note that if your PyPI password contains [special characters](/user/encryption-keys/#note-on-escaping-certain-symbols) you need to escape them before encrypting your password. Some people have [reported difficulties](https://github.com/travis-ci/dpl/issues/377) connecting to PyPI with passwords containing anything except alphanumeric characters.
-## Deploying tags
+## Deploy on Tags
Most likely, you would only want to deploy to PyPI when a new version of your
package is cut. To do this, you can tell Travis CI to only deploy on tagged
@@ -64,7 +64,7 @@ deploy:
If you tag a commit locally, remember to run `git push --tags` to ensure that your tags are uploaded to GitHub.
-## Deploying specific branches
+## Deploy Specific Branches
You can explicitly specify the branch to release from with the **on** option:
@@ -94,7 +94,7 @@ By default, Travis CI will only release from the **master** branch.
Builds triggered from Pull Requests will never trigger a release.
-## Releasing to a self hosted PyPI
+## Release to a self-hosted PyPI
To release to a different PyPI index:
@@ -107,7 +107,7 @@ deploy:
```
{: data-file=".travis.yml"}
-## Uploading different distributions
+## Upload different distributions
By default, only a source distribution ('sdist') will be uploaded to PyPI.
If you would like to upload different distributions, specify them using the `distributions` option, like this:
@@ -140,7 +140,7 @@ deploy:
skip_existing: true
```
-## Releasing build artifacts
+## Release build artifacts
After your tests ran and before the release, Travis CI will clean up any additional files and changes you made.
@@ -154,14 +154,14 @@ deploy:
skip_cleanup: true
```
-## Conditional releases
+## Conditional Releases
You can deploy only when certain conditions are met.
See [Conditional Releases with `on:`](/user/deployment/#conditional-releases-with-on).
-## Running commands before and after release
+## Run Commands Before or After Release
-Sometimes you want to run commands before or after releasing a package. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually pushing a release.
+Sometimes, you want to run commands before or after releasing a package. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually pushing a release.
```
before_deploy: "echo 'ready?'"
diff --git a/user/deployment/releases.md b/user/deployment/releases.md
index 803192341d3..32fb244848c 100644
--- a/user/deployment/releases.md
+++ b/user/deployment/releases.md
@@ -28,7 +28,7 @@ This configuration will use the "GITHUB OAUTH TOKEN" to upload "FILE TO UPLOAD"
GitHub Releases works with git tags, so it is important that
you understand how tags affect GitHub Releases.
-## Deploying only on tagged builds
+## Deploy on tagged builds
With [`on.tags: true`](/user/deployment/#conditional-releases-with-on),
your Releases deployment will trigger if and only if the build is a tagged
@@ -42,8 +42,9 @@ Regular releases require tags.
If you set `on.tags: true` (as the initial example in this document), this
requirement is met.
-## Draft releases with `draft: true`
-With
+## Draft releases
+
+For Draft releases using `draft: true`, use the following code:
```yaml
deploy:
@@ -59,9 +60,9 @@ the resultant deployment is a draft Release that only repository collaborators
can see.
This gives you an opportunity to examine and edit the draft release.
-## Setting the tag at deployment time
+## Set the tag at deployment
-GitHub Releases needs the present commit to be tagged at the deployment time.
+GitHub Releases need the present commit to be tagged at the deployment time.
If you set `on.tags: true`, the commit is guaranteed to have a tag.
Depending on the workflow, however, this is not desirable.
@@ -86,7 +87,7 @@ For example:
```
{: data-file=".travis.yml"}
-### When tag is not set at deployment time
+### Tag not set during deployment
If the tag is still not set at the time of deployment, the deployment
provider attempts to match the current commit with a tag from remote,
@@ -110,7 +111,7 @@ other means; for instance, by
If you need to overwrite existing files, add `overwrite: true` to the `deploy` section of your `.travis.yml`.
-## Using Travis CI client to populate initial deployment configuration
+## Populate the initial deployment configuration with Travis CI
You can also use the [Travis CI command line client](https://github.com/travis-ci/travis.rb#installation) to configure your `.travis.yml`:
@@ -124,7 +125,7 @@ Or, if you're using a private repository or the GitHub Apps integration:
travis setup releases --com
```
-## Authenticating with an OAuth token
+## OAuth token Authentication
The recommended way to authenticate is to use a GitHub OAuth token. Instead of setting it up manually, it is highly recommended to use `travis setup releases`, which automatically creates and encrypts a GitHub OAuth token with the correct scopes.
@@ -147,9 +148,9 @@ deploy:
```
{: data-file=".travis.yml"}
-**Warning:** the `public_repo` and `repo` scopes for GitHub OAuth tokens grant write access to all of a user's (public) repositories. For security, it's ideal for `api_key` to have the write access limited to only repositories where Travis deploys to GitHub releases. The suggested workaround is to create a [machine user](https://developer.github.com/v3/guides/managing-deploy-keys/#machine-users) — a dummy GitHub account that is granted write access on a per repository basis.
+**Warning:** the `public_repo` and `repo` scopes for GitHub OAuth tokens grant write access to all of a user's (public) repositories. For security, it's ideal for `api_key` to have the write access limited to only repositories where Travis deploys to GitHub releases. The suggested workaround is to create a [machine user](https://developer.github.com/v3/guides/managing-deploy-keys/#machine-users) — a dummy GitHub account that is granted write access on a per-repository basis.
-## Authentication with a Username and Password
+## Username and Password Authentication
You can also authenticate with your GitHub username and password using the `user` and `password` options. This is not recommended as it allows full access to your GitHub account but is simplest to setup. It is recommended to encrypt your password using `travis encrypt "GITHUB PASSWORD" --add deploy.password`. This example authenticates using a username and password.
@@ -165,7 +166,7 @@ deploy:
```
{: data-file=".travis.yml"}
-## Deploying to GitHub Enterprise
+## Deploy to GitHub Enterprise
If you wish to upload assets to a GitHub Enterprise repository, you must override the `$OCTOKIT_API_ENDPOINT` environment variable with your GitHub Enterprise API endpoint:
@@ -182,9 +183,9 @@ env:
```
{: data-file=".travis.yml"}
-## Uploading Multiple Files
+## Upload Multiple Files
-You can upload multiple files using yml array notation. This example uploads two files.
+You can upload multiple files using the yml array notation. This example uploads two files.
```yaml
deploy:
@@ -236,7 +237,7 @@ Please note that all paths in `file` are relative to the current working directo
You can deploy only when certain conditions are met.
See [Conditional Releases with `on:`](/user/deployment/#conditional-releases-with-on).
-## Running commands before or after release
+## Run Commands Before or After Release
Sometimes you want to run commands before or after releasing a gem. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually pushing a release.
@@ -265,7 +266,7 @@ and [#update_release](https://octokit.github.io/octokit.rb/Octokit/Client/Releas
Note that formatting in `body` is [not preserved](https://github.com/travis-ci/dpl/issues/155).
-## Troubleshooting Git Submodules
+## Troubleshoot Git Submodules
-GitHub Releases executes a number of git commands during deployment. For this reason, it is important that the working directory is set to the one for which the release will be created, which generally isn't a problem, but if you clone another repository during the build or use submodules, it is worth double checking.
+GitHub Releases executes a number of git commands during deployment. For this reason, it is important that the working directory is set to the one for which the release will be created, which generally isn't a problem, but if you clone another repository during the build or use submodules, it is worth double-checking.
diff --git a/user/deployment/rubygems.md b/user/deployment/rubygems.md
index c6f20d8f88e..faf54979f7b 100644
--- a/user/deployment/rubygems.md
+++ b/user/deployment/rubygems.md
@@ -48,7 +48,7 @@ travis setup rubygems
Keep in mind that the above command has to run in your project directory, so it can modify the `.travis.yml` for you.
-## Pre-releasing
+## Pre-release
Instead of releasing for each new version of your gem, you can have Travis CI create a [prerelease](http://guides.rubygems.org/patterns#prerelease-gems) for each build.
@@ -62,7 +62,7 @@ s.version = "#{s.version}-alpha-#{ENV['TRAVIS_BUILD_NUMBER']}" if ENV['TRAVIS']
If your gem's current version is 1.0.0, then Travis CI will create a prerelease with the version 1.0.0-alpha-20, where `20` is the build number.
-### Gem to release
+### Gem Release
By default, we will try to release a gem by the same name as the repository. For example, if you release a gem from the GitHub repository [travis-ci/travis-chat](https://github.com/travis-ci/travis-chat) without explicitly specify the name of the application, Travis CI will try to release the gem named *travis-chat*.
@@ -102,9 +102,9 @@ deploy:
```
{: data-file=".travis.yml"}
-### Gemspec to use
+### Use Gemspec
-If you like, you can specify can alternate option with the `gemspec` option:
+If you like, you can specify an alternate option with the `gemspec` option:
```yaml
deploy:
@@ -114,9 +114,9 @@ deploy:
```
{: data-file=".travis.yml"}
-### Branch to release from
+### Release Branch
-If you have branch specific options, as [shown above](#gem-to-release), Travis CI will automatically figure out which branches to release from. Otherwise, it will only release from your **master** branch.
+If you have branch-specific options, as [shown above](#gem-to-release), Travis CI will automatically figure out which branches to release from. Otherwise, it will only be released from your **master** branch.
You can also explicitly specify the branch to release from with the **on** option:
@@ -142,9 +142,9 @@ deploy:
Builds triggered from Pull Requests will never trigger a release.
-### Releasing build artifacts
+### Release build artifacts
-After your tests ran and before the release, Travis CI will clean up any additional files and changes you made.
+After your tests run and before the release, Travis CI will clean up any additional files and changes you made.
Maybe that is not what you want, as you might generate some artifacts that are supposed to be released, too. There is now an option to skip the clean up:
@@ -156,20 +156,20 @@ deploy:
```
{: data-file=".travis.yml"}
-### Conditional releases
+### Conditional Releases
You can deploy only when certain conditions are met.
See [Conditional Releases with `on:`](/user/deployment/#conditional-releases-with-on).
-### Gem must be registered beforehand
+### Register Gem
Note that the gem you upload must be registered beforehand.
If the gem does not exist on the host to which it is uploaded, deployment will fail.
See [this GitHub issue](https://github.com/travis-ci/dpl/issues/574) for details.
-### Running commands before and after release
+### Run Commands Before or After Release
-Sometimes you want to run commands before or after releasing a gem. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually pushing a release.
+Sometimes, you want to run commands before or after releasing a gem. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually pushing a release.
```yaml
before_deploy: "echo 'ready?'"
diff --git a/user/deployment/s3.md b/user/deployment/s3.md
index 3131eb80bf2..9659632a602 100644
--- a/user/deployment/s3.md
+++ b/user/deployment/s3.md
@@ -47,9 +47,9 @@ $ travis setup s3
Keep in mind that the above command has to run in your project directory, so it can modify the `.travis.yml` for you.
-## S3 ACL via option
+## Set S3 ACL
-You can set the acl of your uploaded files via the `acl` option like this:
+You can set the ACL of your uploaded files via the `acl` option like this:
```yaml
deploy:
@@ -93,7 +93,7 @@ An example policy might look like this:
Be sure to set up the principal and resources according to your needs.
-## S3 ACL with bucket policy
+## Set S3 ACL with Bucket Policy
Another way to set ACL for your artifacts is via a S3 bucket policy.
@@ -118,7 +118,7 @@ This bucket policy grants the public read permission:
## S3 bucket regions
-By default the region `us-east-1` is used when deploying to S3. If your bucket is hosted in a different region, deploying using the default region results in the following error.
+By default, the region `us-east-1` is used when deploying to S3. If your bucket is hosted in a different region, deploying using the default region results in the following error.
```
The bucket you are attempting to access must be addressed using the specified endpoint.
@@ -138,7 +138,7 @@ deploy:
```
{: data-file=".travis.yml"}
-## Deploy One or More files Matching a Pattern
+## Deploy Files Matching a Pattern
To upload files matching a specific pattern, you can add the pattern via the `glob` directive as illustrated in the following example:
@@ -185,7 +185,7 @@ deploy:
```
{: data-file=".travis.yml"}
-## Deploy to a S3 hosted website:
+## Deploy to a S3 hosted Website
To upload to a S3 hosted website, to use this template to upload to your website.
@@ -202,7 +202,7 @@ deploy:
Remember that you need to set the bucket to have an ACL of `public` for anybody to be able to see your website.
-## Deploy to Multiple Buckets:
+## Deploy to Multiple Buckets
If you want to upload to multiple buckets, you can do this:
@@ -226,7 +226,7 @@ deploy:
You can deploy only when certain conditions are met.
See [Conditional Releases with `on:`](/user/deployment/#conditional-releases-with-on).
-## Running commands before and after release
+## Run Commands Before or After Release
Sometimes you want to run commands before or after releasing a gem. You can use the `before_deploy` and `after_deploy` stages for this. These will only be triggered if Travis CI is actually pushing a release.
@@ -240,7 +240,7 @@ Sometimes you want to run commands before or after releasing a gem. You can use
```
{: data-file=".travis.yml"}
-## Setting `Content-Encoding` header
+## Set the Content-Encoding header
S3 uploads can optionally set HTTP header `Content-Encoding`.
This header allows files to be sent compressed while retaining file extensions and
@@ -259,7 +259,7 @@ deploy:
If the file is compressed with `gzip` or `compress`, it will be uploaded with
the appropriate header.
-## Setting `charset` on `Content-Type` header
+## Set charset on Content-Type Header
S3 can take a content-type header. Normally this doesn't include a character set as well. If you would like to add a character set, add the `default_text_charset` option with what you want it to be. For example:
@@ -301,7 +301,7 @@ deploy:
{: data-file=".travis.yml"}
-## Using S3-compatible Object Storage
+## S3-compatible Object Storage
You can use an S3-compatible object storage such as Digital Ocean Spaces
by setting the `endpoint` key.
diff --git a/user/deployment/scalingo.md b/user/deployment/scalingo.md
index 74b86db039d..dbfd0a8df26 100644
--- a/user/deployment/scalingo.md
+++ b/user/deployment/scalingo.md
@@ -1,5 +1,5 @@
---
-title: Scalingo deployment
+title: Scalingo Deployment
layout: en
deploy: v1
@@ -18,7 +18,7 @@ Chose one of two ways to connect to your Scalingo account:
-## Connecting using a username and password
+## Connect with Username and Password
Add your Scalingo username and your [encrypted](/user/encryption-keys/#usage)
Scalingo password to your `.travis.yml`:
@@ -32,7 +32,7 @@ deploy:
```
{: data-file=".travis.yml"}
-## Connecting using an api key
+## Connect with an API key
Add your [encrypted](/user/encryption-keys/#usage)
Scalingo `api_key` to your `.travis.yml`:
@@ -45,7 +45,7 @@ deploy:
```
{: data-file=".travis.yml"}
-## Optional settings
+## Optional Settings
* `remote`: Remote url or git remote name of your git repository. The default
remote name is "scalingo".
@@ -55,7 +55,7 @@ deploy:
remote. Specifying the `app` will add a remote to your local repository: `git
remote add sudo is not available for builds that are running on the
-## Using the [Chrome addon](/user/chrome) in the headless mode
+## Headless mode with the Chrome addon
Starting with version 57 for Linux Trusty and version 59 on macOS, Google Chrome can be used in "headless"
-mode, which is suitable for driving browser-based tests using Selenium and other tools.
+mode with the [Chrome addon](/user/chrome), which is suitable for driving browser-based tests using Selenium and other tools.
> As of 2017-05-02, this means `stable` or `beta` on Linux builds, and `beta` on macOS builds.
@@ -181,14 +179,14 @@ before_install:
```
{: data-file=".travis.yml"}
-#### Documentation
+### More Documentation
* [Headless Chromium documentation](https://chromium.googlesource.com/chromium/src/+/lkgr/headless/README.md)
* [Getting Started with Headless Chrome](https://developers.google.com/web/updates/2017/04/headless-chrome)
-## Using the [Firefox addon](/user/firefox) in headless mode
+## Headless mode with the Firefox addon
-Starting with version 56, Firefox can be used in "headless" mode, which is
+Starting with version 56, Firefox can be used in "headless" mode with the [Firefox addon](/user/firefox), which is
suitable for driving browser-based tests using Selenium and other tools.
Headless mode can be enabled using the `MOZ_HEADLESS`
[environment variable](/user/environment-variables/):
@@ -215,12 +213,12 @@ options.add_argument('-headless')
firefox = Firefox(firefox_options=options)
```
-#### Documentation
+### More Documentation
* [Using headless mode](https://developer.mozilla.org/en-US/Firefox/Headless_mode#Using_headless_mode)
* [Automated testing with headless mode](https://developer.mozilla.org/en-US/Firefox/Headless_mode#Automated_testing_with_headless_mode)
-## Using PhantomJS
+## Use PhantomJS
[PhantomJS](http://phantomjs.org/) is a headless WebKit with JavaScript API. It is an optimal solution for fast headless testing, site scraping, pages capture, SVG renderer, network monitoring and many other use cases.
@@ -237,12 +235,14 @@ If you need a web server to serve the tests, see the previous section.
## Examples
+The following are a series of examples.
+
### Real World Projects
- [Ember.js](https://github.com/emberjs/ember-mocha/blob/master/.travis.yml) (starts web server programmatically)
- [Sproutcore](https://github.com/sproutcore/sproutcore/blob/master/.travis.yml) (starts web server with *before_script*)
-### Ruby
+### Ruby Example
#### RSpec, Jasmine, Cucumber
diff --git a/user/hashicorp-vault-integration.md b/user/hashicorp-vault-integration.md
index 39c1edba245..86815deff1e 100644
--- a/user/hashicorp-vault-integration.md
+++ b/user/hashicorp-vault-integration.md
@@ -63,9 +63,9 @@ vault:
See usage examples below:
-#### Single `.travis.yml` file
+### Single .travis.yml file
-**As a data accessible for all jobs in the build definition:**
+**As data accessible for all jobs in the build definition:**
```yaml
os: linux
@@ -85,7 +85,7 @@ script:
```
{: data-file=".travis.yml"}
-**As a datat accessible only within one of many jobs:**
+**As data accessible only within one of many jobs:**
```yaml
os: linux
@@ -109,7 +109,7 @@ jobs:
```
{: data-file=".travis.yml"}
-#### Imported shared build configuration
+### Import shared build configuration
```yaml
vault:
diff --git a/user/hostname.md b/user/hostname.md
index b820fc413ca..f496d831461 100644
--- a/user/hostname.md
+++ b/user/hostname.md
@@ -13,4 +13,4 @@ addons:
This is useful when your processes require a short hostname.
For example, [OpenJDK 6 and OpenJDK 7 processes will encounter
-buffer overflows when the host name is too long](https://github.com/travis-ci/travis-ci/issues/5227).
+buffer overflows when the hostname is too long](https://github.com/travis-ci/travis-ci/issues/5227).
diff --git a/user/ibm-power.md b/user/ibm-power.md
index 5dcbb6cea9c..227e6ecf893 100644
--- a/user/ibm-power.md
+++ b/user/ibm-power.md
@@ -13,11 +13,11 @@ layout: en
_TODO_
-## How do I test on IBM POWER?
+## Test on IBM POWER
_TODO_
-## What features are available on IBM POWER?
+## IBM POWER Features
## Examples
diff --git a/user/installing-dependencies.md b/user/installing-dependencies.md
index e8e9e409554..312efb778eb 100644
--- a/user/installing-dependencies.md
+++ b/user/installing-dependencies.md
@@ -8,7 +8,7 @@ redirect_from:
-## Installing Packages on Standard Infrastructure
+## Install Packages on Standard Infrastructure
To install Ubuntu packages that are not included in the standard [precise](/user/reference/precise/), [trusty](/user/reference/trusty/), [xenial](/user/reference/xenial/), or [bionic](/user/reference/bionic/) distribution, use apt-get in the `before_install` step of your `.travis.yml`:
@@ -42,7 +42,7 @@ addons:
>
> Use the `-y` parameter with apt-get to assume yes to all queries by the apt tools.
-### Installing Packages from a custom APT repository
+### Install Packages from a custom APT Repository
For some packages, you may find an existing repository, which isn't yet set up on our build environment by default. You can easily add custom repositories and Launchpad PPAs as part of your build.
@@ -71,7 +71,7 @@ before_script:
```
{: data-file=".travis.yml"}
-### Installing Packages without an APT Repository
+### Install Packages without an APT Repository
For some projects, there may be a Debian/Ubuntu package available, but no corresponding APT repository. These are still easy to install, but require the extra step of downloading.
@@ -86,13 +86,13 @@ before_install:
```
{: data-file=".travis.yml"}
-### Installing Packages with the APT Addon
+### Install Packages with the APT Addon
You can also install packages and sources using the APT addon, without running `apt-get` commands in your `before_install` script.
-If your requirements goes beyond the normal installation, please use another method described above.
+If your requirements go beyond the normal installation, please use another method described above.
-#### Adding APT Sources
+#### Add APT Sources
To add APT sources, you can use one of the following three types of entries:
@@ -100,7 +100,7 @@ To add APT sources, you can use one of the following three types of entries:
2. `sourceline` key-value pairs which will be added to `/etc/apt/sources.list`
3. when APT sources require GPG keys, you can specify this with `key_url` pairs in addition to `sourceline`.
-The following snippet shows these three types of APT sources
+The following snippet shows these three types of APT sources.
```yaml
addons:
@@ -113,7 +113,7 @@ addons:
```
{: data-file=".travis.yml"}
-#### Adding APT Packages
+#### Add APT Packages
List APT packages under the `addons.apt.packages` key:
@@ -144,7 +144,7 @@ addons:
> You can also have a look at the [Apt](https://config.travis-ci.com/ref/job/addons/apt) section in our [Travis CI Build Config Reference](https://config.travis-ci.com/).
-### Installing Snap Packages with the Snaps Addon
+### Install Snap Packages with the Snaps Addon
You can install [snap](http://snapcraft.io/) packages using our Xenial or
Bionic images:
@@ -182,7 +182,7 @@ of the two possible forms:
$ sudo snap install hugo
```
-1. The map specifying how the snap should be installed. Possible keys are:
+1. The map specifies how the snap should be installed. Possible keys are:
`name`, `confinement`, and `channel`.
The `confinement` key will be used to add `--classic` or `--devmode` flag,
and `channel` will be passed to `--channel` flag.
@@ -206,7 +206,7 @@ of the two possible forms:
`confinement` and `channel` are optional.
-## Installing Packages on macOS
+## Install Packages on macOS
To install packages that are not included in the [default macOS environment](/user/reference/osx/#compilers-and-build-toolchain) use [Homebrew](http://brew.sh).
@@ -232,7 +232,7 @@ addons:
```
{: data-file=".travis.yml"}
-### Installing Casks
+### Install Casks
The Homebrew addon also supports installing [casks][homebrew-cask]. You can add them to the `casks` key in the Homebrew addon configuration to install them:
@@ -246,7 +246,7 @@ addons:
```
{: data-file=".travis.yml"}
-### Installing From Taps
+### Install From Taps
Homebrew supports installing casks and packages from third-party repositories called [taps][homebrew-tap], and you can use these with the Homebrew addon.
@@ -264,9 +264,9 @@ addons:
```
{: data-file=".travis.yml"}
-### Using a Brewfile
+### Use Brewfile
-Under the hood, the Homebrew addon works by creating a `~/.Brewfile` and running `brew bundle --global`. You can also use the addon to install dependencies from your own [Brewfile][] that is checked in to your project. By passing `brewfile: true`, the addon will look for a `Brewfile` in the root directory of your project:
+Under the hood, the Homebrew addon works by creating a `~/.Brewfile` and running `brew bundle --global`. You can also use the addon to install dependencies from your own [Brewfile][] that is checked into your project. By passing `brewfile: true`, the addon will look for a `Brewfile` in the root directory of your project:
[brewfile]: https://github.com/Homebrew/homebrew-bundle
@@ -286,7 +286,7 @@ addons:
```
{: data-file=".travis.yml"}
-### Using Homebrew without addon on older macOS images
+### Use Homebrew without addon on older macOS images
If you're running the `brew` command directly in your build scripts, and you're using an older macOS image, you may see a warning such as this:
@@ -303,7 +303,7 @@ rvm use $TRAVIS_RUBY_VERSION # optionally, switch back to the Ruby version you n
> You can also have a look at the [Homebrew](https://config.travis-ci.com/ref/job/addons/homebrew) section in our [Travis CI Build Config Reference](https://config.travis-ci.com/).
-## Installing Packages on FreeBSD
+## Install Packages on FreeBSD
To install packages that are not included in the default FreeBSD environment use `pkg` in the `before_install` step of your `.travis.yml`:
@@ -323,7 +323,7 @@ addons:
```
{: data-file=".travis.yml"}
-## Installing Dependencies on Multiple Operating Systems
+## Install Dependencies on Multiple Operating Systems
If you're testing on both Linux and macOS, you can use both the APT addon and the Homebrew addon together. Each addon will only run on the appropriate platform:
@@ -344,7 +344,7 @@ install:
```
{: data-file=".travis.yml"}
-## Installing Projects from Source
+## Install Projects from Source
Some dependencies can only be installed from a source package. The build may require a more recent version or a tool or library that's not available as a Ubuntu package.
diff --git a/user/integration/platformio.md b/user/integration/platformio.md
index dfa3a5f17e0..04d377ef0c0 100644
--- a/user/integration/platformio.md
+++ b/user/integration/platformio.md
@@ -1,5 +1,5 @@
---
-title: Embedded Builds with PlatformIO
+title: Embed Builds with PlatformIO
layout: en
---
@@ -8,7 +8,7 @@ layout: en
## Overview
-[PlatformIO](http://platformio.org/) is a cross-platform code-builder and library manager for embedded development with no external dependencies. Using PlatformIO you can compile your code on multiple platforms, frameworks and boards. Unit testing requires a [monthly subscription](http://platformio.org/pricing).
+[PlatformIO](http://platformio.org/) is a cross-platform code-builder and library manager for embedded development with no external dependencies. Using PlatformIO you can compile your code on multiple platforms, frameworks, and boards. Unit testing requires a [monthly subscription](http://platformio.org/pricing).
- *Platforms* - pre-built different development platforms for the most popular host OS (macOS, Windows, Linux 32/64bit, Linux ARMv6+). Each of them
includes compiler, debugger, uploader, etc:
@@ -31,7 +31,7 @@ layout: en
[Full list](http://platformio.org/#!/boards) at PlatformIO
-## .travis.yml Settings
+## .travis.yml file Settings
Please read the official
[PlatformIO & Travis CI](http://docs.platformio.org/en/latest/ci/travis.html) documentation before using PlatformIO.
@@ -61,7 +61,7 @@ script:
```
{: data-file=".travis.yml"}
-### Testing Libraries
+### Test Libraries
If the project you are testing is a library, please use the `--lib="."` option for the [platformio ci](http://docs.platformio.org/en/latest/userguide/cmd_ci.html#cmdoption-platformio-ci-l) command
@@ -71,7 +71,7 @@ script:
```
{: data-file=".travis.yml"}
-### Managing dependencies
+### Manage dependencies
There are two options for testing projects with external dependencies:
@@ -92,7 +92,7 @@ install:
```
{: data-file=".travis.yml"}
-#### Installing dependencies manually
+#### Install dependencies manually
For the dependencies not available in the PlatformIO Library Registry:
@@ -126,7 +126,7 @@ install:
```
{: data-file=".travis.yml"}
-More details available at [build flags/options](http://docs.platformio.org/en/latest/projectconf.html#build-flags).
+More details are available at [build flags/options](http://docs.platformio.org/en/latest/projectconf.html#build-flags).
### Advanced configuration
diff --git a/user/ip-addresses.md b/user/ip-addresses.md
index f49b17dd18d..2722ac2c935 100644
--- a/user/ip-addresses.md
+++ b/user/ip-addresses.md
@@ -4,7 +4,7 @@ layout: en
---
-Knowing the IP addresses of the build machines which Travis CI uses can be helpful
+Knowing the IP addresses of the build machines that Travis CI uses can be helpful
when you need them safelisted to access your internal resources. Since builds
run in a variety of different infrastructures, the IP ranges to safelist depend
on the infrastructure your builds are running on.
@@ -47,7 +47,7 @@ If this occurs, reconfigure your servers to allow for connections from multiple
## Notification
-We will announce changes to this set of IP addresses with a 24 hour notice period. We recommend you use the DNS record to keep track automatically, but if you require a manual notification, you can subscribe to the mailing list:
+We will announce changes to this set of IP addresses with a 24-hour notice period. We recommend you use the DNS record to keep track automatically, but if you require a manual notification, you can subscribe to the mailing list:
diff --git a/user/job-lifecycle.md b/user/job-lifecycle.md
index cf29a69e16f..f99df2e30ea 100644
--- a/user/job-lifecycle.md
+++ b/user/job-lifecycle.md
@@ -118,7 +118,7 @@ script: bundle exec rake build && bundle exec rake builddoc
The example above fails immediately when `bundle exec rake build` fails. Note the `&&`
-### Use the `$?` Command
+### Use the $? Command
Each command in `script` is processed by a special bash function. This function manipulates the `$?` command to produce logs suitable for display. Consequently, you should not rely on the value of `$?` in the `script` section to alter the build behavior.
@@ -158,7 +158,7 @@ Follow these steps to run that script from your `.travis.yml` file:
```
{: data-file=".travis.yml"}
-#### Use the `exit` Command
+#### Use the exit Command
After specifying the steps in the job lifecycle, these are compiled into a single bash script and executed on the worker.
@@ -181,7 +181,7 @@ The exit code of `after_success`, `after_failure`, `after_script`, `after_deploy
To troubleshoot more common issues, see our [Common Builds Problems](/user/common-build-problems/) documentation.
-## Deploying your Code
+## Code Deployment
Deployment is an optional phase in the job lifecycle. It is defined by using one of our continuous deployment providers to deploy code to Heroku, Amazon, or a different supported platform.
diff --git a/user/jwt.md b/user/jwt.md
index fe056f34404..68812e292ac 100644
--- a/user/jwt.md
+++ b/user/jwt.md
@@ -12,18 +12,18 @@ Integration between Travis-CI and third-party services like Sauce Labs relies
on [encrypted variables](/user/environment-variables/#encrypting-environment-variables)
which works well for trusted branches and committers.
For security reasons, encrypted variables are not exposed to untrusted pull requests,
-so builds of pull requests do not have access to third party integrations.
+so builds of pull requests do not have access to third-party integrations.
The JWT addon replaces encrypted variables with a time-limited authentication
token, which is exposed to pull requests without security consequences.
For this to work the JWT addon needs to be enabled in the `.travis.yml` file,
-and the third-party need to have integrated with the JWT service and allow
+and the third-party needs to have integrated with the JWT service and allow
token-based authentication.
-### .travis.yml
+### .travis.yml file
Add the encrypted key to the `jwt` section of the `.travis.yml` file.
This can be done manually or using the `travis encrypt` command
@@ -67,7 +67,7 @@ environment variables containing the JWT tokens instead of the original values.
For example, using the previous configuration `SAUCE_ACCESS_KEY` and
`THIRDPARTY_SHARED_SECRET` will be available as environment variables.
-### How secure is this addon?
+### Secure the addon
The JWT token is only valid for 90 minutes. It is signed in a way that lets you securely
transmit your secret information without worrying that it is leaked.
@@ -106,7 +106,7 @@ Where:
- `exp` will be when the token expires (now + 5400 seconds, so 90 minutes)
- `iat` is the issued at time (now)
-### Third Party Service Provider Code Sample
+### Third-Party Service Provider Code Sample
A code sample which illustrates how to add JWT token authentication to third party services.
@@ -125,7 +125,7 @@ The HTTP BASIC AUTH header's payload is base64 encoded which will decode to stri
johndoe:eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ0cmF2aXMtY2kub3JnIiwic2x1ZyI6InRyYXZpcy1jaS90cmF2aXMtY2kiLCJwdWxsLXJlcXVlc3QiOiIiLCJleHAiOjU0MDAsImlhdCI6MH0.soQJgHR6cGNr9Lj_N6yL2Nk5SQug-hXGUPenJy1QTVc
```
-The colon separated string contains the username before the colon and the JWT
+The colon-separated string contains the username before the colon and the JWT
token after the colon. The username is used to retrieve the user object from
the user database. Below is a function which is executed against the user
object and the token to validate them for authentication. Please note that the
@@ -154,7 +154,7 @@ def authenticate(user, access_key):
return False
```
-## List of Third-Party Services Integrated with the JWT Addon
+## Third-Party Services Integrated with the JWT Addon
### Sauce Labs
diff --git a/user/languages/android.md b/user/languages/android.md
index 1649b41a9f3..e1fa7bb8205 100644
--- a/user/languages/android.md
+++ b/user/languages/android.md
@@ -1,17 +1,15 @@
---
-title: Building an Android Project
+title: Build an Android Project
layout: en
---
-### What This Guide Covers
This guide covers build environment and configuration topics specific to Android projects. Please make sure to read our [Onboarding](/user/onboarding/) and [General Build configuration](/user/customizing-the-build/) guides first.
Android builds are not available on the macOS environment.
-
## CI Environment for Android Projects
### Overview
@@ -60,9 +58,9 @@ android:
```
{: data-file=".travis.yml"}
-### How to install Android SDK components
+### Install Android SDK Components
-In your `.travis.yml` you can define the list of SDK components to be installed, as illustrated in the following example:
+In your `.travis.yml`, you can define the list of SDK components to be installed, as illustrated in the following example:
```yaml
language: android
@@ -77,7 +75,7 @@ android:
The exact component names must be specified (filter aliases like `add-on` or `extra` are also accepted). To get a list of available exact component names and descriptions run the command `sdkmanager --list` (preferably in your local development machine).
-#### Dealing with Licenses
+#### Deal with Licenses
By default, Travis CI will accept all the requested licenses, but it is also possible to define a white list of licenses to be accepted, as shown in the following example:
@@ -99,7 +97,7 @@ android:
For more flexibility, the licenses can also be referenced with regular expressions (using Tcl syntax as `expect` command is used to automatically respond to the interactive prompts).
-### Pre-installed components
+### Pre-installed Components
While the following components are preinstalled, the exact list may change without prior notice. To ensure the stability of your build environment, we recommend that you explicitly specify the required components for your project.
@@ -111,7 +109,7 @@ While the following components are preinstalled, the exact list may change witho
- extra-google-m2repository
- extra-android-m2repository
-### How to Create and Start an Emulator
+### Create and Start an Emulator
**Warning:** At the moment, these steps are not fully supported by Travis CI Android builder.
@@ -184,7 +182,7 @@ cache:
## Default Test Command
-If Travis CI could not detect Maven or Gradle files, Travis CI Android builder will try to use Ant to build your project. By default it will use
+If Travis CI cannot detect Maven or Gradle files, Travis CI Android builder will try to use Ant to build your project. By default, it will use
```bash
ant debug install test
@@ -192,7 +190,7 @@ ant debug install test
to run your test suite. This can be overridden as described in the [general build configuration](/user/customizing-the-build/) guide.
-## Testing Against Multiple JDKs
+## Test against Multiple JDKs
As for any JVM language, it is also possible to [test against multiple JDKs](/user/languages/java/#testing-against-multiple-jdks).
@@ -200,7 +198,7 @@ As for any JVM language, it is also possible to [test against multiple JDKs](/us
For Android projects, `env` and `jdk` can be given as arrays to construct a build matrix.
-## Building Android projects on new build environments
+## Build Android projects on new build environments
The `dist: trusty` build environment is the only supported build environment for Android but if you would like to build on newer build environments e.g. `dist: jammy`, you can exercise your access to the Travis CI build environments and install required packages and tools. An example .travis.yml config can be reviewed below:
diff --git a/user/languages/c.md b/user/languages/c.md
index 9f3b088224f..d68e0f15990 100644
--- a/user/languages/c.md
+++ b/user/languages/c.md
@@ -1,10 +1,9 @@
---
-title: Building a C Project
+title: Build a C Project
layout: en
---
-## What This Guide Covers