Merge branch 'master' into patch-1

nrios14 · web-flow · commit dcb5e853d659 · 2021-04-05T21:06:33.000-04:00
diff --git a/Gemfile.lock b/Gemfile.lock
@@ -147,14 +147,15 @@ GEM
     mime-types (3.3.1)
       mime-types-data (~> 3.2015)
     mime-types-data (3.2020.0512)
-    mini_portile2 (2.4.0)
+    mini_portile2 (2.5.0)
     minitest (5.14.1)
     multi_json (1.14.1)
     multipart-post (2.1.1)
     netrc (0.11.0)
     nio4r (2.5.2)
-    nokogiri (1.10.9)
-      mini_portile2 (~> 2.4.0)
+    nokogiri (1.11.2)
+      mini_portile2 (~> 2.5.0)
+      racc (~> 1.4)
     nokogumbo (2.0.2)
       nokogiri (~> 1.8, >= 1.8.4)
     padrino-helpers (0.12.9)
@@ -174,6 +175,7 @@ GEM
     public_suffix (4.0.5)
     puma (4.3.5)
       nio4r (~> 2.0)
+    racc (1.5.2)
     rack (1.6.13)
     rack-jekyll (0.5.0)
       jekyll (>= 1.3)
diff --git a/_data/snippets.yml b/_data/snippets.yml
@@ -119,7 +119,7 @@ github_oauth_access_rights: |
   
   > Travis CI by travis-pro wants to access your [account name] account.
   
-  and in the repositorie's section it will state: 
+  and in the repositories section it will state: 
   
   > This application will be able to read and write all public and private repository data.
   
diff --git a/user/billing-overview.md b/user/billing-overview.md
@@ -137,7 +137,7 @@ With every build started, Travis CI keeps track of how many unique users trigger
 
 | Area                            | Details    |
 | :---                            | ---        |
-| **Payment**                     | Credits are paid in advance:<BR />1. Upon purchasing a Plan, an immediate charge is applied depending on credits allotment coming with a Plan.<BR />2. The additional credit addons can be purchased at any time and credits used only when you need them. Charge is applied immediately upon transaction.<BR /><BR />The user license cost is charged automatically in arrears, at the end of each billing period. The number of unique users trigerring a build is charged according to the license rates. |
+| **Payment**                     | Credits are paid in advance:<BR />1. Upon purchasing a Plan, an immediate charge is applied depending on credits allotment coming with a Plan.<BR />2. The additional credit addons can be purchased at any time and credits used only when you need them. Charge is applied immediately upon transaction.<BR /><BR />The user license cost is charged automatically in arrears, at the end of each billing period. The number of unique users trigerring a build is charged according to the license rates.<br /><br />The Free Plan assigned upon sign-up grants you unlimited users for free. |
 | **Private/Public repositories** | With Credits you can build over both private and public repositories. <BR/> With OSS Credits you can build only over public repositories. |
 | **Build job limits**            | None or very high. <BR/><BR/>The Free Plan assigned automatically upon sign-up has a limit of 20 concurrent jobs. |
 
