From 3cb952dd10b1fc702bf5f5589dcf493751e4254b Mon Sep 17 00:00:00 2001 From: Ben Bodenmiller Date: Fri, 4 May 2018 01:11:05 +0000 Subject: fix runner requirements --- doc/ci/quick_start/README.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/ci/quick_start/README.md b/doc/ci/quick_start/README.md index fec0ff87326..47e658f610e 100644 --- a/doc/ci/quick_start/README.md +++ b/doc/ci/quick_start/README.md @@ -151,7 +151,8 @@ The next step is to configure a Runner so that it picks the pending jobs. In GitLab, Runners run the jobs that you define in `.gitlab-ci.yml`. A Runner can be a virtual machine, a VPS, a bare-metal machine, a docker container or even a cluster of containers. GitLab and the Runners communicate through an API, -so the only requirement is that the Runner's machine has [Internet] access. +so the only requirement is that the Runner's machine has network access to the +GitLab server. A Runner can be specific to a certain project or serve multiple projects in GitLab. If it serves all projects it's called a _Shared Runner_. @@ -226,4 +227,3 @@ CI with various languages. [enabled]: ../enable_or_disable_ci.md [stages]: ../yaml/README.md#stages [pipeline]: ../pipelines.md -[internet]: https://about.gitlab.com/images/theinternet.png -- cgit v1.2.1 From 9b3953eed4c901397b1f107fec08e52abf3384b0 Mon Sep 17 00:00:00 2001 From: Ben Bodenmiller Date: Fri, 4 May 2018 07:48:32 +0000 Subject: improve basic details on inspecting NFS mounts --- doc/administration/high_availability/nfs.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index ad8ffc46559..957f17e3ea3 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -1,7 +1,7 @@ # NFS You can view information and options set for each of the mounted NFS file -systems by running `sudo nfsstat -m`. +systems by running `nfsstat -m` and `cat /etc/fstab`. ## NFS Server features -- cgit v1.2.1 From 42d191c9d6c772afcfa67f986406075337c6cc3d Mon Sep 17 00:00:00 2001 From: Yuji Yaginuma Date: Fri, 4 May 2018 23:30:19 +0000 Subject: Fix link for `query_recorder.rb` This file is now under `helpers`. Ref: https://gitlab.com/gitlab-org/gitlab-ce/commit/023d4f6f2f3d88d0966fe01e6ef921fd03a309fe --- doc/development/query_recorder.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/development/query_recorder.md b/doc/development/query_recorder.md index 12e90101139..26d3355e94d 100644 --- a/doc/development/query_recorder.md +++ b/doc/development/query_recorder.md @@ -2,7 +2,7 @@ QueryRecorder is a tool for detecting the [N+1 queries problem](http://guides.rubyonrails.org/active_record_querying.html#eager-loading-associations) from tests. -> Implemented in [spec/support/query_recorder.rb](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/support/query_recorder.rb) via [9c623e3e](https://gitlab.com/gitlab-org/gitlab-ce/commit/9c623e3e5d7434f2e30f7c389d13e5af4ede770a) +> Implemented in [spec/support/query_recorder.rb](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/spec/support/helpers/query_recorder.rb) via [9c623e3e](https://gitlab.com/gitlab-org/gitlab-ce/commit/9c623e3e5d7434f2e30f7c389d13e5af4ede770a) As a rule, merge requests [should not increase query counts](merge_request_performance_guidelines.md#query-counts). If you find yourself adding something like `.includes(:author, :assignee)` to avoid having `N+1` queries, consider using QueryRecorder to enforce this with a test. Without this, a new feature which causes an additional model to be accessed will silently reintroduce the problem. -- cgit v1.2.1 From 6fd75502d6afed374bf34f193b44eac57bf5ba33 Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Tue, 8 May 2018 14:51:29 +0000 Subject: correct doc-nav header hierarchy --- doc/development/fe_guide/vuex.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index 6a89bfc7721..d6305bc4dec 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -149,7 +149,7 @@ import { mapActions } from 'vuex'; }; ``` -#### `mutations.js` +### `mutations.js` The mutations specify how the application state changes in response to actions sent to the store. The only way to change state in a Vuex store should be by committing a mutation. @@ -188,7 +188,7 @@ Remember that actions only describe that something happened, they don't describe }; ``` -#### `getters.js` +### `getters.js` Sometimes we may need to get derived state based on store state, like filtering for a specific prop. Using a getter will also cache the result based on dependencies due to [how computed props work](https://vuejs.org/v2/guide/computed.html#Computed-Caching-vs-Methods) This can be done through the `getters`: @@ -213,7 +213,7 @@ import { mapGetters } from 'vuex'; }; ``` -#### `mutations_types.js` +### `mutations_types.js` From [vuex mutations docs][vuex-mutations]: > It is a commonly seen pattern to use constants for mutation types in various Flux implementations. This allows the code to take advantage of tooling like linters, and putting all constants in a single file allows your collaborators to get an at-a-glance view of what mutations are possible in the entire application. -- cgit v1.2.1 From 7e0af6cfc9d9d0272f3b29f128a37863bd6e6324 Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Tue, 8 May 2018 14:55:49 +0000 Subject: add rewire gotcha about testing vuex actions/getters --- doc/development/fe_guide/vuex.md | 12 ++++++++++++ 1 file changed, 12 insertions(+) (limited to 'doc') diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index d6305bc4dec..29d5e446e20 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -352,6 +352,18 @@ describe('component', () => { }); ``` +#### Testing Vuex actions and getters +Because we're currently using `babel-plugin-rewire`, you may encounter the following error when testing your Vuex actions and getters: +`[vuex] actions should be function or object with "handler" function` + +To prevent this error from happening, you need to export an empty function: +``` +// /stores/getters.js or /stores/actions.js + +// prevent babel-plugin-rewire from generating an invalid default during karma tests +export default () => {}; +``` + [vuex-docs]: https://vuex.vuejs.org [vuex-structure]: https://vuex.vuejs.org/en/structure.html [vuex-mutations]: https://vuex.vuejs.org/en/mutations.html -- cgit v1.2.1 From e69d6ae0f8c27dcfc111b4ac9b401deb1ae33725 Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Tue, 8 May 2018 14:56:43 +0000 Subject: Update vuex.md --- doc/development/fe_guide/vuex.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index 29d5e446e20..d047fd96dda 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -358,7 +358,7 @@ Because we're currently using `babel-plugin-rewire`, you may encounter the follo To prevent this error from happening, you need to export an empty function: ``` -// /stores/getters.js or /stores/actions.js +// getters.js or actions.js // prevent babel-plugin-rewire from generating an invalid default during karma tests export default () => {}; -- cgit v1.2.1 From e665169a94a855d7eb45924d8c6ec602578447dd Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Tue, 8 May 2018 17:13:22 +0000 Subject: add link for babel-plugin-rewire --- doc/development/fe_guide/vuex.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index d047fd96dda..95636153805 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -353,7 +353,7 @@ describe('component', () => { ``` #### Testing Vuex actions and getters -Because we're currently using `babel-plugin-rewire`, you may encounter the following error when testing your Vuex actions and getters: +Because we're currently using [`babel-plugin-rewire`](https://github.com/speedskater/babel-plugin-rewire), you may encounter the following error when testing your Vuex actions and getters: `[vuex] actions should be function or object with "handler" function` To prevent this error from happening, you need to export an empty function: -- cgit v1.2.1 From 1a12471d315fac6e4d6a12ffa4f3331c29017602 Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Fri, 11 May 2018 12:39:32 +0000 Subject: fix typo --- doc/development/fe_guide/vuex.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index 95636153805..0335109366a 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -68,7 +68,7 @@ Often we need to provide data from haml to our Vue application. Let's store it i You can use `mapState` to access state properties in the components. ### `actions.js` -An action is a playload of information to send data from our application to our store. +An action is a payload of information to send data from our application to our store. An action is usually composed by a `type` and a `payload` and they describe what happened. Enforcing that every change is described as an action lets us have a clear understanting of what is going on in the app. -- cgit v1.2.1 From 8284118f3619943976cff6c228de4e08e32abf73 Mon Sep 17 00:00:00 2001 From: Robert Speicher Date: Fri, 11 May 2018 11:23:12 -0500 Subject: Move footnote from CONTRIBUTING.md to doc/development/code_review.md A section was moved in f644b8c8 but this got lost. --- doc/development/code_review.md | 1 + 1 file changed, 1 insertion(+) (limited to 'doc') diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 7165b8062a7..53ddf3b062d 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -207,3 +207,4 @@ Largely based on the [thoughtbot code review guide]. [projects]: https://about.gitlab.com/handbook/engineering/projects/ [team]: https://about.gitlab.com/team/ [build handbook]: https://about.gitlab.com/handbook/build/handbook/build#how-to-work-with-build +[^1]: Please note that specs other than JavaScript specs are considered backend code. -- cgit v1.2.1 From 07adee306e960ce1151f6fc14914db3515e2724f Mon Sep 17 00:00:00 2001 From: Robert Speicher Date: Fri, 11 May 2018 11:24:05 -0500 Subject: Add Code Review documentation that maintainers also perform code review --- doc/development/code_review.md | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'doc') diff --git a/doc/development/code_review.md b/doc/development/code_review.md index 53ddf3b062d..d03b7fa23ca 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -29,6 +29,10 @@ There are a few rules to get your merge request accepted: to ask one of the [Merge request coaches][team]. 1. The reviewer will assign the merge request to a maintainer once the reviewer is satisfied with the state of the merge request. +1. Keep in mind that maintainers are also going to perform a final code review. + The ideal scenario is that the reviewer has already addressed any concerns + the maintainer would have found, and the maintainer only has to perform the + merge, but be prepared for further review comments. For more guidance, see [CONTRIBUTING.md](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md). -- cgit v1.2.1 From a9520809a33f8ae070e6bff4c89fbe6156d478f5 Mon Sep 17 00:00:00 2001 From: James Ramsay Date: Fri, 11 May 2018 16:24:09 +0000 Subject: Update Web IDE documentation with recent changes - Add file finder docs - Updated commit panel docs and screenshot --- doc/user/project/web_ide/img/commit_changes.png | Bin 672321 -> 244172 bytes doc/user/project/web_ide/index.md | 23 ++++++++++++++++++----- 2 files changed, 18 insertions(+), 5 deletions(-) (limited to 'doc') diff --git a/doc/user/project/web_ide/img/commit_changes.png b/doc/user/project/web_ide/img/commit_changes.png index b6fcbf699aa..a5364c12760 100644 Binary files a/doc/user/project/web_ide/img/commit_changes.png and b/doc/user/project/web_ide/img/commit_changes.png differ diff --git a/doc/user/project/web_ide/index.md b/doc/user/project/web_ide/index.md index b7064b83c4e..105d8a6ab61 100644 --- a/doc/user/project/web_ide/index.md +++ b/doc/user/project/web_ide/index.md @@ -13,15 +13,27 @@ and from merge requests. ![Open Web IDE](img/open_web_ide.png) -## Commit changes +## File finder -Changed files are shown on the right in the commit panel. All changes are -automatically staged. To commit your changes, add a commit message and click -the 'Commit Button'. +> [Introduced in](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/18323) [GitLab Core][ce] 10.8. + +The file finder allows you to quickly open files in the current branch by +searching. The file finder is launched using the keyboard shortcut `Command-p`, +`Control-p`, or `t` (when editor is not in focus). Type the filename or +file path fragments to start seeing results. + +## Stage and commit changes + +After making your changes, click the Commit button in the bottom left to +review the list of changed files. Click on each file to review the changes and +click the tick icon to stage the file. + +Once you have staged some changes, you can add a commit message and commit the +staged changes. Unstaged changes will not be commited. ![Commit changes](img/commit_changes.png) -## Comparing changes +## Reviewing changes Before you commit your changes, you can compare them with the previous commit by switching to the review mode or selecting the file from the staged files @@ -30,4 +42,5 @@ list. An additional review mode is available when you open a merge request, which shows you a preview of the merge request diff if you commit your changes. +[ce]: https://about.gitlab.com/pricing/ [ee]: https://about.gitlab.com/pricing/ -- cgit v1.2.1 From 3889ca9b95d29017f316d6b3eb1b493b072f38d5 Mon Sep 17 00:00:00 2001 From: Robert Speicher Date: Fri, 11 May 2018 11:36:00 -0500 Subject: Remove an extra backtick from Group Milestones API documentation --- doc/api/group_milestones.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/api/group_milestones.md b/doc/api/group_milestones.md index 21d3ac73000..152929b7614 100644 --- a/doc/api/group_milestones.md +++ b/doc/api/group_milestones.md @@ -22,7 +22,7 @@ Parameters: | --------- | ---- | -------- | ----------- | | `id` | integer/string | yes | The ID or [URL-encoded path of the group](README.md#namespaced-path-encoding) owned by the authenticated user | | `iids[]` | Array[integer] | optional | Return only the milestones having the given `iid` | -| `state` | string | optional | Return only `active` or `closed` milestones` | +| `state` | string | optional | Return only `active` or `closed` milestones | | `search` | string | optional | Return only milestones with a title or description matching the provided string | ```bash -- cgit v1.2.1 From 3241cf6b252f2c03ba9d1e0b30bddd18c301aa05 Mon Sep 17 00:00:00 2001 From: Joshua Lambert Date: Fri, 11 May 2018 19:05:44 +0000 Subject: Update runner links to repo based on restructuring --- doc/install/kubernetes/gitlab_runner_chart.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/install/kubernetes/gitlab_runner_chart.md b/doc/install/kubernetes/gitlab_runner_chart.md index 0a093c9ec32..2aab225fcdb 100644 --- a/doc/install/kubernetes/gitlab_runner_chart.md +++ b/doc/install/kubernetes/gitlab_runner_chart.md @@ -1,6 +1,6 @@ # GitLab Runner Helm Chart > **Note:** -These charts have been tested on Google Kubernetes Engine and Azure Container Service. Other Kubernetes installations may work as well, if not please [open an issue](https://gitlab.com/charts/charts.gitlab.io/issues). +These charts have been tested on Google Kubernetes Engine and Azure Container Service. Other Kubernetes installations may work as well, if not please [open an issue](https://gitlab.com/charts/gitlab-runner/issues). The `gitlab-runner` Helm chart deploys a GitLab Runner instance into your Kubernetes cluster. @@ -25,7 +25,7 @@ For more information on available GitLab Helm Charts, please see our [overview]( Create a `values.yaml` file for your GitLab Runner configuration. See [Helm docs](https://github.com/kubernetes/helm/blob/master/docs/chart_template_guide/values_files.md) for information on how your values file will override the defaults. -The default configuration can always be found in the [values.yaml](https://gitlab.com/charts/charts.gitlab.io/blob/master/charts/gitlab-runner/values.yaml) in the chart repository. +The default configuration can always be found in the [values.yaml](https://gitlab.com/charts/gitlab-runner/blob/master/values.yaml) in the chart repository. ### Required configuration @@ -39,7 +39,7 @@ Unless you need to specify additional configuration, you are [ready to install]( ### Other configuration -The rest of the configuration is [documented in the `values.yaml`](https://gitlab.com/charts/charts.gitlab.io/blob/master/charts/gitlab-runner/values.yaml) in the chart repository. +The rest of the configuration is [documented in the `values.yaml`](https://gitlab.com/charts/gitlab-runner/blob/master/values.yaml) in the chart repository. Here is a snippet of the important settings: -- cgit v1.2.1 From c3882c261173226a4d14c83ea5fd1c13986d4754 Mon Sep 17 00:00:00 2001 From: blackst0ne Date: Thu, 10 May 2018 16:35:07 +1100 Subject: Clean up docs --- doc/api/jobs.md | 4 ++-- doc/development/database_debugging.md | 2 +- doc/development/rake_tasks.md | 5 +---- doc/development/testing_guide/best_practices.md | 3 +-- doc/development/testing_guide/ci.md | 3 +-- doc/development/testing_guide/frontend_testing.md | 20 -------------------- doc/development/testing_guide/index.md | 15 --------------- doc/development/testing_guide/testing_levels.md | 1 - 8 files changed, 6 insertions(+), 47 deletions(-) (limited to 'doc') diff --git a/doc/api/jobs.md b/doc/api/jobs.md index db4fe2f6880..e4e48edd9a7 100644 --- a/doc/api/jobs.md +++ b/doc/api/jobs.md @@ -82,7 +82,7 @@ Example of response "artifacts_file": null, "finished_at": "2015-12-24T17:54:24.921Z", "id": 6, - "name": "spinach:other", + "name": "rspec:other", "pipeline": { "id": 6, "ref": "master", @@ -196,7 +196,7 @@ Example of response "artifacts_file": null, "finished_at": "2015-12-24T17:54:24.921Z", "id": 6, - "name": "spinach:other", + "name": "rspec:other", "pipeline": { "id": 6, "ref": "master", diff --git a/doc/development/database_debugging.md b/doc/development/database_debugging.md index 32f392f1303..9c31265e417 100644 --- a/doc/development/database_debugging.md +++ b/doc/development/database_debugging.md @@ -11,7 +11,7 @@ Available `RAILS_ENV` - `production` (generally not for your main GDK db, but you may need this for e.g. omnibus) - `development` (this is your main GDK db) - - `test` (used for tests like rspec and spinach) + - `test` (used for tests like rspec) ## Nuke everything and start over diff --git a/doc/development/rake_tasks.md b/doc/development/rake_tasks.md index fdfa1f10402..31addcaf675 100644 --- a/doc/development/rake_tasks.md +++ b/doc/development/rake_tasks.md @@ -65,12 +65,11 @@ To make sure that indices still fit. You could find great details in: ## Run tests In order to run the test you can use the following commands: -- `rake spinach` to run the spinach suite - `rake spec` to run the rspec suite - `rake karma` to run the karma test suite - `rake gitlab:test` to run all the tests -Note: Both `rake spinach` and `rake spec` takes significant time to pass. +Note: `rake spec` takes significant time to pass. Instead of running full test suite locally you can save a lot of time by running a single test or directory related to your changes. After you submit merge request CI will run full test suite for you. Green CI status in the merge request means @@ -82,12 +81,10 @@ files it can find, also the ones in `/tmp` To run a single test file you can use: - `bin/rspec spec/controllers/commit_controller_spec.rb` for a rspec test -- `bin/spinach features/project/issues/milestones.feature` for a spinach test To run several tests inside one directory: - `bin/rspec spec/requests/api/` for the rspec tests if you want to test API only -- `bin/spinach features/profile/` for the spinach tests if you want to test only profile pages ### Speed-up tests, rake tasks, and migrations diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index 61fa5459b91..9d3f2935127 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -12,8 +12,7 @@ Here are some things to keep in mind regarding test performance: - `FactoryBot.build(...)` and `.build_stubbed` are faster than `.create`. - Don't `create` an object when `build`, `build_stubbed`, `attributes_for`, `spy`, or `double` will do. Database persistence is slow! -- Don't mark a feature as requiring JavaScript (through `@javascript` in - Spinach or `:js` in RSpec) unless it's _actually_ required for the test +- Don't mark a feature as requiring JavaScript (through `:js` in RSpec) unless it's _actually_ required for the test to be valid. Headless browser testing is slow! [parallelization]: ci.md#test-suite-parallelization-on-the-ci diff --git a/doc/development/testing_guide/ci.md b/doc/development/testing_guide/ci.md index e90de55068d..0d8e150e090 100644 --- a/doc/development/testing_guide/ci.md +++ b/doc/development/testing_guide/ci.md @@ -24,8 +24,7 @@ Our current CI parallelization setup is as follows: uploaded to S3. After that, the next pipeline will use the up-to-date -`knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` file. The same strategy -is used for Spinach tests as well. +`knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` file. ### Monitoring diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md index 0d0d511582b..3b2b9c8c947 100644 --- a/doc/development/testing_guide/frontend_testing.md +++ b/doc/development/testing_guide/frontend_testing.md @@ -280,26 +280,6 @@ describe "Admin::AbuseReports", :js do end ``` -### Spinach errors due to missing JavaScript - -NOTE: **Note:** Since we are discouraging the use of Spinach when writing new -feature tests, you shouldn't ever need to use this. This information is kept -available for legacy purposes only. - -In Spinach, the JavaScript driver is enabled differently. In the `*.feature` -file for the failing spec, add the `@javascript` flag above the Scenario: - -``` -@javascript -Scenario: Developer can approve merge request - Given I am a "Shop" developer - And I visit project "Shop" merge requests page - And merge request 'Bug NS-04' must be approved - And I click link "Bug NS-04" - When I click link "Approve" - Then I should see approved merge request "Bug NS-04" -``` - [jasmine-focus]: https://jasmine.github.io/2.5/focused_specs.html [jasmine-jquery]: https://github.com/velesin/jasmine-jquery [karma]: http://karma-runner.github.io/ diff --git a/doc/development/testing_guide/index.md b/doc/development/testing_guide/index.md index 74d09eb91ff..0cd63a54b55 100644 --- a/doc/development/testing_guide/index.md +++ b/doc/development/testing_guide/index.md @@ -72,21 +72,6 @@ Everything you should know about how to run end-to-end tests using --- -## Spinach (feature) tests - -GitLab [moved from Cucumber to Spinach](https://github.com/gitlabhq/gitlabhq/pull/1426) -for its feature/integration tests in September 2012. - -As of March 2016, we are [trying to avoid adding new Spinach -tests](https://gitlab.com/gitlab-org/gitlab-ce/issues/14121) going forward, -opting for [RSpec feature](#features-integration) specs. - -Adding new Spinach scenarios is acceptable _only if_ the new scenario requires -no more than one new `step` definition. If more than that is required, the -test should be re-implemented using RSpec instead. - ---- - [Return to Development documentation](../README.md) [^1]: /ci/yaml/README.html#dependencies diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md index 51794f7f4df..07ced36f0c1 100644 --- a/doc/development/testing_guide/testing_levels.md +++ b/doc/development/testing_guide/testing_levels.md @@ -81,7 +81,6 @@ possible). | Tests path | Testing engine | Notes | | ---------- | -------------- | ----- | | `spec/features/` | [Capybara] + [RSpec] | If your spec has the `:js` metadata, the browser driver will be [Poltergeist], otherwise it's using [RackTest]. | -| `features/` | Spinach | Spinach tests are deprecated, [you shouldn't add new Spinach tests](#spinach-feature-tests). | ### Consider **not** writing a system test! -- cgit v1.2.1 From 1ae2d4ec0def3336283f07b466492bd98cbc945a Mon Sep 17 00:00:00 2001 From: Bob Van Landuyt Date: Mon, 14 May 2018 12:27:12 +0200 Subject: Change `expect` to `except` on help page --- doc/README.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/README.md b/doc/README.md index c929ba7a59e..ff8dd3fab8a 100644 --- a/doc/README.md +++ b/doc/README.md @@ -241,7 +241,7 @@ GitLab.com is hosted, managed, and administered by GitLab, Inc., with and teams: Free, Bronze, Silver, and Gold. GitLab.com subscriptions grants access -to the same features available in GitLab self-hosted, **expect +to the same features available in GitLab self-hosted, **except [administration](administration/index.md) tools and settings**: - GitLab.com Free includes the same features available in Core -- cgit v1.2.1 From f1a22c6cf5cfd6551932c83ba7188a3d3ed7066c Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Mon, 14 May 2018 11:16:24 +0000 Subject: clarify that the function export should be default --- doc/development/fe_guide/vuex.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index 0335109366a..bebd0edab57 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -356,7 +356,7 @@ describe('component', () => { Because we're currently using [`babel-plugin-rewire`](https://github.com/speedskater/babel-plugin-rewire), you may encounter the following error when testing your Vuex actions and getters: `[vuex] actions should be function or object with "handler" function` -To prevent this error from happening, you need to export an empty function: +To prevent this error from happening, you need to export an empty function as `default`: ``` // getters.js or actions.js -- cgit v1.2.1 From dde62ccff57371ee68089d21dc431bf435b2a896 Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Mon, 14 May 2018 11:31:14 +0000 Subject: typo in `endpoint` --- doc/development/fe_guide/vuex.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index bebd0edab57..def6f0ade5e 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -87,7 +87,7 @@ In this file, we will write the actions that will call the respective mutations: export const fetchUsers = ({ state, dispatch }) => { dispatch('requestUsers'); - axios.get(state.endoint) + axios.get(state.endpoint) .then(({ data }) => dispatch('receiveUsersSuccess', data)) .catch((error) => { dispatch('receiveUsersError', error) @@ -102,7 +102,7 @@ In this file, we will write the actions that will call the respective mutations: export const addUser = ({ state, dispatch }, user) => { dispatch('requestAddUser'); - axios.post(state.endoint, user) + axios.post(state.endpoint, user) .then(({ data }) => dispatch('receiveAddUserSuccess', data)) .catch((error) => dispatch('receiveAddUserError', error)); } -- cgit v1.2.1 From 274a446dfba2d98f48562f8dd48c8e91ae2699e8 Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Mon, 14 May 2018 11:41:50 +0000 Subject: more typos --- doc/development/fe_guide/vuex.md | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index def6f0ade5e..459dc540788 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -71,7 +71,7 @@ You can use `mapState` to access state properties in the components. An action is a payload of information to send data from our application to our store. An action is usually composed by a `type` and a `payload` and they describe what happened. -Enforcing that every change is described as an action lets us have a clear understanting of what is going on in the app. +Enforcing that every change is described as an action lets us have a clear understanding of what is going on in the app. In this file, we will write the actions that will call the respective mutations: @@ -126,7 +126,7 @@ The component MUST only dispatch the `fetchNamespace` action. Actions namespaced The `fetch` action will be responsible to dispatch `requestNamespace`, `receiveNamespaceSuccess` and `receiveNamespaceError` By following this pattern we guarantee: -1. All aplications follow the same pattern, making it easier for anyone to maintain the code +1. All applications follow the same pattern, making it easier for anyone to maintain the code 1. All data in the application follows the same lifecycle pattern 1. Actions are contained and human friendly 1. Unit tests are easier @@ -289,7 +289,7 @@ export default { ``` ### Vuex Gotchas -1. Do not call a mutation directly. Always use an action to commit a mutation. Doing so will keep consistency through out the application. From Vuex docs: +1. Do not call a mutation directly. Always use an action to commit a mutation. Doing so will keep consistency throughout the application. From Vuex docs: > why don't we just call store.commit('action') directly? Well, remember that mutations must be synchronous? Actions aren't. We can perform asynchronous operations inside an action. @@ -342,7 +342,7 @@ describe('component', () => { }; // populate the store - store.dipatch('addUser', user); + store.dispatch('addUser', user); vm = new Component({ store, -- cgit v1.2.1 From 6c9af2d1e547e2c07b2f0cf5c60cdcee09c1bbec Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Mon, 14 May 2018 11:50:19 +0000 Subject: code example formatting --- doc/development/fe_guide/vuex.md | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'doc') diff --git a/doc/development/fe_guide/vuex.md b/doc/development/fe_guide/vuex.md index 459dc540788..8997a5889dc 100644 --- a/doc/development/fe_guide/vuex.md +++ b/doc/development/fe_guide/vuex.md @@ -175,7 +175,7 @@ Remember that actions only describe that something happened, they don't describe state.isLoading = false; }, [types.REQUEST_ADD_USER](state, user) { - state.isAddingUser = true; + state.isAddingUser = true; }, [types.RECEIVE_ADD_USER_SUCCESS](state, user) { state.isAddingUser = false; @@ -183,7 +183,7 @@ Remember that actions only describe that something happened, they don't describe }, [types.REQUEST_ADD_USER_ERROR](state, error) { state.isAddingUser = true; - state.errorAddingUser = error∂; + state.errorAddingUser = error; }, }; ``` -- cgit v1.2.1 From c6aa8be3e035e86b19f5c5a409d147d1acb19e7c Mon Sep 17 00:00:00 2001 From: Mark Fletcher Date: Mon, 14 May 2018 18:36:39 +0100 Subject: Fix link to MR for Maintainer Access docs --- doc/user/project/merge_requests/maintainer_access.md | 2 ++ 1 file changed, 2 insertions(+) (limited to 'doc') diff --git a/doc/user/project/merge_requests/maintainer_access.md b/doc/user/project/merge_requests/maintainer_access.md index c9763a3fe02..89f71e16a50 100644 --- a/doc/user/project/merge_requests/maintainer_access.md +++ b/doc/user/project/merge_requests/maintainer_access.md @@ -16,3 +16,5 @@ source project, and only lasts while the merge request is open. Enable this functionality while creating a merge request: ![Enable maintainer edits](./img/allow_maintainer_push.png) + +[ce-17395]: https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/17395 -- cgit v1.2.1 From d134c0fb70eb9330680872edefa8841641931018 Mon Sep 17 00:00:00 2001 From: Grzegorz Bizon Date: Tue, 15 May 2018 10:38:00 +0200 Subject: Update docs describing `fast_spec_helper` best practices --- doc/development/testing_guide/best_practices.md | 27 +++++++++++++++++++++---- 1 file changed, 23 insertions(+), 4 deletions(-) (limited to 'doc') diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index 61fa5459b91..5aa2068b495 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -134,11 +134,30 @@ really fast since: - gitlab-shell and Gitaly setup are skipped - Test repositories setup are skipped -Note that in some cases, you might have to add some `require_dependency 'foo'` -in your file under test since Rails autoloading is not available in these cases. +`fast_spec_helper` also support autoloading classes that are located inside the +`lib/` directory. It means that as long as your class / module is using only +code from the `lib/` directory you will not need to explicitly load any +dependencies. `fast_spec_helper` also loads all ActiveSupport extensions, +including core extensions that are commonly used in the Rails environment. -This shouldn't be a problem since explicitely listing dependencies should be -considered a good practice anyway. +Note that in some cases, you might still have to load some dependencies using +`require_dependency` in your `*_spec.rb` file, like when a code is using gems. + +For example, if you want to test your code that is calling the +`Gitlab::UntrustedRegexp` class, which under the hood uses `re2` library, you +should be able to define a test using follow code snippet. + +```ruby +require 'fast_spec_helper' +require_dependency 're2' + +describe Gitlab::MyModule::MyClass do + # ... +end +``` + +It takes around one second to load tests that are using `fast_spec_helper` +instead of 30+ seconds in case of a regular `spec_helper`. ### `let` variables -- cgit v1.2.1 From 2bfc4d331c874f71f1b93c3547ae3c0ff7c132b1 Mon Sep 17 00:00:00 2001 From: Dennis Tang Date: Tue, 15 May 2018 10:49:16 +0000 Subject: fix typos Frontend Guide, development_process.md --- doc/development/fe_guide/development_process.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) (limited to 'doc') diff --git a/doc/development/fe_guide/development_process.md b/doc/development/fe_guide/development_process.md index 5504a6421d5..d240dbe8b02 100644 --- a/doc/development/fe_guide/development_process.md +++ b/doc/development/fe_guide/development_process.md @@ -22,9 +22,9 @@ Please use your best judgement when to use it and please contribute new points t - [ ] Are all [departments](https://about.gitlab.com/handbook/engineering/#engineering-teams) that are needed from your perspective already involved in the issue? (For example is UX missing?) - [ ] Is the specification complete? Are you missing decisions? How about error handling/defaults/edge cases? Take your time to understand the needed implementation and go through its flow. - [ ] Are all necessary UX specifications available that you will need in order to implement? Are there new UX components/patterns in the designs? Then contact the UI component team early on. How should error messages or validation be handled? -- [ ] **Library usage** Use Vuex as soon as you have even a medium state to manage, use Vue router if you need to have different views internally and want to link from the outside. Check what libraries we already have for which occassions. +- [ ] **Library usage** Use Vuex as soon as you have even a medium state to manage, use Vue router if you need to have different views internally and want to link from the outside. Check what libraries we already have for which occasions. - [ ] **Plan your implementation:** - - [ ] **Architecture plan:** Create a plan aligned with GitLab's architecture, how you are going to do the implementation, for example Vue application setup and its components (through [onion skinning](https://gitlab.com/gitlab-org/gitlab-ce/issues/35873#note_39994091)), Store structure and data flow, which existing Vue components can you reuse. Its a good idea to go through your plan with another engineer to refine it. + - [ ] **Architecture plan:** Create a plan aligned with GitLab's architecture, how you are going to do the implementation, for example Vue application setup and its components (through [onion skinning](https://gitlab.com/gitlab-org/gitlab-ce/issues/35873#note_39994091)), Store structure and data flow, which existing Vue components can you reuse. It's a good idea to go through your plan with another engineer to refine it. - [ ] **Backend:** The best way is to kickoff the implementation in a call and discuss with the assigned Backend engineer what you will need from the backend and also when. Can you reuse existing API's? How is the performance with the planned architecture? Maybe create together a JSON mock object to already start with development. - [ ] **Communication:** It also makes sense to have for bigger features an own slack channel (normally called #f_{feature_name}) and even weekly demo calls with all people involved. - [ ] **Dependency Plan:** Are there big dependencies in the plan between you and others, then maybe create an execution diagram to show what is blocking which part and the order of the different parts. @@ -56,7 +56,7 @@ Please use your best judgement when to use it and please contribute new points t - [ ] If you have multiple MR's then also smoke test against the final merge. - [ ] Are there any big changes on how and especially how frequently we use the API then let production know about it - [ ] Smoke test of the RC on dev., staging., canary deployments and .com -- [ ] Follow up on issues that came out of the review. Create isssues for discovered edge cases that should be covered in future iterations. +- [ ] Follow up on issues that came out of the review. Create issues for discovered edge cases that should be covered in future iterations. --- -- cgit v1.2.1 From 7186f0de657f510e27e24b6845f99ded158118af Mon Sep 17 00:00:00 2001 From: Grzegorz Bizon Date: Tue, 15 May 2018 13:34:49 +0200 Subject: Improve testing best practices guidelines It mentions that explicitly defining dependencies in sources is preferred over defining such dependencies only in spec files. --- doc/development/testing_guide/best_practices.md | 16 +++++----------- 1 file changed, 5 insertions(+), 11 deletions(-) (limited to 'doc') diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index 5aa2068b495..c4d350e3676 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -141,20 +141,14 @@ dependencies. `fast_spec_helper` also loads all ActiveSupport extensions, including core extensions that are commonly used in the Rails environment. Note that in some cases, you might still have to load some dependencies using -`require_dependency` in your `*_spec.rb` file, like when a code is using gems. +`require_dependency` when a code is using gems or a dependency is not located +in `lib/`. For example, if you want to test your code that is calling the `Gitlab::UntrustedRegexp` class, which under the hood uses `re2` library, you -should be able to define a test using follow code snippet. - -```ruby -require 'fast_spec_helper' -require_dependency 're2' - -describe Gitlab::MyModule::MyClass do - # ... -end -``` +should either add `require_dependency 're2'` to files in your library that +need `re2` gem, to make this requirement explicit, or you can add it to the +spec itself, but the former is preferred. It takes around one second to load tests that are using `fast_spec_helper` instead of 30+ seconds in case of a regular `spec_helper`. -- cgit v1.2.1 From e1eba2da37f7949d36afd5d6ed9f675dc845b046 Mon Sep 17 00:00:00 2001 From: Mark Fletcher Date: Sun, 21 Jan 2018 17:42:05 +0000 Subject: Add documentation for bulk editing of issues and merge requests --- doc/user/project/bulk_editing.md | 17 +++++++++++++++++ doc/user/project/issues/index.md | 4 ++++ doc/user/project/merge_requests/index.md | 4 ++++ 3 files changed, 25 insertions(+) create mode 100644 doc/user/project/bulk_editing.md (limited to 'doc') diff --git a/doc/user/project/bulk_editing.md b/doc/user/project/bulk_editing.md new file mode 100644 index 00000000000..324a7fa6603 --- /dev/null +++ b/doc/user/project/bulk_editing.md @@ -0,0 +1,17 @@ +# Bulk Editing + +>**Note:** +- A permission level of `Reporter` or higher is required in order to manage +issues. +- A permission level of `Developer` or higher is required in order to manage +merge requests. + +Fields across multiple issues or merge requests can be updated simutaneously by using the bulk edit feature. + +>**Note:** +- Bulk editing of issues and merge requests is only available at the project level. + +To access the feature, navigate to either the issue or merge request list for the project and click 'Edit Issues' or 'Edit Merge Requests'. This will cause a sidebar to be shown on the right-hand side of the screen, where the available, editable fields are displayed. Checkboxes will also appear to the left-hand side of each issue or merge request, ready to be selected. + +Once all items have been selected, choose the appropriate fields and their values from the sidebar and click 'Update All' to apply these changes. + diff --git a/doc/user/project/issues/index.md b/doc/user/project/issues/index.md index be4436749f9..bf17731c523 100644 --- a/doc/user/project/issues/index.md +++ b/doc/user/project/issues/index.md @@ -151,3 +151,7 @@ or Bugzilla. ### Issue's API Read through the [API documentation](../../../api/issues.md). + +### Bulk editing issues + +Find out about [bulk editing issues](../../project/bulk_editing.md). diff --git a/doc/user/project/merge_requests/index.md b/doc/user/project/merge_requests/index.md index a6c0fd49c45..5932f5a2bc1 100644 --- a/doc/user/project/merge_requests/index.md +++ b/doc/user/project/merge_requests/index.md @@ -233,6 +233,10 @@ all your changes will be available to preview by anyone with the Review Apps lin [Read more about Review Apps.](../../../ci/review_apps/index.md) +## Bulk editing merge requests + +Find out about [bulk editing merge requests](../../project/bulk_editing.md). + ## Tips Here are some tips that will help you be more efficient with merge requests in -- cgit v1.2.1 From 3f4a3e4f608508044e2f91d7a78cfb64b71ec90c Mon Sep 17 00:00:00 2001 From: Achilleas Pipinellis Date: Wed, 16 May 2018 08:47:18 +0200 Subject: Document the 3h timeout for GitLab.com shared Runners --- doc/user/gitlab_com/index.md | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) (limited to 'doc') diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index 7baccb796c6..0c1cd113686 100644 --- a/doc/user/gitlab_com/index.md +++ b/doc/user/gitlab_com/index.md @@ -75,7 +75,6 @@ Shared Runners on GitLab.com run in [autoscale mode] and powered by Google Cloud Platform and DigitalOcean. Autoscaling means reduced waiting times to spin up CI/CD jobs, and isolated VMs for each project, thus maximizing security. - They're free to use for public open source projects and limited to 2000 CI minutes per month per group for private projects. Read about all [GitLab.com plans](https://about.gitlab.com/pricing/). @@ -90,6 +89,10 @@ ephemeral instances with 3.75GB of RAM, CoreOS and the latest Docker Engine installed. Instances provide 1 vCPU and 25GB of HDD disk space. The default region of the VMs is US East1. +Jobs handled by the shared Runners on GitLab.com (`shared-runners-manager-X.gitlab.com`), +**will be timed out after 3 hours**, regardless of the timeout configured in a +project. Check the issues [4010] and [4070] for the reference. + Below are the shared Runners settings. | Setting | GitLab.com | Default | @@ -340,3 +343,5 @@ High Performance TCP/HTTP Load Balancer: [mailgun]: https://www.mailgun.com/ "Mailgun website" [sidekiq]: http://sidekiq.org/ "Sidekiq website" [unicorn-worker-killer]: https://rubygems.org/gems/unicorn-worker-killer "unicorn-worker-killer" +[4010]: https://gitlab.com/gitlab-com/infrastructure/issues/4010 "Find a good value for maximum timeout for Shared Runners" +[4070]: https://gitlab.com/gitlab-com/infrastructure/issues/4070 "Configure per-runner timeout for shared-runners-manager-X on GitLab.com" -- cgit v1.2.1 From 143a98a3054644f70fbcc725c453f443c4546e3c Mon Sep 17 00:00:00 2001 From: Fabio Busatto Date: Thu, 17 May 2018 12:57:49 +0000 Subject: Update quick_start_guide.md --- doc/topics/autodevops/quick_start_guide.md | 4 ++++ 1 file changed, 4 insertions(+) (limited to 'doc') diff --git a/doc/topics/autodevops/quick_start_guide.md b/doc/topics/autodevops/quick_start_guide.md index 15567715c98..0b16af2953b 100644 --- a/doc/topics/autodevops/quick_start_guide.md +++ b/doc/topics/autodevops/quick_start_guide.md @@ -23,6 +23,10 @@ page](https://gitlab.com/auto-devops-examples/minimal-ruby-app) and press the **Fork** button. Soon you should have a project under your namespace with the necessary files. +You can also start a new project from a +[GitLab project template](https://gitlab.com/gitlab-org/project-templates) if +you want to use a different language. + ## Setup your own cluster on Google Kubernetes Engine If you do not already have a Google Cloud account, create one at -- cgit v1.2.1