armory · aimeeu · Oct 31, 2023 · Oct 31, 2023 · Oct 31, 2023
@@ -23,7 +23,7 @@ You can configure webhooks on multiple GitHub organizations or repositories to s
 
 When you make a GitHub pull request (PR) and there is a change in a `dinghyfile`, Pipelines-as-Code automatically performs a validation for that `dinghyfile`. It also updates the GitHub status accordingly. If the validation fails, you see an unsuccessful `dinghy` check.
 
-{{< figure src="/images/dinghy/pr_validation/pr_validation.png" alt="PR that fails validation." >}}
+{{< figure src="/media/plugins/pac/pr_validation.png" alt="PR that fails validation." >}}
 
 Make PR validations mandatory to ensure users only merge working `dinghyfiles`.
 
@@ -37,4 +37,4 @@ Perform the following steps to configure mandatory PR validation:
 
 The following screenshot shows what your GitHub settings should resemble:
 
-{{< figure src="/images/dinghy/pr_validation/branch_mandatory.png" alt="Configured dinghy PR validation." >}}
+{{< figure src="/media/plugins/pac/branch_mandatory.png" alt="Configured dinghy PR validation." >}}
@@ -364,7 +364,7 @@ spec:
 {{% /tab %}}
 {{< /tabpane >}}
 
-{{< figure src="/images/dinghy-slack-notifications.png" >}}
+{{< figure src="dinghy-slack-notifications.png" >}}
 
 ### GitHub notifications
 
@@ -401,7 +401,7 @@ spec:
 {{% /tab %}}
 {{< /tabpane >}}
 
-{{< figure src="/images/plugins/pac/dinghy-github-notifications.jpg" >}}
+{{< figure src="dinghy-github-notifications.jpg" >}}
 
 ## Permissions check for a commit
 

@@ -224,7 +224,7 @@ Note that only the `application` and `pipelines` keys are required; everything e
 
 - **Modules**: These are templates that define a Stage/Task in the pipeline. They are kept in a single GitHub repo that is configurable when the dinghy service starts. eg:
 
-{{< figure src="/images/dinghy-template-repo.png" >}}
+{{< figure src="dinghy-template-repo.png" >}}
 
  They are JSON files with replacable values in them. e.g., a module that defines a wait stage in a pipeline might look like:
 
@@ -240,7 +240,7 @@ Note that only the `application` and `pipelines` keys are required; everything e
 
 - **Pipeline definitions**: These define a pipeline for an application in a file called `dinghyfile`. The `dinghyfile` usually resides at the root level of the application repo. eg:
 
-{{< figure src="/images/dinghyfile.png" >}}
+{{< figure src="dinghyfile.png" >}}
 
 You can compose stage/task templates to make a full definition. e.g., a Pipeline definition that has a single wait stage might look like:
 
