Add Helm CLI only onboarding steps

docs/partials/getting-started/_community-help.mdx

@@ -0,0 +1,5 @@
+The [Replicated community site](https://community.replicated.com/) is a forum where Replicated team members and users can post questions and answers related to working with the Replicated Platform. It is designed to help Replicated users troubleshoot and learn more about common tasks involved with distributing, installing, observing, and supporting their application. 
+
+Before posting in the community site, use the search to find existing knowledge base articles related to your question. If you are not able to find an existing article that addresses your question, create a new topic or add a reply to an existing topic so that a member of the Replicated community or team can respond.
+
+To get help from and participate in the Replicated community, see https://community.replicated.com/.

docs/partials/getting-started/_create-app.mdx

@@ -0,0 +1,23 @@
+To get started with onboarding, first create a new application. This will be the official Vendor Portal application used by your team to create and promote both internal and customer-facing releases.
+
+To create an application:
+
+1. Create a new application using the Replicated CLI or the Vendor Portal. Use an official name for your application. See [Create an Application](/vendor/vendor-portal-manage-app#create-an-application).
+
+   <details>
+   <summary>Can I change the application name in the future?</summary>
+
+   You can change the application name, but you cannot change the application _slug_.
+
+   The Vendor Portal automatically generates and assigns a unique slug for each application based on the application's name. For example, the slug for "Example App" would be `example-app`.
+
+   Application slugs are unique across all of Replicated. This means that, if necessary, the Vendor Portal will append a random word to the end of slug to ensure uniqueness. For example, `example-app-flowers`.
+   </details>
+
+1. Set the `REPLICATED_APP` environment variable to the unique slug of the application that you created. This will allow you to interact with the application from the Replicated CLI throughout onboarding. See [Set Environment Variables](/reference/replicated-cli-installing#replicated_app) in _Installing the Replicated CLI_.
+
+   For example:
+
+   ```bash
+   export REPLICATED_APP=my-app
+   ```

docs/partials/getting-started/_custom-domains.mdx

@@ -0,0 +1,7 @@
+Your customers are exposed to several Replicated domains by default. Replicated recommends you use custom domains to unify the customer's experience with your brand and simplify security reviews. For more information, see [About Custom Domains](/vendor/custom-domains).
+
+To add and use custom domains for Replicated endpoints:
+
+1. Add and verify your custom domain(s) in the Vendor Portal. See [Add a Custom Domain in the Vendor Portal](/vendor/custom-domains-using#add-domain).
+
+1. If you add a custom domain for the Replicated proxy registry, update any image references in your Helm chart values to point to your custom domain rather than the proxy registry (`proxy.replicated.com`).

docs/partials/getting-started/_customize-release-channels.mdx

@@ -0,0 +1,11 @@
+By default, the Vendor Portal includes Unstable, Beta, and Stable channels. You can customize the channels in the Vendor Portal based on your application needs.
+
+Consider the following recommendations:
+* Use the Stable channel for your primary release cadence. Releases should be promoted to the Stable channel only as frequently as your average customer can consume new releases. Typically, this is no more than monthly. However, this cadence varies depending on the customer base.
+* If you have a SaaS product, you might want to create an "Edge" channel where you promote the latest SaaS releases.
+* You can consider a "Long Term Support" channel where you promote new releases less frequently and support those releases for longer.
+* It can be useful to create channels for each feature branch so that internal teams reviewing a PR can easily get the installation artifacts as well as review the code. You can automate channel creation as part of a pipeline or Makefile.
+
+For more information, see:
+* [About Channels and Releases](/vendor/releases-about)
+* [Creating and Editing Channels](/vendor/releases-creating-channels)

docs/partials/getting-started/_enterprise-portal.mdx

@@ -0,0 +1,17 @@
+The Replicated Enterprise Portal is a customizable, web-based portal where your customers can find installation instructions, check for application updates, manage their team members, upload support bundles, and more. For more information, see [About the Enterprise Portal](/vendor/enterprise-portal-about).
+
+To set up the Enterprise Portal:
+
+1. (Recommended) Add a custom domain for the Enterprise Portal. See [Use Custom Domains](/vendor/custom-domains-using).
+
+    :::note
+    You can also do this later as part of [Alias Replicated Endpoints With Your Own Domains](#custom-domains).
+    :::
+
+1. Customize Enteprise Portal settings and the customer-facing install and upgrade instructions. See [Customize the Enterprise Portal](/vendor/enterprise-portal-configure).
+
+1. Enable the Enterprise Portal for an internal development customer so that you can test your changes. For information about how to enable and then access the Enterprise Portal for a customer, see [Manage Customer Access to the Enterprise Portal](/vendor/enterprise-portal-invite) and [View a Customer's Enterprise Portal](/vendor/enterprise-portal-access). For information about how end customers can log in to and use the Enterprise Portal, see [Log In To and Use the Enterprise Portal](/vendor/enterprise-portal-use).
+
+1. When you are ready, enable the Enterprise Portal so that it is available to one or more of your end customers. You can enable the Enterprise Portal for all customers by default, or manage access on a per-customer basis. For more information, see [Manage Customer Access to the Enterprise Portal](/vendor/enterprise-portal-invite).
+
+1. (Optional) Enable self-service signups so that current and potential customers can access your application by signing up for a trial or community license through the Enterprise Portal. See [Enable Self-Service Sign-Ups](/vendor/enterprise-portal-self-serve-signup).

docs/partials/getting-started/_integrate-ci-cd.mdx

@@ -0,0 +1,6 @@
+Replicated recommends that teams integrate the Replicated Platform into their existing develeopment and production CI/CD workflows. This can be useful for automating the processes of creating new releases, promoting releases, and testing releases with the Replicated Compatibility Matrix (CMX).
+
+For more information, see:
+* [About Integrating with CI/CD](/vendor/ci-overview)
+* [About CMX](/vendor/testing-about)
+* [Recommended CI/CD Workflows](/vendor/ci-workflows)

docs/partials/getting-started/_preflight-sb-onboarding-intro.mdx

@@ -0,0 +1,7 @@
+In the next two tasks, you will add specs for _preflight checks_ and _support bundles_.
+
+Preflight checks and support bundles are provided by the Troubleshoot open source project, which is maintained by Replicated. Troubleshoot is a kubectl plugin that provides diagnostic tools for Kubernetes applications. For more information, see the open source [Troubleshoot](https://troubleshoot.sh/docs/) documentation.
+
+Preflight checks and support bundles analyze data from customer environments to provide insights that help users to avoid or troubleshoot common issues with an application:
+* **Preflight checks** run before an application is installed to check that the customer environment meets the application requirements.
+* **Support bundles** collect troubleshooting data from customer environments to help users diagnose problems with application deployments.

docs/partials/getting-started/_support-bundle-spec.mdx

@@ -0,0 +1,57 @@
+1. In your Helm chart `templates` directory, add the following YAML to a Kubernetes Secret to enable the default support bundle spec for your application:
+
+    ```yaml
+    apiVersion: v1
+    kind: Secret
+    metadata:
+      labels:
+        troubleshoot.sh/kind: support-bundle
+      name: example
+    stringData:
+      support-bundle-spec: |
+        apiVersion: troubleshoot.sh/v1beta2
+        kind: SupportBundle
+        metadata:
+          name: support-bundle
+        spec:
+          collectors: []
+          analyzers: []
+    ```
+    :::note
+    If your application is installed as multiple Helm charts, you can optionally create separate support bundle specs in each chart. The specs are automatically merged when a support bundle is generated. Alternatively, continue with a single support bundle spec and then optionally revisit how you organize your support bundle specs after you finish onboarding.
+    :::
+
+1. (Recommended) At a minimum, Replicated recommends that all support bundle specs include the `logs` collector. This collects logs from running Pods in the cluster.
+
+   **Example:**
+
+   ```yaml
+   apiVersion: v1
+   kind: Secret
+   metadata:
+     name: example
+     labels:
+       troubleshoot.sh/kind: support-bundle
+   stringData: 
+     support-bundle-spec: |-
+       apiVersion: troubleshoot.sh/v1beta2
+       kind: SupportBundle
+       metadata:
+         name: example
+       spec:
+         collectors:
+           - logs:
+               selector:
+                 - app.kubernetes.io/name=myapp
+               namespace: {{ .Release.Namespace }}
+               limits:
+                 maxAge: 720h
+                 maxLines: 10000
+   ```
+
+   For more information, see:
+   * [Adding and Customizing Support Bundles](/vendor/support-bundle-customizing)
+   * [Example Support Bundle Specs](/vendor/support-bundle-examples)
+   * [Pod Logs](https://troubleshoot.sh/docs/collect/logs/) in the Troubleshoot documentation.
+
+1. (Recommended) Ensure that any preflight checks that you added are also included in your support bundle spec. This ensures that support bundles collect at least the same information that is collected when running preflight checks. 

docs/partials/getting-started/_write-your-docs.mdx

@@ -0,0 +1,3 @@
+Before distributing your application to customers, ensure that your documentation is up-to-date.
+
+For guidance on how to get started with documentation for applications distributed with Replicated, including key considerations, examples, and templates, see [Writing Great Documentation for On-Prem Software Distributed with Replicated](https://www.replicated.com/blog/writing-great-documentation-for-on-prem-software-distributed-with-replicated) in the Replicated blog.

docs/partials/proxy-service/_step-helm-helper.mdx

@@ -0,0 +1,44 @@
+In your `_helper.tpl`, add a Helm helper for the image pull secret. This helper creates an `imagePullSecrets` value that lists both the Replicated pull secret that you created (if present) as well as any global or chart-level pull secrets provided by your customers. This supports use cases where customers need to provide additional pull secrets, such as in air gap installations where images are pushed to a private regitsry in the air-gapped environment.
+
+    ```yam1
+    {{/*
+    Image pull secrets
+    */}}
+    {{- define "replicated.imagePullSecrets" -}}
+      {{- $pullSecrets := list }}
+
+      {{- with ((.Values.global).imagePullSecrets) -}}
+        {{- range . -}}
+          {{- if kindIs "map" . -}}
+            {{- $pullSecrets = append $pullSecrets .name -}}
+          {{- else -}}
+            {{- $pullSecrets = append $pullSecrets . -}}
+          {{- end }}
+        {{- end -}}
+      {{- end -}}
+
+      {{/* use image pull secrets provided as values */}}
+      {{- with .Values.images -}}
+        {{- range .pullSecrets -}}
+          {{- if kindIs "map" . -}}
+            {{- $pullSecrets = append $pullSecrets .name -}}
+          {{- else -}}
+            {{- $pullSecrets = append $pullSecrets . -}}
+          {{- end -}}
+        {{- end -}}
+      {{- end -}}
+
+      {{/* use secret created with injected docker config */}}
+      {{- if hasKey ((.Values.global).replicated) "dockerconfigjson" }}
+        {{- $pullSecrets = append $pullSecrets "replicated-pull-secret" -}}
+      {{- end -}}
+
+
+      {{- if (not (empty $pullSecrets)) -}}
+    imagePullSecrets:
+        {{- range $pullSecrets | uniq }}
+      - name: {{ . }}
+        {{- end }}
+      {{- end }}
+    {{- end -}}
+    ```

docs/partials/proxy-service/_step-helm-replicated-pull-secret.mdx

@@ -0,0 +1,20 @@
+In your Helm chart templates, add a YAML file that evaluates if the `global.replicated.dockerconfigjson` value is set, and then writes the rendered value into a Secret on the cluster, as shown below.
+
+   Do not use `replicated` for the name of the image pull secret because the Replicated SDK automatically creates a Secret named `replicated`. Using the same name causes an error.
+
+   ```yaml
+   # templates/replicated-pull-secret.yaml
+
+   {{- $global := default dict .Values.global -}}
+   {{- $replicated := default dict (index $global "replicated") -}}
+   {{- if hasKey $replicated "dockerconfigjson" }}
+   apiVersion: v1
+   kind: Secret
+   metadata:
+     # Note: Do not use "replicated" for the name of the pull secret
+     name: replicated-pull-secret
+   type: kubernetes.io/dockerconfigjson
+   data:
+     .dockerconfigjson: {{ .Values.global.replicated.dockerconfigjson }}
+   {{ end }}
+   ```

docs/partials/proxy-service/_step-rewrite-helm-values.mdx

@@ -1,4 +1,4 @@
-For each image reference in your Helm chart values file, set the image repository URL to the location of the image in the proxy registry. The domain for this URL is either `proxy.replicated.com` or your custom domain.
+For each image reference in your Helm chart values file, set the image repository URL to the location of the image in the proxy registry.
 
     The proxy registry URL has the following format: `DOMAIN/proxy/APP_SLUG/EXTERNAL_REGISTRY_IMAGE_URL`
 

docs/partials/proxy-service/_step-use-helper.mdx

@@ -0,0 +1,15 @@
+Use your helper in any manifests that reference the image.
+
+   **Example:**
+
+    ```yaml
+    apiVersion: v1
+    kind: Pod
+    spec:
+      # Add the pull secret with your helper
+      {{- include "replicated.imagePullSecrets" . | nindent 6 }}
+      containers:
+        - name: api 
+      # Access the registry, repository, and tag fields from the values file
+            image: {{ .Values.images.api.registry }}/{{ .Values.images.api.repository }}:{{ .Values.images.api.tag }}
+    ```

docs/vendor/helm-image-registry.mdx

@@ -1,6 +1,9 @@
 import StepCreds from "../partials/proxy-service/_step-creds.mdx"
 import StepCustomDomain from "../partials/proxy-service/_step-custom-domain.mdx"
 import RewriteHelmValues from "../partials/proxy-service/_step-rewrite-helm-values.mdx"
+import PullSecret from "../partials/proxy-service/_step-helm-replicated-pull-secret.mdx"
+import Helper from "../partials/proxy-service/_step-helm-helper.mdx"
+import UseHelper from "../partials/proxy-service/_step-use-helper.mdx"
 
 # Use the Proxy Registry with Helm CLI Installations
 
@@ -26,88 +29,13 @@ To configure your application to use the proxy registry with Helm CLI installati
 
 1. <RewriteHelmValues/>
 
-1. In your Helm chart templates, add a YAML file that evaluates if the `global.replicated.dockerconfigjson` value is set, and then writes the rendered value into a Secret on the cluster, as shown below.
-
-   :::note
-   Do not use `replicated` for the name of the image pull secret because the Replicated SDK automatically creates a Secret named `replicated`. Using the same name causes an error.
-   :::
-
-   ```yaml
-   # templates/replicated-pull-secret.yaml
-
-   {{- $global := default dict .Values.global -}}
-   {{- $replicated := default dict (index $global "replicated") -}}
-   {{- if hasKey $replicated "dockerconfigjson" }}
-   apiVersion: v1
-   kind: Secret
-   metadata:
-     # Note: Do not use "replicated" for the name of the pull secret
-     name: replicated-pull-secret
-   type: kubernetes.io/dockerconfigjson
-   data:
-     .dockerconfigjson: {{ .Values.global.replicated.dockerconfigjson }}
-   {{ end }}
-   ```
-1. In your `_helper.tpl`, add a Helm helper for the image pull secret. This helper creates an `imagePullSecrets` value that lists both the Replicated pull secret that you created (if present) as well as any global or chart-level pull secrets provided by your customers. This supports use cases where customers need to provide additional pull secrets, such as in air gap installations where images are pushed to a private regitsry in the air-gapped environment.
-
-    ```yam1
-    {{/*
-    Image pull secrets
-    */}}
-    {{- define "replicated.imagePullSecrets" -}}
-      {{- $pullSecrets := list }}
-
-      {{- with ((.Values.global).imagePullSecrets) -}}
-        {{- range . -}}
-          {{- if kindIs "map" . -}}
-            {{- $pullSecrets = append $pullSecrets .name -}}
-          {{- else -}}
-            {{- $pullSecrets = append $pullSecrets . -}}
-          {{- end }}
-        {{- end -}}
-      {{- end -}}
-
-      {{/* use image pull secrets provided as values */}}
-      {{- with .Values.images -}}
-        {{- range .pullSecrets -}}
-          {{- if kindIs "map" . -}}
-            {{- $pullSecrets = append $pullSecrets .name -}}
-          {{- else -}}
-            {{- $pullSecrets = append $pullSecrets . -}}
-          {{- end -}}
-        {{- end -}}
-      {{- end -}}
-
-      {{/* use secret created with injected docker config */}}
-      {{- if hasKey ((.Values.global).replicated) "dockerconfigjson" }}
-        {{- $pullSecrets = append $pullSecrets "replicated-pull-secret" -}}
-      {{- end -}}
-
-
-      {{- if (not (empty $pullSecrets)) -}}
-    imagePullSecrets:
-        {{- range $pullSecrets | uniq }}
-      - name: {{ . }}
-        {{- end }}
-      {{- end }}
-    {{- end -}}
-    ```
-
-1. Use your helper in any manifests that reference the image.
-
-   **Example:**
-
-    ```yaml
-    apiVersion: v1
-    kind: Pod
-    spec:
-      # Add the pull secret with your helper
-      {{- include "replicated.imagePullSecrets" . | nindent 6 }}
-      containers:
-        - name: api 
-      # Access the registry, repository, and tag fields from the values file
-            image: {{ .Values.images.api.registry }}/{{ .Values.images.api.repository }}:{{ .Values.images.api.tag }}
-    ```
+1. <PullSecret/> 
+
+1. <Helper/>
+
+1. <UseHelper/>
+
+1. If your application is deployed as multiple Helm charts, repeat the previous steps to modify image references and add the pull secret for each of your charts.
 
 1. Package your Helm chart and add it to a release. Promote the release to a development channel. See [Managing Releases with Vendor Portal](releases-creating-releases).