Merge pull request circleci#3750 from circleci/config-reference-updated-0923

[WIP]Update configuration-reference.md

Author: thomasr8

jekyll/_cci2/configuration-reference.md

@@ -503,9 +503,24 @@ Class            | vCPUs | Memory (GiB) | GPUs | GPU Memory (*GiB)
 {: class="table table-striped"}
 
 **Note**: Java, Erlang and any other languages that introspect the `/proc` directory for information about CPU count may require additional configuration to prevent them from slowing down when using the CircleCI 2.0 resource class feature. Programs with this issue may request 32 CPU cores and run slower than they would when requesting one core. Users of languages with this issue should pin their CPU count to their guaranteed CPU resources.
-
 If you want to confirm how much memory you have been allocated, you can check the cgroup memory hierarchy limit with `grep hierarchical_memory_limit /sys/fs/cgroup/memory/memory.stat`.
 
+
+#### **`project_slug`**
+
+**What is a Project Slug?**
+
+The CircleCI v2 API is backwards compatible with previous API versions in the way it identifies your projects using repository name. For example, if you want to pull information from CircleCI about the GitHub repository https://github.com/CircleCI-Public/circleci-cli you can refer to that in the CircleCI API as `gh/CircleCI-Public/circleci-cli`, which is a "triplet" of the project type, the name of your "organization", and the name of the repository.
+
+For the project type you can use github or bitbucket as well as the shorter forms `gh` or `bb`, which are now supported in API v2. The organization is your username or organization name in your version control system.
+
+With API v2, CircleCI has introduced a string representation of the triplet called the `project_slug`, and takes the following form:
+
+`<project_type>/<org_name>/<repo_name>`
+
+The `project_slug` is included in the payload when pulling information about a project as well as when looking up a pipeline or workflow by ID. It is important to note that the `project_slug` is just a new name for the existing format, and not a new shape of the URLS that can then be used to retrieve information about a project. It is possible in the future CircleCI may change the shape of a `project_slug`, but in all cases it would be usable as a human-readable identifier for a given project.
+
+
 #### **`steps`**
 
 The `steps` setting in a job should be a list of single key/value pairs, the key of which indicates the step type. The value may be either a configuration map or a string (depending on what that type of step requires). For example, using a map:
@@ -800,7 +815,6 @@ version | N        | String | Version string of Docker you would like to use (de
 - `setup_remote_docker` is not compatible with the `machine` executor. See [Docker Layer Caching in Machine Executor]({{ site.baseurl }}/2.0/docker-layer-caching/#machine-executor) for information on how to enable DLC with the `machine` executor.
 - The `version` key is not currently supported on CircleCI installed in your private cloud or datacenter. Contact your system administrator for information about the Docker version installed in your remote Docker environment.
 
-
 ##### **`save_cache`**
 
 Generates and stores a cache of a file or directory of files such as dependencies or source code in our object storage. Later jobs can [restore this cache](#restore_cache). Learn more in [the caching documentation]({{ site.baseurl }}/2.0/caching/).
@@ -1290,6 +1304,50 @@ ignore | N | String, or List of Strings | Either a single tag specifier, or a li
 
 For more information, see the [Executing Workflows For a Git Tag]({{ site.baseurl }}/2.0/workflows/#executing-workflows-for-a-git-tag) section of the Workflows document.
 
+##### **`when` in Workflows**
+
+## Using 'when' in Workflows
+
+When using CircleCI API v2, you may use a `when` clause (the inverse clause is also supported) under a workflow declaration with a boolean value to determine whether or not to run that workflow. The most common use of `when` in API v2 is to use a pipeline parameter as the value, allowing an API trigger to pass that parameter to determine which workflows to run.
+
+The example below shows an example configuration using two different pipeline parameters. You may use one of the parameters to drive a particular workflow, while you may use the other parameter to determine whether a particular step will run.
+
+```yaml
+version: 2.1
+
+parameters:
+  run_integration_tests:
+    type: boolean
+    default: false
+  deploy:
+    type: boolean
+    default: false
+
+workflows:
+  version: 2
+  integration_tests:
+    when: << pipeline.parameters.run_integration_tests >>
+    jobs:
+      - mytestjob
+      - when:
+          condition: << pipeline.parameters.deploy >>
+          steps:
+            - deploy
+
+jobs:
+...
+```
+ 
+This example prevents the workflow `integration_tests` from being triggered unless the tests were invoked explicitly when the pipeline is triggered with the following in the `POST` body:
+
+```
+{
+    "parameters": {
+        "run_integration_tests": true
+    }
+}
+```
+
 ###### *Example*
 
 ```