diff --git a/docs/developer-guide/contributors-quickstart.md b/docs/developer-guide/contributors-quickstart.md index 5fe914c476188..3a9de03de88d1 100644 --- a/docs/developer-guide/contributors-quickstart.md +++ b/docs/developer-guide/contributors-quickstart.md @@ -20,7 +20,7 @@ Before starting, ensure you have the following tools installed with the specifie ### Fork and Clone the Repository -1. Fork the Argo CD repository to your personal Github Account +1. Fork the Argo CD repository to your personal GitHub Account 2. Clone the forked repository: ```shell diff --git a/docs/developer-guide/dependencies.md b/docs/developer-guide/dependencies.md index 2a4c869825e31..e609a23e16330 100644 --- a/docs/developer-guide/dependencies.md +++ b/docs/developer-guide/dependencies.md @@ -47,7 +47,7 @@ If you make changes to the Argo UI component, and your Argo CD changes depend on 2. Also, prepare your Argo CD changes, but don't create the PR just yet. 3. **After** the Argo UI PR has been merged to master, then as part of your Argo CD changes: - Run `yarn add git+https://github.com/argoproj/argo-ui.git` in the `ui/` directory, and then, - - Check in the regenerated yarn.lock file as part of your Argo CD commit + - Check in the regenerated `yarn.lock` file as part of your Argo CD commit 4. Create the Argo CD PR when you are ready. The PR build and test checks should pass. -If your Argo UI change is a 'stand-alone' fix, and you simply want Argo CD to pull in your change, then simply create an Argo CD PR with the yarn.lock file change. +If your Argo UI change is a 'stand-alone' fix, and you simply want Argo CD to pull in your change, then simply create an Argo CD PR with the `yarn.lock` file change. diff --git a/docs/developer-guide/release-process-and-cadence.md b/docs/developer-guide/release-process-and-cadence.md index 94ece653b6ce9..415ac10ede987 100644 --- a/docs/developer-guide/release-process-and-cadence.md +++ b/docs/developer-guide/release-process-and-cadence.md @@ -88,4 +88,4 @@ These evaluations vary from dependency to dependencies. Dependencies are also scheduled for removal if the project has been deprecated or if the project is no longer maintained. CVEs in dependencies will be patched for all supported versions if the CVE is applicable and is assessed by Snyk to be -of high or critical severity. Automation generates a [new Snyk scan weekly](../snyk). +of high or critical severity. Automation generates a [new Snyk scan weekly](../snyk/index.md). diff --git a/docs/developer-guide/running-locally.md b/docs/developer-guide/running-locally.md index 25f4510e9e18a..f1e6db9b88a43 100644 --- a/docs/developer-guide/running-locally.md +++ b/docs/developer-guide/running-locally.md @@ -123,7 +123,7 @@ $ goreman run status [...] ``` -If not all critical processes run (marked with `*`), check logs to see why they terminated. +If some of the processes fail to start (not marked with `*`), check logs to see why they are not running. In case of an error like `gpg: key generation failed: Unknown elliptic curve` (a [gnupg bug](https://dev.gnupg.org/T5444)), disable GPG verification before running `make start-local`: diff --git a/docs/developer-guide/static-code-analysis.md b/docs/developer-guide/static-code-analysis.md index 90798a70f5a32..bdc331c02e803 100644 --- a/docs/developer-guide/static-code-analysis.md +++ b/docs/developer-guide/static-code-analysis.md @@ -2,9 +2,9 @@ We use the following static code analysis tools: -* golangci-lint and eslint for compile time linting +* `golangci-lint` and `eslint` for compile time linting * [codecov.io](https://codecov.io/gh/argoproj/argo-cd) - for code coverage * [snyk.io](https://app.snyk.io/org/argoproj/projects) - for image scanning * [sonarcloud.io](https://sonarcloud.io/organizations/argoproj/projects) - for code scans and security alerts -These are at least run daily or on each pull request. \ No newline at end of file +These are at least run daily or on each pull request. diff --git a/docs/developer-guide/toolchain-guide.md b/docs/developer-guide/toolchain-guide.md index 46525280f42da..c2e1c3f960fce 100644 --- a/docs/developer-guide/toolchain-guide.md +++ b/docs/developer-guide/toolchain-guide.md @@ -42,7 +42,6 @@ You will need at least the following things in your toolchain in order to develo When you submit a PR against Argo CD's GitHub repository, a couple of CI checks will be run automatically to ensure your changes will build fine and meet certain quality standards. Your contribution needs to pass those checks in order to be merged into the repository. !!!note - Please make sure that you always create PRs from a branch that is up-to-date with the latest changes from Argo CD's master branch. Depending on how long it takes for the maintainers to review and merge your PR, it might be necessary to pull in latest changes into your branch again. Please understand that we, as an Open Source project, have limited capacities for reviewing and merging PRs to Argo CD. We will do our best to review your PR and give you feedback as soon as possible, but please bear with us if it takes a little longer as expected. @@ -95,7 +94,7 @@ ok github.com/argoproj/argo-cd/server/cache 0.029s coverage: 89.3% ## Local vs Virtualized toolchain -Argo CD provides a fully virtualized development and testing toolchain using Docker images. It is recommended to use those images, as they provide the same runtime environment as the final product and it is much easier to keep up-to-date with changes to the toolchain and dependencies. But as using Docker comes with a slight performance penalty, you might want to setup a local toolchain. +Argo CD provides a fully virtualized development and testing toolchain using Docker images. It is recommended to use those images, as they provide the same runtime environment as the final product, and it is much easier to keep up-to-date with changes to the toolchain and dependencies. But as using Docker comes with a slight performance penalty, you might want to set up a local toolchain. Most relevant targets for the build & test cycles in the `Makefile` provide two variants, one of them suffixed with `-local`. For example, `make test` will run unit tests in the Docker container, `make test-local` will run it natively on your local system. @@ -104,7 +103,7 @@ If you are going to use the virtualized toolchain, please bear in mind the follo * Your Kubernetes API server must listen on the interface of your local machine or VM, and not on `127.0.0.1` only. * Your Kubernetes client configuration (`~/.kube/config`) must not use an API URL that points to `localhost` or `127.0.0.1`. -You can test whether the virtualized toolchain has access to your Kubernetes cluster by running `make verify-kube-connect` (*after* you have setup your development environment, as described below), which will run `kubectl version` inside the Docker container used for running all tests. +You can test whether the virtualized toolchain has access to your Kubernetes cluster by running `make verify-kube-connect` (*after* you have set up your development environment, as described below), which will run `kubectl version` inside the Docker container used for running all tests. The Docker container for the virtualized toolchain will use the following local mounts from your workstation, and possibly modify its contents: @@ -151,7 +150,7 @@ The following steps are required no matter whether you chose to use a virtualize * `git clone https://github.com/YOUR-USERNAME/argo-cd` * `cd argo-cd` -### Optional: Setup an additional Git remote +### Optional: Set up an additional Git remote While everyone has their own Git workflow, the author of this document recommends to create a remote called `upstream` in your local copy pointing to the original Argo CD repository. This way, you can easily keep your local branches up-to-date by merging in latest changes from the Argo CD repository, i.e. by doing a `git pull upstream master` in your locally checked out branch. To create the remote, run `git remote add upstream https://github.com/argoproj/argo-cd` @@ -215,7 +214,7 @@ k3d cluster create my-cluster --wait --k3s-arg '--disable=traefik@server:*' --ap ``` !!!note -For k3d versions less than v5.0.0, the example command flags `--k3s-arg` and `'--disable=traefik@server:*'` should change to `--k3s-server-arg` and `'--disable=traefik'`, respectively. + For k3d versions less than v5.0.0, the example command flags `--k3s-arg` and `'--disable=traefik@server:*'` should change to `--k3s-server-arg` and `'--disable=traefik'`, respectively. ## The development cycle @@ -250,7 +249,7 @@ After the code glue has been generated, your code should build and the unit test * `make build` * `make test` -These steps are non-modifying, so there's no need to check for changes afterwards. +These steps are non-modifying, so there's no need to check for changes afterward. ### Lint your code base @@ -327,7 +326,7 @@ You need to pull in all required Go dependencies. To do so, run ### Test your build toolchain -The first thing you can do to test whether your build toolchain is setup correctly is by generating the glue code for the API and after that, run a normal build: +The first thing you can do to test whether your build toolchain is set up correctly is by generating the glue code for the API and after that, run a normal build: * `make codegen-local` * `make build-local` @@ -336,7 +335,7 @@ This should return without any error. ### Run unit-tests -The next thing is to make sure that unit tests are running correctly on your system. These will require that all dependencies, such as Helm, Kustomize, Git, GnuPG, etc are correctly installed and fully functioning: +The next thing is to make sure that unit tests are running correctly on your system. These will require that all dependencies, such as Helm, Kustomize, Git, GnuPG, etc. are correctly installed and fully functioning: * `make test-local` diff --git a/docs/developer-guide/use-gitpod.md b/docs/developer-guide/use-gitpod.md index 36f783bdc99dc..5c9d0f21462e6 100644 --- a/docs/developer-guide/use-gitpod.md +++ b/docs/developer-guide/use-gitpod.md @@ -29,7 +29,7 @@ access Argo CD API/UI from your laptop. Gitpod is a perfect tool in following cases: * you are a first-time contributor and eager to start coding; -* you are traveling and don't want to setup development tools on your laptop; +* you are traveling and don't want to set up development tools on your laptop; * you want to review pull request and need to quickly run code from the PR without changing your local setup; ## Limitations