fix

Author: rosieyohannan

jekyll/_cci2/config-policies-for-self-hosted-runner.adoc

@@ -20,7 +20,7 @@ Follow this how-to guide to learn how to create a config policy to restrict whic
 
 * Install/update the CircleCI CLI, and ensure you have authenticated with a token before attempting to use the CLI with config policies. See the xref:local-cli#[Installing the Local CLI] page for more information.
 
-* Set up a self-hosted runner. See the xref:runner-installation#[Installing self-hosted runners] guide.
+* Set up a self-hosted runner. See the xref:runner-overview/#getting-started[Getting started] section of the Self-hosted runners overview.
 
 * Ensure you have **enabled** config policy evaluation for your organization so that project configurations **will** be evaluated against your organization's policies when pipelines are triggered:
 +
@@ -72,7 +72,7 @@ In the following steps you will replace `namespace/resource_class` and `project_
 == 2. Update policy with your details
 
 . Replace `namespace/resource_class` with one of your runner resource classes:
-.. In the CircleCI web app, go to your self-hosted runner's inventory page by selecting **Self-Hosted Runners** in the sidebar. If you do not see this option, check that you have followed the xref:runner-installation#[Installing self-hosted runners] guide. Here you will see all your available self-hosted runner resource classes.
+.. In the CircleCI web app, go to your self-hosted runner's inventory page by selecting **Self-Hosted Runners** in the sidebar. If you do not see this option, check that you have accepted the CircleCI Runner Terms and created a namespace and resource class, as outlined in the runner installation guides. Here you will see all your available self-hosted runner resource classes.
 .. Replace `namespace/resource_class` in the `runner.rego` file with the name of the resource class that you would like to restrict.
 
 . Replace `project_UUIDs` with a project ID:

jekyll/_cci2/config-policy-management-overview.adoc

@@ -375,6 +375,34 @@ For further reading, see the link:https://circleci.com/blog/compliance-with-conf
 
 It is important to be able to deploy new policies with confidence, knowing how they will be applied, and the decisions they will generate ahead of time. To enable this process, the `circleci policy test` command is available. The `test` subcommand is inspired by the golang and opa test commands. For more information on setting up testing, see the xref:test-config-policies#[Test config policies] guide.
 
+[#dynamic-config]
+== Config policies and dynamic configuration
+
+You can write config policies to govern projects that use dynamic configuration too. Policies are evaluated against:
+
+* _Setup_ configurations
+* _Continuation_ configurations
+* Standard configurations
+
+If required for your project, you can encode rules to apply only to setup configs, or only to non-setup configs, as follows:
+
+[source,rego]
+----
+enable_hard["setup_rule"] { input.setup } # only applied to configs with `setup: true`
+----
+
+[source,rego]
+----
+enable_hard["not_setup_rule"] { not input.setup } # only applied to configs that do not have `setup: true`
+----
+
+[source,rego]
+----
+enable_hard["some_rule"] # rule applied to all configs
+----
+
+For more information about dynamic configuration, see the xref:dynamic-config#[Dynamic configuration overview].
+
 [#example-policy]
 == Example policy
 

jekyll/_cci2/configuration-reference.md

@@ -704,6 +704,11 @@ A [custom image]({{ site.baseurl
 
 You can specify image versions using tags or digest. You can use any public images from any public Docker registry (defaults to Docker Hub). Learn more about specifying images on the [Using the Docker Execution Environment]({{ site.baseurl }}/using-docker) page.
 
+---
+
+##### Docker registry authentication
+{: #docker-auth }
+
 Some registries, Docker Hub, for example, may rate limit anonymous docker pulls. It is recommended you authenticate in such cases to pull private and public images. The username and password can be specified in the `auth` field.  See [Using Docker Authenticated Pulls]({{ site.baseurl }}/private-images/) for details.
 
 Example:
@@ -743,7 +748,33 @@ jobs:
           password: $DOCKERHUB_PASSWORD  # context / project UI env-var reference
 ```
 
