diff --git a/docs/guides/modules/config-policies/pages/config-policy-management-overview.adoc b/docs/guides/modules/config-policies/pages/config-policy-management-overview.adoc index 15c5f45d5a..4d61355005 100644 --- a/docs/guides/modules/config-policies/pages/config-policy-management-overview.adoc +++ b/docs/guides/modules/config-policies/pages/config-policy-management-overview.adoc @@ -155,9 +155,6 @@ input.workflows # an array of nested structures mirroring workflows in the C input.jobs # an array of nested structures mirroring jobs in the CircleCI config ---- -[#define-a-rule] -==== Define a rule - In OPA, rules can produce any type of output. At CircleCI, rules that produce violations must have outputs of the following types: * String @@ -168,7 +165,7 @@ This restriction is in place so that rule violations produce error messages that Helper rules that produce differently typed outputs can still be defined, but rules that will be considered when making CircleCI decisions must have the output types specified above. For more information see the <<#enablement>> section below. [#evaluation] -===== Evaluation +==== Evaluation Evaluation is how the decision engine determines if a config violates the given policy. The evaluation defines the name and ID of the rule, checks a condition, and returns a user-friendly string describing the violation. Rule evaluations include the **rule name** and an **optional rule ID**. The rule name will be used to enable and set the enforcement level for a rule. @@ -217,7 +214,7 @@ docker_images := {image | walk(input, [path, value]) # walk the entire config t ---- [#enforcement] -===== Enforcement +==== Enforcement The policy service allows rules to be enforced at different levels. @@ -239,7 +236,7 @@ hard_fail["use_official_docker_image"] ---- [#enablement] -===== Enablement +==== Enablement A rule must be enabled for it to be inspected for policy violations. Rules that are not enabled do not need to match CircleCI violation output formats, and can be used as helpers for other rules. diff --git a/docs/guides/modules/deploy/pages/deployment-overview.adoc b/docs/guides/modules/deploy/pages/deployment-overview.adoc index ae54adb61c..bf9350bbbc 100644 --- a/docs/guides/modules/deploy/pages/deployment-overview.adoc +++ b/docs/guides/modules/deploy/pages/deployment-overview.adoc @@ -187,14 +187,12 @@ Labels are composed of two values separated by a colon, for example, `team:my-te Once you have added labels to your components and environments, you can use them to filter your view in the deploys UI. In the timeline, environments, or components view, select a filter to reduce the content in the tab to only your selection. You can also use the label filter dropdown menu at the top of the page. -==== Add or edit labels - To add or edit labels follow the steps below. .Add and Edit environment and component labels image::guides:ROOT:releases/edit-labels.png[Screenshot showing the location of the add/edit labels button] -===== Component labels +==== Component labels To add or edit labels for a component, follow these steps: @@ -204,7 +202,7 @@ To add or edit labels for a component, follow these steps: . You are now on the component view page. Select the edit button image:guides:ROOT:icons/edit-solid.svg[edit icon, role="no-border"] in the labels panel. . Enter or edit your label(s) and select btn:[Done]. -===== Environment labels +==== Environment labels To add or edit labels for an environment, follow these steps: diff --git a/docs/guides/modules/execution-runner/pages/container-runner.adoc b/docs/guides/modules/execution-runner/pages/container-runner.adoc index 87cd0a57f4..1ce64aed0e 100644 --- a/docs/guides/modules/execution-runner/pages/container-runner.adoc +++ b/docs/guides/modules/execution-runner/pages/container-runner.adoc @@ -198,7 +198,7 @@ Image match types govern how images are matched for container customization. The * *Default:* The `Default` match type applies when an image did not match any of the other image match types. It sets a single specification for all such service containers. -===== Order of precedence +==== Order of precedence Selectors follow the hierarchy: `Exact` -> `Prefix` -> `Pattern` -> `Default`. If a given image name does not match any rule in the hierarchy, it defaults to the `Default` rule. @@ -237,7 +237,7 @@ agent: memory: "200Mi" ---- -===== Order of precedence +==== Order of precedence The `Resource class` scope overrides any `Global` scope selection for a given match type. If a match is available in both scopes, the `Resource class` scope prevails. diff --git a/docs/guides/modules/execution-runner/pages/runner-api.adoc b/docs/guides/modules/execution-runner/pages/runner-api.adoc index 637663b94f..f34b372f42 100644 --- a/docs/guides/modules/execution-runner/pages/runner-api.adoc +++ b/docs/guides/modules/execution-runner/pages/runner-api.adoc @@ -65,7 +65,7 @@ Lists the available self-hosted runners based on the specified parameters. It is ** This allows the endpoint to be accessible on circleci.com/api/v3/runner for users that have already logged into circleci.com [#get-api-v3-runner-request] -===== Request +==== Request [cols=5*, options="header"] |=== diff --git a/docs/guides/modules/execution-runner/pages/runner-upgrading-on-server.adoc b/docs/guides/modules/execution-runner/pages/runner-upgrading-on-server.adoc index 26a3bdbd01..ddf0035d2e 100644 --- a/docs/guides/modules/execution-runner/pages/runner-upgrading-on-server.adoc +++ b/docs/guides/modules/execution-runner/pages/runner-upgrading-on-server.adoc @@ -88,27 +88,42 @@ Set-ExecutionPolicy Bypass -Scope Process -Force; [System.Net.ServicePointManage The currently running `circleci-launch-agent` process will need to be halted before starting the newly updated binary. Platform-specific instructions for this are given below. -[#stopping-the-machine-runner-on-linux] -===== Stopping the machine runner on Linux - +[tabs] +==== +Linux:: ++ +-- Run the following commands: ```shell sudo systemctl stop circleci.service sudo systemctl disable circleci.service ``` +-- +Mac:: ++ +-- +Run the following command: -[#stopping-the-machine-runner-on-mac] -===== Stopping the machine runner on Mac - -Run the following commands: ```shell sudo launchctl unload '/Library/LaunchDaemons/com.circleci.runner.plist' ``` +-- +Windows:: ++ +-- +Run the following command: + + +``` powershell +Stop-ScheduledTask -TaskName "CircleCI Launch Agent" +``` +-- +==== [#stopping-the-machine-runner-on-windows] -===== Stopping the machine runner on Windows +==== Stopping the machine runner on Windows Run the following command: @@ -121,9 +136,11 @@ Stop-ScheduledTask -TaskName "CircleCI Launch Agent" Platform-specific instructions are given below. -[#starting-on-linux] -===== Starting on Linux - +[tabs] +==== +Linux:: ++ +-- Run the following commands: ```shell @@ -131,24 +148,26 @@ sudo systemctl reload circleci.service sudo systemctl enable circleci.service sudo systemctl start circleci.service ``` - -[#starting-on-mac] -===== Starting on Mac - +-- +Mac:: ++ +-- Run the following command: ```shell sudo launchctl load '/Library/LaunchDaemons/com.circleci.runner.plist' ``` - -[#starting-on-windows] -===== Starting on Windows - -Run the following commands: +-- +Windows:: ++ +-- +Run the following command: ``` powershell Start-ScheduledTask -TaskName "CircleCI Launch Agent" ``` +-- +==== [#additional-resources] === Additional resources diff --git a/docs/guides/modules/optimize/pages/use-the-circleci-cli-to-split-tests.adoc b/docs/guides/modules/optimize/pages/use-the-circleci-cli-to-split-tests.adoc index cfb3671b52..663436fc87 100644 --- a/docs/guides/modules/optimize/pages/use-the-circleci-cli-to-split-tests.adoc +++ b/docs/guides/modules/optimize/pages/use-the-circleci-cli-to-split-tests.adoc @@ -62,7 +62,7 @@ Two commands are available for you to split your tests. We recommend using `circ Alternatively, you can see `circleci tests split` examples <> [#tests-run-examples] -==== Test framework examples using `circleci tests run` +== Test framework examples using circleci tests run The following set of examples show how to use the `circelci tests run` command to split and run your tests across parallel execution environments. Using this command also allows you to use the xref:test:rerun-failed-tests.adoc[rerun failed tests] feature. @@ -76,7 +76,7 @@ Some notes on the examples below: * If you do not use `store_test_results`, there will be no timing data available to split your tests. [#ruby-rspec-tests] -===== Ruby (RSpec) +=== Ruby (RSpec) . Add the following gem to your Gemfile: + @@ -108,7 +108,7 @@ jobs: ** Update the `glob` command to match your use case. See the RSpec section in the xref:test:collect-test-data.adoc#rspec[Collect Test Data] document for details on how to output test results in an acceptable format for `rspec`. [#configure-a-job-running-ruby-cucumber-tests] -===== Ruby (Cucumber) +=== Ruby (Cucumber) Modify your CircleCI configuration file to specify parallelism, and update your test command to use `circleci tests run`: @@ -133,7 +133,7 @@ jobs: * Update the `glob` command to match your use case. See the Cucumber section in the xref:test:collect-test-data.adoc#cucumber[Collect Test Data] document for details on how to output test results in an acceptable format for `Cucumber`. [#cypress-tests] -===== Cypress +=== Cypress . Use the link:https://www.npmjs.com/package/cypress-circleci-reporter[`cypress-circleci-reporter`] (this is a 3rd party tool that is not maintained by CircleCI). You can install the tool in your `.circleci/config.yml` or add to your `package.json`. Example for adding to `.circleci/config.yml`: + @@ -178,7 +178,7 @@ jobs: ** Cypress may output a warning: `Warning: It looks like you're passing --spec a space-separated list of arguments:`. This can be ignored, but it can be removed by following the guidance from our link:https://discuss.circleci.com/t/product-launch-re-run-failed-tests-only-circleci-tests-run/47775/18[community forum]. [#javascript-typescript-jest-tests] -===== JavaScript/TypeScript (Jest) +=== JavaScript/TypeScript (Jest) . Install the `jest-junit` dependency. You can add this step in your `.circleci/config.yml`: + @@ -217,7 +217,7 @@ jobs: ** `JEST_JUNIT_ADD_FILE_ATTRIBUTE=true` is added to ensure that the `file` attribute is present. `JEST_JUNIT_ADD_FILE_ATTRIBUTE=true` can also be added to your `jest.config.js` file instead of including it in `.circleci/config.yml`, by using the following attribute: `addFileAttribute="true"`. [#playwright-tests] -===== Playwright +=== Playwright Modify your CircleCI configuration file to specify parallelism, and update your test command to use `circleci tests run`: @@ -246,7 +246,7 @@ jobs: * Ensure that you are using version 1.34.2 or later of Playwright. Earlier versions of Playwright may not output JUnit XML in a format that is compatible with this feature. [#kotlin-or-gradle-tests] -===== Kotlin or Gradle +=== Kotlin or Gradle . Modify your CircleCI configuration file to specify parallelism, and update your test command to use `circleci tests run`: + @@ -280,7 +280,7 @@ jobs: . Update the `glob` command to match your use case. [#configure-a-job-running-go-tests] -===== Go +=== Go Modify your CircleCI configuration file to specify parallelism, and update your test command to use `circleci tests run`: @@ -302,7 +302,7 @@ jobs: * Ensure you are using `xargs` in your `circleci tests run` command to pass the list of test files/classnames via stdin to `--command`. [#elixir-tests] -===== Elixir +=== Elixir Modify your CircleCI configuration file to specify parallelism, and update your test command to use `circleci tests run`: @@ -332,7 +332,7 @@ jobs: * Update the `glob` command to match your use case. [#configure-a-job-running-phpunit-tests] -===== PHPUnit +=== PHPUnit Modify your CircleCI configuration file to specify parallelism, and update your test command to use `circleci tests run`: @@ -362,7 +362,7 @@ jobs: * Note that this example uses a utility named link:https://github.com/previousnext/phpunit-finder[`phpunit-finder`] which is a third party tool that is not supported by CircleCI, use at your own risk. [#configure-django-tests] -===== Django +=== Django Modify your CircleCI configuration file to specify parallelism, and update your test command to use `circleci tests run`. Also, Django takes as input test filenames with a format that uses dots ("."), however, it outputs JUnit XML in a format that uses slashes "/". To account for this, get the list of test filenames first, change the filenames to be separated by dots "." instead of slashes "/", and pass the filenames into the test command. @@ -393,7 +393,7 @@ jobs: . Ensure you are using `xargs` in your `circleci tests run` command to pass the list of test files/classnames via stdin to `--command`. [#output-test-files-only] -===== Output test files only +=== Output test files only If your testing set-up on CircleCI is not compatible with invoking your test runner in the `circleci tests run` command, you can opt to use `circleci tests run` to: @@ -520,7 +520,7 @@ The available timing data will then be analyzed and your tests will be split acr NOTE: If no timing data is found, you will receive a message: `Error auto-detecting timing type, falling back to weighting by name.`. The tests will then be split alphabetically by test name. [#set-the-timing-type] -===== Set the timing type +=== Set the timing type The environment CLI attempts to autodetect the granularity of the test split (for example, whether to split by filename, or down to class name) based on the input. You may need to choose a different timing type depending on how your test coverage output is formatted, using the `--timings-type` option. Valid timing types are: @@ -534,7 +534,7 @@ cat my_java_test_classnames | circleci tests split --split-by=timings --timings- ``` [#set-the-default-value-for-missing-timing-data] -===== Set the default value for missing timing data +=== Set the default value for missing timing data For partially found test results, any tests with missing data are assigned a random small value. You can override this default value with the `--time-default` flag: @@ -543,7 +543,7 @@ circleci tests glob "**/*.rb" | circleci tests split --split-by=timings --time-d ``` [#download-timing-data] -===== Download timing data +=== Download timing data If you need to manually store and retrieve timing data, add the xref:reference:ROOT:configuration-reference.adoc#storeartifacts[`store_artifacts` step] to your job. diff --git a/docs/guides/modules/permissions-authentication/pages/openid-connect-tokens.adoc b/docs/guides/modules/permissions-authentication/pages/openid-connect-tokens.adoc index 0ff5a6afc0..e3f5210744 100644 --- a/docs/guides/modules/permissions-authentication/pages/openid-connect-tokens.adoc +++ b/docs/guides/modules/permissions-authentication/pages/openid-connect-tokens.adoc @@ -216,7 +216,7 @@ workflows: You can take advantage of the format of the claims in CircleCI's <> to limit what your CircleCI jobs can do in AWS. [#limit-role-access-based-on-project] -===== Limit role access based on project +=== Limit role access based on project If certain projects should only be able to access certain AWS resources, you can restrict your IAM role so that only CircleCI jobs in a specific project can assume that role. @@ -235,7 +235,7 @@ To do this, edit your IAM role's trust policy so that only an OIDC token from yo This uses https://docs.aws.amazon.com/IAM/latest/UserGuide/reference_policies_elements_condition_operators.html#Conditions_String[StringLike] to match the sub claim of CircleCI's OIDC token in your chosen project. Now, jobs in your other projects cannot assume this role. [#limit-role-access-based-on-branch] -===== Limit role access based on branch +=== Limit role access based on branch You can also restrict access to specific branches. The following is an example of a trust policy that restricts the `AssumeRoleWithWebIdentity` action to any project pipelines running only on the `main` branch in the `my-org` GitHub organization and the CircleCI organization with the ID: `organization_id`. Note that the `sub` claim uses the `$CIRCLE_OIDC_TOKEN_V2` format. diff --git a/docs/guides/modules/toolkit/pages/environment-cli-usage-guide.adoc b/docs/guides/modules/toolkit/pages/environment-cli-usage-guide.adoc index 6a0d9d6568..0d3d1e2b84 100644 --- a/docs/guides/modules/toolkit/pages/environment-cli-usage-guide.adoc +++ b/docs/guides/modules/toolkit/pages/environment-cli-usage-guide.adoc @@ -109,7 +109,7 @@ For more information, including an example, see the xref:permissions-authenticat A subcommand of `run`. The `circleci run release` commands allow you to manage your deployments. -===== Plan +==== Plan A subcommand of `release`. The `circleci run release plan` command is used to plan and identify a new deployment that will be referenced in the CircleCI UI. When a release is planned you can then update its status later in your pipeline to track progress of a deployment. @@ -154,7 +154,7 @@ jobs: For more information on using the `circleci run release plan` command, see the xref:deploy:configure-deploy-markers.adoc[Configure deploy markers] page. -===== Update +==== Update WARNING: The `circleci run release update` command is only for use with deploy markers. If you are using the CircleCI xref:deploy:release-agent-overview.adoc[release agent] for Kubernetes deployments, do NOT use the `update` commands. The release agent automatically handles status updates for you. @@ -187,7 +187,7 @@ jobs: For more information on using the `circleci run release update` command, see the xref:deploy:configure-deploy-markers.adoc[Configure deploy markers] page. -===== Log +==== Log A subcommand of `release`. The `circleci run release log` command allows you to log your deployments without status updates diff --git a/docs/orbs/modules/author/pages/orb-author.adoc b/docs/orbs/modules/author/pages/orb-author.adoc index 648dd82c49..0c0ca99358 100644 --- a/docs/orbs/modules/author/pages/orb-author.adoc +++ b/docs/orbs/modules/author/pages/orb-author.adoc @@ -180,7 +180,7 @@ The directories listed above represent orb components that can be included with Each directory within `src` corresponds with a xref:reference:ROOT:reusing-config.adoc[reusable configuration] component type, which can be added or removed from the orb. If, for example, your orb does not require any `executors` or `jobs`, these directories can be deleted. [#orbyml] -===== @orb.yml +==== @orb.yml @orb.yml acts as the "root" to your orb project and contains the config version, the orb description, the display key, and imports any additional orbs if needed. @@ -199,7 +199,7 @@ display: ---- [#commands] -===== Commands +==== Commands Author and add xref:reference:ROOT:reusing-config.adoc#authoring-reusable-commands[Reusable Commands] to the `src/commands` directory. Each _YAML_ file within this directory will be treated as an orb command, with a name which matches its filename. @@ -224,7 +224,7 @@ steps: ---- [#examples] -===== Examples +==== Examples Author and add xref:orb-concepts.adoc#usage-examples[Usage Examples] to the `src/examples` directory. Usage examples are not for use directly by end users in their configs. They provide a way for you to share use-case specific examples for users to reference. @@ -233,7 +233,7 @@ Each _YAML_ file within this directory will be treated as an orb usage example, View a full example from the link:https://github.com/CircleCI-Public/Orb-Template/tree/main/src/examples[Orb Template]. [#executors] -===== Executors +==== Executors Author and add xref:reference:ROOT:reusing-config.adoc#authoring-reusable-executors[Parameterized Executors] to the `src/executors` directory. @@ -242,7 +242,7 @@ Each _YAML_ file within this directory will be treated as an orb executor, with View a full example from the link:https://github.com/CircleCI-Public/Orb-Template/tree/main/src/executors[Orb Template]. [#jobs] -===== Jobs +==== Jobs Author and add xref:reference:ROOT:reusing-config.adoc#authoring-parameterized-jobs[Parameterized Jobs] to the `src/jobs` directory. @@ -316,7 +316,7 @@ steps: ==== [#why-include-scripts] -===== Why include scripts? +==== Why include scripts? CircleCI configuration is written in `YAML`. Logical code such as `bash` can be encapsulated and executed on CircleCI through `YAML`, but, for developers, it is not convenient to write and test programmatic code within a non-executable format. Also, parameters can become cumbersome in more complex scripts as the `\<>` syntax is a CircleCI native YAML enhancement, and not something that can be interpreted and executed locally. @@ -327,7 +327,7 @@ Using the orb development kit and the `\<>` syntax, you can: * Utilize true testing frameworks for your code. [#using-parameters-with-scripts] -===== Using parameters with scripts +==== Using parameters with scripts To keep your scripts portable and locally executable, it is best practice to expect a set of environment variables within your scripts and set them at the config level. The `greet.sh` file, which was included with the special `\<>` syntax above in our `greet.yml` command file, looks like this: diff --git a/docs/reference/modules/ROOT/pages/configuration-reference.adoc b/docs/reference/modules/ROOT/pages/configuration-reference.adoc index 151e55bf1d..7e73a1149a 100644 --- a/docs/reference/modules/ROOT/pages/configuration-reference.adoc +++ b/docs/reference/modules/ROOT/pages/configuration-reference.adoc @@ -515,7 +515,7 @@ jobs: For more information on cache retention, see the xref:guides:optimize:persist-data.adoc#custom-storage-usage[Persisting data overview] page. [#retention-errors] -===== Common errors +==== Common errors When configuring job retention, you may encounter the following validation errors: @@ -630,7 +630,7 @@ workflows: ''' [#executor-job] -==== Executor *`docker`* / *`machine`* / *`macos`* +== Executor *`docker`* / *`machine`* / *`macos`* CircleCI offers several execution environments in which to run your jobs. To specify an execution environment choose an _executor_, then specify and image and a resource class. An executor defines the underlying technology, environment, and operating system in which to run a job. @@ -641,7 +641,7 @@ Learn more about execution environments and executors in the xref:guides:executi ''' [#docker] -==== `docker` +=== `docker` Configure a job to use the Docker execution environment using the `docker` key which takes a list of maps: @@ -719,7 +719,7 @@ workflows: ''' [#docker-auth] -===== Docker registry authentication +==== Docker registry authentication Some registries, Docker Hub, for example, may rate limit anonymous Docker pulls. We recommend that you authenticate to pull private and public images. The username and password can be specified in the `auth` field. See xref:guides:execution-managed:private-images.adoc#[Using Docker Authenticated Pulls] for details. @@ -764,12 +764,12 @@ jobs: ''' [#aws-authentication] -===== AWS authentication +==== AWS authentication Using an image hosted on https://aws.amazon.com/ecr/[AWS ECR] requires authentication using AWS credentials. The two configuration options are described in the following sections. [#oidc] -====== Use OIDC +==== Use OIDC Authenticate using OpenID Connect (OIDC) using the `oidc_role_arn` field, as follows: @@ -788,7 +788,7 @@ jobs: For steps to get set up with OIDC to pull images from AWS ECR, see the xref:guides:permissions-authentication:pull-an-image-from-aws-ecr-with-oidc.adoc#[Pull and image from AWS ECR with OIDC] page. [#env-vars] -====== Use environment variables +==== Use environment variables 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: @@ -808,7 +808,7 @@ jobs: ''' [#machine] -==== *`machine`* +=== *`machine`* NOTE: *Using CircleCI cloud?* The use of `machine: true` is deprecated. You must specify an image to use. @@ -864,7 +864,7 @@ jobs: ''' [#available-linux-machine-images-cloud] -===== Linux `machine` images +==== Linux `machine` images *Specifying an image in your configuration file is strongly recommended.* CircleCI supports multiple Linux machine images that can be specified in the `image` field. For a full list of supported image tags, refer to the following pages in the Developer Hub: @@ -878,14 +878,14 @@ The machine executor supports xref:guides:optimize:docker-layer-caching.adoc#[Do ''' [#available-linux-machine-images-server] -===== Linux `machine` images on server +==== Linux `machine` images on server If you are using CircleCI server, contact your system administrator for details of available Linux machine images. ''' [#available-linux-gpu-images] -===== Linux GPU `machine` images +==== Linux GPU `machine` images When using the Linux xref:guides:execution-managed:using-gpu.adoc#[GPU executor], the available images are: @@ -895,7 +895,7 @@ When using the Linux xref:guides:execution-managed:using-gpu.adoc#[GPU executor] ''' [#available-android-machine-images] -===== Android `machine` images +==== Android `machine` images CircleCI supports running jobs on Android for testing and deploying Android applications. @@ -918,7 +918,7 @@ For examples, refer to the xref:guides:execution-managed:android-machine-image.a ''' [#available-windows-machine-images-cloud] -===== Windows `machine` images +==== Windows `machine` images *Specifying an image in your configuration file is strongly recommended.* CircleCI supports multiple Windows machine images that can be specified in the `image` field. @@ -934,14 +934,14 @@ Alternatively, use the link:https://circleci.com/developer/orbs/orb/circleci/win ''' [#available-windows-machine-images-server] -===== Windows `machine` images on server +==== Windows `machine` images on server If you are using CircleCI server, contact your system administrator for details of available Windows machine images. ''' [#available-windows-gpu-image] -===== Windows GPU `machine` image +==== Windows GPU `machine` image When using the Windows xref:guides:execution-managed:using-gpu.adoc#[GPU executor], the available image is: @@ -962,7 +962,7 @@ jobs: ''' [#macos] -==== *`macos`* +=== *`macos`* CircleCI supports running jobs on link:https://developer.apple.com/macos/[macOS], to allow you to build, test, and deploy apps for macOS, link:https://developer.apple.com/ios/[iOS], link:https://developer.apple.com/tvos/[tvOS] and https://developer.apple.com/watchos/[watchOS]. To run a job on a macOS virtual machine, add the `macos` key to the top-level configuration for your job and specify the version of Xcode to use. @@ -996,7 +996,7 @@ This key is deprecated. Use <> to control which ''' [#resourceclass] -==== *`resource_class`* +== *`resource_class`* The `resource_class` feature allows you to configure CPU and RAM resources for each job. Resource classes are available for each execution environment, as described in the tables below. @@ -1011,7 +1011,7 @@ NOTE: If you want to confirm how much memory you have been allocated, you can ch ''' [#self-hosted-runner] -===== Self-hosted runner +=== Self-hosted runner Use the `resource_class` key to configure a xref:guides:execution-runner:runner-overview.adoc#[self-hosted runner instance]. @@ -1028,7 +1028,7 @@ jobs: ''' [#docker-execution-environment] -===== Docker execution environment +=== Docker execution environment *Example:* @@ -1044,19 +1044,19 @@ jobs: ---- [#x86] -====== x86 +==== x86 include::guides:ROOT:partial$execution-resources/docker-resource-table.adoc[] [#arm] -====== Arm +==== Arm include::guides:ROOT:partial$execution-resources/docker-arm-resource-table.adoc[] ''' [#linuxvm-execution-environment] -===== LinuxVM execution environment +==== LinuxVM execution environment include::guides:ROOT:partial$execution-resources/machine-resource-table.adoc[] @@ -1096,7 +1096,7 @@ jobs: ''' [#macos-execution-environment] -===== macOS execution environment +==== macOS execution environment include::guides:ROOT:partial$execution-resources/macos-resource-table.adoc[] @@ -1116,14 +1116,14 @@ jobs: ''' [#macos-server] -===== macOS execution environment on server +==== macOS execution environment on server If you are working on CircleCI server you can access the macOS execution environment using xref:guides:execution-runner:runner-overview.adoc#[self-hosted runner]. ''' [#windows-execution-environment] -===== Windows execution environment +==== Windows execution environment include::guides:ROOT:partial$execution-resources/windows-resource-table.adoc[] @@ -1172,7 +1172,7 @@ jobs: ''' [#gpu-execution-environment-linux] -===== GPU execution environment (Linux) +==== GPU execution environment (Linux) include::guides:ROOT:partial$execution-resources/gpu-linux-resource-table.adoc[] @@ -1197,7 +1197,7 @@ See the <> section for th ''' [#gpu-execution-environment-windows] -===== GPU execution-environment (Windows) +==== GPU execution-environment (Windows) include::guides:ROOT:partial$execution-resources/gpu-windows-resource-table.adoc[] @@ -1223,7 +1223,7 @@ jobs: ''' [#arm-execution-environment-linux] -===== Arm VM execution-environment +==== Arm VM execution-environment include::guides:ROOT:partial$execution-resources/arm-resource-table.adoc[] @@ -1266,7 +1266,7 @@ jobs: ''' [#steps] -==== *`steps`* +== *`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: @@ -1332,7 +1332,7 @@ Each built-in step is described in detail below. ''' [#run] -===== *`run`* +=== *`run`* The `run` step is used to invoke command-line programs. The `run` step takes either a map of configuration values, or, when called in its short-form, a string that will be used as both the `command` and `name`. Run commands are executed using non-login shells by default, so you must explicitly source any `dotfiles` as part of the command. @@ -1407,7 +1407,7 @@ You can also configure commands to run <> ''' [#default-shell-options] -====== _Default shell options_ +==== _Default shell options_ For jobs that run on *Linux*, the default value of the `shell` option is `/bin/bash -eo pipefail` if `/bin/bash` is present in the build container. Otherwise it is `/bin/sh -eo pipefail`. The default shell is not a login shell (`--login` or `-l` are not specified). Hence, the shell will *not* source your `~/.bash_profile`, `~/.bash_login`, `~/.profile` files. @@ -1417,7 +1417,7 @@ For more information about which files are executed when Bash is invocated, link Descriptions of the `-eo pipefail` options are provided below. -====== `-e` +==== `-e` Exit immediately if any of the following exits with a non-zero status: @@ -1446,7 +1446,7 @@ In the previous example, `mkdir` failed to create a directory and returned a non make test ---- -====== `-o pipefail` +==== `-o pipefail` If `pipefail` is enabled, the pipeline's return status is the value of the last (rightmost) command to exit with a non-zero status, or zero if all commands exit successfully. The shell waits for all commands in the pipeline to terminate before returning a value. @@ -1470,7 +1470,7 @@ For more information, see the xref:guides:orchestrate:using-shell-scripts.adoc#[ ''' [#background-commands] -====== _Background commands_ +==== _Background commands_ The `background` attribute enables you to configure commands to run in the background. Job execution will immediately proceed to the next step rather than waiting for return of a command with the `background` attribute set to `true`. The following example shows the configuration for running the X virtual framebuffer in the background which is commonly required to run Selenium tests. @@ -1489,7 +1489,7 @@ The `background` attribute enables you to configure commands to run in the backg ''' [#shorthand-syntax] -====== _Shorthand syntax_ +==== _Shorthand syntax_ `run` has a very convenient shorthand syntax. @@ -1510,7 +1510,7 @@ In this case, `command` and `name` become the string value of `run`, and the res ''' [#the-when-attribute] -====== The `when` attribute +==== The `when` attribute By default, CircleCI will execute job steps one at a time, in the order that they are defined in `config.yml`, until a step fails (returns a non-zero exit code). After a command fails, no further job steps will be executed. @@ -1539,7 +1539,7 @@ NOTE: Some steps, such as `store_artifacts` and `store_test_results` will always ''' [#ending-a-job-from-within-a-step] -====== Ending a job from within a `step` +==== Ending a job from within a `step` A job can exit without failing by using `run: circleci-agent step halt`. However, if a step within the job is already failing then the job will continue to fail. This can be useful in situations where jobs need to conditionally execute. @@ -1556,7 +1556,7 @@ A job can exit without failing by using `run: circleci-agent step halt`. However ''' [#the-when-step] -===== *The `when` step* +=== *The `when` step* NOTE: The `when` and `unless` steps are supported in `version: 2.1` configuration @@ -1611,7 +1611,7 @@ workflows: ''' [#checkout] -===== *`checkout`* +=== *`checkout`* **** *Blobless clones* @@ -1686,12 +1686,12 @@ NOTE: The `checkout` step will configure Git to skip automatic garbage collectio ''' [#setupremotedocker] -===== *`setup_remote_docker`* +=== *`setup_remote_docker`* [NOTE] ==== * `setup_remote_docker` is not compatible with the `machine` executor. See xref:guides:optimize:docker-layer-caching.adoc#machine-executor[Docker Layer Caching in Machine Executor] for information on how to enable DLC with the `machine` executor. -* The `version` key is not currently supported on CircleCI server. Contact your system administrator for information about the Docker version installed in your remote Docker environment. If you are on server 4.x, you can find the default AWS AMI xref:server-admin:operator:manage-virtual-machines-with-machine-provisioner.adoc#x86-ami-list[here]. +* The `version` key is not currently supported on CircleCI server. Contact your system administrator for information about the Docker version installed in your remote Docker environment. If you are on server 4.x, you can find the default AWS AMI xref:server-admin:operator:manage-virtual-machines-with-machine-provisioner.adoc#default-aws-ami-lists[here]. ==== Allows Docker commands to be run locally. See xref:guides:execution-managed:building-docker-images.adoc#[Running Docker commands] for details. @@ -1728,7 +1728,7 @@ jobs: ''' [#savecache] -===== *`save_cache`* +=== *`save_cache`* Generates and stores a cache of a file or directory of files such as dependencies or source code. Caches are stored in CircleCI's object storage. Later jobs can <>. Learn more on the xref:guides:optimize:caching.adoc#[Caching dependencies] page. @@ -1834,7 +1834,7 @@ Wildcards are not currently supported in `save_cache` paths. Visit the link:http ''' [#restorecache] -===== *`restore_cache`* +=== *`restore_cache`* Restores a previously saved cache based on a `key`. Cache needs to have been saved first for this key using the <>. Learn more in xref:guides:optimize:caching.adoc#[the caching documentation]. @@ -1915,14 +1915,14 @@ A path is not required here because the cache will be restored to the location f ''' [#deploy-deprecated] -===== *`deploy` - DEPRECATED* +=== *`deploy` - DEPRECATED* See <> for current processes. If you have parallelism `> 1` in your job, see the xref:guides:orchestrate:migrate-from-deploy-to-run.adoc#[Migrate from deploy to run] guide. ''' [#storeartifacts] -===== *`store_artifacts`* +=== *`store_artifacts`* Step to store artifacts (for example logs, binaries, etc) to be available in the web app or through the API. See the xref:guides:optimize:artifacts.adoc#[Uploading Artifacts] page for more information. @@ -1960,7 +1960,7 @@ Artifact storage retention can be customized on the link:https://app.circleci.co ''' [#storetestresults] -===== *`store_test_results`* +=== *`store_test_results`* Special step used to upload and store test results for a build. Test results are visible on the CircleCI web application under each build's *Test Summary* section. Storing test results is useful for timing analysis of your test suites. For more information on storing test results, see the xref:guides:test:collect-test-data.adoc#[Collecting Test Data] page. @@ -2002,7 +2002,7 @@ test-results ''' [#persisttoworkspace] -===== *`persist_to_workspace`* +=== *`persist_to_workspace`* Special step used to persist a temporary file to be used by another job in the workflow. For more information on using workspaces, see the xref:guides:orchestrate:workspaces.adoc#[Using Workspaces to Share Data Between Jobs] page. @@ -2084,7 +2084,7 @@ NOTE: Everything must be relative to the work space root directory. ''' [#attachworkspace] -===== *`attach_workspace`* +=== *`attach_workspace`* Special step used to attach the workflow's workspace to the current container. The full contents of the workspace are downloaded and copied into the directory the workspace is being attached at. For more information on using workspaces, see the xref:guides:orchestrate:workspaces.adoc#[Using workspaces] page. @@ -2113,7 +2113,7 @@ NOTE: The lifetime of artifacts, workspaces, and caches can be customized on the ''' [#add-ssh-keys] -===== *`add_ssh_keys`* +=== *`add_ssh_keys`* Special step that adds SSH keys from a project's settings to a container. Also configures SSH to use these keys. For more information on SSH keys see the xref:guides:integration:github-integration.adoc#create-additional-github-ssh-keys[Create additional GitHub SSH keys] page. @@ -2143,7 +2143,7 @@ NOTE: Even though CircleCI uses `ssh-agent` to sign all added SSH keys, you *mus ''' [#using-pipeline-values] -===== Using `pipeline` values +=== Using `pipeline` values Pipeline values are available to all pipeline configurations and can be used without previous declaration. For a list of pipeline values, see the xref:guides:orchestrate:pipeline-variables.adoc#[Pipeline values and parameters] page. @@ -2166,7 +2166,7 @@ jobs: ''' [#circleciipranges] -==== *`circleci_ip_ranges`* +== *`circleci_ip_ranges`* NOTE: A paid account on a https://circleci.com/pricing/[Performance or Scale Plan] is required to access IP ranges. @@ -2243,7 +2243,7 @@ workflows: ''' -==== *`max_auto_reruns`* +=== *`max_auto_reruns`* The `max_auto_reruns` key is used to configure the maximum number of automatic reruns for a workflow. @@ -2270,7 +2270,7 @@ For more information, see the xref:guides:orchestrate:automatic-reruns.adoc[Auto ''' [#triggers] -==== *`triggers`* +=== *`triggers`* Specifies which triggers will cause this workflow to be executed. Default behavior is to trigger the workflow when pushing to a branch. @@ -2303,7 +2303,7 @@ workflows: ''' [#schedule] -===== *`schedule`* +==== *`schedule`* NOTE: Scheduled workflows are not available for projects integrated through the GitHub App, GitLab or Bitbucket Data Center. @@ -2330,7 +2330,7 @@ workflows: ''' [#cron] -====== *`cron`* +==== *`cron`* The `cron` key is defined using POSIX `crontab` syntax. @@ -2363,7 +2363,7 @@ workflows: ''' [#filters] -====== *`filters`* +==== *`filters`* Trigger filters can have the key `branches`. @@ -2396,7 +2396,7 @@ workflows: ''' [#schedule-branches] -====== *`branches`* +==== *`branches`* The `branches` key controls whether the _current_ branch should have a schedule trigger created for it, where _current_ branch is the branch containing the `config.yml` file with the `trigger` stanza. That is, a push on the `main` branch will only schedule a xref:guides:orchestrate:workflows.adoc#using-filters-in-your-workflows[workflow] for the `main` branch. @@ -2481,7 +2481,7 @@ Refer to the xref:guides:orchestrate:workflows.adoc#[Workflows] for more example ''' [#jobs-in-workflow] -==== *`jobs`* +== *`jobs`* A job can have the keys `requires`, `name`, `context`, `type`, and `filters`. @@ -2498,7 +2498,7 @@ A job can have the keys `requires`, `name`, `context`, `type`, and `filters`. ''' [#job-name-in-workflow] -===== *<``job_name``>* +=== *<``job_name``>* A job name that exists in your `config.yml`. @@ -2522,7 +2522,7 @@ workflows: ''' [#override-with] -====== *`override-with`* +==== *`override-with`* The `override-with` key is used to override the job configuration with a job from the referenced orb. @@ -2549,7 +2549,7 @@ If the `my-orb/my-test` job is not defined inside the orb, the `test` job will c ''' [#serial-group] -====== `serial-group` +==== `serial-group` The `serial-group` key is used to add a property to a job to allow a group of jobs to run in series, rather than concurrently, across an organization. Serial groups control the orchestration of jobs across an organization, not just within projects and pipelines. @@ -2601,7 +2601,7 @@ For more information, see the xref:guides:orchestrate:controlling-serial-executi ''' [#requires] -====== *`requires`* +==== *`requires`* Jobs are run concurrently by default, so you must explicitly require any dependencies by their job name if you need some jobs to run sequentially. @@ -2650,7 +2650,7 @@ workflows: ''' [#name] -====== *`name`* +==== *`name`* The `name` key can be used to invoke reusable jobs across any number of workflows. Using the name key ensures numbers are not appended to your job name (for example, sayhello-1 , sayhello-2, etc.). The name you assign to the `name` key needs to be unique, otherwise the numbers will still be appended to the job name. @@ -2676,7 +2676,7 @@ workflows: ''' [#context] -====== *`context`* +==== *`context`* Jobs may be configured to use global environment variables set for an organization, see the xref:guides:security:contexts.adoc#[Contexts] document for adding a context in the application settings. @@ -2715,7 +2715,7 @@ workflows: ''' [#type] -====== *`type`* +==== *`type`* A job may have a `type` of `approval` indicating it must be manually approved before downstream jobs may proceed. For more information see the xref:guides:orchestrate:workflows.adoc#holding-a-workflow-for-a-manual-approval[Using workflows to orchestrate jobs] page. @@ -2744,7 +2744,7 @@ An approval job can have any name. In the example above the approval job is name ''' [#jobfilters] -====== *`filters`* +==== *`filters`* Filter job execution within a workflow based on the following: * Branch @@ -2784,7 +2784,7 @@ You can read more about using regular expressions in your config in the xref:gui ''' -====== Expression-based job filters +==== Expression-based job filters Expression-based job filters allow you to conditionally run jobs based on the following: * xref:variables.adoc#pipeline-values[Pipeline values] @@ -2901,7 +2901,7 @@ include::guides:ROOT:partial$using-expressions/operators.adoc[] ''' [#branches] -====== *`branches`* +==== *`branches`* The branches filter can have the keys `only` and `ignore`, which map to a single string naming a branch. You may also use regular expressions to match against branches by enclosing them with slashes, or map to a list of such strings. Regular expressions must match the *entire* string. @@ -2954,7 +2954,7 @@ workflows: ''' [#tags] -====== *`tags`* +==== *`tags`* CircleCI does not run workflows for tags unless you explicitly specify tag filters. If a job requires any other jobs (directly or indirectly), you must specify tag filters for those jobs. @@ -3004,7 +3004,7 @@ workflows: ''' [#matrix] -====== *`matrix`* +==== *`matrix`* NOTE: The `matrix` key is supported in `version: 2.1` configuration @@ -3075,7 +3075,7 @@ workflows: ''' [#excluding-sets-of-parameters-from-a-matrix] -====== Excluding sets of parameters from a matrix +==== Excluding sets of parameters from a matrix Sometimes you may wish to run a job with every combination of arguments _except_ some value or values. You can use an `exclude` stanza to achieve this: @@ -3101,7 +3101,7 @@ The matrix above would expand into 8 jobs: every combination of the parameters ''' [#dependencies-and-matrix-jobs] -====== Dependencies and matrix jobs +==== Dependencies and matrix jobs To require an entire matrix (every job within the matrix), use its `alias`. The `alias` defaults to the name of the job being invoked. @@ -3175,7 +3175,7 @@ workflows: ''' [#pre-steps-and-post-steps] -====== *`pre-steps`* and *`post-steps`* +==== *`pre-steps`* and *`post-steps`* NOTE: Pre-steps and post-steps are supported in `version: 2.1` configuration diff --git a/docs/server-admin-4.2/modules/installation/pages/phase-3-execution-environments.adoc b/docs/server-admin-4.2/modules/installation/pages/phase-3-execution-environments.adoc index e1b765afbc..685b44efd8 100644 --- a/docs/server-admin-4.2/modules/installation/pages/phase-3-execution-environments.adoc +++ b/docs/server-admin-4.2/modules/installation/pages/phase-3-execution-environments.adoc @@ -201,7 +201,7 @@ kubectl create secret generic nomad-autoscaler-secret \ [#iam-policy-for-nomad-autoscaler] -===== IAM policy for Nomad Autoscaler +==== IAM policy for Nomad Autoscaler [source, json] { diff --git a/docs/server-admin-4.2/modules/operator/pages/manage-virtual-machines-with-vm-service.adoc b/docs/server-admin-4.2/modules/operator/pages/manage-virtual-machines-with-vm-service.adoc index abfc5faffd..e6468e9429 100644 --- a/docs/server-admin-4.2/modules/operator/pages/manage-virtual-machines-with-vm-service.adoc +++ b/docs/server-admin-4.2/modules/operator/pages/manage-virtual-machines-with-vm-service.adoc @@ -55,9 +55,11 @@ vm_service: The default AMIs for server v4.2 are based on Ubuntu 22.04. -[#x86-ami-list] -===== x86 AMI list - +[tabs] +==== +x86 AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -115,10 +117,10 @@ The default AMIs for server v4.2 are based on Ubuntu 22.04. | `us-gov-west-1` | `ami-02abf947586cae56b` |=== - -[#arm-ami-list] -===== Arm AMI list - +-- +Arm AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -173,6 +175,8 @@ The default AMIs for server v4.2 are based on Ubuntu 22.04. |`us-gov-west-1` |`ami-0ab175883ff460b17` |=== +-- +==== [#gcp] === GCP diff --git a/docs/server-admin-4.3/modules/installation/pages/phase-3-execution-environments.adoc b/docs/server-admin-4.3/modules/installation/pages/phase-3-execution-environments.adoc index b2aae16717..c9d2ff92ec 100644 --- a/docs/server-admin-4.3/modules/installation/pages/phase-3-execution-environments.adoc +++ b/docs/server-admin-4.3/modules/installation/pages/phase-3-execution-environments.adoc @@ -200,7 +200,7 @@ kubectl create secret generic nomad-autoscaler-secret \ [#iam-policy-for-nomad-autoscaler] -===== IAM policy for Nomad Autoscaler +==== IAM policy for Nomad Autoscaler [source, json] ---- diff --git a/docs/server-admin-4.3/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc b/docs/server-admin-4.3/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc index b8737c67de..c47580c759 100644 --- a/docs/server-admin-4.3/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc +++ b/docs/server-admin-4.3/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc @@ -55,9 +55,11 @@ machine_provisioner: The default AMIs for server v4.3 are based on Ubuntu 22.04. -[#x86-ami-list] -===== x86 AMI list - +[tabs] +==== +x86 AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -115,10 +117,10 @@ The default AMIs for server v4.3 are based on Ubuntu 22.04. | `us-gov-west-1` | `ami-02abf947586cae56b` |=== - -[#arm-ami-list] -===== Arm AMI list - +-- +Arm AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -173,6 +175,8 @@ The default AMIs for server v4.3 are based on Ubuntu 22.04. |`us-gov-west-1` |`ami-0ab175883ff460b17` |=== +-- +==== [#gcp] === GCP diff --git a/docs/server-admin-4.4/modules/installation/pages/phase-3-execution-environments.adoc b/docs/server-admin-4.4/modules/installation/pages/phase-3-execution-environments.adoc index 0487ab31bb..35971e7241 100644 --- a/docs/server-admin-4.4/modules/installation/pages/phase-3-execution-environments.adoc +++ b/docs/server-admin-4.4/modules/installation/pages/phase-3-execution-environments.adoc @@ -215,7 +215,7 @@ kubectl create secret generic nomad-autoscaler-secret \ [#iam-policy-for-nomad-autoscaler] -===== IAM policy for Nomad Autoscaler +==== IAM policy for Nomad Autoscaler [source, json] { diff --git a/docs/server-admin-4.4/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc b/docs/server-admin-4.4/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc index 31b3776ed9..33cfc646b2 100644 --- a/docs/server-admin-4.4/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc +++ b/docs/server-admin-4.4/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc @@ -57,8 +57,11 @@ machine_provisioner: The default AMIs for server v4.4 are based on Ubuntu 22.04. -[#x86-ami-list] -===== x86 AMI list +[tabs] +==== +x86 AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] @@ -117,10 +120,10 @@ The default AMIs for server v4.4 are based on Ubuntu 22.04. | `us-gov-west-1` | `ami-0fdf4561a0d3b0346` |=== - -[#arm-ami-list] -===== Arm AMI list - +-- +Arm AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -175,6 +178,8 @@ The default AMIs for server v4.4 are based on Ubuntu 22.04. |`us-gov-west-1` |`ami-02268e2fe5572a88c` |=== +-- +==== [#gcp] === GCP diff --git a/docs/server-admin-4.5/modules/installation/pages/phase-3-execution-environments.adoc b/docs/server-admin-4.5/modules/installation/pages/phase-3-execution-environments.adoc index e44b9c865c..97c8ec4550 100644 --- a/docs/server-admin-4.5/modules/installation/pages/phase-3-execution-environments.adoc +++ b/docs/server-admin-4.5/modules/installation/pages/phase-3-execution-environments.adoc @@ -215,7 +215,7 @@ kubectl create secret generic nomad-autoscaler-secret \ [#iam-policy-for-nomad-autoscaler] -===== IAM policy for Nomad Autoscaler +==== IAM policy for Nomad Autoscaler [source, json] { diff --git a/docs/server-admin-4.5/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc b/docs/server-admin-4.5/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc index 6ae82eece4..07a83494fb 100644 --- a/docs/server-admin-4.5/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc +++ b/docs/server-admin-4.5/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc @@ -57,9 +57,11 @@ machine_provisioner: The default AMIs for server v4.5 are based on Ubuntu 22.04. -[#x86-ami-list] -===== x86 AMI list - +[tabs] +==== +x86 AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -117,10 +119,10 @@ The default AMIs for server v4.5 are based on Ubuntu 22.04. | `us-gov-west-1` | `ami-0fdf4561a0d3b0346` |=== - -[#arm-ami-list] -===== Arm AMI list - +-- +Arm AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -175,6 +177,8 @@ The default AMIs for server v4.5 are based on Ubuntu 22.04. |`us-gov-west-1` |`ami-02268e2fe5572a88c` |=== +-- +==== [#gcp] === GCP diff --git a/docs/server-admin-4.6/modules/installation/pages/phase-3-execution-environments.adoc b/docs/server-admin-4.6/modules/installation/pages/phase-3-execution-environments.adoc index 778a25b663..aa5f29ace7 100644 --- a/docs/server-admin-4.6/modules/installation/pages/phase-3-execution-environments.adoc +++ b/docs/server-admin-4.6/modules/installation/pages/phase-3-execution-environments.adoc @@ -215,7 +215,7 @@ kubectl create secret generic nomad-autoscaler-secret \ [#iam-policy-for-nomad-autoscaler] -===== IAM policy for Nomad Autoscaler +==== IAM policy for Nomad Autoscaler [source, json] { diff --git a/docs/server-admin-4.6/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc b/docs/server-admin-4.6/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc index 8809466b72..3647c6fdd0 100644 --- a/docs/server-admin-4.6/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc +++ b/docs/server-admin-4.6/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc @@ -57,9 +57,11 @@ machine_provisioner: The default AMIs for server v4.6 are based on Ubuntu 22.04. -[#x86-ami-list] -===== x86 AMI list - +[tabs] +==== +x86 AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -117,10 +119,10 @@ The default AMIs for server v4.6 are based on Ubuntu 22.04. | `us-gov-west-1` | `ami-0fdf4561a0d3b0346` |=== - -[#arm-ami-list] -===== Arm AMI list - +-- +Arm AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -175,6 +177,8 @@ The default AMIs for server v4.6 are based on Ubuntu 22.04. |`us-gov-west-1` |`ami-02268e2fe5572a88c` |=== +-- +==== [#gcp] === GCP diff --git a/docs/server-admin-4.7/modules/ROOT/partials/installation/phase-3.adoc b/docs/server-admin-4.7/modules/ROOT/partials/installation/phase-3.adoc index 635ca4f7d7..cc86c1f064 100644 --- a/docs/server-admin-4.7/modules/ROOT/partials/installation/phase-3.adoc +++ b/docs/server-admin-4.7/modules/ROOT/partials/installation/phase-3.adoc @@ -219,7 +219,7 @@ kubectl create secret generic nomad-autoscaler-secret \ [#iam-policy-for-nomad-autoscaler] -===== IAM policy for Nomad Autoscaler +==== IAM policy for Nomad Autoscaler [source,json] ---- diff --git a/docs/server-admin-4.7/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc b/docs/server-admin-4.7/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc index 37c07d7ca8..070612e14d 100644 --- a/docs/server-admin-4.7/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc +++ b/docs/server-admin-4.7/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc @@ -60,9 +60,11 @@ machine_provisioner: The default AMIs for server v4.7 are based on Ubuntu 22.04. -[#x86-ami-list] -===== x86 AMI list - +[tabs] +==== +x86 AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -120,10 +122,10 @@ The default AMIs for server v4.7 are based on Ubuntu 22.04. | `us-gov-west-1` | `ami-0fdf4561a0d3b0346` |=== - -[#arm-ami-list] -===== Arm AMI list - +-- +Arm AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -178,6 +180,8 @@ The default AMIs for server v4.7 are based on Ubuntu 22.04. |`us-gov-west-1` |`ami-02268e2fe5572a88c` |=== +-- +==== [#gcp] === GCP diff --git a/docs/server-admin-4.8/modules/ROOT/partials/installation/phase-3.adoc b/docs/server-admin-4.8/modules/ROOT/partials/installation/phase-3.adoc index 6a17eedfbd..9451e14c50 100644 --- a/docs/server-admin-4.8/modules/ROOT/partials/installation/phase-3.adoc +++ b/docs/server-admin-4.8/modules/ROOT/partials/installation/phase-3.adoc @@ -220,7 +220,7 @@ kubectl create secret generic nomad-autoscaler-secret \ [#iam-policy-for-nomad-autoscaler] -===== IAM policy for Nomad Autoscaler +==== IAM policy for Nomad Autoscaler [source,json] ---- diff --git a/docs/server-admin-4.8/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc b/docs/server-admin-4.8/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc index 15ab4f0820..2f54fdee6b 100644 --- a/docs/server-admin-4.8/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc +++ b/docs/server-admin-4.8/modules/operator/pages/manage-virtual-machines-with-machine-provisioner.adoc @@ -54,9 +54,11 @@ machine_provisioner: The default AMIs for server v4.8 are based on Ubuntu 22.04. -[#x86-ami-list] -===== x86 AMI list - +[tabs] +==== +x86 AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -114,10 +116,10 @@ The default AMIs for server v4.8 are based on Ubuntu 22.04. | `us-gov-west-1` | `ami-0fdf4561a0d3b0346` |=== - -[#arm-ami-list] -===== Arm AMI list - +-- +Arm AMI list:: ++ +-- [.table.table-striped] [cols=2*, options="header", stripes=even] |=== @@ -172,6 +174,8 @@ The default AMIs for server v4.8 are based on Ubuntu 22.04. |`us-gov-west-1` |`ami-02268e2fe5572a88c` |=== +-- +==== [#gcp] === GCP