fix image blocks and xrefs (#9422)

Author: rosieyohannan

jekyll/_cci2/about-circleci.adoc

@@ -32,7 +32,7 @@ The CI/CD process allows developers to release higher quality, more stable produ
 [#circleci-in-your-workflow]
 == CircleCI in your workflow
 
-A software repository on a supported version control system (VCS) needs to be authorized and added as a project on link:https://app.circleci.com/[CircleCI]. Every code change then triggers automated tests in a clean container or virtual machine. CircleCI runs each link:/docs/glossary/#job[job] in a separate xref:glossary#container[container] or link:https://circleci.com/developer/images?imageType=machine[virtual machine].
+A software repository on a supported version control system (VCS) needs to be authorized and added as a project on link:https://app.circleci.com/[CircleCI]. Every code change then triggers automated tests in a clean container or virtual machine. CircleCI runs each xref:glossary#job[job] in a separate xref:glossary#container[container] or link:https://circleci.com/developer/images?imageType=machine[virtual machine].
 
 CircleCI sends an email notification of success or failure after the tests complete. CircleCI also includes integrated xref:notifications#[Slack and IRC notifications]. Code test coverage results are available from the details page for any project for which a reporting library is added.
 

jekyll/_cci2/caching-strategy.adoc

@@ -36,7 +36,7 @@ Using cache keys that are too strict can mean that you will get a minimal number
 
 If your project has "flaky tests," workflows might be rerun unnecessarily. This will both use up your credits and increase your storage usage. To avoid this situation, address flaky tests. For help with identifying them, see xref:insights-tests#flaky-tests[Test Insights].
 
-You can also consider configuring your projects to rerun failed jobs rather than entire workflows. To achieve this you can use the `when` step. For further information, see the link:/docs/configuration-reference/#the-when-attribute[Configuration Reference].
+You can also consider configuring your projects to rerun failed jobs rather than entire workflows. To achieve this you can use the `when` step. For further information, see the xref:configuration-reference#the-when-attribute[Configuration Reference].
 
 [#split-cache-keys-by-directory]
 === Split cache keys by directory

jekyll/_cci2/concepts.adoc

@@ -476,7 +476,7 @@ A standalone project can have:
 Select *Projects* in the CircleCI web app sidebar to enter the projects dashboard. On the dashboard, you can set up and follow any project you have access to. There are two options:
 
 * _Set Up_ or _Create_ any project that you are the owner of in your VCS.
-* _Follow_ any project in your organization to gain access to its pipelines and to subscribe to link:/docs/notifications/[email notifications] for the project's status.
+* _Follow_ any project in your organization to gain access to its pipelines and to subscribe to xref:notifications#[email notifications] for the project's status.
 
 image::CircleCI-2.0-setup-project-circle101_cloud.png[Project dashboard]
 

jekyll/_cci2/config-intro.adoc

@@ -77,7 +77,7 @@ image::config-intro-part1-job.png[Successful build job]
 +
 You should see your step - The First Step - with the output of the commands:
 +
-image:config-first-step.png[Successful step within job]
+image::config-first-step.png[Successful step within job]
 
 NOTE: Although the `config.yml` syntax itself is straightforward, the indentation is more complicated. Incorrect indentation is the most common error. If you are experiencing problems with this example, check your indentation carefully, or copy and paste the sample code.
 

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

@@ -40,7 +40,7 @@ The following how-to guides are available for config policies:
 
 Config policies use a decision engine based on link:https://www.openpolicyagent.org/[Open Policy Agent (OPA)]. Policies are written in the Rego query language, as defined by OPA. Rule violations are surfaced when pipeline triggers are applied.
 
-Policies can be developed locally and pushed to CircleCI using the CircleCI CLI. Policies can be saved to a repository within your VCS. For more information see the link:/docs/create-and-manage-config-policies[Create and manage config policies] page.
+Policies can be developed locally and pushed to CircleCI using the CircleCI CLI. Policies can be saved to a repository within your VCS. For more information see the xref:create-and-manage-config-policies#[Create and manage config policies] page.
 
 CircleCI uses the result of OPA output to generate _decisions_ from policy executions. Those decisions have the following outputs:
 
@@ -151,7 +151,7 @@ After declaring the `org` package and `policy_name` rule, policies can then be d
 * Enforcement status - Determines how a violation should be enforced.
 * Enablement - Determines if a policy violation should be enabled.
 
-Using this format allows policy writers to create custom helper functions without impacting CircleCI's ability to parse policy evaluation output. You can create your own helper functions, but also CircleCI provides a set of helpers by importing `data.circleci.config` in your policies. For more information, see the link:/docs/config-policy-reference[Config policy reference].
+Using this format allows policy writers to create custom helper functions without impacting CircleCI's ability to parse policy evaluation output. You can create your own helper functions, but also CircleCI provides a set of helpers by importing `data.circleci.config` in your policies. For more information, see the xref:config-policy-reference#[Config policy reference].
 
 NOTE: **Helpers** in the context of config policies are rules like any other, but rules that are not individually _enabled_ for the process of determining policy violation. Helpers can be written and used as building blocks for your policies.
 

jekyll/_cci2/create-and-manage-config-policies.adoc

@@ -69,7 +69,7 @@ CircleCI policies are managed by pushing directories of policies to CircleCI via
 
 * Store your policies in a repository in your VCS, within your organization. This is how policies are managed internally at CircleCI. Pushing a policy bundle is done by triggering a CircleCI pipeline.
 
-* Create a bot account for pushing policies, and use its associated CircleCI personal API token for authentication. For maximum security the token should be stored as an environment variable within a context, and that context should be restricted to groups that are responsible for managing policies. For more information, see the link:/docs/contexts[Using Contexts] page.
+* Create a bot account for pushing policies, and use its associated CircleCI personal API token for authentication. For maximum security the token should be stored as an environment variable within a context, and that context should be restricted to groups that are responsible for managing policies. For more information, see the xref:contexts#[Using Contexts] page.
 
 The rest on the steps in this section show how to set up a CI/CD pipeline to manage your policies.
 
@@ -177,7 +177,7 @@ Once you have decided how to manage your policies, the next step is to create a
 [#write-your-policy]
 === 1. Write your policy
 
-CAUTION: Ensure you have authenticated your version of the CLI with a token, and updated the CLI, before attempting to use the CLI with config policies. See the link:/docs/local-cli[Installing the Local CLI] page for more information.
+CAUTION: Ensure you have authenticated your version of the CLI with a token, and updated the CLI, before attempting to use the CLI with config policies. See the xref:local-cli#[Installing the Local CLI] page for more information.
 
 . <<config-policy-management-enablement,Enable config policies>> for your organization, if you have not already done so.
 

jekyll/_cci2/creating-orbs.adoc

@@ -44,7 +44,7 @@ The included `config.yml` and `test-deploy.yml` files in the `./circleci` direct
 You can view the results of your tests directly on GitHub within the Pull Request, or, for a more detailed view, watch the entire pipeline in the CircleCI web app.
 Notice there are two workflows, `lint-pack` will run first and contains our linting, ShellCheck, review, and will publish a development version to be tested in the second workflow. The `test-deploy` workflow contains our integration tests, and can publish the production version of our orb when ready.
 +
-image:orbtools-11-checks.png[Orb test results as reported by GitHub Checks API on pull request]
+image::orbtools-11-checks.png[Orb test results as reported by GitHub Checks API on pull request]
 . *"Squash" Merge.*
 +
 When your changes are complete, we recommend (not required) link:https://docs.github.com/en/pull-requests/collaborating-with-pull-requests/incorporating-changes-from-a-pull-request/about-pull-request-merges#squash-and-merge-your-pull-request-commits[Squash Merging] your changes into a single commit, with a link:https://www.conventionalcommits.org/[Conventional Commit Message].

jekyll/_cci2/dynamic-config.adoc

@@ -36,7 +36,7 @@ To enable dynamic configuration in CircleCI:
 . From the sidebar, select *Advanced*.
 . Scroll to the *Enable dynamic config using setup workflows* setting, and toggle it to the "on" position, as shown below:
 +
-image:dynamic-config-enable.png[Enable dynamic config in the UI]
+image::dynamic-config-enable.png[Enable dynamic config in the UI]
 
 These steps make dynamic configuration features available for your project, but any _static_ `config.yml` you have previously set up will continue to work as normal.
 

jekyll/_cci2/executor-intro.adoc

@@ -67,7 +67,7 @@ jobs:
         # Commands run in the primary container
 ----
 
-Find out more about the Docker execution environment on the link:/docs/using-docker/[Using Docker] page.
+Find out more about the Docker execution environment on the xref:using-docker#[Using Docker] page.
 
 [#linux-vm]
 == Linux VM

jekyll/_cci2/glossary.adoc

@@ -96,7 +96,7 @@ A feature that enables building, running, and pushing images to Docker registrie
 
 [#resource-class]
 == Resource class
-A configuration option for specifying compute resource sizing for a job. Also used as a label to identify a pool of self-hosted runners and to configure a job to run on a self-hosted runner from that pool. Read more on the link:/docs/resource-class-overview[resource class overview] page.
+A configuration option for specifying compute resource sizing for a job. Also used as a label to identify a pool of self-hosted runners and to configure a job to run on a self-hosted runner from that pool. Read more on the xref:resource-class-overview#[resource class overview] page.
 
 [#step]
 == Step