-Using an image hosted on [AWS ECR](https://aws.amazon.com/ecr/) requires authentication using AWS credentials. By default, CircleCI uses the AWS credentials you provide by setting the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` project environment variables. It is also possible to set the credentials by using the `aws_auth` field as in the following example:
+---
+
+##### AWS authentication
+{: #aws-authentication}
+
+Using an image hosted on [AWS ECR](https://aws.amazon.com/ecr/) requires authentication using AWS credentials.
+
+###### Use OIDC
+{: #oidc }
+
+Authenticate using OpenID Connect (OIDC) using the `oidc_role_arn` field, as follows:
+
+```yaml
+jobs:
+  job_name:
+    docker:
+      - image: <your-image-arn>
+        aws_auth:
+          oidc_role_arn: <your-iam-role-arn>
+```
+
+For steps to get set up with OIDC to pull images from AWS ECR, see the [Pull and image from AWS ECR with OIDC](/docs/pull-an-image-from-aws-ecr-with-oidc/) page.
+
+###### Use environment variables
+{: #env-vars}
+
+By default, CircleCI uses the AWS credentials you provide by setting the `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` project environment variables. It is also possible to set the credentials by using the `aws_auth` field as in the following example:
 
 ```yaml
 jobs:

jekyll/_cci2/container-runner-installation.adoc

@@ -2,8 +2,6 @@
 contentTags: 
   platform:
   - Cloud
-  - Server v4.x
-  - Server v3.x
 ---
 = Container runner installation (Kubernetes)
 :page-layout: classic-docs
@@ -12,35 +10,78 @@ contentTags:
 :icons: font
 :toc: macro
 :toc-title:
+:container:
 
 This page describes how to install CircleCI's container runner.
 
-{% include snippets/runner-platform-prerequisites.adoc %}
+// {% include snippets/runner-platform-prerequisites.adoc %}
 
-[#installation-instructions]
-== Installation instructions
+[#prerequisites]
+== Prerequisites
 
-1. Add the container runner Helm repo by running `helm repo add container-agent https://packagecloud.io/circleci/container-agent/helm`
+{% include snippets/runner/container-runner-prereq.adoc %}
 
-2. Run `helm repo update`
+[#self-hosted-runner-terms-agreement]
+== Self-hosted runner terms agreement
 
-3. Run `kubectl create namespace circleci` to create the `circleci` Kubernetes namespace
+{% include snippets/runner/terms.adoc %}
 
-4. Create a file called `values.yaml` file containing the following:
+[#create-namespace-and-resource-class]
+== 1. Create namespace and resource class 
+
+[.tab.container-runner.Web_app_installation]
+--
+{% include snippets/runner/install-with-web-app-steps.adoc %}
+--
+[.tab.container-runner.CLI_installation]
+--
+{% include snippets/runner/install-with-cli-steps.adoc %}
+--
+
+[#container-runner-installation]
+== 2. Container runner installation
+
+. Add the container runner Helm repo by running the following command:
++
+[source,shell]
+----
+helm repo add container-agent https://packagecloud.io/circleci/container-agent/helm
+----
+
+. Next, run the following:
++
+[source,shell]
+----
+helm repo update
+----
+
+. Then, run the following command to create the `circleci` Kubernetes namespace:
++
+[source,shell]
+----
+kubectl create namespace circleci
+----
+
+. Create a file called `values.yaml` file containing the following:
 +
 ```yaml
 agent:
   resourceClasses:
     namespace/my-rc:
       token: <resource_class_token>
 ```
+
+. Finally, run the following command:
 +
-5. Run `helm install container-agent container-agent/container-agent -n circleci -f values.yaml`
+[source,shell]
+----
+helm install container-agent container-agent/container-agent -n circleci -f values.yaml
+----
 
 [#container-runner-configuration-example]
 == Container runner configuration example
 
-Once you have installed the container runner within your cluster, create and trigger a CircleCI job that uses the Docker executor to validate the installation. The fields you must set for a specific job to run using your self-hosted runners are:
+Once you have installed the container runner within your cluster, create and trigger a CircleCI job that uses the Docker executor to validate the installation. The fields you must set for a specific job to run using your container runners are:
 
 * `image:`
 * `resource_class: <namespace>/<resource-class>`

jekyll/_cci2/container-runner.adoc

@@ -16,7 +16,7 @@ This document is a comprehensive guide to operating and configuring jobs with th
 [#running-your-first-job]
 == Running your first job with container runner
 
-Follow the instructions outlined on the <<runner-installation#,self-hosted runner installation>> page to download the container runner and run your first job. You can also use the link:https://app.circleci.com/[CircleCI web app] to get started with self-hosted runners.
+Follow the instructions outlined on the xref:container-runner-installation#[Container runner installation] page to download the container runner and run your first job. You can also use the link:https://app.circleci.com/[CircleCI web app] to get started with self-hosted runners.
 
 [#sample-configuration-container-agent]
 == Container runner sample configuration

jekyll/_cci2/convenience-images-support-policy.adoc

@@ -0,0 +1,84 @@
+---
+contentTags:
+  platform:
+  - Cloud
+  - Server v4.x
+  - Server v3.x
+---
+= CircleCI convenience images support policy
+:page-layout: classic-docs
+:page-liquid:
+:page-description: CircleCI Convenience Images release, update, and deprecation policy
+:icons: font
+:toc: macro
+:toc-title:
+
+[#overview]
+== Overview
+
+This document outlines the xref:circleci-images#[CircleCI Docker convenience images] release, update, and deprecation policy.
+
+This policy applies to all CircleCI convenience images we publish to the `cimg` namespace on Docker Hub.
+
+[#base-images]
+== Base images
+
+Our Docker convenience images are all built upon our base image, `cimg/base`. This image is in turn built upon the official Ubuntu docker image. 
+
+We aim to build variants of this image for all LTS versions of Ubuntu that are being maintained in “Standard Support” status. We will stop building variants of `cimg/base` with Ubuntu LTS versions that drop out of support.
+
+When a new Ubuntu LTS version is released, the child CircleCI convenience images will have the underlying base image switched to this version around 6 months after the first release of the `cimg/base` variant.
+
+By building all of our convenience images on top of a common image, we increase the chance of the underlying base layers being cached by the execution environment, therefore increasing the spin up speed for the job.
+
+We build a new base image each month. However, we only update the base image used in child convenience images once per quarter. These updates are not retroactively applied to existing images, but will apply to new releases of the image after the change has been made.
+
+We encourage users who are building their own images for use on CircleCI to use our `cimg/base` image as a starting point.
+
+[#release-policy]
+== Release policy
+
+We track new releases of languages and aim to provide new convenience images that support these new releases within 48 hours. Please note that this is not an SLA (service level agreement). We can not, and do not, provide an official SLA turnaround time for new convenience images.
+
+For our deployment focused images, we provide a new image once per month.
+
+We do not provide new image releases for alpha, beta, preview or release candidates of languages.
+
+[#tagging]
+== Tagging
+
+Each image is tagged with the specific `major.minor.patch` version of the language it contains. We also provide `major.minor` tags, which always point to the latest patch release of the image.
+
+In special cases, we also provide additional tags, such as `lts` or `current`, which track releases as per the tagging scheme of the parent project.
+
+We do not provide a `latest`, or `current`, tag for any convenience images, other than special cases as mentioned above. This is by design, and is not something we have plans to implement in the future. We do this to ensure that jobs based on our images are more deterministic in nature, with minimal changes due to us pushing new tags that switch `current` to a new major version, for example. This helps lower the risk of breaking changes occurring when customers have not explicitly updated their configurations.
+
+[#critical-cve-patches]
+== Critical CVE patches
+
+When critical CVEs are disclosed that affect the versions of the operating system or software stack in our convenience images, we will investigate the impact that this has on our images being used within CircleCI execution environments. 
+
+In most cases, due to the ephemeral and isolated nature of the containers in the environment, it is not necessary to patch these images. We will always communicate our stance on these disclosures on our link:https://discuss.circleci.com/[Discuss Forum].
+
+[#bug-reports-issues-and-prs]
+== Bug reports, issues, and PRs
+
+We welcome bug reports and PRs from our community via GitHub for each image. The GitHub repository for each image can be found by visiting the link:https://circleci.com/developer/images[Developer Hub].
+
+As a general rule, minor, non-blocking bugs will be fixed in the next release of the image. For major/blocking changes, we will patch the existing live image, depending on how old the image is.
+
+For issues and PRs that are requesting new features in the image, we ask that justification and scope is provided. Keeping the images small in size and simple to build, whilst providing the most functionality is our main aim.
+
+While we make every effort to respond to issues and PRs in a timely manner, we do not provide an official SLA for this.
+
+[#image-lifespan-eol]
+== Image lifespan / EOL
+
+We generally do not remove images from Docker Hub once published, however we encourage customers to follow the projects for the languages they use and update the images in their jobs once the project declares a version as EOL (end-of-life).
+
+For versions that are EOL, we do not issue bug fixes or patches.
+
+[#exceptions]
+== Exceptions
+
+​​At any time, we reserve the right to work outside of the information in this document if the circumstances require. In the event that we are required to make an exception to the policy, we will aim to provide as much notice and clarity as possible. In these cases, an announcement will be posted on our Discuss Forum, along with additional outreach, such as an email notice, where possible.

jekyll/_cci2/dynamic-config.adoc

@@ -2,7 +2,9 @@
 layout: classic-docs
 contentTags:
   platform:
-  - Cloud
+    - Cloud
+    - Server v4.x
+    - Server v3.x
 ---
 = Dynamic Configuration
 :description: Docs page on using Setup Workflows for Dynamic Configuration

jekyll/_cci2/introduction-to-the-circleci-web-app.adoc

@@ -129,7 +129,7 @@ image::web_ui_runner.png[Runner inventory]
 
 New resource classes will require an existing namespace, or creation of a new namespace if no namespace for the organization has been created yet (organizations can only create a single namespace), as well as a label to match your CircleCI job with a type of runner.
 
-In this process you select the environment you are working with (Linux, macOS, etc) and the web app will display the instructions for installing self-hosted runner software. This process is also laid out on the xref:runner-installation#[self-hosted runner] page.
+In this process you select the environment you are working with (Linux, macOS, etc) and the web app will display the instructions for installing self-hosted runner software. Learn more and get started with self-hosted runners on the xref:runner-overview#[CircleCI self-hosted runners overview].
 
 image::runnerui_step_four.png[Runner setup]
 

jekyll/_cci2/openid-connect-tokens.adoc

@@ -19,9 +19,9 @@ CircleCI provides OpenID Connect ID (OIDC) tokens in environment variables. A jo
 CircleCI OpenID Connect ID tokens are available in the following environment variables:
 
 * `$CIRCLE_OIDC_TOKEN`
-* `$CIRCLE_OIDC_TOKEN_V2`
+* `$CIRCLE_OIDC_TOKEN_V2` - Includes a different format for the `sub` claim, See <<format-of-the-openid-connect-id-token>> for full details.
 
-The `$CIRCLE_OIDC_TOKEN_V2` token includes a different format for the `sub` claim, which is highlighted in the table below.
+CAUTION: **What about forks?** OIDC tokens will only be generated for forked builds if the **Pass secrets to builds from forked pull requests** setting is enabled. Find this option at **Project settings** > **Advanced**.
 
 [#setting-up-your-cloud-service]
 == Setting up your cloud service
@@ -86,6 +86,9 @@ The OpenID Connect ID tokens also contain some https://openid.net/specs/openid-c
 
 | `oidc.circleci.com/context-ids`
 | An array of strings containing UUIDs that identify the context(s) used in the job. Currently, just one context is supported.
+
+| `oidc.circleci.com/ssh-rerun`
+| A boolean indicating if the CI job is started using the SSH rerun feature.
 |===
 
 

jekyll/_cci2/parallelism-faster-jobs.md

@@ -15,6 +15,8 @@ Use parallelism and test splitting to:
 * Specify a number of [executors](/docs/executor-intro/) across which to split your tests.
 * Split your test suite using one of the options provided by the CircleCI CLI: by name, size or by using timing data.
 
+If you are interested to read about concurrent job runs, see the [Concurrency overview](/docs/concurrency) page.
+
 ## Introduction
 {: #introduction }
 
@@ -104,28 +106,21 @@ The first time the tests are run there will be no timing data for the command to
 ## Manual allocation
 {: #manual-allocation }
 
-The CLI looks up the number of available execution environments, along with the current container index (`$CIRCLE_NODE_INDEX`). Then, it uses deterministic splitting algorithms to split the test files across all available containers.
+For full control over how tests are split across parallel executors, CircleCI provides two environment variables that you can use in place of the CLI to configure each container individually.
 
-By default, the number of containers is specified by the `parallelism` key in the project configuration file. You can also manually set the number by using the `--total` flag.
+* `$CIRCLE_NODE_TOTAL` is the total number of parallel containers being used to run your job.
+* `$CIRCLE_NODE_INDEX` is the index of the specific container that is currently running.
 
-```shell
-circleci tests split --total=4 test_filenames.txt
-```
+The CLI looks up the number of available execution environments (`$CIRCLE_NODE_TOTAL`), along with the current container index (`$CIRCLE_NODE_INDEX`). Then, it uses deterministic splitting algorithms to split the test files across all available containers.
+
+The number of containers is specified by the [`parallelism` key](/docs/configuration-reference/#parallelism) in the project configuration file.
 
-Similarly, the current container index is automatically picked up from the `$CIRCLE_NODE_INDEX` environment variable, but can be manually set by using the `--index` flag.
+The current container index is automatically picked up from the `$CIRCLE_NODE_INDEX` environment variable, but can be manually set by using the `--index` flag.
 
 ```shell
 circleci tests split --index=0 test_filenames.txt
 ```
 
-## Use environment variables to split tests
-{: #using-environment-variables-to-split-tests }
-
-For full control over how tests are split across parallel executors, CircleCI provides two environment variables that you can use in place of the CLI to configure each container individually.
-
-* `$CIRCLE_NODE_TOTAL` is the total number of parallel containers being used to run your job.
-* `$CIRCLE_NODE_INDEX` is the index of the specific container that is currently running.
-
 Refer to the [Project values and variables](/docs/variables#built-in-environment-variables) page for more details.
 
 ## Other ways to split tests