Merge branch 'master' into ph-new-lts-version

Author: Pezi777

user/job-lifecycle.md

@@ -9,7 +9,7 @@ Travis CI provides a default build environment and a default set of phases for e
 
 Keep reading to see how you can customize any phase in this process, via your `.travis.yml`.
 
-## The job lifecycle
+## The Job Lifecycle
 
 A job on Travis CI is made up of two main parts:
 
@@ -36,7 +36,7 @@ The complete job lifecycle, including three optional deployment phases and after
 1. OPTIONAL `after_deploy`
 1. `after_script`
 
-A *build* can be composed of many jobs.
+> A *build* can be composed of many jobs.
 
 ## Customizing the Installation Phase
 
@@ -50,7 +50,7 @@ install: ./install-dependencies.sh
 ```
 {: data-file=".travis.yml"}
 
-> When using custom scripts they should be executable (for example, using `chmod +x`) and contain a valid shebang line such as `/usr/bin/env sh`, `/usr/bin/env ruby`, or `/usr/bin/env python`.
+> When using custom scripts, they should be executable (for example, using `chmod +x`) and contain a valid shebang line such as `/usr/bin/env sh`, `/usr/bin/env ruby`, or `/usr/bin/env python`.
 
 You can also provide multiple steps, for instance to install both ruby and node dependencies:
 
@@ -94,7 +94,7 @@ script:
 ```
 {: data-file=".travis.yml"}
 
-When one of the build commands returns a non-zero exit code, the Travis CI build runs the subsequent commands as well, and accumulates the build result.
+When one of the build commands returns a non-zero exit code, the Travis CI build runs the subsequent commands as well and accumulates the build result.
 
 In the example above, if `bundle exec rake build` returns an exit code of 1, the following command `bundle exec rake builddoc` is still run, but the build will result in a failure.
 
@@ -134,7 +134,7 @@ if [ "${TRAVIS_PULL_REQUEST}" = "false" ]; then
 fi
 ```
 
-Note the `set -ev` at the top. The `-e` flag causes the script to exit as soon as one command returns a non-zero exit code. This can be handy if you want whatever script you have to exit early. It also helps in complex installation scripts where one failed command wouldn't otherwise cause the installation to fail.
+> Note the `set -ev` at the top. The `-e` flag causes the script to exit as soon as one command returns a non-zero exit code. This can be handy if you want whatever script you have to exit early. It also helps in complex installation scripts where one failed command wouldn't otherwise cause the installation to fail.
 
 The `-v` flag makes the shell print all lines in the script before executing them, which helps identify which steps failed.
 
@@ -157,7 +157,7 @@ When overriding these steps, do not use `exit` shell built-in command.
 Doing so will run the risk of terminating the build process without giving Travis a chance to
 perform subsequent tasks.
 
-Using `exit` inside a custom script which will be invoked from during a build is fine.
+> Using `exit` inside a custom script which will be invoked from during a build is fine.
 
 
 ## Breaking the Build
@@ -175,7 +175,7 @@ However, if one of these stages times out, the build is marked as **failed**.
 
 An optional phase in the job lifecycle is deployment.
 This phase is defined by using one of our continuous deployment providers to deploy code to Heroku, Amazon, or a different supported platform.
-The deploy steps are skipped if the build is broken.
+The deploy steps are skipped, if the build is broken.
 
 When deploying files to a provider, prevent Travis CI from resetting your
 working directory and deleting all changes made during the build ( `git stash
@@ -189,6 +189,8 @@ deploy:
 
 You can run commands before a deploy by using the `before_deploy` phase. A non-zero exit code in this phase will mark the build as **errored**.
 
-If there are any steps you'd like to run after the deployment, you can use the `after_deploy` phase. Note that `after_deploy` does not affect the status of the build.
+If there are any steps you'd like to run after the deployment, you can use the `after_deploy` phase. 
 
-Note that `before_deploy` and `after_deploy` are run before and after every deploy provider, so will run multiple times if there are multiple providers.
+> Note that `after_deploy` does not affect the status of the build.
+
+> Note that `before_deploy` and `after_deploy` are run before and after every deploy provider, so they will run multiple times, if there are multiple providers.

user/languages/rust.md

@@ -36,7 +36,7 @@ By default, we download and install the latest stable Rust release at the start
 of the build (thanks to `rustup`). The [`minimal` profile][profiles] is used
 and includes the following language tools `cargo`, `rustc`, and `rustup`.
 
-[profiles]: https://blog.rust-lang.org/2019/10/15/Rustup-1.20.0.html#profiles
+[profiles]: https://github.com/rust-lang/rustup.rs#profiles
 
 If you want additional language tools like `rustfmt` or `clippy`, please
 install them in `before_install`.

user/speeding-up-the-build.md

@@ -75,7 +75,7 @@ file](https://github.com/rails/rails/blob/master/.travis.yml) for more examples.
 
 Parallelizing the test suite on one virtual machine depends on the language and test runner:
 
-- For Ruby and RSpec use the [parallel_tests](https://github.com/grosser/parallel_tests)
+- For Ruby and RSpec use the [parallel_tests](https://github.com/grosser/parallel_tests) gem.
 - For Java, use the built-in feature [to run tests in parallel
   using JUnit](http://incodewetrustinc.blogspot.com/2009/07/run-your-junit-tests-in-parallel-with.html).
 

user/travis-ci-for-private.md

@@ -14,7 +14,7 @@ continuous integration solution for private repositories.
 
 Yes, of course! No need to put in your credit card details, the trial starts whenever you trigger your first build on [Travis CI for private repositories](https://travis-ci.com). It includes 100 trial builds for free and 2-concurrent-jobs.
 
-When you're ready to start using Travis CI, head over to the [billing page](https://billing.travis-ci.com/) to add your billing details and end your trial.
+When you're ready to start using Travis CI, head over to the [billing page](https://travis-ci.com/account/subscription) to add your billing details and end your trial.
 
 ## Can I use pull request testing on Travis CI for private repositories?
 
@@ -35,12 +35,12 @@ To keep the access rights up to date, we sync every user account approximately o
 
 ## Who has access to the billing details?
 
-Access rights to the Travis CI [billing page](https://billing.travis-ci.com) can be one of the following:
+Access rights to the Travis CI [billing page](https://travis-ci.com/account/subscription) can be one of the following:
 
 - **Open (default)**: anyone with admin access to at least one private repository belonging to the organization in GitHub has access to the billing information in Travis CI.
 - **Restricted**: access is limited to members of the organization having the _owner_ and/or _billing manager_ permissions in GitHub (see their [documentation about the _Permission levels for an organization_](https://help.github.com/articles/permission-levels-for-an-organization/)).
 
-You can change the access rights of an organization to **Restricted** (or back to **Open**) under the organization's tab on [our billing page](https://billing.travis-ci.com) as shown below:
+You can change the access rights of an organization to **Restricted** (or back to **Open**) under the organization's tab on [our billing page](https://travis-ci.com/account/subscription) as shown below:
 
 ![Billing access toggle](/images/admin_only_toggle.png "Billing access toggle")