@@ -148,6 +148,30 @@ With every build started, Travis CI keeps track of how many unique users trigger
 2. Navigate to the [Plans](https://travis-ci.com/account/plan) and make sure you have your billing and contact details filled in correctly. 
 3. Contact [Travis CI support](mailto:support@travis-ci.com) requesting Usage based Plan.
 
+## Premium Virtual Machines
+
+Usage and Concurrency based plans allow you to choose the instance size, the build will run on. This can be done by setting a 'vm' property in the .travis.yml config. This property allows you to choose the Virtual machine instance for a build:
+```yaml
+vm:
+  size: [medium|large|x-large|2x-large]
+```
+Available VM sizes are:
+
+| size      | vCPU        | Memory GiB  | Plan                     |
+|:---------:|:-----------:|:-----------:|:------------------------:|
+| medium    | 2           | 8           | Standard/Pro/Concurrency |
+| large     | 4           | 16          | Standard/Pro/Concurrency |
+| x-large   | 8           | 32          | Standard/Pro/Concurrency |
+| 2x-large  | 16          | 64          | Pro                      |
+
+VM size property impacts the build minutes/credits usage:
+
+| VM size              | Credits per<br />started build minute |
+|:--------------------:|:-----------:|
+| medium               | 50          |
+| large                | 60          |
+| x-large              | 70          |
+| 2x-large             | 80          |
 
 ## Getting Help
 
diff --git a/user/deployment/releases.md b/user/deployment/releases.md
@@ -126,7 +126,12 @@ travis setup releases --com
 
 ## Authenticating with an OAuth token
 
-The recommended way to authenticate is to use a GitHub OAuth token. It must have the `public_repo` or `repo` scope to upload assets. 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.
+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.
+
+If you can't use `travis setup releases`, you can set up the token manually with the following steps:
+1. Create a personal access token on the Github account. It must have the `public_repo` or `repo` scope to upload assets.
+2. Encrypt the token using Travis CLI: `travis encrypt [super_secret_token]`. Note that you must _not_ give the token a name in the encrypt command, as you might for an environment variable.
+3. Add the secure encrypted token to the deploy section of your `.travis.yml`, under the `api_key`.
 
 This results in something similar to:
 
@@ -142,7 +147,7 @@ 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 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
 
diff --git a/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise.md b/user/enterprise/tcie-3.x-setting-up-travis-ci-enterprise.md
@@ -76,7 +76,7 @@ Ubuntu 18.04 LTS or later as the underlying operating system.
 3. Set up your cluster/machine instances configuration - at least 1 virtual machine is needed (in microk8s scenario) or Kubernetes cluster prepared and started
 4. Install Replicated KOTS on *your local machine*. Please make sure that you can connect to the Kubernetes cluster.
 5. TCIE 3.x installed on **single** virtual machine instance
-    1. On *your new virtual machine instance* run kurl.sh via 'curl https://kurl.sh/latest | sudo bash' 
+    1. On *your new virtual machine instance* run kurl.sh via `curl https://kurl.sh/latest | sudo bash`
     2. Get credentials from microk8s cluster running on *your new vm instance*. Please view e.g. [kurl documentation](https://kurl.sh/docs/install-with-kurl/connecting-remotely) where kubectl config with credentials is created and can be used afterwards.
     3. Please refer to various cluster and installation options in [kURL documentation](https://kurl.sh/docs/install-with-kurl/). Please adjust your setup and configuration according to your needs before progressing with TCIE 3.X installation
 6. TCIE 3.x installed as Kubernetes cluster in the cloud
diff --git a/user/languages/java.md b/user/languages/java.md
@@ -204,7 +204,7 @@ The list of available JVMs for different dists are at
 ### Switching JDKs (Java 8 and below) Within One Job
 
 If your build needs to switch JDKs (Java 8 and below) during a job, you can do so with
-`jdk_switcher use …`.
+[`jdk_switcher`](https://github.com/michaelklishin/jdk_switcher#what-jdk-switcher-is).
 
 ```yaml
 script:
@@ -253,16 +253,18 @@ jdk:
 
 ### Switching JDKs (to Java 10 and up) Within One Job
 
-If your build needs to switch JDKs (Java 8 and up) during a job, you can do so with
-`install-jdk.sh`.
+If your build needs to switch JDKs (Java 10 and up) during a job, you can do so with
+[`install-jdk.sh`](https://sormuras.github.io/blog/2017-12-08-install-jdk-on-travis.html).
 
 ```yaml
 jdk: openjdk10
 script:
   - jdk_switcher use openjdk10
   - # do stuff with OpenJDK 10
+  - wget https://github.com/sormuras/bach/raw/master/install-jdk.sh
+  - chmod +x $TRAVIS_BUILD_DIR/install-jdk.sh
   - export JAVA_HOME=$HOME/openjdk11
-  - $TRAVIS_BUILD_DIR/install-jdk.sh --install openjdk11 --target $JAVA_HOME
+  - $TRAVIS_BUILD_DIR/install-jdk.sh -F 11 --target $JAVA_HOME
   - # do stuff with open OpenJDK 11
 ```
 {: data-file=".travis.yml"}
diff --git a/user/multi-cpu-architectures.md b/user/multi-cpu-architectures.md
@@ -102,6 +102,8 @@ The `.travis.yml` file above creates a 2x4 [build matrix](/user/customizing-the-
 
 There are many options available and using the `matrix.include` key is essential to include any specific entries. For example, this matrix would route builds to the arm64 and amd64 architecture environments:
 
+> Note that `group: edge` is required for `arm64-graviton2` architectures.
+
 ```yaml
 jobs:
   include:
diff --git a/user/reference/osx.md b/user/reference/osx.md
@@ -95,15 +95,19 @@ and later, use `xcode9.4` (or later).
 ## Compilers and Build toolchain
 
 - automake
+- clang
+- cmake
+- gcc
 - maven
 - mercurial
 - pkg-config
 - wget
 - xctool
-- cmake
 
 ## Languages
 
+- C
+- C++
 - Go
 - Java
 - Nodejs
diff --git a/user/reference/windows.md b/user/reference/windows.md
@@ -143,8 +143,8 @@ cache:
 
 This will download and install MSYS2 the first time, and store both the downloaded initial archive and the MSYS2 installation in your [build cache](/user/caching/#arbitrary-directories). Subsequent builds will avoid re-downloading the initial archive and will update the cached installation before use, and cache the updated installation upon success.
 
-MSYS2 contains two noteworthy [subsystems](https://github.com/msys2/msys2/wiki/MSYS2-introduction#subsystems): "msys2" and "mingw64". The code above prepares the `$msys2` and `$mingw64` prefixes for entering the corresponding shells. As an example, the `$msys2` prefix is used to run `pacman` appropriately. Your build commands should use the `$mingw64` prefix to build native Windows programs, and the `$msys2` prefix to build POSIX-based programs requiring the MSYS2 DLL.
+MSYS2 contains two noteworthy [subsystems](https://www.msys2.org/wiki/MSYS2-introduction/#subsystems): "msys2" and "mingw64". The code above prepares the `$msys2` and `$mingw64` prefixes for entering the corresponding shells. As an example, the `$msys2` prefix is used to run `pacman` appropriately. Your build commands should use the `$mingw64` prefix to build native Windows programs, and the `$msys2` prefix to build POSIX-based programs requiring the MSYS2 DLL.
 
-A point of caution: the pre-installed "mingw" Chocolatey package should **not** be used within any MSYS2 subsystem. (In fact, the above snippet uninstalls the "mingw" Chocolatey package to be safe.) Note that the [MSYS2 wiki](https://github.com/msys2/msys2/wiki/MSYS2-introduction#path) says:
+A point of caution: the pre-installed "mingw" Chocolatey package should **not** be used within any MSYS2 subsystem. (In fact, the above snippet uninstalls the "mingw" Chocolatey package to be safe.) Note that the [MSYS2 wiki](https://www.msys2.org/wiki/MSYS2-introduction/#path) says:
 
 > Be aware that mixing in programs from other MSYS2 installations, Cygwin installations, compiler toolchains or even various other programs is not supported and will probably break things in unexpected ways.
diff --git a/user/triggering-builds.md b/user/triggering-builds.md
@@ -19,13 +19,14 @@ Trigger Travis CI builds using the API V3 by sending a POST request to `/repo/{s
    ```
 
 2. Send a request to the API. This example shell script sends a POST request to
-   `/repo/travis-ci/travis-core/requests` to trigger a build of the most recent
-   commit of the master branch of the `travis-ci/travis-core` repository:
+   `/repo/travis-ci/travis-core/requests` to trigger a build of a specific 
+   commit (omit `sha` for most recent) of the master branch of the `travis-ci/travis-core` repository:
 
    ```bash
    body='{
    "request": {
    "branch":"master"
+   "sha":"bf944c952724dd2f00ff0c466a5e217d10f73bea"
    }}'
 
    curl -s -X POST \
