diff --git a/README.md b/README.md index cbfcb5ad0..1628bfb34 100644 --- a/README.md +++ b/README.md @@ -20,27 +20,27 @@

Gitpod is an open-source Kubernetes application for ready-to-code developer environments that spins up fresh, automated dev environments -for each task, in the cloud, in seconds. It enables you to describe your dev environment as code and start instant, remote and cloud-based developer environments directly from your browser or your Desktop IDE. +for each task, in the cloud, in seconds. It enables you to describe thy dev environment as code and start instant, remote and cloud-based developer environments directly from thy browser or thy Desktop IDE. -Tightly integrated with GitLab, GitHub, and Bitbucket, Gitpod automatically and continuously prebuilds dev environments for all your branches. As a result, team members can instantly start coding with fresh, ephemeral, and fully-compiled dev environments - no matter if you are building a new feature, want to fix a bug, or do a code review. +Tightly integrated with GitLab, GitHub, and Bitbucket, Gitpod automatically and continuously prebuilds dev environments for all thy branches. As a result, team members can instantly start coding with fresh, ephemeral, and fully-compiled dev environments - no matter if you are building a new feature, want to fix a bug, or do a code review. ![browser-vscode](https://user-images.githubusercontent.com/22498066/135150975-23bba3a6-f099-48c5-83ed-a1a6627ff0e9.png) ## Features -🏗 [Dev environments as code](https://www.gitpod.io/docs/#-dev-environments-as-code) - Gitpod applies lessons learned from infrastructure-as-code. Spinning up dev environments is easily repeatable and reproducible empowering you to automate, version-control, and share dev environments across your team. +🏗 [Dev environments as code](https://www.gitpod.io/docs/#-dev-environments-as-code) - Gitpod applies lessons learned from infrastructure-as-code. Spinning up dev environments is easily repeatable and reproducible empowering you to automate, version-control, and share dev environments across thy team. -⚡ī¸ [Prebuilt dev environments](https://www.gitpod.io/docs/#prebuilds) - Gitpod continuously prebuilds all your git branches similar to a CI server. Control how Gitpod pre-configures and initializes environments before you even start a workspace through `init` commands in your `.gitpod.yml`. +⚡ī¸ [Prebuilt dev environments](https://www.gitpod.io/docs/#prebuilds) - Gitpod continuously prebuilds all thy git branches similar to a CI server. Control how Gitpod pre-configures and initializes environments before you even start a workspace through `init` commands in thy `.gitpod.yml`. -đŸŗ [Integrated Docker build](https://www.gitpod.io/docs/config-docker/) - Gitpod instantly starts a container in the cloud based on your Docker image. Tools that are required for your project are easy to install and configure. +đŸŗ [Integrated Docker build](https://www.gitpod.io/docs/config-docker/) - Gitpod instantly starts a container in the cloud based on thy Docker image. Tools that are required for thy project are easy to install and configure. -👐 [GitLab, GitHub, and Bitbucket integration](https://www.gitpod.io/docs/integrations/) - Gitpod seamlessly integrates into your workflow and works with all major git hosting platforms including GitHub, GitLab and Bitbucket. +👐 [GitLab, GitHub, and Bitbucket integration](https://www.gitpod.io/docs/integrations/) - Gitpod seamlessly integrates into thy workflow and works with all major git hosting platforms including GitHub, GitLab and Bitbucket. -👀 [Integrated code reviews](https://www.gitpod.io/docs/context-urls#pullmerge-request-context) - with Gitpod you can do native code reviews on any PR/MR. No need to switch context anymore and clutter your local machine with your colleagues' PR/MR. +👀 [Integrated code reviews](https://www.gitpod.io/docs/context-urls#pullmerge-request-context) - with Gitpod you can do native code reviews on any PR/MR. No need to switch context anymore and clutter thy local machine with thy colleagues' PR/MR. -đŸ‘¯â€â™€ī¸ [Collaboration](https://www.gitpod.io/docs/sharing-and-collaboration/) - invite team members to your dev environment or snapshot any state of your dev environment to share it with your team asynchronously. +đŸ‘¯â€â™€ī¸ [Collaboration](https://www.gitpod.io/docs/sharing-and-collaboration/) - invite team members to thy dev environment or snapshot any state of thy dev environment to share it with thy team asynchronously. -🛠 Professional & customizable developer experience - a Gitpod workspace gives you the same capabilities (yes, even [root & docker](https://www.gitpod.io/docs/config-docker#configure-a-custom-dockerfile)) as your Linux machine - pre-configured and optimized for your individual development workflow. Install any [VS Code extension](https://www.gitpod.io/docs/vscode-extensions/) with one click on a user and/or team level. +🛠 Professional & customizable developer experience - a Gitpod workspace gives you the same capabilities (yes, even [root & docker](https://www.gitpod.io/docs/config-docker#configure-a-custom-dockerfile)) as thy Linux machine - pre-configured and optimized for thy individual development workflow. Install any [VS Code extension](https://www.gitpod.io/docs/vscode-extensions/) with one click on a user and/or team level. [Learn more 👉](https://www.gitpod.io/) @@ -51,7 +51,7 @@ Gitpod is provided as a [managed Saas version](https://gitpod.io) with a free su You can start using Gitpod in one or more of the following ways: 1. Quickstart using an [Example Project](https://www.gitpod.io/docs/quickstart) or [OSS Project](https://contribute.dev/) -1. Getting started with [one of your existing projects](https://www.gitpod.io/docs/getting-started) +1. Getting started with [one of thy existing projects](https://www.gitpod.io/docs/getting-started) 1. [Use a Prefixed URL](https://www.gitpod.io/docs/getting-started/#prefixed-url) 1. [Install Browser Extension](https://www.gitpod.io/docs/getting-started#browser-extension) 1. [Enable GitLab Integration](https://www.gitpod.io/docs/gitlab-integration#gitlab-integration) diff --git a/components/common-go/nsenter/README.md b/components/common-go/nsenter/README.md index ca396b4e2..435cb1b13 100644 --- a/components/common-go/nsenter/README.md +++ b/components/common-go/nsenter/README.md @@ -13,7 +13,7 @@ The `nsenter` package registers a special init constructor that is called before the Go runtime has a chance to boot. This provides us the ability to `setns` on existing namespaces and avoid the issues that the Go runtime has with multiple threads. This constructor will be called if this package is registered, -imported, in your go application. +imported, in thy go application. The `nsenter` package will `import "C"` and it uses [cgo](https://golang.org/cmd/cgo/) package. In cgo, if the import of "C" is immediately preceded by a comment, that comment, diff --git a/components/dashboard/README.md b/components/dashboard/README.md index 8e1244a9e..dbf89a623 100644 --- a/components/dashboard/README.md +++ b/components/dashboard/README.md @@ -40,16 +40,16 @@ All the commands in this section are meant to be executed from the `components/d ### 1. Environment variables -Set the following 2 [environment variables](https://www.gitpod.io/docs/environment-variables) either [via your account settings](https://gitpod.io/variables) or [via the command line](https://www.gitpod.io/docs/environment-variables#using-the-command-line-gp-env). +Set the following 2 [environment variables](https://www.gitpod.io/docs/environment-variables) either [via thy account settings](https://gitpod.io/variables) or [via the command line](https://www.gitpod.io/docs/environment-variables#using-the-command-line-gp-env). You are not expected to update the values of these variables for a long time after you first set them. -> **🚨 Heads up!** Be careful when using the command line, as the `gp` CLI will restrict the scope of the variables to the current project, meaning if you are not already working from your own personal fork you'll end up having variables you can't access when you do. +> **🚨 Heads up!** Be careful when using the command line, as the `gp` CLI will restrict the scope of the variables to the current project, meaning if you are not already working from thy own personal fork you'll end up having variables you can't access when you do. -You can always go to your account settings and edit the scope for each variable to something like `*/gitpod`. +You can always go to thy account settings and edit the scope for each variable to something like `*/gitpod`. ```bash -# Use "gitpod.io" for the SaaS version of Gitpod, or specify the host of your self-hosted gitpod +# Use "gitpod.io" for the SaaS version of Gitpod, or specify the host of thy self-hosted gitpod GP_DEV_HOST=gitpod.io # Notice the cookie name (_gitpod_io_) may be different if self-hosted. @@ -57,7 +57,7 @@ GP_DEV_HOST=gitpod.io GP_DEV_COOKIE="_gitpod_io_=AUTHENTICATION_COOKIE_VALUE" ``` -Replace `AUTHENTICATION_COOKIE_VALUE` with the value of your auth cookie taken from your browser's dev tools while visiting your target Gitpod host (e.g. `s%3Axxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.XXXXXXXXXXXXXXX`). +Replace `AUTHENTICATION_COOKIE_VALUE` with the value of thy auth cookie taken from thy browser's dev tools while visiting thy target Gitpod host (e.g. `s%3Axxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx.XXXXXXXXXXXXXXX`). | ℹī¸ How to get the cookie name and value | | -------------------------------------------------------------------------- | diff --git a/components/gitpod-db/README.md b/components/gitpod-db/README.md index 0c6d91f76..bb50f780f 100644 --- a/components/gitpod-db/README.md +++ b/components/gitpod-db/README.md @@ -3,7 +3,7 @@ Contains all the database related functionality, implemented using [typeorm](https://typeorm.io/). ### Working on gitpod-protocol component -When you are making changes to gitpod-protocol component, make sure to run `yarn build` in gitpod-protocol folder to make sure your changes will be rebuild. Also consider running `yarn watch` so that any changes are rebuilt in realtime. +When you are making changes to gitpod-protocol component, make sure to run `yarn build` in gitpod-protocol folder to make sure thy changes will be rebuild. Also consider running `yarn watch` so that any changes are rebuilt in realtime. ### Adding a new table 1. Create a [migration](./src/typeorm/migration/README.md) - use the [baseline](./src/typeorm/migration/1592203031938-Baseline.ts) as an exemplar diff --git a/components/ide/jetbrains/backend-plugin/README.md b/components/ide/jetbrains/backend-plugin/README.md index dc6ed902a..112edf462 100644 --- a/components/ide/jetbrains/backend-plugin/README.md +++ b/components/ide/jetbrains/backend-plugin/README.md @@ -13,7 +13,7 @@ you experience any issues with JetBrains remote dev make sure to report issues [here](https://youtrack.jetbrains.com/issues?q=project:%20CWM) under remote development subsystem. -Usually you will need to create a preview environments to try your changes, but if your changes don't touch any other +Usually you will need to create a preview environments to try thy changes, but if thy changes don't touch any other components beside the backend plugin then you can test against the running workspace: - Launch `./launch-dev-server.sh` from `components/ide/jetbrains/backend-plugin`. It builds the backend plugin, and diff --git a/components/local-app/README.md b/components/local-app/README.md index 5ad942f40..bb0cab4b2 100644 --- a/components/local-app/README.md +++ b/components/local-app/README.md @@ -15,5 +15,5 @@ docker run --rm -it -v /tmp/dest:/out eu.gcr.io/gitpod-core-dev/build/local-app: ## How to run in Gitpod against a dev-staging environment ``` cd components/local-app -BROWSER= GITPOD_HOST= go run main.go --mock-keyring run +BROWSER= GITPOD_HOST= go run main.go --mock-keyring run ``` diff --git a/components/ws-manager/README.md b/components/ws-manager/README.md index ef538fceb..2749f6535 100644 --- a/components/ws-manager/README.md +++ b/components/ws-manager/README.md @@ -14,7 +14,7 @@ You can start `ws-manager` in any Kubernetes cluster, it will only look at pods To run `ws-manager` you need: 1. _messagebus you can connect to:_ e.g. `kubectl port-forward deployment/messagebus 5672` 2. _valid configuration file:_ e.g. `example-config.json`. You can use `wsman validate-config --config example-config.json` to make sure you have a valid configuration file. -3. _Kubernetes cluster to work with:_ you can use your `kubectl` config file using the `--kubeconfig` flag or otherwise have it connect to the cluster it's running in +3. _Kubernetes cluster to work with:_ you can use thy `kubectl` config file using the `--kubeconfig` flag or otherwise have it connect to the cluster it's running in Then run `wsman run --config example-config.json --kubeconfig ~/.kube/config -v` diff --git a/dev/blowtorch/README.md b/dev/blowtorch/README.md index 4b7d833d6..fdf66e34b 100644 --- a/dev/blowtorch/README.md +++ b/dev/blowtorch/README.md @@ -7,7 +7,7 @@ blowtorch is a tool to selectively burn down bridges, i.e. Kubernetes service co ## Usage ``` -blowtorch helps using toxiproxy to create network chaos in your k8s application +blowtorch helps using toxiproxy to create network chaos in thy k8s application Usage: blowtorch [command] diff --git a/dev/loadgen/README.md b/dev/loadgen/README.md index 8ffa5894f..0c43a583d 100644 --- a/dev/loadgen/README.md +++ b/dev/loadgen/README.md @@ -7,7 +7,7 @@ A load generator (framework) for Gitpod. You can find a short explanation of this tool in this [loom video](https://www.loom.com/share/6487e3403c0746cc97bb3f766e15fab6). ## How to run a benchmark -- Ensure your kubeconfig has the configuration for the cluster you want to benchmark. You can use kubecdl to update your kubeconfig with the cluster information +- Ensure thy kubeconfig has the configuration for the cluster you want to benchmark. You can use kubecdl to update thy kubeconfig with the cluster information ```console $ kubecdl -p workspace-clusters [cluster-name] $ kubectx [cluster-name] @@ -50,7 +50,7 @@ In order to configure the benchmark, you can use the configuration file | repo.environment | Environment variables that will only be set for this repository | | repo.workspaceClass | The workspace class to use for the workspace that will be created for this repository | -After the benchmark has completed, you will find a benchmark-result.json file in your working directory, that contains information about every started workspace. +After the benchmark has completed, you will find a benchmark-result.json file in thy working directory, that contains information about every started workspace. ``` [ diff --git a/install/README.md b/install/README.md index be50baccb..5ff785574 100644 --- a/install/README.md +++ b/install/README.md @@ -33,7 +33,7 @@ Download the licenses below: #### Existing Cluster 1. Ensure you meet all of the requirements listed [here](https://www.gitpod.io/docs/self-hosted/latest/requirements) -2. Additionally, you will need to have `cert-manager` installed in your existing Kubernetes cluster. If not installed already, instructions on how to do so can be found [here](https://cert-manager.io/docs/installation/) +2. Additionally, you will need to have `cert-manager` installed in thy existing Kubernetes cluster. If not installed already, instructions on how to do so can be found [here](https://cert-manager.io/docs/installation/) 3. Then run: ```shell diff --git a/install/infra/single-cluster/aws/README.md b/install/infra/single-cluster/aws/README.md index 406b8297f..75818cf99 100644 --- a/install/infra/single-cluster/aws/README.md +++ b/install/infra/single-cluster/aws/README.md @@ -12,7 +12,7 @@ This module will do the following steps: - Set up external-dns using our [`external-dns` module](../../modules/tools/external-dns/) - Creates a cluster-issuer using our [`issuer` module](../../modules/tools/issuer/) -> 💡 If you would like to create the infrastructure orchestrating the terraform modules by yourself, you can find all the modules we support [here](../../modules/). +> 💡 If you would like to create the infrastructure orchestrating the terraform modules by thyself, you can find all the modules we support [here](../../modules/). Since the entire setup requires more than one terraform target to be run due to dependencies (eg: helm provider depends on kubernetes cluster config, which is @@ -37,7 +37,7 @@ Before starting the installation process, you need: * Setup credentials to be usable in one of the following ways: * [As environmental variables](https://docs.aws.amazon.com/cli/latest/userguide/cli-configure-envvars.html) * Copy the file `.env_sample` to `.env` and update the values corresponding - to your AWS user. Run: + to thy AWS user. Run: ```sh source .env ``` @@ -146,12 +146,12 @@ make output Once the apply process has exited successfully, we can go ahead and prepare to setup Gitpod. If you specified the `domain_name` in the `terraform.tfvars` file, the terraform module registers the module with `route53` to point to the -cluster. Now you have to configure whichever provider you use to host your +cluster. Now you have to configure whichever provider you use to host thy domain name to route traffic to the AWS name servers. You can find these name servers in the `make output` command from above. It would be of the format: ```json -Nameservers for the domain(to be added as NS records in your domain provider): +Nameservers for the domain(to be added as NS records in thy domain provider): ================= [ "ns-1444.awsdns-52.org.", @@ -161,8 +161,8 @@ Nameservers for the domain(to be added as NS records in your domain provider): ] ``` -Add the `ns` records similar to the above 4 URIs as NS records under your domain -DNS management setup. Check with your domain hosting service for specific information. +Add the `ns` records similar to the above 4 URIs as NS records under thy domain +DNS management setup. Check with thy domain hosting service for specific information. ## Note the dependency credentials from terraform output @@ -212,7 +212,7 @@ NAME READY STATUS RESTARTS AGE proxy-5998488f4c-t8vkh 0/1 Init 0/1 0 5m ``` -The most likely reason is that the DNS01 challenge has yet to resolve. To fix this, make sure you have added the NS records corresponding to the `route53` zone of the `domain_name` added to your domain provider. +The most likely reason is that the DNS01 challenge has yet to resolve. To fix this, make sure you have added the NS records corresponding to the `route53` zone of the `domain_name` added to thy domain provider. Once the DNS record has been updated, you will need to delete all Cert Manager pods to retrigger the certificate request @@ -230,7 +230,7 @@ https-certificates True https-certificates 5m ### Cannot connect to the created cluster after a while -There is a chance that your kubeconfig has gotten expired after a specific amount of time. You can reconnect to the cluster by using: +There is a chance that thy kubeconfig has gotten expired after a specific amount of time. You can reconnect to the cluster by using: ``` sh aws eks --region update-kubeconfig --name diff --git a/install/infra/single-cluster/gcp/README.md b/install/infra/single-cluster/gcp/README.md index 751e97d26..8ed16eee9 100644 --- a/install/infra/single-cluster/gcp/README.md +++ b/install/infra/single-cluster/gcp/README.md @@ -12,7 +12,7 @@ This module will do the following steps: - Set up external-dns using our [`external-dns` module](../../modules/tools/external-dns/) - Creates a cluster-issuer using our [`issuer` module](../../modules/tools/issuer/) -> 💡 If you would like to create the infrastructure orchestrating the terraform modules by yourself, you can find all the modules we support [here](../../modules/). +> 💡 If you would like to create the infrastructure orchestrating the terraform modules by thyself, you can find all the modules we support [here](../../modules/). Since the entire setup requires more than one terraform target to be run due to @@ -57,7 +57,7 @@ to the service account stored as a JSON file. The path to the JSON file is expected to be provided as a value to the `credentials` field. Alongside, one is expected to provide the name of the project(`project` field) corresponding to this service account and region in with the cluster to be created(`region` -field). If you want your cluster to be zonal(only existing in one zone), you can +field). If you want thy cluster to be zonal(only existing in one zone), you can provide a zone corresponding to the project(`zone` field), else the cluster will be regional. @@ -141,12 +141,12 @@ make output Once the apply process has exited successfully, we can go ahead and prepare to setup Gitpod. If you specified the `domain_name` in the `terraform.tfvars` file, the terraform module registers the module with `cloudDNS` to point to the -cluster. Now you have to configure whichever provider you use to host your +cluster. Now you have to configure whichever provider you use to host thy domain name to route traffic to the GCP name servers. You can find these name servers in the `make output` command from above. It would be of the format: ```json -Nameservers for the domain(to be added as NS records in your domain provider): +Nameservers for the domain(to be added as NS records in thy domain provider): ================= [ "ns-cloud-c1.googledomains.com.", @@ -158,8 +158,8 @@ Nameservers for the domain(to be added as NS records in your domain provider): ``` -Add the `ns` records similar to the above 4 URIs as NS records under your domain -DNS management setup. Check with your domain hosting service for specific information. +Add the `ns` records similar to the above 4 URIs as NS records under thy domain +DNS management setup. Check with thy domain hosting service for specific information. ## Note the dependency credentials from terraform output @@ -215,7 +215,7 @@ https-certificates True https-certificates 5m ### Cannot connect to the created cluster after a while -There is a chance that your kubeconfig has gotten expired after a specific amount of time. You can reconnect to the cluster by using: +There is a chance that thy kubeconfig has gotten expired after a specific amount of time. You can reconnect to the cluster by using: ``` sh # make sure you are authenticated using the service account you used to create the cluster diff --git a/install/installer/README.md b/install/installer/README.md index 986b6fa8f..546d8e0f3 100644 --- a/install/installer/README.md +++ b/install/installer/README.md @@ -24,7 +24,7 @@ Or, [open a Gitpod workspace](https://gitpod.io/from-referrer/) The process to install Gitpod is: 1. generate a base config -2. amend the config for your own use-case +2. amend the config for thy own use-case 3. validate 4. render the Kubernetes YAML 5. `kubectl apply` @@ -34,7 +34,7 @@ The process to install Gitpod is: ## Download the Installer on Linux Releases can be downloaded from [GitHub Releases](https://github.com/gitpod-io/gitpod/releases/) -Select your desired binary, download and install +Select thy desired binary, download and install 1. Download the latest release with the command: @@ -80,12 +80,12 @@ gitpod-installer version gitpod-installer init > gitpod.config.yaml ``` -## Customise your config +## Customise thy config -There are many things you can change in your config, which can be found in +There are many things you can change in thy config, which can be found in the [Config Guide](#config). -For the purposes of a quickstart, just change the `domain` to one of your +For the purposes of a quickstart, just change the `domain` to one of thy own. ## Validate @@ -99,7 +99,7 @@ Any errors here must be fixed before deploying. See [Config](#config) for more details. ```shell -# Checks that your cluster is ready to install Gitpod +# Checks that thy cluster is ready to install Gitpod gitpod-installer validate cluster --kubeconfig ~/.kube/config --config gitpod.config.yaml ``` @@ -118,21 +118,21 @@ gitpod-installer render --config gitpod.config.yaml > gitpod.yaml kubectl apply -f gitpod.yaml ``` -After a few minutes, your Gitpod installation will be available on the +After a few minutes, thy Gitpod installation will be available on the specified `domain`. ## Uninstallation The Installer generates a ConfigMap with the metadata of every Kubernetes object generated by the Installer. This can be retrieved to remove Gitpod -from your cluster. +from thy cluster. ```shell kubectl get configmaps gitpod-app -o jsonpath='{.data.app\.yaml}' \ | kubectl delete -f - # Piping to this will delete automatically ``` -**Important**. This may leave certain objects still in your Kubernetes +**Important**. This may leave certain objects still in thy Kubernetes cluster. This will include `Secrets` generated from internal `Certificates` and `PersistentVolumeClaims`. These will need to be manually deleted. @@ -146,12 +146,12 @@ defined in the spec and so will be deleted shortly after the jobs have run. > Here be dragons. > -> Whilst you are welcome to post-process your YAML should the need arise, it is not -> recommended and is entirely unsupported. Do so at your own risk. +> Whilst you are welcome to post-process thy YAML should the need arise, it is not +> recommended and is entirely unsupported. Do so at thy own risk. The Gitpod Installer is designed as a way of providing you a robust and well-tested -framework for installing Gitpod to your own infrastructure. There may be times when -this framework doesn't meet your individual requirements. In these situations, you +framework for installing Gitpod to thy own infrastructure. There may be times when +this framework doesn't meet thy individual requirements. In these situations, you should post-process the generated YAML. As an example, this will allow you to change the `proxy` service to a `ClusterIP` @@ -178,7 +178,7 @@ yq eval-all --inplace \ ```shell error: error validating "gitpod.yaml": error validating data: ValidationError(StatefulSet.status): missing required field "availableReplicas" in io.k8s.api.apps.v1.StatefulSetStatus; if you choose to ignore these errors, turn validation off with --validate=false ``` -Depending upon your Kubernetes implementation, you may receive this error. This is +Depending upon thy Kubernetes implementation, you may receive this error. This is due to a bug in the underlying StatefulSet dependency, which is used to generate the OpenVSX proxy (see [#8529](https://github.com/gitpod-io/gitpod/issues/8529)). @@ -212,10 +212,10 @@ is `true`. External dependencies can be used in their place | --- | --- | --- | --- | | `domain` | Y | The domain to deploy to | This will need to be changed on every deployment | | `kind` | Y | Installation type to run - for most users, this will be `Full` | Available options are:
  • `Meta`: To install the tools that make up the front-end facing side of `Gitpod`
  • `Workspace`: To install the components that make up the `Gitpod Workspaces`
  • `Full`: To install the complete setup, i.e. both `Meta` and `Workspace`
    • | -| `metadata.region` | Y | Location for your `objectStorage` provider | If using Minio, set to `local` | +| `metadata.region` | Y | Location for thy `objectStorage` provider | If using Minio, set to `local` | | `workspace.runtime.containerdRuntimeDir` | Y | The location of containerd on host machine | Common values are:
    • `/run/containerd/io.containerd.runtime.v2.task/k8s.io` (K3s)
    • `/var/lib/containerd/io.containerd.runtime.v2.task/k8s.io` (AWS/Azure/GCP)
    • `/run/containerd/io.containerd.runtime.v1.linux/k8s.io`
    • `/run/containerd/io.containerd.runtime.v1.linux/moby`
    | | `workspace.runtime.containerdSocket` | Y | The location of containerd socket on the host machine | -| `workspace.runtime.fsShiftMethod` | Y | File system | Can be either `fuse` (fuse-overlayfs) or `shiftfs`. This depending upon your host OS/distribution. If unsure, use `fuse`. | +| `workspace.runtime.fsShiftMethod` | Y | File system | Can be either `fuse` (fuse-overlayfs) or `shiftfs`. This depending upon thy host OS/distribution. If unsure, use `fuse`. | ## Auth Providers @@ -225,7 +225,7 @@ as a Kubernetes secret. ### Setting via config -1. Update your configuration file: +1. Update thy configuration file: ```yaml authProviders: @@ -441,8 +441,8 @@ and `ide` nodes together and the `workspace` nodes together. ## TLS certificates It is a requirement that a certificate secret exists, named as per -`certificate.name` in your config YAML with `tls.crt` and `tls.key` -in the secret data. How this certificate is generated is entirely your +`certificate.name` in thy config YAML with `tls.crt` and `tls.key` +in the secret data. How this certificate is generated is entirely thy choice - we suggest [cert-manager](https://cert-manager.io/) for simplicity, however any certificate authority can be used by creating a Kubernetes secret. @@ -458,7 +458,7 @@ with creating a TLS certificate using cert-manager. ### cert-manager -cert-manager **MUST** be installed to your cluster. In order to secure +cert-manager **MUST** be installed to thy cluster. In order to secure communication between the various components, the application creates internally which are created using the cert-manager `Certificate` and `Issuer` Custom Resource Definitions. @@ -482,7 +482,7 @@ helm upgrade \ # FAQs -## Why are you writing your own Installer instead of using Helm/Kustomize/etc? +## Why are you writing thy own Installer instead of using Helm/Kustomize/etc? The Installer is a complete replacement for our Helm charts. Over time, this had grown to be too complex to effectively support and was a barrier @@ -510,10 +510,10 @@ for instructions. This can be either an ### 2. Create the certificate -Replace `$DOMAIN` with your domain. This example assumes you have created a +Replace `$DOMAIN` with thy domain. This example assumes you have created a `ClusterIssuer` called `gitpod-issuer` - please change this if necessary. -This certificate is called `https-certificates` - please use that in your +This certificate is called `https-certificates` - please use that in thy Gitpod installer [config](#config). ```yaml @@ -535,13 +535,13 @@ spec: ## How do I use my own TLS certificate? If you don't wish to use cert-manager to create a TLS certificate with a public -certificate authority, you can bring your own. +certificate authority, you can bring thy own. -To do this, generate your certificate as you would normally and then create a +To do this, generate thy certificate as you would normally and then create a secret with the CRT set to `tls.crt` and the Key set to `tls.key`. The DNS names must be `$DOMAIN`, `*.$DOMAIN` and `*.ws.$DOMAIN`, where `$DOMAIN` -is your domain. +is thy domain. ```yaml apiVersion: v1 @@ -573,7 +573,7 @@ gitpod-installer validate cluster --kubeconfig ~/.kube/config --config gitpod.co **IMPORTANT**: this does not create the namespace, so you will need to create that separately. This is so that uninstallation of Gitpod does not remove any -Kubernetes objects, such as your TLS certificate or connection secrets. +Kubernetes objects, such as thy TLS certificate or connection secrets. ```shell kubectl create namespace gitpod diff --git a/install/installer/cmd/testdata/render/README.md b/install/installer/cmd/testdata/render/README.md index ad5b776f0..7a83789d4 100644 --- a/install/installer/cmd/testdata/render/README.md +++ b/install/installer/cmd/testdata/render/README.md @@ -33,19 +33,19 @@ VERSION=main.4110 make getRenderVersionManifest To generate a new test, the following process must be followed - in this example, the name of the test will be `testname`, but this should be substituted for whatever you want to call it. This becomes the test name and is how the files are stored in the codebase, so it should be descriptive. -First, create your folder: +First, create thy folder: ```shell mkdir -p ./cmd/testdata/render/testname ``` -Second, create your config file and amend it as required: +Second, create thy config file and amend it as required: ```shell go run . init > ./cmd/testdata/render/testname/config.yaml ``` -Finally, generate your output: +Finally, generate thy output: ```shell make generateRenderTests diff --git a/install/kots/README.md b/install/kots/README.md index 47926c8c4..487c07453 100644 --- a/install/kots/README.md +++ b/install/kots/README.md @@ -20,7 +20,7 @@ commercially supported project. # Development -> tl;dr the `make` command will build and push a release to your development channel +> tl;dr the `make` command will build and push a release to thy development channel ## Authentication @@ -39,14 +39,14 @@ The following environment variables are required to be able to publish to our Re # Create a development release A development release can be created by running `make create_dev_release`. This builds and publishes -a new development release to the account. This can then be applied to your development cluster. +a new development release to the account. This can then be applied to thy development cluster. Development releases should be used by individual developers when testing and developing a KOTS release. ## Create an unstable release An unstable release can be created by running `make create_unstable_release`. This builds and publishes -a new unstable release to the account. This can then be applied to your development cluster. +a new unstable release to the account. This can then be applied to thy development cluster. Unstable releases should be used as the first part of creating a stable release. diff --git a/install/preview/README.md b/install/preview/README.md index b783acc2a..9b335f582 100644 --- a/install/preview/README.md +++ b/install/preview/README.md @@ -11,7 +11,7 @@ docker run --privileged --name gitpod --rm -it -v /tmp/gitpod:/var/gitpod eu.gcr ``` Once the above command starts running and the pods are ready (can be checked by running `docker exec gitpod kubectl get pods`), -The URL to access your gitpod instance can be retrieved by running +The URL to access thy gitpod instance can be retrieved by running ``` docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' gitpod | sed -r 's/[.]+/-/g' | sed 's/$/.nip.io/g' @@ -19,7 +19,7 @@ docker inspect -f '{{range.NetworkSettings.Networks}}{{.IPAddress}}{{end}}' gitp [nip.io](https://nip.io/) is just wildcard DNS for local addresses, So all off this is local, and cannot be accessed over the internet. -As the `self-hosted` instance is self-signed, The root certificate to upload into your browser trust store to access the URL is available at +As the `self-hosted` instance is self-signed, The root certificate to upload into thy browser trust store to access the URL is available at `/tmp/gitpod/gitpod-ca.crt`. ## Known Issues diff --git a/operations/observability/mixins/README.md b/operations/observability/mixins/README.md index de60eb1a6..818a65d12 100644 --- a/operations/observability/mixins/README.md +++ b/operations/observability/mixins/README.md @@ -109,7 +109,7 @@ local runningWorkspacesGraph = } ``` -To make sure your jsonnet code compiles and is well-formated, you can always run `make lint`. +To make sure thy jsonnet code compiles and is well-formated, you can always run `make lint`. You can also use our [preview environments to make sure the dashboard really looks like what you imagined](#How-do-I-review-dashboards-before-merging-PRs). @@ -271,7 +271,7 @@ We also have this same validation running in our CI, to make sure we don't merge ## Deploying merged changes to production -Alright, you got your changes merged, now what? The changes need to land on our [gitpod-io/observability](https://github.com/gitpod-io/observability) repository by updating the `vendor/` folder. +Alright, you got thy changes merged, now what? The changes need to land on our [gitpod-io/observability](https://github.com/gitpod-io/observability) repository by updating the `vendor/` folder. The `vendor/` folder can be updated by triggering this [workflow](https://github.com/gitpod-io/observability/actions/workflows/dep-update.yaml). Yes, you just need to click the button and the workflow will open a new Pull Request with the updates. @@ -295,7 +295,7 @@ This `jsonnetfile.json` lists all dependencies that we use, which includes this ### How do I review dashboards before merging PRs? -There are a couple of options to trigger a werft job that will deploy a preview environment with Prometheus+Grafana with your changes: +There are a couple of options to trigger a werft job that will deploy a preview environment with Prometheus+Grafana with thy changes: #### Pull request description @@ -305,7 +305,7 @@ The following combination of annotations can be used to deploy monitoring satell * Use harvester previews. Monitoring-satellite is deployed on those previews by default ``` /werft with-vm=true -# Just in case your PR requires extra configuration on Prometheus side (and you have a new branch on https://github.com/gitpod-io/observability with such changes) +# Just in case thy PR requires extra configuration on Prometheus side (and you have a new branch on https://github.com/gitpod-io/observability with such changes) # You can add the line below /werft withObservabilityBranch= ``` @@ -313,7 +313,7 @@ The following combination of annotations can be used to deploy monitoring satell * Use Gitpod helm charts to deploy a preview, and add the observability annotation ``` /werft with-helm=true with-observability=true -# Just in case your PR requires extra configuration on Prometheus side (and you have a new branch on https://github.com/gitpod-io/observability with such changes) +# Just in case thy PR requires extra configuration on Prometheus side (and you have a new branch on https://github.com/gitpod-io/observability with such changes) # You can add the line below /werft withObservabilityBranch= ``` diff --git a/test/README.md b/test/README.md index c70ec1a0a..20f5eacc5 100644 --- a/test/README.md +++ b/test/README.md @@ -41,7 +41,7 @@ You may want to run tests to assert whether a Gitpod installation is successfull Best for when you want to validate an environment. 1. Update image name in `integration.yaml` for job `integration-job` to latest built by werft. -2. Optionally add your username in that job argument or any other additional params. +2. Optionally add thy username in that job argument or any other additional params. 2. Apply yaml file that will add all necessary permissions and create a job that will run tests. * [`kubectl apply -f ./integration.yaml`](./integration.yaml) 3. Check logs to inspect test results like so `kubectl logs -f jobs/integration-job`. @@ -54,7 +54,7 @@ This is best for when you're actively developing Gitpod. Test will work if images that they use are already cached by Gitpod instance. If not, they might fail if it takes too long to pull an image. There are 4 different types of tests: 1. Enterprise specific, that require valid license to be installed. Run those with `-enterprise=true` -2. Tests that require correct user (user should have github OAuth integration setup with gitpod). Run those with `-username=`. Make sure to load https://github.com/gitpod-io/gitpod-test-repo and https://github.com/gitpod-io/gitpod workspaces inside your gitpod that you are testing to preload those images onto your node. Wait for it to finish pulling those image, this will ensure that test will not fail due to timeout while waiting to pull an image for the first time. +2. Tests that require correct user (user should have github OAuth integration setup with gitpod). Run those with `-username=`. Make sure to load https://github.com/gitpod-io/gitpod-test-repo and https://github.com/gitpod-io/gitpod workspaces inside thy gitpod that you are testing to preload those images onto thy node. Wait for it to finish pulling those image, this will ensure that test will not fail due to timeout while waiting to pull an image for the first time. 3. To test gitlab integration, add `-gitlab=true` 4. All other tests.