diff --git a/doc/ci/caching/index.md b/doc/ci/caching/index.md index b83814560c768907aa92b156d0e8e4df8be97993..0109d87921b394161a0f2a8e9a33609a2c4744ab 100644 --- a/doc/ci/caching/index.md +++ b/doc/ci/caching/index.md @@ -197,19 +197,19 @@ For more fine tuning, read also about the The most common use case of cache is to preserve contents between subsequent runs of jobs for things like dependencies and commonly used libraries -(Nodejs packages, PHP packages, rubygems, Python libraries, etc.), +(Node.js packages, PHP packages, rubygems, Python libraries, etc.), so they don't have to be re-fetched from the public internet. NOTE: **Note:** For more examples, check out our [GitLab CI/CD templates](https://gitlab.com/gitlab-org/gitlab-foss/tree/master/lib/gitlab/ci/templates). -### Caching Nodejs dependencies +### Caching Node.js dependencies Assuming your project is using [npm](https://www.npmjs.com/) or -[Yarn](https://classic.yarnpkg.com/en/) to install the Nodejs dependencies, the +[Yarn](https://classic.yarnpkg.com/en/) to install the Node.js dependencies, the following example defines `cache` globally so that all jobs inherit it. -Nodejs modules are installed in `node_modules/` and are cached per-branch: +Node.js modules are installed in `node_modules/` and are cached per-branch: ```yaml # diff --git a/doc/ci/examples/deployment/composer-npm-deploy.md b/doc/ci/examples/deployment/composer-npm-deploy.md index c9c78c9a4e47293548ea5808a9e982eb72bf61ad..f780a13998c1d1face18310536ab4d2ad0f173dd 100644 --- a/doc/ci/examples/deployment/composer-npm-deploy.md +++ b/doc/ci/examples/deployment/composer-npm-deploy.md @@ -6,7 +6,7 @@ type: tutorial This guide covers the building of dependencies of a PHP project while compiling assets via an NPM script using [GitLab CI/CD](../../README.md). -While it is possible to create your own image with custom PHP and Node JS versions, for brevity, we will use an existing [Docker image](https://hub.docker.com/r/tetraweb/php/) that contains both PHP and NodeJS installed. +While it is possible to create your own image with custom PHP and Node.js versions, for brevity, we will use an existing [Docker image](https://hub.docker.com/r/tetraweb/php/) that contains both PHP and Node.js installed. ```yaml image: tetraweb/php @@ -23,7 +23,7 @@ before_script: - php -r "unlink('composer-setup.php');" ``` -This will make sure we have all requirements ready. Next, we want to run `composer install` to fetch all PHP dependencies and `npm install` to load node packages, then run the `npm` script. We need to append them into `before_script` section: +This will make sure we have all requirements ready. Next, we want to run `composer install` to fetch all PHP dependencies and `npm install` to load Node.js packages, then run the `npm` script. We need to append them into `before_script` section: ```yaml before_script: diff --git a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md index 3de8f3c675cbbaafd85f6488f8c7ebec9b197756..28d16ebb8c5402816ed4ce6f5c96bdaa88b887d2 100644 --- a/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md +++ b/doc/ci/examples/test-and-deploy-ruby-application-to-heroku.md @@ -74,7 +74,7 @@ gitlab-runner register \ --description "ruby:2.6" \ --executor "docker" \ --docker-image ruby:2.6 \ - --docker-postgres latest + --docker-services latest ``` With the command above, you create a Runner that uses the [ruby:2.6](https://hub.docker.com/_/ruby) image and uses a [postgres](https://hub.docker.com/_/postgres) database. diff --git a/doc/ci/jenkins/index.md b/doc/ci/jenkins/index.md index edb585c0a21baf5fa81b2c6e2bdea978abfcdbe5..db97a6b4f2ccb362b642e2dd99288817eb619584 100644 --- a/doc/ci/jenkins/index.md +++ b/doc/ci/jenkins/index.md @@ -102,7 +102,7 @@ and is meant to be a mapping of concepts there to concepts in GitLab. The agent section is used to define how a pipeline will be executed. For GitLab, we use the [GitLab Runner](../runners/README.md) to provide this capability. You can configure your own runners in Kubernetes or on any host, or take advantage -of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users.) The link above will bring you to the documenation which will describe how to get +of our shared runner fleet (note that the shared runner fleet is only available for GitLab.com users.) The link above will bring you to the documentation which will describe how to get up and running quickly. We also support using [tags](../runners/README.md#using-tags) to direct different jobs to different Runners (execution agents). diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index ba64194472fecde047e931c600cac3f0173676e5..aa2890ed9db89db8efb106c1f3d94079d5a5043d 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -1641,7 +1641,7 @@ cache: - node_modules ``` -In this example we are creating a cache for Ruby and Nodejs dependencies that +In this example we are creating a cache for Ruby and Node.js dependencies that is tied to current versions of the `Gemfile.lock` and `package.json` files. Whenever one of these files changes, a new cache key is computed and a new cache is created. Any future job runs using the same `Gemfile.lock` and `package.json` with `cache:key:files` will diff --git a/doc/development/architecture.md b/doc/development/architecture.md index 101897ecb7c7a4016168af610122c0132012fccc..c5ac8c040f8799455e7a81adfb6d37ce8f7fbdd8 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -129,7 +129,7 @@ Component statuses are linked to configuration documentation for each component. | [Unicorn (GitLab Rails)](#unicorn) | Handles requests for the web interface and API | [✅][unicorn-omnibus] | [✅][unicorn-charts] | [✅][unicorn-charts] | [✅](../user/gitlab_com/index.md#unicorn) | [⚙][unicorn-source] | [✅][gitlab-yml] | CE & EE | | [Sidekiq](#sidekiq) | Background jobs processor | [✅][sidekiq-omnibus] | [✅][sidekiq-charts] | [✅](https://docs.gitlab.com/charts/charts/gitlab/sidekiq/index.html) | [✅](../user/gitlab_com/index.md#sidekiq) | [✅][gitlab-yml] | [✅][gitlab-yml] | CE & EE | | [Gitaly](#gitaly) | Git RPC service for handling all Git calls made by GitLab | [✅][gitaly-omnibus] | [✅][gitaly-charts] | [✅][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][gitaly-source] | ✅ | CE & EE | -| [Praefect](#praefect) | A transparant proxy between any Git client and Gitaly storage nodes. | [✅][gitaly-omnibus] | [❌][gitaly-charts] | [❌][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][praefect-source] | ✅ | CE & EE | +| [Praefect](#praefect) | A transparent proxy between any Git client and Gitaly storage nodes. | [✅][gitaly-omnibus] | [❌][gitaly-charts] | [❌][gitaly-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][praefect-source] | ✅ | CE & EE | | [GitLab Workhorse](#gitlab-workhorse) | Smart reverse proxy, handles large HTTP requests | [✅][workhorse-omnibus] | [✅][workhorse-charts] | [✅][workhorse-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][workhorse-source] | ✅ | CE & EE | | [GitLab Shell](#gitlab-shell) | Handles `git` over SSH sessions | [✅][shell-omnibus] | [✅][shell-charts] | [✅][shell-charts] | [✅](https://about.gitlab.com/handbook/engineering/infrastructure/production-architecture/#service-architecture) | [⚙][shell-source] | [✅][gitlab-yml] | CE & EE | | [GitLab Pages](#gitlab-pages) | Hosts static websites | [⚙][pages-omnibus] | [❌][pages-charts] | [❌][pages-charts] | [✅](../user/gitlab_com/index.md#gitlab-pages) | [⚙][pages-source] | [⚙][pages-gdk] | CE & EE | diff --git a/doc/development/contributing/issue_workflow.md b/doc/development/contributing/issue_workflow.md index eba650ea22f85ccd65a40f89d7ff267d373d72c6..7c2a7a6560eeb470823809fc7d14e1e08b93d15e 100644 --- a/doc/development/contributing/issue_workflow.md +++ b/doc/development/contributing/issue_workflow.md @@ -159,7 +159,7 @@ the issue should be relabelled as ~"group::access" while keeping the original ~"devops::create" unchanged. We also use stage and group labels to help quantify our [throughput](https://about.gitlab.com/handbook/engineering/management/throughput/). -Please read [Stage and Group labels in Throughtput](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput) for more information on how the labels are used in this context. +Please read [Stage and Group labels in Throughput](https://about.gitlab.com/handbook/engineering/management/throughput/#stage-and-group-labels-in-throughput) for more information on how the labels are used in this context. ### Category labels diff --git a/doc/development/diffs.md b/doc/development/diffs.md index ac0b8555360967fecbe097cb26e8448b8ea89be1..43d0d6b490211333a688ed385f24e91b1bfd8b1b 100644 --- a/doc/development/diffs.md +++ b/doc/development/diffs.md @@ -8,7 +8,7 @@ Currently we rely on different sources to present diffs, these include: ## Deep Dive -In Jaunary 2019, Oswaldo Ferreira hosted a [Deep Dive] on GitLab's Diffs and Commenting on Diffs functionality to share his domain specific knowledge with anyone who may work in this part of the code base in the future. You can find the [recording on YouTube], and the slides on [Google Slides] and in [PDF]. Everything covered in this deep dive was accurate as of GitLab 11.7, and while specific details may have changed since then, it should still serve as a good introduction. +In January 2019, Oswaldo Ferreira hosted a [Deep Dive] on GitLab's Diffs and Commenting on Diffs functionality to share his domain specific knowledge with anyone who may work in this part of the code base in the future. You can find the [recording on YouTube], and the slides on [Google Slides] and in [PDF]. Everything covered in this deep dive was accurate as of GitLab 11.7, and while specific details may have changed since then, it should still serve as a good introduction. [Deep Dive]: https://gitlab.com/gitlab-org/create-stage/issues/1 [recording on YouTube]: https://www.youtube.com/watch?v=K6G3gMcFyek diff --git a/doc/development/integrations/secure.md b/doc/development/integrations/secure.md index c54c20507901e21bccb60c393e6566629b2200f0..469e81464471658a4622453ea05b5d62818a47e2 100644 --- a/doc/development/integrations/secure.md +++ b/doc/development/integrations/secure.md @@ -37,7 +37,7 @@ For instance, it is common practice to use `before_script` to install system lib a particular project needs before performing SAST or Dependency Scanning. Similarly, [`after_script`](../../ci/yaml/README.md#before_script-and-after_script) -should not not be used in the job definition, because it may be overriden by users. +should not not be used in the job definition, because it may be overridden by users. ### Stage diff --git a/doc/development/internal_api.md b/doc/development/internal_api.md index 0bdc1d07591ed4703aabae2ecf956f932194d173..b0c35b5742265d2fa7326c0e3644c66997c3c6ef 100644 --- a/doc/development/internal_api.md +++ b/doc/development/internal_api.md @@ -47,7 +47,7 @@ POST /internal/allowed | `protocol` | string | yes | SSH when called from GitLab-shell, HTTP or SSH when called from Gitaly | | `action` | string | yes | Git command being run (`git-upload-pack`, `git-receive-pack`, `git-upload-archive`) | | `changes` | string | yes | ` ` when called from Gitaly, The magic string `_any` when called from GitLab Shell | -| `check_ip` | string | no | Ip adress from which call to GitLab Shell was made | +| `check_ip` | string | no | Ip address from which call to GitLab Shell was made | Example request: diff --git a/doc/development/logging.md b/doc/development/logging.md index 780038cf2dd65aa442cc47ab7856ba3c2c84ed69..a90d78ba8d90e946035ece6f131934fae9949499 100644 --- a/doc/development/logging.md +++ b/doc/development/logging.md @@ -265,7 +265,7 @@ provides helper methods to track exceptions: and DOES NOT send the exception to Sentry, 1. `Gitlab::ErrorTracking.track_and_raise_for_dev_exception`: this method logs, sends exception to Sentry (if configured) and re-raises the exception - for development and test enviroments. + for development and test environments. It is advised to only use `Gitlab::ErrorTracking.track_and_raise_exception` and `Gitlab::ErrorTracking.track_exception` as presented on below examples. diff --git a/doc/development/reactive_caching.md b/doc/development/reactive_caching.md index 3563ff5322a456dba943b9c6c65c4fbf255e73fe..bc5fbb58af98332bad2716b4a9133be8c0a3ded5 100644 --- a/doc/development/reactive_caching.md +++ b/doc/development/reactive_caching.md @@ -207,7 +207,7 @@ the default by adding the following to your service: - `ReactiveCaching` uses `Gitlab::ExclusiveLease` to ensure that the cache calculation is never run concurrently by multiple workers. - This attribute is the timeout for the `Gitlab::ExclusiveLease`. -- It defaults to 2 minutes, but can be overriden if a different timeout is required. +- It defaults to 2 minutes, but can be overridden if a different timeout is required. ```ruby self.reactive_cache_lease_timeout = 2.minutes diff --git a/doc/development/scalability.md b/doc/development/scalability.md index 37ffdbdbfde2bbf541875c253cbf339a71abd98b..3a9f5387b1165f5ce610446f5d7c76aee4dbfff0 100644 --- a/doc/development/scalability.md +++ b/doc/development/scalability.md @@ -178,7 +178,7 @@ talking to the primary can mitigate this. In the second case, existing connections to the newly-demoted replica may execute a write query, which would fail. During a failover, it may -be advantegeous to shut down the PgBouncer talking to the primary to +be advantageous to shut down the PgBouncer talking to the primary to ensure no more traffic arrives for it. The alternative would be to make the application aware of the failover event and terminate its connections gracefully. diff --git a/doc/development/testing_guide/end_to_end/best_practices.md b/doc/development/testing_guide/end_to_end/best_practices.md index e060312e05fd117890fd9fd15e4fa31e42b64c3b..97daf4885cad42e33b2a5e339e8838b05adda780 100644 --- a/doc/development/testing_guide/end_to_end/best_practices.md +++ b/doc/development/testing_guide/end_to_end/best_practices.md @@ -78,7 +78,7 @@ That's not possible if a test leaves the browser logged in when it finishes. Nor For an example see: -Ideally, any actions peformed in an `after(:context)` (or [`before(:context)`](#limit-the-use-of-beforeall-and-after-hooks)) block would be performed via the API. But if it's necessary to do so via the UI (e.g., if API functionality doesn't exist), make sure to log out at the end of the block. +Ideally, any actions performed in an `after(:context)` (or [`before(:context)`](#limit-the-use-of-beforeall-and-after-hooks)) block would be performed via the API. But if it's necessary to do so via the UI (e.g., if API functionality doesn't exist), make sure to log out at the end of the block. ```ruby after(:all) do diff --git a/doc/development/value_stream_analytics.md b/doc/development/value_stream_analytics.md index 5c6d3f18d9a8a1553c40ae63a9b2d7bdfb2daa91..3ceb523ab73e5d4263328a92abb95807409b27b0 100644 --- a/doc/development/value_stream_analytics.md +++ b/doc/development/value_stream_analytics.md @@ -235,7 +235,7 @@ SELECT (START_EVENT_TIME-END_EVENT_TIME) as duration, END_EVENT.timestamp - Services (`Analytics::CycleAnalytics` module): All `Stage` related actions will be delegated to respective service objects. - Models (`Analytics::CycleAnalytics` module): Models are used to persist the `Stage` objects `ProjectStage` and `GroupStage`. - Feature classes (`Gitlab::Analytics::CycleAnalytics` module): - - Responsible for composing queries and define feature specific busines logic. + - Responsible for composing queries and define feature specific business logic. - `DataCollector`, `Event`, `StageEvents`, etc. ## Testing diff --git a/doc/topics/autodevops/index.md b/doc/topics/autodevops/index.md index ad203b2a7cf36647ea5411413a4dace782737f93..abd946e1f2376369039cd52b6e8b3cd4b28501fc 100644 --- a/doc/topics/autodevops/index.md +++ b/doc/topics/autodevops/index.md @@ -805,7 +805,7 @@ commands to be wrapped as follows: /bin/herokuish procfile exec $COMMAND ``` -This might be neccessary, for example, when: +This might be necessary, for example, when: - Attaching using `kubectl exec`. - Using GitLab's [Web Terminal](../../ci/environments.md#web-terminals). diff --git a/doc/topics/web_application_firewall/index.md b/doc/topics/web_application_firewall/index.md index db1265e08acb749d1704d59e4dc9397998d5308c..6c847f12bba7ade7bd3c882e988975b32f365841 100644 --- a/doc/topics/web_application_firewall/index.md +++ b/doc/topics/web_application_firewall/index.md @@ -55,7 +55,7 @@ you can configure a cluster on GKE. Once this is set up, you can follow the step NOTE: **Note** This guide shows how the WAF can be deployed using Auto DevOps. The WAF -is avaliable by default to all applications no matter how they are deployed, +is available by default to all applications no matter how they are deployed, as long as they are using Ingress. ## Network firewall vs. Web Application Firewall diff --git a/doc/topics/web_application_firewall/quick_start_guide.md b/doc/topics/web_application_firewall/quick_start_guide.md index 35003785753b99da5f6fec1480492ecff8f835c1..e3cf0bcd498af063779f37c5823ab8dd5ff1e627 100644 --- a/doc/topics/web_application_firewall/quick_start_guide.md +++ b/doc/topics/web_application_firewall/quick_start_guide.md @@ -12,7 +12,7 @@ need to ensure your own [Runners are configured](../../ci/runners/README.md) and [Google OAuth is enabled](../../integration/google.md). **Note**: GitLab's Web Application Firewall is deployed with [Ingress](../../user/clusters/applications.md#Ingress), -so it will be avaliable to your applications no matter how you deploy them to Kubernetes. +so it will be available to your applications no matter how you deploy them to Kubernetes. ## Enable or disable ModSecurity diff --git a/lib/gitlab/ci/templates/Jobs/Test.gitlab-ci.yml b/lib/gitlab/ci/templates/Jobs/Test.gitlab-ci.yml index a0ddd273552c3b71dc0b7a896b55f91e60674550..a8e6d2636662a00cb44ee390749860c83276120d 100644 --- a/lib/gitlab/ci/templates/Jobs/Test.gitlab-ci.yml +++ b/lib/gitlab/ci/templates/Jobs/Test.gitlab-ci.yml @@ -15,9 +15,7 @@ test: - export DATABASE_URL="postgres://${POSTGRES_USER}:${POSTGRES_PASSWORD}@${DB_HOST}:5432/${POSTGRES_DB}" - cp -R . /tmp/app - /bin/herokuish buildpack test - only: - - branches - - tags - except: - variables: - - $TEST_DISABLED + rules: + - if: '$TEST_DISABLED' + when: never + - if: '$CI_COMMIT_TAG || $CI_COMMIT_BRANCH' diff --git a/spec/lib/gitlab/ci/templates/Jobs/test_gitlab_ci_yaml_spec.rb b/spec/lib/gitlab/ci/templates/Jobs/test_gitlab_ci_yaml_spec.rb new file mode 100644 index 0000000000000000000000000000000000000000..2186bf038eb44e5b362aa26980a173f25250626e --- /dev/null +++ b/spec/lib/gitlab/ci/templates/Jobs/test_gitlab_ci_yaml_spec.rb @@ -0,0 +1,86 @@ +# frozen_string_literal: true + +require 'spec_helper' + +describe 'Jobs/Test.gitlab-ci.yml' do + subject(:template) { Gitlab::Template::GitlabCiYmlTemplate.find('Jobs/Test') } + + describe 'the created pipeline' do + let_it_be(:user) { create(:admin) } + let_it_be(:project) { create(:project, :repository) } + + let(:default_branch) { 'master' } + let(:pipeline_ref) { default_branch } + let(:service) { Ci::CreatePipelineService.new(project, user, ref: pipeline_ref) } + let(:pipeline) { service.execute!(:push) } + let(:build_names) { pipeline.builds.pluck(:name) } + + before do + stub_ci_pipeline_yaml_file(template.content) + allow_any_instance_of(Ci::BuildScheduleWorker).to receive(:perform).and_return(true) + allow(project).to receive(:default_branch).and_return(default_branch) + end + + context 'on master' do + it 'creates the test job' do + expect(build_names).to contain_exactly('test') + end + end + + context 'on another branch' do + let(:pipeline_ref) { 'feature' } + + it 'creates the test job' do + expect(build_names).to contain_exactly('test') + end + end + + context 'on tag' do + let(:pipeline_ref) { 'v1.0.0' } + + it 'creates the test job' do + expect(pipeline).to be_tag + expect(build_names).to contain_exactly('test') + end + end + + context 'on merge request' do + let(:service) { MergeRequests::CreatePipelineService.new(project, user) } + let(:merge_request) { create(:merge_request, :simple, source_project: project) } + let(:pipeline) { service.execute(merge_request) } + + it 'has no jobs' do + expect(pipeline).to be_merge_request_event + expect(build_names).to be_empty + end + end + + context 'TEST_DISABLED is set' do + before do + create(:ci_variable, key: 'TEST_DISABLED', value: 'true', project: project) + end + + context 'on master' do + it 'has no jobs' do + expect { pipeline }.to raise_error(Ci::CreatePipelineService::CreateError) + end + end + + context 'on another branch' do + let(:pipeline_ref) { 'feature' } + + it 'has no jobs' do + expect { pipeline }.to raise_error(Ci::CreatePipelineService::CreateError) + end + end + + context 'on tag' do + let(:pipeline_ref) { 'v1.0.0' } + + it 'has no jobs' do + expect { pipeline }.to raise_error(Ci::CreatePipelineService::CreateError) + end + end + end + end +end