Inline commands

content/en/docs/guides/install-guides/_index.md

@@ -133,7 +133,7 @@ The following environment variables can be used to configure the installation:
 
 Monitor the installation on your terminal.
 
-Log onto your VM using ssh on another terminal and use commands *docker* and *kubectl* to monitor the installation.
+Log onto your VM using ssh on another terminal and use commands `docker` and `kubectl` to monitor the installation.
 
 ## Access to the User Interfaces
 

content/en/docs/guides/install-guides/explore-sandbox.md

@@ -34,7 +34,7 @@ Everything is installed on the Management KinD cluster by Ansible scripts using
 
 The install unpacks each kpt package in the */tmp* directory. It then applies the kpt functions to the packages and
 applies the packages to the Management KinD cluster. This allows the user to check the status of the kpt packages in
-the cluster using the *kpt live status* command on the unpacked packages in the */tmp* directory.
+the cluster using the `kpt live status` command on the unpacked packages in the */tmp* directory.
 
 The rendered kpt packages containing components are unpacked in the */tmp/kpt-pkg* directory. The rendered kpt packages
 that create the *mgmt* and *mgmt-staging* repositories are unpacked in the */tmp/repository* directory. The rendered kpt
@@ -58,7 +58,7 @@ You can examine the contents of any rendered kpt packager by examining the conte
 └── resource-backend
 
 ```
-You can check the status of an applied kpt package using a "kpt live status package_dir" command.
+You can check the status of an applied kpt package using a `kpt live status package_dir` command.
 
 ```bash
 kpt live status /tmp/kpt-pkg/nephio-controllers/

content/en/docs/guides/install-guides/package-transformations.md

@@ -192,9 +192,7 @@ mgmt-staging              git    Package   false        True    http://172.18.0.
 nephio-example-packages   git    Package   false        True    https://github.com/nephio-project/nephio-example-packages.git
 ```
 
-To see all the remote packages that are available:
-
-$ porchctl rpkg get
+To see all the remote packages that are available use the `$ porchctl rpkg get` command.
 
 ```bash
 NAME                                                               PACKAGE                              WORKSPACENAME   REVISION   LATEST   LIFECYCLE   REPOSITORY
@@ -297,12 +295,12 @@ NAME                                           PACKAGE  WORKSPACENAME REVISION L
 mgmt-08c26219f9879acdefed3469f8c3cf89d5db3868  regional v1                     false  Draft     mgmt
 ```
 
-2. Pull the package to get a local copy of it
+2. Pull the package to get a local copy of it:
 
 ```bash
 porchctl rpkg pull -n default mgmt-08c26219f9879acdefed3469f8c3cf89d5db3868 regional
 ```
-3. Set the Nephio labels on the package
+3. Set the Nephio labels on the package:
 
 ```bash
 kpt fn eval --image gcr.io/kpt-fn/set-labels:v0.2.0 regional -- "nephio.org/site-type=regional" "nephio.org/region=us-west1"
@@ -379,16 +377,16 @@ The `PackageVariant` specified in `pv-cluster.yaml` is executed and:
    package called `lambda-cluster` in the gitea `mgmt` repository on your management
    cluster.
 2. Applies the `lambda-cluster` kpt package to create the kind cluster for the
-   workload cluster
+   workload cluster.
 
 #### Package transformations
 
 During creation of the package variant kpt package, the following transformations occur:
 
 1. It creates a `drafts/lambda-cluster/v1` branch on the `mgmt` repository
-2. It does the equivalent of a [kpt pkg get](#kpt-pkg-get) on the `cluster-capi-kind` package into a directory called
+2. It does the equivalent of a [`kpt pkg get`](#kpt-pkg-get) on the `cluster-capi-kind` package into a directory called
    `lambda-cluster` on that branch, with the same transformations on package files carried out as the
-   [kpt pkg get](#kpt-pkg-get) command above, this content is checked into the new branch in the initial commit
+   [`kpt pkg get`](#kpt-pkg-get) command above, this content is checked into the new branch in the initial commit
 3. The pipeline specified in the `Kptfile`of the `cluster-capi-kind` package specifies an `apply-replacements` specified
    in the `apply-replacements.yaml` file in the package and uses the value of the
    `workload-cluster.yaml:spec.clusterName` field set in 2. above (which is the workload cluster name). This has the

content/en/docs/guides/user-guides/exercise-1-free5gc.md

@@ -786,7 +786,7 @@ kubectl apply -f test-infra/e2e/tests/free5gc/007-edge01-ueransim.yaml
 ```
 
 You can check to see if the simulated UE is up and running by checking the UERANSIM deployment. First, you can use the
-get_capi_kubeconfig` shortcut to retrieve the kubeconfig for the edge01 cluster, and then query that cluster for the
+`get_capi_kubeconfig` shortcut to retrieve the kubeconfig for the edge01 cluster, and then query that cluster for the
 UERANSIM pods.
 
 ```bash
@@ -927,7 +927,7 @@ The output is similar to:
 ```
 
 
-Observe the changes to the UPF configuration using the kpt pkg diff command.
+Observe the changes to the UPF configuration using the `kpt pkg diff` command.
 
 ```bash
 kpt pkg diff /tmp/upf-scale-package | grep linkThroughput

content/en/docs/guides/user-guides/exercise-2-oai.md

@@ -356,7 +356,7 @@ packagevariant.config.porch.kpt.dev/oai-ran-operator-regional created
 
 ## Step 4: Check Database and Operator Deployment
 
-Within five minutes of applying the RAN, Core Operator, and database Packages, you should see `oai-core` and `oai-cn-operators` namespaces on the Core workload cluster, :
+Within five minutes of applying the RAN, Core Operator, and database Packages, you should see `oai-core` and `oai-cn-operators` namespaces on the Core workload cluster:
 
 ```bash
 kubectl get ns --context core-admin@core

content/en/docs/porch/contributors-guide/environment-setup.md

@@ -127,7 +127,7 @@ packages                                         porch.kpt.dev/v1alpha1
 To connect Porch to Gitea, follow [step 7 in the Starting with Porch](../using-porch/install-and-using-porch.md)
 tutorial to create the repositories in Porch.
 
-You will notice logging messages in VSCode when you run the command `kubectl apply -f porch-repositories.yaml` command.
+You will notice logging messages in VSCode when you run the `kubectl apply -f porch-repositories.yaml` command.
 
 You can check that your locally running Porch server has created the repositories by running the `porchctl` command:
 

content/en/docs/porch/running-porch/running-on-GKE.md

@@ -129,17 +129,14 @@ git clone https://github.com/GoogleContainerTools/kpt.git "${GOPATH}/src/github.
 repository.
 
 If your use case doesn't require Porch to interact with GCP container registries, you can build and deploy Porch by
-running the following command. It will build and push Porch Docker images into (by default) Google Container Registry
-named (example shown is the Porch server image):
-
-`gcr.io/YOUR-PROJECT-ID/porch-server:SHORT-COMMIT-SHA`
-
+running the `gcr.io/YOUR-PROJECT-ID/porch-server:SHORT-COMMIT-SHA` command. It will build and push Porch Docker images into (by default) Google Container Registry
+named (example shown is the Porch server image).
 
 ```bash
 IMAGE_TAG=$(git rev-parse --short HEAD) make push-and-deploy-no-sa
 ```
 
-If you want to use different repository, you can set `IMAGE_REPO` variable
+If you want to use a different repository, you can set `IMAGE_REPO` variable
 (see [Makefile](https://github.com/nephio-project/porch/blob/main/Makefile#L32) for details).
 
 The `make push-and-deploy-no-sa` target will install Porch but not Config Sync. You can install Config Sync in your k8s