@@ -341,7 +341,7 @@ Optionally, you can include a default parameter: `{{ var "waitName" ?: "defaultV
 
 Let us create a more realistic pipeline using templates. One that would look like this:
 
-{{< figure src="/images/Screen-Shot-2018-03-12-at-11.18.38-AM.png" >}}
+{{< figure src="pipeline.png" >}}
 
 You would use the following JSON to create such. Note that any of the stages could have come from an imported module, but we show the full JSON here for readability:
 
@@ -472,9 +472,9 @@ This module inherits two stages and overrides variables within them. The `wait.s
 }
 ```
 
-Note how the `requisiteStageRefIds` is overwritten while calling the module so that the deploy stage _depends on_ the wait stage. This pipeline would look like this in the spinnaker UI:
+Note how the `requisiteStageRefIds` is overwritten while calling the module so that the deploy stage _depends on_ the wait stage. This pipeline would look like this in the Spinnaker UI:
 
-{{< figure src="/images/Screen_Shot_2018-03-26_at_5_06_25_PM.png" >}}
+{{< figure src="multi-inheritance.png" >}}
 
 ## Local module functionality
 

@@ -9,7 +9,7 @@ aliases:
 
 ## How the Armory Scale Agent plugin communicates with Clouddriver instances
 
-{{< figure src="/images/scale-agent/k8s-clustering.png"  alt="Kubernetes clustering"  height="75%" width="75%" >}}
+{{< figure src="k8s-clustering.png"  alt="Kubernetes clustering"  height="75%" width="75%" >}}
 
 At startup, Clouddriver registers a watch for the kind `Endpoints` in the Kubernetes cluster where it is running for the namespace where Clouddriver is running. Objects of kind `Endpoints` are automatically generated based on a Kubernetes Service. The plugin knows that there's a Clouddriver Service for routing HTTP traffic to Clouddriver pods (usually named `spin-clouddriver`). This means that the Clouddriver pod needs to mount a Kubernetes Service Account that has permissions to list and watch the kind `Endpoints` in the current namespace. The Agent plugin does the equivalent of these calls at startup:
 

@@ -12,7 +12,7 @@ description: >
 
 In this mode, you install the Armory Scale Agent service as a new Spinnaker service (`spin-armory-agent`), so you can configure it like other services.
 
-{{< figure src="/images/scale-agent/in-cluster-mode.png" >}}
+{{< figure src="in-cluster-mode.png" height="80%" width="80%" >}}
 
 If you provision clusters automatically, the Armory Scale Agent service can dynamically reload accounts when `armory-agent.yaml` changes. You could, for example, configure accounts in a `ConfigMap` mounting to `/opt/armory/config/armory-agent-local.yaml`.  The Agent service reflects `ConfigMap` changes within seconds after [etcd](https://etcd.io/) sync.
 
@@ -42,7 +42,7 @@ Keep the following pros and cons in mind when deciding if Infrastructure mode fi
 - The API servers of the target clusters need to be accessible from the Armory Scale Agent cluster.
 - You need to expose gRPC port for Clouddriver through an external load balancer capable of handling HTTP/2 for gRPC communication.
 
-{{< figure src="/images/scale-agent/agent-infra-mode.png" >}}
+{{< figure src="agent-infra-mode.png" height="80%" width="80%" >}}
 
 > Kubernetes account names must be unique across all your infrastructure. Clouddriver rejects new accounts with a name that matches a different cluster.
 
@@ -69,7 +69,7 @@ Keep the following pros and cons in mind when deciding if Agent mode fits your u
 - There is no authentication/authorization, so any team can start an Agent and register itself with Armory CD (Spinnaker). mTLS encryption can be used so that only agents with the right certificate can register. For information about how to configure mTLS, see {{< linkWithTitle "plugins/scale-agent/tasks/configure-mtls.md" >}}.
 - You need to expose gRPC port for Clouddriver through an external load balancer capable of handling HTTP/2 for gRPC communication.
 
-{{< figure src="/images/scale-agent/agent-mode.png" >}}
+{{< figure src="agent-mode.png" height="80%" width="80%" >}}
 
 
 

@@ -98,7 +98,7 @@ Run the pipeline.
 
 ## Create a Terraform Integration stage
 
-{{< figure src="/images/plugins/terraform/terraform_stage_ui.png" >}}
+{{< figure src="terraform_stage_ui.png" >}}
 
 {{< include "rdbms-utf8-required.md" >}}
 
@@ -126,7 +126,7 @@ To create a new Terraform stage, perform the following steps:
       * **Workspace**: [Terraform workspace](https://www.terraform.io/docs/state/workspaces.html) to use. The workspace gets created if it does not already exist. For remote backends, the workspace must be explicit or prefixed. For more information about what that means, see the Terraform documentation about [remote backends](https://www.terraform.io/docs/backends/types/remote.html)
     * **Main Terraform Artifact**
       * **Expected Artifact**: Required. Select or define only one `git/repo` type artifact.
-        {{< figure src="/images/plugins/terraform/terraform-git-repo.png" >}}
+        {{< figure src="terraform-git-repo.png" >}}
         * **Account**: The account to use for your artifact.
         * **URL**: If you use a GitHub artifact, make sure you supply the _API_ URL of the file, not the URL from the `Raw` GitHub page. Use the following examples as a reference for the API URL:
 
@@ -205,7 +205,7 @@ Terraform Integration caches all the defined plugins by default and does not red
 
 ## View Terraform log output
 
-{{< figure src="/images/plugins/terraform/terraformer-ui-logs.png" >}}
+{{< figure src="terraformer-ui-logs.png" >}}
 
 Terraform provides logs that describe the status of your Terraform action. When you run Terraform actions on your workstation, the log output is streamed to `stdout`. For Armory's Terraform Integration, Spinnaker captures the log output and makes it available on the **Pipelines** page of Deck as part of the **Execution Details**. Exit codes in the log represent the following states: