diff --git a/app/assets/javascripts/pipelines/mixins/graph_pipeline_bundle_mixin.js b/app/assets/javascripts/pipelines/mixins/graph_pipeline_bundle_mixin.js index c76869d90d50c87b0196fcbacc3e7a55641066d2..1d9366f26dfeee42abbfb970ea3cb30581cab3f3 100644 --- a/app/assets/javascripts/pipelines/mixins/graph_pipeline_bundle_mixin.js +++ b/app/assets/javascripts/pipelines/mixins/graph_pipeline_bundle_mixin.js @@ -59,7 +59,7 @@ export default { }, requestRefreshPipelineGraph() { // When an action is clicked - // (wether in the dropdown or in the main nodes, we refresh the big graph) + // (whether in the dropdown or in the main nodes, we refresh the big graph) this.mediator .refreshPipeline() .catch(() => flash(__('An error occurred while making the request.'))); diff --git a/app/finders/concerns/finder_with_cross_project_access.rb b/app/finders/concerns/finder_with_cross_project_access.rb index 06ebb286086c06cd7d19421b1b94c7561bfd9e77..a55fb58a1bcf2e88410afa31d749deddbf6f1bf4 100644 --- a/app/finders/concerns/finder_with_cross_project_access.rb +++ b/app/finders/concerns/finder_with_cross_project_access.rb @@ -1,6 +1,6 @@ # frozen_string_literal: true -# Module to prepend into finders to specify wether or not the finder requires +# Module to prepend into finders to specify whether or not the finder requires # cross project access # # This module depends on the finder implementing the following methods: diff --git a/changelogs/unreleased/revert_rename_services_template_to_instance_migration.yml b/changelogs/unreleased/revert_rename_services_template_to_instance_migration.yml new file mode 100644 index 0000000000000000000000000000000000000000..5bf8c29035511bac43aa3a75fdfd00aacada1aa2 --- /dev/null +++ b/changelogs/unreleased/revert_rename_services_template_to_instance_migration.yml @@ -0,0 +1,5 @@ +--- +title: Revert rename services template to instance migration +merge_request: 24885 +author: +type: fixed diff --git a/db/post_migrate/20200211152410_remove_instance_from_services.rb b/db/post_migrate/20200211152410_remove_instance_from_services.rb new file mode 100644 index 0000000000000000000000000000000000000000..1f27455b541441f56d99535a603811571de11114 --- /dev/null +++ b/db/post_migrate/20200211152410_remove_instance_from_services.rb @@ -0,0 +1,19 @@ +# frozen_string_literal: true + +class RemoveInstanceFromServices < ActiveRecord::Migration[6.0] + include Gitlab::Database::MigrationHelpers + + DOWNTIME = false + + def up + return unless column_exists?(:services, :instance) + + undo_rename_column_concurrently :services, :template, :instance + end + + def down + # This migration should not be rolled back because it + # removes a column that got added in migrations that + # have been reverted in https://gitlab.com/gitlab-org/gitlab/-/merge_requests/24857 + end +end diff --git a/db/schema.rb b/db/schema.rb index ecc4870b33daebd7cc9cc19eb6578c866da3a06b..162964f25e81327ff4d96f12238b3a2a1d96b143 100644 --- a/db/schema.rb +++ b/db/schema.rb @@ -10,7 +10,7 @@ # # It's strongly recommended that you check this file into your version control system. -ActiveRecord::Schema.define(version: 2020_02_07_151640) do +ActiveRecord::Schema.define(version: 2020_02_11_152410) do # These are extensions that must be enabled in order to support this database enable_extension "pg_trgm" diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md index c3d45d51ea6380272bd098a85e3f4001f0aaece8..5c8ad18a4df530e808d49aec063d125d4b87e98d 100644 --- a/doc/administration/geo/replication/configuration.md +++ b/doc/administration/geo/replication/configuration.md @@ -171,7 +171,7 @@ keys must be manually replicated to the **secondary** node. sudo -i ``` -1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** name for your node. You will need this in the next steps: +1. Edit `/etc/gitlab/gitlab.rb` and add a **unique** name for your node. You will need this in the next steps: ```ruby # The unique identifier for the Geo node. diff --git a/doc/administration/geo/replication/faq.md b/doc/administration/geo/replication/faq.md index 8a3439d2aaaa13fb46313412dfcf7455d1068729..2405e2cbfd23fe9918b21fccdc9f59842c1b09c0 100644 --- a/doc/administration/geo/replication/faq.md +++ b/doc/administration/geo/replication/faq.md @@ -45,7 +45,7 @@ query. ## Can I `git push` to a **secondary** node? -Yes! Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3. +Yes! Pushing directly to a **secondary** node (for both HTTP and SSH, including Git LFS) was [introduced](https://about.gitlab.com/releases/2018/09/22/gitlab-11-3-released/) in [GitLab Premium](https://about.gitlab.com/pricing/#self-managed) 11.3. ## How long does it take to have a commit replicated to a **secondary** node? diff --git a/doc/administration/gitaly/praefect.md b/doc/administration/gitaly/praefect.md index 2f80dd66548421d63cf45e4e81bb04288cc9b9a6..073e2010fd26f7cc1d65d2199fadb9cbde865558 100644 --- a/doc/administration/gitaly/praefect.md +++ b/doc/administration/gitaly/praefect.md @@ -227,7 +227,7 @@ remember to run `sudo gitlab-ctl reconfigure` again before trying the #### Gitaly -Next we will configure each Gitaly server assigned to Praefect. Configuration for these +Next we will configure each Gitaly server assigned to Praefect. Configuration for these is the same as a normal standalone Gitaly server, except that we use storage names and auth tokens from Praefect instead of GitLab. diff --git a/doc/administration/operations/moving_repositories.md b/doc/administration/operations/moving_repositories.md index a11bce9aa02b192bf4bcda564efda53ea51be91b..2b9ef02ec4213771d05716b89ac695c19cd4cd23 100644 --- a/doc/administration/operations/moving_repositories.md +++ b/doc/administration/operations/moving_repositories.md @@ -16,9 +16,9 @@ source and the target.** ## Target directory is empty: use a tar pipe If the target directory `/mnt/gitlab/repositories` is empty the -simplest thing to do is to use a tar pipe. This method has low +simplest thing to do is to use a tar pipe. This method has low overhead and tar is almost always already installed on your system. -However, it is not possible to resume an interrupted tar pipe: if +However, it is not possible to resume an interrupted tar pipe: if that happens then all data must be copied again. ```shell @@ -82,7 +82,7 @@ repository at a time. In addition to rsync we will use [GNU Parallel](http://www.gnu.org/software/parallel/). This utility is not included in GitLab so you need to install it yourself with apt -or yum. Also note that the GitLab scripts we used below were added +or yum. Also note that the GitLab scripts we used below were added in GitLab 8.1. ** This process does not clean up repositories at the target location that no diff --git a/doc/administration/operations/unicorn.md b/doc/administration/operations/unicorn.md index a19617daaef80e7ae4d82be806f48545bbbb8635..653fad7e24fe57655a9a51d70b409d4662250d47 100644 --- a/doc/administration/operations/unicorn.md +++ b/doc/administration/operations/unicorn.md @@ -75,7 +75,7 @@ Otherwise, you can set the `GITLAB_UNICORN_MEMORY_MIN` and `GITLAB_UNICORN_MEMOR This is what a Unicorn worker memory restart looks like in unicorn_stderr.log. You see that worker 4 (PID 125918) is inspecting itself and decides to exit. The threshold memory value was 254802235 bytes, about 250MB. With GitLab this -threshold is a random value between 200 and 250 MB. The master process (PID +threshold is a random value between 200 and 250 MB. The master process (PID 117565) then reaps the worker process and spawns a new 'worker 4' with PID 127549. diff --git a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md index d4719bb41dc1e7f393798d80cfc631758e8ded64..a4180eb638a281f23a742452ebfe0a47d3064227 100644 --- a/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md +++ b/doc/administration/troubleshooting/gitlab_rails_cheat_sheet.md @@ -166,7 +166,7 @@ GIT_CURL_VERBOSE=1 GIT_TRACE=1 git clone # A single project project = Project.find_by_full_path('PROJECT_PATH') -# All projects in a particular namespace. Can be a username, a group +# All projects in a particular namespace. Can be a username, a group # ('gitlab-org'), or even include subgroups ('gitlab-org/distribution') namespace = Namespace.find_by_full_path('NAMESPACE_PATH') projects = namespace.all_projects @@ -997,7 +997,7 @@ gitlab_rails['env'] = { } ``` -Then `gitlab-ctl reconfigure; gitlab-ctl restart sidekiq`. The Sidekiq logs will now include additional data for troubleshooting. +Then `gitlab-ctl reconfigure; gitlab-ctl restart sidekiq`. The Sidekiq logs will now include additional data for troubleshooting. ### Sidekiq kill signals diff --git a/doc/administration/troubleshooting/linux_cheat_sheet.md b/doc/administration/troubleshooting/linux_cheat_sheet.md index 0ad1f028f20efbb332bfbebe7259b3eaa0be82ae..d53745c58b3dd8420286d60d017868d653b30237 100644 --- a/doc/administration/troubleshooting/linux_cheat_sheet.md +++ b/doc/administration/troubleshooting/linux_cheat_sheet.md @@ -133,7 +133,7 @@ sudo !! ### Memory, Disk, & CPU usage ```shell -# disk space info. The '-h' gives the data in human-readable values +# disk space info. The '-h' gives the data in human-readable values df -h # size of each file/dir and its contents in the current dir @@ -186,7 +186,7 @@ Be aware that strace can have major impacts to system performance when it is run ### The Strace Parser tool Our [strace-parser tool](https://gitlab.com/wchandler/strace-parser) can be used to -provide a high level summary of the `strace` output. It is similar to `strace -C`, +provide a high level summary of the `strace` output. It is similar to `strace -C`, but provides much more detailed statistics. MacOS and Linux binaries [are available](https://gitlab.com/gitlab-com/support/toolbox/strace-parser/-/tags), @@ -198,7 +198,7 @@ First run the tool with no arguments other than the strace output file name to g a summary of the top processes sorted by time spent actively performing tasks. You can also sort based on total time, # of syscalls made, PID #, and # of child processes using the `-S` or `--sort` flag. The number of results defaults to 25 processes, but -can be changed using the `-c`/`--count` option. See `--help` for full details. +can be changed using the `-c`/`--count` option. See `--help` for full details. ```shell $ ./strace-parser strace.txt diff --git a/doc/development/adding_database_indexes.md b/doc/development/adding_database_indexes.md index 6932858c69980588e9c15f83898ee3fd34fa01bb..3ddb15fa2903e3a5bbcba82259cc9e899e99579b 100644 --- a/doc/development/adding_database_indexes.md +++ b/doc/development/adding_database_indexes.md @@ -105,7 +105,7 @@ ORDER BY pg_relation_size(indexrelname::regclass) desc; ``` This query outputs a list containing all indexes that are never used and sorts -them by indexes sizes in descending order. This query can be useful to +them by indexes sizes in descending order. This query can be useful to determine if any previously indexes are useful after all. More information on the meaning of the various columns can be found at . diff --git a/doc/development/code_review.md b/doc/development/code_review.md index ddece96a9af99195d6f886c1af669c5d0e00a5a3..41ebcc7f2d0fe0139084bf057e793fc1bd7fce65 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -107,7 +107,7 @@ confidence in their solution will not have been reached. Before the review, the author is requested to submit comments on the merge request diff alerting the reviewer to anything important as well as for anything -that demands further explanation or attention. Examples of content that may +that demands further explanation or attention. Examples of content that may warrant a comment could be: - The addition of a linting rule (Rubocop, JS etc) @@ -181,8 +181,8 @@ vulnerabilities must be either empty or containing: Maintainers should **never** dismiss vulnerabilities to "empty" the list, without duly verifying them. -Note that certain Merge Requests may target a stable branch. These are rare -events. These types of Merge Requests cannot be merged by the Maintainer. +Note that certain Merge Requests may target a stable branch. These are rare +events. These types of Merge Requests cannot be merged by the Maintainer. Instead these should be sent to the [Release Manager](https://about.gitlab.com/community/release-managers/). ## Best practices diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md index 233bf2553610be7c6e76a2d51c160cd06ea3495d..8270e52e0ab8fa6cb8f01e1c2c55baa1baec6522 100644 --- a/doc/development/contributing/index.md +++ b/doc/development/contributing/index.md @@ -82,9 +82,9 @@ When you submit code to GitLab, we really want it to get merged, but there will When maintainers are reading through a merge request they may request guidance from other maintainers. If merge request maintainers conclude that the code should not be merged, our reasons will be fully disclosed. If it has been decided that the code quality is not up to GitLab’s standards, the merge request maintainer will refer the author to our docs and code style guides, and provide some guidance. -Sometimes style guides will be followed but the code will lack structural integrity, or the maintainer will have reservations about the code’s overall quality. When there is a reservation the maintainer will inform the author and provide some guidance. The author may then choose to update the merge request. Once the merge request has been updated and reassigned to the maintainer, they will review the code again. Once the code has been resubmitted any number of times, the maintainer may choose to close the merge request with a summary of why it will not be merged, as well as some guidance. If the merge request is closed the maintainer will be open to discussion as to how to improve the code so it can be approved in the future. +Sometimes style guides will be followed but the code will lack structural integrity, or the maintainer will have reservations about the code’s overall quality. When there is a reservation the maintainer will inform the author and provide some guidance. The author may then choose to update the merge request. Once the merge request has been updated and reassigned to the maintainer, they will review the code again. Once the code has been resubmitted any number of times, the maintainer may choose to close the merge request with a summary of why it will not be merged, as well as some guidance. If the merge request is closed the maintainer will be open to discussion as to how to improve the code so it can be approved in the future. -GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/company/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request. For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches. +GitLab will do its best to review community contributions as quickly as possible. Specially appointed developers review community contributions daily. You may take a look at the [team page](https://about.gitlab.com/company/team/) for the merge request coach who specializes in the type of code you have written and mention them in the merge request. For example, if you have written some JavaScript in your code then you should mention the frontend merge request coach. If your code has multiple disciplines you may mention multiple merge request coaches. GitLab receives a lot of community contributions, so if your code has not been reviewed within two days (excluding weekend and public holidays) of its initial submission feel free to re-mention the appropriate merge request coach. diff --git a/doc/development/elasticsearch.md b/doc/development/elasticsearch.md index e3ec69b6489a3fc8f30ea9e49ac525a71b322373..b8d2a873d8b9ce695d3be0646867a8c086c6b7ca 100644 --- a/doc/development/elasticsearch.md +++ b/doc/development/elasticsearch.md @@ -193,7 +193,7 @@ You might get an error such as This is because you've exceeded the disk space threshold - it thinks you don't have enough disk space left, based on the default 95% threshold. -In addition, the `read_only_allow_delete` setting will be set to `true`. It will block indexing, `forcemerge`, etc +In addition, the `read_only_allow_delete` setting will be set to `true`. It will block indexing, `forcemerge`, etc ``` curl "http://localhost:9200/gitlab-development/_settings?pretty" diff --git a/doc/development/fe_guide/performance.md b/doc/development/fe_guide/performance.md index 6d5021c0f08d8c1c2a4510075f2bc1b0b4970491..fcba8758c2f9212eed85013c82c681e34a4231a2 100644 --- a/doc/development/fe_guide/performance.md +++ b/doc/development/fe_guide/performance.md @@ -85,15 +85,15 @@ browser's developer console while on any page within GitLab. #### Important Considerations - **Keep Entry Points Lite:** - Page-specific JavaScript entry points should be as lite as possible. These + Page-specific JavaScript entry points should be as lite as possible. These files are exempt from unit tests, and should be used primarily for instantiation and dependency injection of classes and methods that live in - modules outside of the entry point script. Just import, read the DOM, + modules outside of the entry point script. Just import, read the DOM, instantiate, and nothing else. - **Entry Points May Be Asynchronous:** _DO NOT ASSUME_ that the DOM has been fully loaded and available when an - entry point script is run. If you require that some code be run after the + entry point script is run. If you require that some code be run after the DOM has loaded, you should attach an event handler to the `DOMContentLoaded` event with: @@ -113,7 +113,7 @@ browser's developer console while on any page within GitLab. with a relative path (e.g. `import initMyWidget from './my_widget';`). - If a class or module is _used by multiple routes_, place it within a shared directory at the closest common parent directory for the entry - points that import it. For example, if `my_widget.js` is imported within + points that import it. For example, if `my_widget.js` is imported within both `pages/widget/show/index.js` and `pages/widget/run/index.js`, then place the module at `pages/widget/shared/my_widget.js` and import it with a relative path if possible (e.g. `../shared/my_widget`). @@ -122,7 +122,7 @@ browser's developer console while on any page within GitLab. For GitLab Enterprise Edition, page-specific entry points will override their Community Edition counterparts with the same name, so if `ee/app/assets/javascripts/pages/foo/bar/index.js` exists, it will take - precedence over `app/assets/javascripts/pages/foo/bar/index.js`. If you want + precedence over `app/assets/javascripts/pages/foo/bar/index.js`. If you want to minimize duplicate code, you can import one entry point from the other. This is not done automatically to allow for flexibility in overriding functionality. @@ -131,7 +131,7 @@ browser's developer console while on any page within GitLab. For any code that does not need to be run immediately upon page load, (e.g. modals, dropdowns, and other behaviors that can be lazy-loaded), you can split -your module into asynchronous chunks with dynamic import statements. These +your module into asynchronous chunks with dynamic import statements. These imports return a Promise which will be resolved once the script has loaded: ```javascript diff --git a/doc/development/github_importer.md b/doc/development/github_importer.md index 5445f36b9fa728320d8d3071f3371948f52610fd..6b8c083d55f55a638be147f8ba3c735c4b0b4d85 100644 --- a/doc/development/github_importer.md +++ b/doc/development/github_importer.md @@ -140,7 +140,7 @@ long we're still performing work. GitHub has a rate limit of 5 000 API calls per hour. The number of requests necessary to import a project is largely dominated by the number of unique users involved in a project (e.g. issue authors). Other data such as issue pages -and comments typically only requires a few dozen requests to import. This is +and comments typically only requires a few dozen requests to import. This is because we need the Email address of users in order to map them to GitLab users. We handle this by doing the following: diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md index 71c5be7c0cfa82c9407470b1be88240f0e52abc2..1be09bfeddfe14abefb186c08dfa7abda62d5f8b 100644 --- a/doc/development/go_guide/index.md +++ b/doc/development/go_guide/index.md @@ -188,9 +188,9 @@ code readability and test output. ### Better output in tests When comparing expected and actual values in tests, use -[testify/require.Equal](https://godoc.org/github.com/stretchr/testify/require#Equal), -[testify/require.EqualError](https://godoc.org/github.com/stretchr/testify/require#EqualError), -[testify/require.EqualValues](https://godoc.org/github.com/stretchr/testify/require#EqualValues), +[`testify/require.Equal`](https://godoc.org/github.com/stretchr/testify/require#Equal), +[`testify/require.EqualError`](https://godoc.org/github.com/stretchr/testify/require#EqualError), +[`testify/require.EqualValues`](https://godoc.org/github.com/stretchr/testify/require#EqualValues), and others to improve readability when comparing structs, errors, large portions of text, or JSON documents: diff --git a/doc/development/logging.md b/doc/development/logging.md index b649f6a9b05165dab65813dafceaa2630dc17f28..780038cf2dd65aa442cc47ab7856ba3c2c84ed69 100644 --- a/doc/development/logging.md +++ b/doc/development/logging.md @@ -129,7 +129,7 @@ importer progresses. Here's what to do: ## Multi-destination Logging -GitLab is transitioning from unstructured/plaintext logs to structured/JSON logs. During this transition period some logs will be recorded in multiple formats through multi-destination logging. +GitLab is transitioning from unstructured/plaintext logs to structured/JSON logs. During this transition period some logs will be recorded in multiple formats through multi-destination logging. ### How to use multi-destination logging diff --git a/doc/development/migration_style_guide.md b/doc/development/migration_style_guide.md index 18afeeb181462365fd2a386729f2ad62bd0d2020..2c9ad8c00cfb3292bf641a777618a327f11a91d4 100644 --- a/doc/development/migration_style_guide.md +++ b/doc/development/migration_style_guide.md @@ -267,7 +267,7 @@ end Here the call to `disable_statement_timeout` will use the connection local to the `with_multiple_threads` block, instead of re-using the global connection -pool. This ensures each thread has its own connection object, and won't time +pool. This ensures each thread has its own connection object, and won't time out when trying to obtain one. **NOTE:** PostgreSQL has a maximum amount of connections that it allows. This diff --git a/doc/development/namespaces_storage_statistics.md b/doc/development/namespaces_storage_statistics.md index 6ec37e830c6f65570f0431e19a1a31809fc9ae32..71c9a0b96fb5581ebbe61700b4196b2ef982c188 100644 --- a/doc/development/namespaces_storage_statistics.md +++ b/doc/development/namespaces_storage_statistics.md @@ -26,7 +26,7 @@ by [`Namespaces#with_statistics`](https://gitlab.com/gitlab-org/gitlab/blob/4ab5 Additionally, the pattern that is currently used to update the project statistics (the callback) doesn't scale adequately. It is currently one of the largest [database queries transactions on production](https://gitlab.com/gitlab-org/gitlab-foss/issues/62488) -that takes the most time overall. We can't add one more query to it as +that takes the most time overall. We can't add one more query to it as it will increase the transaction's length. Because of all of the above, we can't apply the same pattern to store diff --git a/doc/development/pry_debugging.md b/doc/development/pry_debugging.md index 17d8428b0c021ba965f23f83e5d2a0dac5a67c52..0558a0a515afd80f0dd7b3e65d5942ff56db050f 100644 --- a/doc/development/pry_debugging.md +++ b/doc/development/pry_debugging.md @@ -103,7 +103,7 @@ You also can move around in the callstack with these commands: ## Short commands When you use `binding.pry` instead of `byebug`, the short commands -like `s`, `n`, `f`, and `c` do not work. To reinstall them, add this +like `s`, `n`, `f`, and `c` do not work. To reinstall them, add this to `~/.pryrc`: ```ruby diff --git a/doc/development/reactive_caching.md b/doc/development/reactive_caching.md index 94058a3c09cad6b96a4a78b32ab5a8a85a957009..3563ff5322a456dba943b9c6c65c4fbf255e73fe 100644 --- a/doc/development/reactive_caching.md +++ b/doc/development/reactive_caching.md @@ -3,7 +3,7 @@ > This doc refers to . The `ReactiveCaching` concern is used for fetching some data in the background and store it -in the Rails cache, keeping it up-to-date for as long as it is being requested. If the +in the Rails cache, keeping it up-to-date for as long as it is being requested. If the data hasn't been requested for `reactive_cache_lifetime`, it will stop being refreshed, and then be removed. diff --git a/doc/development/renaming_features.md b/doc/development/renaming_features.md index ca204bd420e138df1159ce892a825fd89a321c50..6a196921a5dd17e5cdaa9149d891afca6fc98e63 100644 --- a/doc/development/renaming_features.md +++ b/doc/development/renaming_features.md @@ -21,4 +21,4 @@ The more of the following that are true, the more likely you should choose the f ## Consider a façade-first approach -The façade approach is not necessarily a final step. It can (and possibly *should*) be treated as the first step, where later iterations will accomplish the complete rename. +The façade approach is not necessarily a final step. It can (and possibly *should*) be treated as the first step, where later iterations will accomplish the complete rename. diff --git a/doc/development/scalability.md b/doc/development/scalability.md index d4772bf3ea5a21f82186e4deb43af8465699e4d4..37ffdbdbfde2bbf541875c253cbf339a71abd98b 100644 --- a/doc/development/scalability.md +++ b/doc/development/scalability.md @@ -165,7 +165,7 @@ and secondaries are set up a bit differently: For replicas, colocating is advantageous because it reduces network hops and hence latency. However, for the primary, colocating is disadvantageous because PgBouncer would become a single point of failure -and cause errors. When a failover occurs, one of two things could +and cause errors. When a failover occurs, one of two things could happen: - The primary disappears from the network. @@ -212,7 +212,7 @@ Redis process. #### High availability/Risks Single-core: Like PgBouncer, a single Redis process can only use one -core. It does not support multi-threading. +core. It does not support multi-threading. Dumb secondaries: Redis secondaries (aka slaves) don't actually handle any load. Unlike PostgreSQL secondaries, they don't even serve diff --git a/doc/development/shell_commands.md b/doc/development/shell_commands.md index 7079f7a9914bd19be9740e253138fa1512c95a99..b8952cae33ef38cf8acd21e735921269823057a6 100644 --- a/doc/development/shell_commands.md +++ b/doc/development/shell_commands.md @@ -126,7 +126,7 @@ Note that unlike `Gitlab::Popen.popen`, `IO.popen` does not capture standard err ## Avoid user input at the start of path strings Various methods for opening and reading files in Ruby can be used to read the -standard output of a process instead of a file. The following two commands do +standard output of a process instead of a file. The following two commands do roughly the same: ```ruby @@ -138,7 +138,7 @@ The key is to open a 'file' whose name starts with a `|`. Affected methods include Kernel#open, File::read, File::open, IO::open and IO::read. You can protect against this behavior of 'open' and 'read' by ensuring that an -attacker cannot control the start of the filename string you are opening. For +attacker cannot control the start of the filename string you are opening. For instance, the following is sufficient to protect against accidentally starting a shell command with `|`: diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index 3285aaed0953ccdc53bde34fe1dfe5c21be71768..e3355e1545545fbd7d3375f3b6ea0749ec961b3e 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -536,7 +536,7 @@ reset before each example, add the `:prometheus` tag to the Rspec test. ### Matchers Custom matchers should be created to clarify the intent and/or hide the -complexity of RSpec expectations.They should be placed under +complexity of RSpec expectations. They should be placed under `spec/support/matchers/`. Matchers can be placed in subfolder if they apply to a certain type of specs only (e.g. features, requests etc.) but shouldn't be if they apply to multiple type of specs. diff --git a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md index aec0a3ede5aa1b42d16042ab45d9464ff5bcecc3..32b1c304a9a49d674ef239fb80c00167f4d56d8d 100644 --- a/doc/development/testing_guide/end_to_end/dynamic_element_validation.md +++ b/doc/development/testing_guide/end_to_end/dynamic_element_validation.md @@ -27,7 +27,7 @@ Runtime::Browser.visit(:gitlab, Some::Page) ### Clicks -When we perform a click within our tests, we expect something to occur. That something could be a component to now +When we perform a click within our tests, we expect something to occur. That something could be a component to now appear on the webpage, or the test to navigate away from the page entirely. Dynamic element validation is instituted when using @@ -57,7 +57,7 @@ Simply put, a required element is a visible HTML element that appears on a UI co #### Application -Requiring elements is very easy. By adding `required: true` as a parameter to an `element`, you've now made it +Requiring elements is very easy. By adding `required: true` as a parameter to an `element`, you've now made it a requirement that the element appear on the page upon navigation. ## Examples diff --git a/doc/development/testing_guide/end_to_end/page_objects.md b/doc/development/testing_guide/end_to_end/page_objects.md index f1e0de0c792b449ca6bf404d2790f3a66619658b..22e7375be1feb13e66d1e96e4b495c92e38df556 100644 --- a/doc/development/testing_guide/end_to_end/page_objects.md +++ b/doc/development/testing_guide/end_to_end/page_objects.md @@ -152,7 +152,7 @@ Things to note: - The name of the element and the qa_selector must match and be snake_cased - If the element appears on the page unconditionally, add `required: true` to the element. See [Dynamic element validation](dynamic_element_validation.md) -- You may see `.qa-selector` classes in existing Page Objects. We should prefer the [`data-qa-selector`](#data-qa-selector-vs-qa-selector) +- You may see `.qa-selector` classes in existing Page Objects. We should prefer the [`data-qa-selector`](#data-qa-selector-vs-qa-selector) method of definition over the `.qa-selector` CSS class ### `data-qa-selector` vs `.qa-selector` @@ -173,7 +173,7 @@ and we should prefer the `data-qa-selector` method of definition. A common occurrence in automated testing is selecting a single "one-of-many" element. In a list of several items, how do you differentiate what you are selecting on? -The most common workaround for this is via text matching. Instead, a better practice is +The most common workaround for this is via text matching. Instead, a better practice is by matching on that specific element by a unique identifier, rather than by text. We got around this by adding the `data-qa-*` extensible selection mechanism. diff --git a/doc/development/testing_guide/testing_migrations_guide.md b/doc/development/testing_guide/testing_migrations_guide.md index 3fef13afa9cb3bc516d176fbe971b7a3762a3bb0..392911b1fda3a95920bdcc989f8708642331fbfa 100644 --- a/doc/development/testing_guide/testing_migrations_guide.md +++ b/doc/development/testing_guide/testing_migrations_guide.md @@ -59,7 +59,7 @@ project = table(:projects).create!(id: 1, name: 'gitlab1', path: 'gitlab1') #### `migrate!` -Use the `migrate!` helper to run the migration that is under test. It will not only +Use the `migrate!` helper to run the migration that is under test. It will not only run the migration, but will also bump the schema version in the `schema_migrations` table. It is necessary because in the `after` hook we trigger the rest of the migrations, and we need to know where to start. Example: diff --git a/lib/gitlab/git/blob.rb b/lib/gitlab/git/blob.rb index 5a6cc0159c6f2652ae0f358929ebbfc6b7211b98..4808cd936f5a2f5c2ae908037f34d51e12564dc3 100644 --- a/lib/gitlab/git/blob.rb +++ b/lib/gitlab/git/blob.rb @@ -128,7 +128,7 @@ module Gitlab def load_all_data!(repository) return if @data == '' # don't mess with submodule blobs - # Even if we return early, recalculate wether this blob is binary in + # Even if we return early, recalculate whether this blob is binary in # case a blob was initialized as text but the full data isn't @binary = nil diff --git a/lib/support/init.d/gitlab b/lib/support/init.d/gitlab index 827c7cf7ce8f69bfaca9262c2feeea59aa69bfd3..1c51288adf65b124d53d8294eee6a5713c803e5a 100755 --- a/lib/support/init.d/gitlab +++ b/lib/support/init.d/gitlab @@ -340,7 +340,7 @@ start_gitlab() { # Wait for the pids to be planted wait_for_pids - # Finally check the status to tell wether or not GitLab is running + # Finally check the status to tell whether or not GitLab is running print_status } diff --git a/spec/helpers/projects_helper_spec.rb b/spec/helpers/projects_helper_spec.rb index 7fc568bb9600d6a27dabaab20d116f1f9ef7af32..d61289dabb6885896ab60ae552383f7873165640 100644 --- a/spec/helpers/projects_helper_spec.rb +++ b/spec/helpers/projects_helper_spec.rb @@ -194,7 +194,7 @@ describe ProjectsHelper do expect(helper.project_list_cache_key(project).last).to start_with('v') end - it 'includes wether or not the user can read cross project' do + it 'includes whether or not the user can read cross project' do expect(helper.project_list_cache_key(project)).to include('cross-project:true') end