diff options
Diffstat (limited to 'doc/development')
36 files changed, 666 insertions, 172 deletions
diff --git a/doc/development/README.md b/doc/development/README.md index 13646cbfe48..5a33c46c620 100644 --- a/doc/development/README.md +++ b/doc/development/README.md @@ -54,6 +54,7 @@ description: 'Learn how to contribute to GitLab.' - [Prometheus metrics](prometheus_metrics.md) - [Guidelines for reusing abstractions](reusing_abstractions.md) - [DeclarativePolicy framework](policies.md) +- [How Git object deduplication works in GitLab](git_object_deduplication.md) ## Performance guides diff --git a/doc/development/architecture.md b/doc/development/architecture.md index ae880e3deb6..115c8cfb9ff 100644 --- a/doc/development/architecture.md +++ b/doc/development/architecture.md @@ -158,6 +158,18 @@ TODO TODO +### Registry + +The registry is what users use to store their own Docker images. The bundled +registry uses nginx as a load balancer and GitLab as an authentication manager. +Whenever a client requests to pull or push an image from the registry, it will +return a `401` response along with a header detailing where to get an +authentication token, in this case the GitLab instance. The client will then +request a pull or push auth token from GitLab and retry the original request +to the registry. Learn more about [token authentication](https://docs.docker.com/registry/spec/auth/token/). + +An external registry can also be configured to use GitLab as an auth endpoint. + ## GitLab by Request Type GitLab provides two "interfaces" for end users to access the service: diff --git a/doc/development/code_review.md b/doc/development/code_review.md index f115045dbb7..b1a32e0ed26 100644 --- a/doc/development/code_review.md +++ b/doc/development/code_review.md @@ -20,7 +20,7 @@ importance of involving reviewer(s) in the section on the responsibility of the If you need some guidance (e.g. it's your first merge request), feel free to ask one of the [Merge request coaches][team]. -If you need assistance with security scans or comments, feel free to include the +If you need assistance with security scans or comments, feel free to include the Security Team (`@gitlab-com/gl-security`) in the review. The `danger-review` CI job will randomly pick a reviewer and a maintainer for @@ -58,12 +58,7 @@ from teams other than your own. #### Security requirements - 1. If your merge request is processing, storing, or transferring any kind of [RED or ORANGE data](https://docs.google.com/document/d/15eNKGA3zyZazsJMldqTBFbYMnVUSQSpU14lo22JMZQY/edit) (this is a confidential document), it must be - **approved by a [Security Engineer][team]**. - 1. If your merge request involves implementing, utilizing, or is otherwise related to any type of authentication, authorization, or session handling mechanism, it must be - **approved by a [Security Engineer][team]**. - 1. If your merge request has a goal which requires a cryptographic function such as: confidentiality, integrity, authentication, or non-repudiation, it must be - **approved by a [Security Engineer][team]**. +View the updated documentation regarding [internal application security reviews](https://about.gitlab.com/handbook/engineering/security/index.html#internal-application-security-reviews) for **when** and **how** to request a security review. ### The responsibility of the merge request author @@ -138,10 +133,10 @@ as a domain expert and/or reviewer, it is recommended that they are not also pic as the maintainer to ultimately approve and merge it. Try to review in a timely manner; doing so allows everyone involved in the merge -request to iterate faster as the context is fresh in memory. Further, this +request to iterate faster as the context is fresh in memory. Further, this improves contributors' experiences significantly. Reviewers should aim to review -within two working days from the date they were assigned the merge request. If -you don't think you'll be able to review a merge request within that time, let +within two working days from the date they were assigned the merge request. If +you don't think you'll be able to review a merge request within that time, let the author know as soon as possible. When the author of the merge request has not heard anything after two days, a new reviewer should be assigned. @@ -151,7 +146,7 @@ required approvers. Maintainers must check before merging if the merge request is introducing new vulnerabilities, by inspecting the list in the Merge Request [Security Widget](https://docs.gitlab.com/ee/user/project/merge_requests/#security-reports-ultimate). -When in doubt, a [Security Engineer][team] can be involved. The list of detected +When in doubt, a [Security Engineer][team] can be involved. The list of detected vulnerabilities must be either empty or containing: - dismissed vulnerabilities in case of false positives diff --git a/doc/development/contributing/index.md b/doc/development/contributing/index.md index bfe1ef75914..b39c302453b 100644 --- a/doc/development/contributing/index.md +++ b/doc/development/contributing/index.md @@ -52,9 +52,12 @@ for audiences of all ages. If a contributor is no longer actively working on a submitted merge request we can decide that the merge request will be finished by one of our [Merge request coaches][team] or close the merge request. We make this decision -based on how important the change is for our product vision. If a Merge request +based on how important the change is for our product vision. If a merge request coach is going to finish the merge request we assign the -~"coach will finish" label. +~"coach will finish" label. When a team member picks up a community contribution, +we credit the original author by adding a changelog entry crediting the author +and optionally include the original author on at least one of the commits +within the MR. ## Helping others diff --git a/doc/development/contributing/style_guides.md b/doc/development/contributing/style_guides.md index 0eedef5e14f..45104a1f91d 100644 --- a/doc/development/contributing/style_guides.md +++ b/doc/development/contributing/style_guides.md @@ -22,6 +22,7 @@ text should be _sorry, we could not create your account because:_ 1. Code should be written in [US English][us-english] 1. [Go](../go_guide/index.md) +1. [Python](../python_guide/index.md) This is also the style used by linting tools such as [RuboCop](https://github.com/bbatsov/rubocop) and [Hound CI](https://houndci.com). diff --git a/doc/development/documentation/feature-change-workflow.md b/doc/development/documentation/feature-change-workflow.md index 3f31fe5ca19..1f68b6a6a70 100644 --- a/doc/development/documentation/feature-change-workflow.md +++ b/doc/development/documentation/feature-change-workflow.md @@ -78,7 +78,7 @@ For issues requiring any new or updated documentation, the Product Manager (PM) must: - Add the `Documentation` label. -- Confirm or add the [documentation requirements](#documentation-requirements). +- Confirm or add the [documentation requirements](#documentation-requirements-in-feature-issues). - Ensure the issue contains any new or updated feature name, overview/description, and use cases, as required per the [documentation structure and template](structure.md), when applicable. diff --git a/doc/development/ee_features.md b/doc/development/ee_features.md index 41a64044c68..c2e05b2d065 100644 --- a/doc/development/ee_features.md +++ b/doc/development/ee_features.md @@ -909,14 +909,15 @@ export default { - Since we [can't async load a mixin](https://github.com/vuejs/vue-loader/issues/418#issuecomment-254032223) we will use the [`ee_else_ce`](https://docs.gitlab.com/ee/development/ee_features.html#javascript-code-in-assetsjavascripts) alias we already have for webpack. - This means all the EE specific props, computed properties, methods, etc that are EE only should be in a mixin in the `ee/` folder and we need to create a CE counterpart of the mixin - ##### Example: - ```javascript - import mixin from 'ee_else_ce/path/mixin'; +##### Example: +```javascript +import mixin from 'ee_else_ce/path/mixin'; - { +{ mixins: [mixin] - } - ``` +} +``` + - Computed Properties/methods and getters only used in the child import still need a counterpart in CE - For store modules, we will need a CE counterpart too. diff --git a/doc/development/new_fe_guide/event_tracking.md b/doc/development/fe_guide/event_tracking.md index 6ab3fa4acf3..6ab3fa4acf3 100644 --- a/doc/development/new_fe_guide/event_tracking.md +++ b/doc/development/fe_guide/event_tracking.md diff --git a/doc/development/fe_guide/index.md b/doc/development/fe_guide/index.md index 86b8972a69e..d5cc28dc00c 100644 --- a/doc/development/fe_guide/index.md +++ b/doc/development/fe_guide/index.md @@ -1,8 +1,5 @@ # Frontend Development Guidelines -> **Notice:** -> We are currently in the process of re-writing our development guide to make it easier to find information. The new guide is still WIP but viewable in [development/new_fe_guide](../new_fe_guide/index.md) - This document describes various guidelines to ensure consistency and quality across GitLab's frontend team. @@ -12,15 +9,6 @@ GitLab is built on top of [Ruby on Rails][rails] using [Haml][haml] and also a J Be wary of [the limitations that come with using Hamlit][hamlit-limits]. We also use [SCSS][scss] and plain JavaScript with modern ECMAScript standards supported through [Babel][babel] and ES module support through [webpack][webpack]. -### Javascript development - -[Vue.js][vue] is used for particularly advanced, dynamic elements and based on previous iterations [jQuery][jquery] is used in lot of places through the application's JavaScript. - -We also use [Axios][axios] to handle all of our network requests. - -We also utilize [webpack][webpack] to handle the bundling, minification, and -compression of our assets. - Working with our frontend assets requires Node (v8.10.0 or greater) and Yarn (v1.10.0 or greater). You can find information on how to install these on our [installation guide][install]. @@ -31,6 +19,14 @@ For our currently-supported browsers, see our [requirements][requirements]. --- +## Initiatives + +Current high-level frontend goals are listed on [Frontend Epics](https://gitlab.com/groups/gitlab-org/-/epics?label_name%5B%5D=frontend). + +## [Principles](principles.md) + +High-level guidelines for contributing to GitLab. + ## [Development Process](development_process.md) How we plan and execute the work on the frontend. @@ -73,6 +69,10 @@ How we use SVG for our Icons and Illustrations. How we use UI components. +## [Event Tracking](event_tracking.md) + +How we use Snowplow to track custom events. + --- ## Style Guides @@ -124,14 +124,3 @@ The [externalization part of the guide](../i18n/externalization.md) explains the [scss-lint]: https://github.com/brigade/scss-lint [install]: ../../install/installation.md#4-node [requirements]: ../../install/requirements.md#supported-web-browsers - ---- - -## [DropLab](droplab/droplab.md) - -Our internal `DropLab` dropdown library. - -- [DropLab](droplab/droplab.md) -- [Ajax plugin](droplab/plugins/ajax.md) -- [Filter plugin](droplab/plugins/filter.md) -- [InputSetter plugin](droplab/plugins/input_setter.md) diff --git a/doc/development/fe_guide/principles.md b/doc/development/fe_guide/principles.md new file mode 100644 index 00000000000..6fb3456222f --- /dev/null +++ b/doc/development/fe_guide/principles.md @@ -0,0 +1,15 @@ +# Principles + +These principles will ensure that your frontend contribution starts off in the right direction. + +## Discuss architecture before implementation + +Discuss your architecture design in an issue before writing code. This helps decrease the review time and also provides good practice for writing and thinking about system design. + +## Be consistent + +There are multiple ways of writing code to accomplish the same results. We should be as consistent as possible in how we write code across our codebases. This will make it more easier us to maintain our code across GitLab. + +## Improve code [iteratively](https://about.gitlab.com/handbook/values/#iteration) + +Whenever you see with existing code that does not follow our current style guide, update it proactively. You don't need to fix everything, but each merge request should iteratively improve our codebase, and reduce technical debt where possible. diff --git a/doc/development/fe_guide/testing.md b/doc/development/fe_guide/testing.md index 98e499b8c0f..b23e37d1eef 100644 --- a/doc/development/fe_guide/testing.md +++ b/doc/development/fe_guide/testing.md @@ -1 +1,5 @@ -This document was moved to [../testing_guide/frontend_testing.md](../testing_guide/frontend_testing.md). +--- +redirect_to: '../testing_guide/frontend_testing.md' +--- + +This document was moved to [another location](../testing_guide/frontend_testing.md). diff --git a/doc/development/fe_guide/vue.md b/doc/development/fe_guide/vue.md index 435fdf39fb4..a34d1fcec89 100644 --- a/doc/development/fe_guide/vue.md +++ b/doc/development/fe_guide/vue.md @@ -120,6 +120,13 @@ You can read more about components in Vue.js site, [Component System][component- #### Vuex Check this [page](vuex.md) for more details. +### Mixing Vue and jQuery + +- Mixing Vue and jQuery is not recommended. +- If you need to use a specific jQuery plugin in Vue, [create a wrapper around it][https://vuejs.org/v2/examples/select2.html]. +- It is acceptable for Vue to listen to existing jQuery events using jQuery event listeners. +- It is not recommended to add new jQuery events for Vue to interact with jQuery. + ## Style guide Please refer to the Vue section of our [style guide](style_guide_js.md#vuejs) diff --git a/doc/development/git_object_deduplication.md b/doc/development/git_object_deduplication.md new file mode 100644 index 00000000000..81c5f69c7b8 --- /dev/null +++ b/doc/development/git_object_deduplication.md @@ -0,0 +1,261 @@ +# How Git object deduplication works in GitLab + +When a GitLab user [forks a project](../workflow/forking_workflow.md), +GitLab creates a new Project with an associated Git repository that is a +copy of the original project at the time of the fork. If a large project +gets forked often, this can lead to a quick increase in Git repository +storage disk use. To counteract this problem, we are adding Git object +deduplication for forks to GitLab. In this document, we will describe how +GitLab implements Git object deduplication. + +## Enabling Git object deduplication via feature flags + +As of GitLab 11.9, Git object deduplication in GitLab is in beta. In this +document, you can read about the caveats of enabling the feature. Also, +note that Git object deduplication is limited to forks of public +projects on hashed repository storage. + +You can enable deduplication globally by setting the `object_pools` +feature flag to `true`: + +``` {.ruby} +Feature.enable(:object_pools) +``` + +Or just for forks of a specific project: + +``` {.ruby} +fork_parent = Project.find(MY_PROJECT_ID) +Feature.enable(:object_pools, fork_parent) +``` + +To check if a project uses Git object deduplication, look in a Rails +console if `project.pool_repository` is present. + +## Pool repositories + +### Understanding Git alternates + +At the Git level, we achieve deduplication by using [Git +alternates](https://git-scm.com/docs/gitrepository-layout#gitrepository-layout-objects). +Git alternates is a mechanism that lets a repository borrow objects from +another repository on the same machine. + +If we want repository A to borrow from repository B, we first write a +path that resolves to `B.git/objects` in the special file +`A.git/objects/info/alternates`. This establishes the alternates link. +Next, we must perform a Git repack in A. After the repack, any objects +that are duplicated between A and B will get deleted from A. Repository +A is now no longer self-contained, but it still has its own refs and +configuration. Objects in A that are not in B will remain in A. For this +to work, it is of course critical that **no objects ever get deleted from +B** because A might need them. + +### Git alternates in GitLab: pool repositories + +GitLab organizes this object borrowing by creating special **pool +repositories** which are hidden from the user. We then use Git +alternates to let a collection of project repositories borrow from a +single pool repository. We call such a collection of project +repositories a pool. Pools form star-shaped networks of repositories +that borrow from a single pool, which will resemble (but not be +identical to) the fork networks that get formed when users fork +projects. + +At the Git level, pool repositories are created and managed using Gitaly +RPC calls. Just like with normal repositories, the authority on which +pool repositories exist, and which repositories borrow from them, lies +at the Rails application level in SQL. + +In conclusion, we need three things for effective object deduplication +across a collection of GitLab project repositories at the Git level: + +1. A pool repository must exist. +2. The participating project repositories must be linked to the pool + repository via their respective `objects/info/alternates` files. +3. The pool repository must contain Git object data common to the + participating project repositories. + +### Deduplication factor + +The effectiveness of Git object deduplication in GitLab depends on the +amount of overlap between the pool repository and each of its +participants. As of GitLab 11.9, we have a somewhat optimistic system. +The only data that will be deduplicated is the data in the source +project repository at the time the pool repository is created. That is, +the data in the source project at the time of the first fork *after* the +deduplication feature has been enabled. + +When we enable the object deduplication feature for +gitlab.com/gitlab-org/gitlab-ce, which is about 1GB at the time of +writing, all new forks of that project would be 1GB smaller than they +would have been without Git object deduplication. So even in its current +optimistic form, we expect Git object deduplication in GitLab to make a +difference. + +However, if a lot of Git objects get added to the project repositories +in a pool after the pool repository was created these new Git objects +will currently (GitLab 11.9) not get deduplicated. Over time, the +deduplication factor of the pool will get worse and worse. + +As an extreme example, if we create an empty repository A, and fork that +to repository B, behind the scenes we get an object pool P with no +objects in it at all. If we then push 1GB of Git data to A, and push the +same Git data to B, it will not get deduplicated, because that data was +not in A at the time P was created. + +This also matters in less extreme examples. Consider a pool P with +source project A and 500 active forks B1, B2,...,B500. Suppose, +optimistically, that the forks are fully deduplicated at the start of +our scenario. Now some time passes and 200MB of new Git data gets added +to project A. Because of the forking workflow, this data makes also its way +into the forks B1, ..., B500. That means we would now have 100GB of Git +data sitting around (500 \* 200MB) across the forks, that could have +been deduplicated. But because of the way we do deduplication this new +data will not be deduplicated. + +> TODO Add periodic maintenance of object pools to prevent gradual loss +> of deduplication over time. +> https://gitlab.com/groups/gitlab-org/-/epics/524 + +## SQL model + +As of GitLab 11.8, project repositories in GitLab do not have their own +SQL table. They are indirectly identified by columns on the `projects` +table. In other words, the only way to look up a project repository is to +first look up its project, and then call `project.repository`. + +With pool repositories we made a fresh start. These live in their own +`pool_repositories` SQL table. The relations between these two tables +are as follows: + +- a `Project` belongs to at most one `PoolRepository` + (`project.pool_repository`) +- as an automatic consequence of the above, a `PoolRepository` has + many `Project`s +- a `PoolRepository` has exactly one "source `Project`" + (`pool.source_project`) + +### Assumptions + +- All repositories in a pool must use [hashed + storage](../administration/repository_storage_types.md). This is so + that we don't have to ever worry about updating paths in + `object/info/alternates` files. +- All repositories in a pool must be on the same Gitaly storage shard. + The Git alternates mechanism relies on direct disk access across + multiple repositories, and we can only assume direct disk access to + be possible within a Gitaly storage shard. +- All project repositories in a pool must have "Public" visibility in + GitLab at the time they join. There are gotchas around visibility of + Git objects across alternates links. This restriction is a defense + against accidentally leaking private Git data. +- The only two ways to remove a member project from a pool are (1) to + delete the project or (2) to move the project to another Gitaly + storage shard. + +### Creating pools and pool memberships + +- When a pool gets created, it must have a source project. The initial + contents of the pool repository are a Git clone of the source + project repository. +- The occasion for creating a pool is when an existing eligible + (public, hashed storage, non-forked) GitLab project gets forked and + this project does not belong to a pool repository yet. The fork + parent project becomes the source project of the new pool, and both + the fork parent and the fork child project become members of the new + pool. +- Once project A has become the source project of a pool, all future + eligible forks of A will become pool members. +- If the fork source is itself a fork, the resulting repository will + neither join the repository nor will a new pool repository be + seeded. + + eg: + + Suppose fork A is part of a pool repository, any forks created off + of fork A *will not* be a part of the pool repository that fork A is + a part of. + + Suppose B is a fork of A, and A does not belong to an object pool. + Now C gets created as a fork of B. C will not be part of a pool + repository. + +> TODO should forks of forks be deduplicated? +> https://gitlab.com/gitlab-org/gitaly/issues/1532 + +### Consequences + +- If a normal Project participating in a pool gets moved to another + Gitaly storage shard, its "belongs to PoolRepository" relation must + be broken. Because of the way moving repositories between shard is + implemented, we will automatically get a fresh self-contained copy + of the project's repository on the new storage shard. +- If the source project of a pool gets moved to another Gitaly storage + shard or is deleted, we may have to break the "PoolRepository has + one source Project" relation? + +> TODO What happens, or should happen, if a source project changes +> visibility, is deleted, or moves to another storage shard? +> https://gitlab.com/gitlab-org/gitaly/issues/1488 + +## Consistency between the SQL pool relation and Gitaly + +As far as Gitaly is concerned, the SQL pool relations make two types of +claims about the state of affairs on the Gitaly server: pool repository +existence, and the existence of an alternates connection between a +repository and a pool. + +### Pool existence + +If GitLab thinks a pool repository exists (i.e. it exists according to +SQL), but it does not on the Gitaly server, then certain RPC calls that +take the object pool as an argument will fail. + +> TODO What happens if SQL says the pool repo exists but Gitaly says it +> does not? https://gitlab.com/gitlab-org/gitaly/issues/1533 + +If GitLab thinks a pool does not exist, while it does exist on disk, +that has no direct consequences on its own. However, if other +repositories on disk borrow objects from this unknown pool repository +then we risk data loss, see below. + +### Pool relation existence + +There are three different things that can go wrong here. + +#### 1. SQL says repo A belongs to pool P but Gitaly says A has no alternate objects + +In this case, we miss out on disk space savings but all RPC's on A itself +will function fine. As long as Git can find all its objects, it does not +matter exactly where those objects are. + +#### 2. SQL says repo A belongs to pool P1 but Gitaly says A has alternate objects in pool P2 + +If we are not careful, this situation can lead to data loss. During some +operations (repository maintenance), GitLab will try to re-link A to its +pool P1. If this clobbers the existing link to P2, then A will loose Git +objects and become invalid. + +Also, keep in mind that if GitLab's database got messed up, it may not +even know that P2 exists. + +> TODO Ensure that Gitaly will not clobber existing, unexpected +> alternates links. https://gitlab.com/gitlab-org/gitaly/issues/1534 + +#### 3. SQL says repo A does not belong to any pool but Gitaly says A belongs to P + +This has the same data loss possibility as scenario 2 above. + +## Git object deduplication and GitLab Geo + +When a pool repository record is created in SQL on a Geo primary, this +will eventually trigger an event on the Geo secondary. The Geo secondary +will then create the pool repository in Gitaly. This leads to an +"eventually consistent" situation because as each pool participant gets +synchronized, Geo will eventuall trigger garbage collection in Gitaly on +the secondary, at which stage Git objects will get deduplicated. + +> TODO How do we handle the edge case where at the time the Geo +> secondary tries to create the pool repository, the source project does +> not exist? https://gitlab.com/gitlab-org/gitaly/issues/1533 diff --git a/doc/development/gitaly.md b/doc/development/gitaly.md index b1785e6f803..27b69ba8278 100644 --- a/doc/development/gitaly.md +++ b/doc/development/gitaly.md @@ -3,6 +3,12 @@ [Gitaly](https://gitlab.com/gitlab-org/gitaly) is a high-level Git RPC service used by GitLab CE/EE, Workhorse and GitLab-Shell. +## Beginner's guide + +Start by reading the gitaly repository's +[Beginner's guide to Gitaly contributions](https://gitlab.com/gitlab-org/gitaly/blob/master/doc/beginners_guide.md). +It describes how to setup gitaly, the various components of gitaly and what they do, and how to run its test suites. + ## Developing new Git features To read or write Git data, a request has to be made to Gitaly. This means that @@ -191,3 +197,82 @@ as a [CI environment variable](../ci/variables/README.md#variables). --- [Return to Development documentation](README.md) + +## Wrapping RPCs in Feature Flags + +Here are the steps to gate a new feature in Gitaly behind a feature flag. + +### Gitaly + +1. Create a package scoped flag name: + + ```go + var findAllTagsFeatureFlag = "go-find-all-tags" + ``` + +1. Create a switch in the code using the `featureflag` package: + + ```go + if featureflag.IsEnabled(ctx, findAllTagsFeatureFlag) { + // go implementation + } else { + // ruby implementation + } + ``` + +1. Create prometheus metrics: + + ```go + var findAllTagsRequests = prometheus.NewCounterVec( + prometheus.CounterOpts{ + Name: "gitaly_find_all_tags_requests_total", + Help: "Counter of go vs ruby implementation of FindAllTags", + }, + []string{"implementation"}, + ) + ) + + func init() { + prometheus.Register(findAllTagsRequests) + } + + if featureflag.IsEnabled(ctx, findAllTagsFeatureFlag) { + findAllTagsRequests.WithLabelValues("go").Inc() + // go implementation + } else { + findAllTagsRequests.WithLabelValues("ruby").Inc() + // ruby impelmentation + } + ``` + +1. Set headers in tests: + + ```go + import ( + "google.golang.org/grpc/metadata" + + "gitlab.com/gitlab-org/gitaly/internal/featureflag" + ) + + //... + + md := metadata.New(map[string]string{featureflag.HeaderKey(findAllTagsFeatureFlag): "true"}) + ctx = metadata.NewOutgoingContext(context.Background(), md) + + c, err = client.FindAllTags(ctx, rpcRequest) + require.NoError(t, err) + ``` + +### Gitlab-Rails + +1. Add feature flag to `lib/gitlab/gitaly_client.rb` (in gitlab-rails): + + ```ruby + SERVER_FEATURE_FLAGS = %w[go-find-all-tags].freeze + ``` + +1. Test in rails console by setting feature flag: + + ```ruby + Feature.enable('gitaly_go-find-all-tags') + ``` diff --git a/doc/development/go_guide/index.md b/doc/development/go_guide/index.md index cdc806a2d31..6dcade3bb51 100644 --- a/doc/development/go_guide/index.md +++ b/doc/development/go_guide/index.md @@ -26,7 +26,7 @@ Reviewers and maintainers should pay attention to: - `defer` functions: ensure the presence when needed, and after `err` check. - Inject dependencies as parameters. -- Void structs when marshalling to JSON (generates `null` instead of `[]`). +- Void structs when marshaling to JSON (generates `null` instead of `[]`). ### Security @@ -161,12 +161,39 @@ in the code. ### Logging -The usage of a logging library is strongly recommended for daemons. Even though -there is a `log` package in the standard library, we generally use -[logrus](https://github.com/sirupsen/logrus). Its plugin ("hooks") system +The usage of a logging library is strongly recommended for daemons. Even +though there is a `log` package in the standard library, we generally use +[Logrus](https://github.com/sirupsen/logrus). Its plugin ("hooks") system makes it a powerful logging library, with the ability to add notifiers and formatters at the logger level directly. +#### Structured (JSON) logging + +Every binary ideally must have structured (JSON) logging in place as it helps +with searching and filtering the logs. At GitLab we use structured logging in +JSON format, as all our infrastructure assumes that. When using +[Logrus](https://github.com/sirupsen/logrus) you can turn on structured +logging simply by using the build in [JSON +formatter](https://github.com/sirupsen/logrus#formatters). This follows the +same logging type we use in our [Ruby +applications](../logging.md#use-structured-json-logging). + +#### How to use Logrus + +There are a few guidelines one should follow when using the +[Logrus](https://github.com/sirupsen/logrus) package: + +- When printing an error use + [WithError](https://godoc.org/github.com/sirupsen/logrus#WithError). For + example, `logrus.WithError(err).Error("Failed to do something")`. +- Since we use [structured logging](#structured-json-logging) we can log + fields in the context of that code path, such as the URI of the request using + [`WithField`](https://godoc.org/github.com/sirupsen/logrus#WithField) or + [`WithFields`](https://godoc.org/github.com/sirupsen/logrus#WithFields). For + example, `logrus.WithField("file", "/app/go).Info("Opening dir")`. If you + have to log multiple keys, always use `WithFields` instead of calling + `WithField` more than once. + ### Tracing and Correlation [LabKit](https://gitlab.com/gitlab-org/labkit) is a place to keep common diff --git a/doc/development/i18n_guide.md b/doc/development/i18n_guide.md index f6e949b5fd8..e588b47e203 100644 --- a/doc/development/i18n_guide.md +++ b/doc/development/i18n_guide.md @@ -1 +1,5 @@ -This document was moved to [a new location](i18n/index.md). +--- +redirect_to: 'i18n/index.md' +--- + +This document was moved to [another location](i18n/index.md). diff --git a/doc/development/new_fe_guide/development/design_patterns.md b/doc/development/new_fe_guide/development/design_patterns.md deleted file mode 100644 index ee06566ed30..00000000000 --- a/doc/development/new_fe_guide/development/design_patterns.md +++ /dev/null @@ -1,3 +0,0 @@ -# Design patterns - -> TODO: Add content diff --git a/doc/development/new_fe_guide/development/index.md b/doc/development/new_fe_guide/development/index.md index cee8e43ebad..5dced3dc466 100644 --- a/doc/development/new_fe_guide/development/index.md +++ b/doc/development/new_fe_guide/development/index.md @@ -1,9 +1,5 @@ # Development -## [Design patterns](design_patterns.md) - -Examples of proven design patterns used in our codebase. - ## [Components](components.md) Documentation on existing components and how to best create a new component. @@ -12,14 +8,6 @@ Documentation on existing components and how to best create a new component. Learn how to implement an accessible frontend. -## [Network requests](network_requests.md) - -Learn how to handle network requests in our codebase. - -## [Security](security.md) - -Learn how to ensure that our frontend is secure. - ## [Performance](performance.md) Learn how to keep our frontend performant. diff --git a/doc/development/new_fe_guide/development/network_requests.md b/doc/development/new_fe_guide/development/network_requests.md deleted file mode 100644 index 047c00313bc..00000000000 --- a/doc/development/new_fe_guide/development/network_requests.md +++ /dev/null @@ -1,3 +0,0 @@ -# Network requests - -> TODO: Add content diff --git a/doc/development/new_fe_guide/development/security.md b/doc/development/new_fe_guide/development/security.md deleted file mode 100644 index 5bb38f17988..00000000000 --- a/doc/development/new_fe_guide/development/security.md +++ /dev/null @@ -1,14 +0,0 @@ -# Security - -## Avoid inline scripts and styles - -Inline scripts and styles should be avoided in almost all cases. In an effort to protect users from [XSS vulnerabilities](https://en.wikipedia.org/wiki/Cross-site_scripting), we will be disabling inline scripts using Content Security Policy. - -## Including external resources - -External fonts, CSS, and JavaScript should never be used with the exception of Google Analytics and Piwik - and only when the instance has enabled it. Assets should always be hosted and served locally from the GitLab instance. Embedded resources via `iframes` should never be used except in certain circumstances such as with ReCaptcha, which cannot be used without an `iframe`. - -## Resources for security testing - -- [Mozilla's HTTP Observatory CLI](https://github.com/mozilla/http-observatory-cli) -- [Qualys SSL Labs Server Test](https://www.ssllabs.com/ssltest/analyze.html) diff --git a/doc/development/new_fe_guide/index.md b/doc/development/new_fe_guide/index.md index 5fd5af252ef..0e8f5486861 100644 --- a/doc/development/new_fe_guide/index.md +++ b/doc/development/new_fe_guide/index.md @@ -3,14 +3,6 @@ This guide contains all the information to successfully contribute to GitLab's frontend. This is a living document, and we welcome contributions, feedback and suggestions. -## [Principles](principles.md) - -Ensure that your frontend contribution starts off in the right direction. - -## [Initiatives](initiatives.md) - -High level overview of where we are going from a frontend perspective. - ## [Development](development/index.md) Guidance on topics related to development. @@ -27,9 +19,6 @@ Learn about all the internal JavaScript modules that make up our frontend. Style guides to keep our code consistent. -## [Event Tracking with Snowplow](event_tracking.md) - -How we use Snowplow to track custom events. ## [Tips](tips.md) diff --git a/doc/development/new_fe_guide/initiatives.md b/doc/development/new_fe_guide/initiatives.md deleted file mode 100644 index c81ed3579f0..00000000000 --- a/doc/development/new_fe_guide/initiatives.md +++ /dev/null @@ -1,3 +0,0 @@ -# Initiatives - -> TODO: Add Initiatives diff --git a/doc/development/new_fe_guide/principles.md b/doc/development/new_fe_guide/principles.md deleted file mode 100644 index 0af5f506a91..00000000000 --- a/doc/development/new_fe_guide/principles.md +++ /dev/null @@ -1,35 +0,0 @@ -# Principles - -These principles will ensure that your frontend contribution starts off in the right direction. - -## Discuss architecture before implementation - -Discuss your architecture design in an issue before writing code. This helps decrease the review time and also provides good practice for writing and thinking about system design. - -## Be consistent - -There are multiple ways of writing code to accomplish the same results. We should be as consistent as possible in how we write code across our codebases. This will make it more easier us to maintain our code across GitLab. - -## Enhance progressively - -Whenever you see with existing code that does not follow our current style guide, update it proactively. Refrain from changing everything but each merge request should progressively enhance our codebase and reduce technical debt. - -## When to use Vue - -- Use Vue for feature that make use of heavy DOM manipulation -- Use Vue for reusable components - -## When to use jQuery - -- Use jQuery to interact with Bootstrap JavaScript components -- Avoid jQuery when a better alternative exists. We are slowly moving away from it [#43559][jquery-future] - -## Mixing Vue and jQuery - -- Mixing Vue and jQuery is not recommended. -- If you need to use a specific jQuery plugin in Vue, [create a wrapper around it][select2]. -- It is acceptable for Vue to listen to existing jQuery events using jQuery event listeners. -- It is not recommended to add new jQuery events for Vue to interact with jQuery. - -[jquery-future]: https://gitlab.com/gitlab-org/gitlab-ce/issues/43559 -[select2]: https://vuejs.org/v2/examples/select2.html diff --git a/doc/development/new_fe_guide/style/html.md b/doc/development/new_fe_guide/style/html.md index 035fcbb28df..e8c9c2ccebf 100644 --- a/doc/development/new_fe_guide/style/html.md +++ b/doc/development/new_fe_guide/style/html.md @@ -2,11 +2,11 @@ ## Buttons -<a name="button-type"></a><a name="1.1"></a> +### Button type -- [1.1](#button-type) **Use button type** Button tags requires a `type` attribute according to the [W3C HTML specification][button-type-spec]. +Button tags requires a `type` attribute according to the [W3C HTML specification](https://www.w3.org/TR/2011/WD-html5-20110525/the-button-element.html#dom-button-type). -``` +```html // bad <button></button> @@ -14,11 +14,11 @@ <button type="button"></button> ``` -<a name="button-role"></a><a name="1.2"></a> +### Button role -- [1.2](#button-role) **Use button role for non buttons** If an HTML element has an onClick handler but is not a button, it should have `role="button"`. This is more [accessible][button-role-accessible]. +If an HTML element has an `onClick` handler but is not a button, it should have `role="button"`. This is [more accessible](https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role). -``` +```html // bad <div onClick="doSomething"></div> @@ -28,11 +28,11 @@ ## Links -<a name="blank-links"></a><a name="2.1"></a> +### Blank target -- [2.1](#blank-links) **Use rel for target blank** Use `rel="noopener noreferrer"` whenever your links open in a new window i.e. `target="_blank"`. This prevents [the following][jitbit-target-blank] security vulnerability documented by JitBit +Use `rel="noopener noreferrer"` whenever your links open in a new window, i.e. `target="_blank"`. This prevents a security vulnerability [documented by JitBit](https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/). -``` +```html // bad <a href="url" target="_blank"></a> @@ -40,18 +40,14 @@ <a href="url" target="_blank" rel="noopener noreferrer"></a> ``` -<a name="fake-links"></a><a name="2.2"></a> +### Fake links -- [2.2](#fake-links) **Do not use fake links** Use a button tag if a link only invokes JavaScript click event handlers. This is more semantic. +**Do not use fake links.** Use a button tag if a link only invokes JavaScript click event handlers, which is more semantic. -``` +```html // bad <a class="js-do-something" href="#"></a> // good <button class="js-do-something" type="button"></button> ``` - -[button-type-spec]: https://www.w3.org/TR/2011/WD-html5-20110525/the-button-element.html#dom-button-type -[button-role-accessible]: https://developer.mozilla.org/en-US/docs/Web/Accessibility/ARIA/ARIA_Techniques/Using_the_button_role -[jitbit-target-blank]: https://www.jitbit.com/alexblog/256-targetblank---the-most-underestimated-vulnerability-ever/ diff --git a/doc/development/new_fe_guide/tips.md b/doc/development/new_fe_guide/tips.md index 881ad1662ae..889a5aab2b7 100644 --- a/doc/development/new_fe_guide/tips.md +++ b/doc/development/new_fe_guide/tips.md @@ -7,3 +7,19 @@ To clear production compiled assets created with `yarn webpack-prod` you can run ``` yarn clean ``` + +## Creating feature flags in development + +The process for creating a feature flag is the same as [enabling a feature flag in development](https://docs.gitlab.com/ee/development/feature_flags.html#enabling-a-feature-flag-in-development). + +Your feature flag can now be: + +- [made available to the frontend](https://docs.gitlab.com/ee/development/feature_flags.html#frontend) via the `gon` +- queried in [tests](https://docs.gitlab.com/ee/development/feature_flags.html#specs) +- queried in HAML templates and ruby files via the `Feature.enabled?(:my_shiny_new_feature_flag)` method + +### More on feature flags + +- [Deleting a feature flag](https://docs.gitlab.com/ee/api/features.html#delete-a-feature) +- [Manage feature flags](https://docs.gitlab.com/ee/development/feature_flags.html) +- [Feature flags API](https://docs.gitlab.com/ee/api/features.html) diff --git a/doc/development/python_guide/index.md b/doc/development/python_guide/index.md new file mode 100644 index 00000000000..6025dc9ebf2 --- /dev/null +++ b/doc/development/python_guide/index.md @@ -0,0 +1,79 @@ +# Python Development Guidelines + +GitLab requires Python as a dependency for [reStructuredText](http://docutils.sourceforge.net/rst.html) +markup rendering. + +As of GitLab 11.10, we require Python 3. + +## Installation + +There are several ways of installing python on your system. To be able to use the same version we use in production, +we suggest you use [pyenv](https://github.com/pyenv/pyenv). It works and behave similar to its counterpart in the +ruby world: [rbenv](https://github.com/rbenv/rbenv). + +### macOS + +To install `pyenv` on macOS, you can use [Homebrew](https://brew.sh/) with: + +```bash +brew install pyenv +``` + +### Linux + +To install `pyenv` on Linux, you can run the command below: + +```bash +curl https://pyenv.run | bash +``` + +Alternatively, you may find `pypenv` available as a system package via your distro package manager. + +You can read more about it in: <https://github.com/pyenv/pyenv-installer#prerequisites>. + +### Shell integration + +Pyenv installation will add required changes to Bash. If you use a different shell, +check for any additional steps required for it. + +For Fish, you can install a plugin for [Fisherman](https://github.com/fisherman/fisherman): + +```bash +fisher add fisherman/pyenv +``` + +Or for [Oh My Fish](https://github.com/oh-my-fish/oh-my-fish): + +```bash +omf install pyenv +``` + +## Dependency management + +While GitLab doesn't directly contain any Python scripts, because we depend on Python to render +[reStructuredText](http://docutils.sourceforge.net/rst.html) markup, we need to keep track on dependencies +on the main project level, so we can run that on our development machines. + +Recently, an equivalent to the `Gemfile` and the [Bundler](https://bundler.io/) project has been introduced to Python: +`Pipfile` and [Pipenv](https://pipenv.readthedocs.io/en/latest/). + +You will now find a `Pipfile` with the dependencies in the root folder. To install them, run: + +```bash +pipenv install +``` + +Running this command will install both the required Python version as well as required pip dependencies. + +## Use instructions + +To run any python code under the Pipenv environment, you need to first start a `virtualenv` based on the dependencies +of the application. With Pipenv, this is a simple as running: + +```bash +pipenv shell +``` + +After running that command, you can run GitLab on the same shell and it will be using the Python and dependencies +installed from the `pipenv install` command. + diff --git a/doc/development/rolling_out_changes_using_feature_flags.md b/doc/development/rolling_out_changes_using_feature_flags.md index 4e0d1b74bc9..8d35a4ecee2 100644 --- a/doc/development/rolling_out_changes_using_feature_flags.md +++ b/doc/development/rolling_out_changes_using_feature_flags.md @@ -105,6 +105,20 @@ Flags](feature_flags.md) guide) supports rolling out changes to a percentage of users. This in turn can be controlled using [GitLab chatops](https://docs.gitlab.com/ee/ci/chatops/). +For an up to date list of feature flag commands please see [the source +code](https://gitlab.com/gitlab-com/chatops/blob/master/lib/chatops/commands/feature.rb). +Note that all the examples in that file must be preceded by +`/chatops run`. + +If you get an error "Whoops! This action is not allowed. This incident +will be reported." that means your Slack account is not allowed to +change feature flags. To test if you are allowed to do anything at all, +run: + +``` +/chatops run feature --help +``` + For example, to enable a feature for 25% of all users, run the following in Slack: diff --git a/doc/development/testing.md b/doc/development/testing.md index 45b1519ece8..79ef8e75432 100644 --- a/doc/development/testing.md +++ b/doc/development/testing.md @@ -1 +1,5 @@ -This document was moved to [testing_guide/index.md](testing_guide/index.md). +--- +redirect_to: 'testing_guide/index.md' +--- + +This document was moved to [another location](testing_guide/index.md). diff --git a/doc/development/testing_guide/best_practices.md b/doc/development/testing_guide/best_practices.md index cfe0e6f70fc..7262c04d746 100644 --- a/doc/development/testing_guide/best_practices.md +++ b/doc/development/testing_guide/best_practices.md @@ -1,5 +1,20 @@ # Testing best practices +## Test Design + +Testing at GitLab is a first class citizen, not an afterthought. It's important we consider the design of our tests +as we do the design of our features. + +When implementing a feature, we think about developing the right capabilities the right way, which helps us +narrow our scope to a manageable level. When implementing tests for a feature, we must think about developing +the right tests, but then cover _all_ the important ways the test may fail, which can quickly widen our scope to +a level that is difficult to manage. + +Test heuristics can help solve this problem. They concisely address many of the common ways bugs +manifest themselves within our code. When designing our tests, take time to review known test heuristics to inform +our test design. We can find some helpful heuristics documented in the Handbook in the +[Test Design](https://about.gitlab.com/handbook/engineering/quality/guidelines/test-engineering/test-design/) section. + ## Test speed GitLab has a massive test suite that, without [parallelization], can take hours diff --git a/doc/development/testing_guide/end_to_end_tests.md b/doc/development/testing_guide/end_to_end_tests.md index 7010250b33c..51fe19c3d9e 100644 --- a/doc/development/testing_guide/end_to_end_tests.md +++ b/doc/development/testing_guide/end_to_end_tests.md @@ -7,6 +7,24 @@ as expected across the entire software stack and architecture, including integration of all micro-services and components that are supposed to work together. +## Branch naming + +If your contribution contains **only** changes under the +[`qa/` folder](https://gitlab.com/gitlab-org/gitlab-ce/tree/master/qa), you can +speed up the CI process by following some branch naming conventions. You have +three choices: + +| Branch name | Valid example | +|:----------------------|:-----------------------------| +| Starting with `qa/` | `qa/new-oauth-login-test` | +| Starting with `qa-` | `qa-new-oauth-login-test` | +| Ending in `-qa` | `123-new-oauth-login-test-qa` | + +If your branch name matches any of the above, it will run only the QA-related +jobs. +If it does not, the whole application test suite will run (including QA-related +jobs). + ## How do we test GitLab? We use [Omnibus GitLab][omnibus-gitlab] to build GitLab packages and then we @@ -27,10 +45,15 @@ Results are reported in the `#qa-staging` Slack channel. ### Testing code in merge requests +#### Using the `package-and-qa` job + It is possible to run end-to-end tests for a merge request, eventually being run in a pipeline in the [`gitlab-qa`](https://gitlab.com/gitlab-org/gitlab-qa/) project, -by triggering the `package-and-qa` manual action in the `test` stage (which should -be present in a merge request widget, unless the merge request comes from a fork). +by triggering the `package-and-qa` manual action in the `test` stage (not +available for forks). + +**This runs end-to-end tests against a custom Omnibus package built from your +merge request's changes.** Manual action that starts end-to-end tests is also available in merge requests in [Omnibus GitLab][omnibus-gitlab]. @@ -85,7 +108,25 @@ subgraph gitlab-qa pipeline 1. The result of the [GitLab QA pipeline][gitlab-qa-pipelines] is being propagated upstream, through Omnibus, back to the CE / EE merge request. -#### How do I write tests? +#### Using the `review-qa-all` jobs + +On every pipeline during the `test` stage, the `review-qa-smoke` job is +automatically started: it runs the QA smoke suite against the +[Review App][review-apps]. + +You can also manually start the `review-qa-all`: it runs the full QA suite +against the [Review App][review-apps]. + +**This runs end-to-end tests against a Review App based on [the official GitLab +Helm chart][helm-chart], itself deployed with custom +[Cloud Native components][cng] built from your merge request's changes.** + +See [Review Apps][review-apps] for more details about Review Apps. + +[helm-chart]: https://gitlab.com/charts/gitlab/ +[cng]: https://gitlab.com/gitlab-org/build/CNG + +## How do I write tests? In order to write new tests, you first need to learn more about GitLab QA architecture. See the [documentation about it][gitlab-qa-architecture]. @@ -105,9 +146,11 @@ you can find an issue you would like to work on in [omnibus-gitlab]: https://gitlab.com/gitlab-org/omnibus-gitlab [gitlab-qa]: https://gitlab.com/gitlab-org/gitlab-qa +[gitlab-qa-pipelines]: https://gitlab.com/gitlab-org/gitlab-qa/pipelines [gitlab-qa-readme]: https://gitlab.com/gitlab-org/gitlab-qa/tree/master/README.md [quality-nightly-pipelines]: https://gitlab.com/gitlab-org/quality/nightly/pipelines [quality-staging-pipelines]: https://gitlab.com/gitlab-org/quality/staging/pipelines +[review-apps]: ./review_apps.md [gitlab-qa-architecture]: https://gitlab.com/gitlab-org/gitlab-qa/blob/master/docs/architecture.md [gitlab-qa-issues]: https://gitlab.com/gitlab-org/gitlab-qa/issues?label_name%5B%5D=new+scenario [gitlab-ce-issues]: https://gitlab.com/gitlab-org/gitlab-ce/issues?label_name[]=QA&label_name[]=test diff --git a/doc/development/testing_guide/frontend_testing.md b/doc/development/testing_guide/frontend_testing.md index d4a2ac246c4..71c9637e72c 100644 --- a/doc/development/testing_guide/frontend_testing.md +++ b/doc/development/testing_guide/frontend_testing.md @@ -53,12 +53,9 @@ Remember that the performance of each test depends on the environment. ## Karma test suite GitLab uses the [Karma][karma] test runner with [Jasmine] as its test -framework for our JavaScript unit and integration tests. For integration tests, -we generate HTML files using RSpec (see `spec/javascripts/fixtures/*.rb` for examples). -Some fixtures are still HAML templates that are translated to HTML files using the same mechanism (see `static_fixtures.rb`). -Adding these static fixtures should be avoided as they are harder to keep up to date with real views. -The existing static fixtures will be migrated over time. -Please see [gitlab-org/gitlab-ce#24753](https://gitlab.com/gitlab-org/gitlab-ce/issues/24753) to track our progress. +framework for our JavaScript unit and integration tests. +We generate HTML and JSON fixtures from backend views and controllers +using RSpec (see `spec/javascripts/fixtures/*.rb` for examples). Fixtures are served during testing by the [jasmine-jquery][jasmine-jquery] plugin. JavaScript tests live in `spec/javascripts/`, matching the folder structure @@ -228,14 +225,12 @@ See this [section][vue-test]. ### Running frontend tests -`rake karma` runs the frontend-only (JavaScript) tests. -It consists of two subtasks: +For running the frontend tests, you need the following commands: -- `rake karma:fixtures` (re-)generates fixtures -- `rake karma:tests` actually executes the tests +- `rake karma:fixtures` (re-)generates fixtures. +- `yarn test` executes the tests. -As long as the fixtures don't change, `rake karma:tests` (or `yarn karma`) -is sufficient (and saves you some time). +As long as the fixtures don't change, `yarn test` is sufficient (and saves you some time). ### Live testing and focused testing diff --git a/doc/development/testing_guide/index.md b/doc/development/testing_guide/index.md index 67e4cfeda0e..ecad9ba48a3 100644 --- a/doc/development/testing_guide/index.md +++ b/doc/development/testing_guide/index.md @@ -33,7 +33,7 @@ changes should be tested. ## [Testing best practices](best_practices.md) -Everything you should know about how to write good tests: RSpec, FactoryBot, +Everything you should know about how to write good tests: Test Design, RSpec, FactoryBot, system tests, parameterized tests etc. --- diff --git a/doc/development/testing_guide/review_apps.md b/doc/development/testing_guide/review_apps.md index fda3ff57316..ffc71051377 100644 --- a/doc/development/testing_guide/review_apps.md +++ b/doc/development/testing_guide/review_apps.md @@ -90,8 +90,8 @@ subgraph GCP `gitlab-review-apps` project ## QA runs On every [pipeline][gitlab-pipeline] during the `test` stage, the -`review-qa-smoke` job is automatically started: it runs the smoke QA suite. -You can also manually start the `review-qa-all`: it runs the full QA suite. +`review-qa-smoke` job is automatically started: it runs the QA smoke suite. +You can also manually start the `review-qa-all`: it runs the QA full suite. Note that both jobs first wait for the `review-deploy` job to be finished. diff --git a/doc/development/testing_guide/smoke.md b/doc/development/testing_guide/smoke.md index 3360031c220..30d861d7d68 100644 --- a/doc/development/testing_guide/smoke.md +++ b/doc/development/testing_guide/smoke.md @@ -7,13 +7,19 @@ functionality is working. Currently, our suite consists of this basic functionality coverage: -- User Login (Standard Auth) -- Project Creation -- Issue Creation -- Merge Request Creation +- User standard authentication +- SSH Key creation and addition to a user +- Project simple creation +- Project creation with Auto-DevOps enabled +- Issue creation +- Merge Request creation +- Snippet creation Smoke tests have the `:smoke` RSpec metadata. +See [End-to-end Testing](./end_to_end_tests.md) for more details about +end-to-end tests. + --- [Return to Testing documentation](index.md) diff --git a/doc/development/testing_guide/testing_levels.md b/doc/development/testing_guide/testing_levels.md index 5d46833a1e2..352651fe91b 100644 --- a/doc/development/testing_guide/testing_levels.md +++ b/doc/development/testing_guide/testing_levels.md @@ -160,7 +160,7 @@ Every new feature should come with a [test plan]. > See [end-to-end tests](end_to_end_tests.md) for more information. Note that `qa/spec` contains unit tests of the QA framework itself, not to be -confused with the application's [unit tests](#unit-tests) or +confused with the application's [unit tests](#unit-tests) or [end-to-end tests](#black-box-tests-at-the-system-level-aka-end-to-end-tests). [multiple pieces]: ../architecture.md#components @@ -234,6 +234,8 @@ you should write an integration test using Jasmine. [big]: https://twitter.com/timbray/status/822470746773409794 [picture]: https://twitter.com/withzombies/status/829716565834752000 [tests-cost]: https://medium.com/table-xi/high-cost-tests-and-high-value-tests-a86e27a54df#.2ulyh3a4e +[RSpec]: https://github.com/rspec/rspec-rails#feature-specs +[Capybara]: https://github.com/teamcapybara/capybara --- diff --git a/doc/development/ux_guide/users.md b/doc/development/ux_guide/users.md index 11bac11257c..3aecbbffd73 100644 --- a/doc/development/ux_guide/users.md +++ b/doc/development/ux_guide/users.md @@ -1,5 +1,5 @@ --- -redirect_to: 'https://design.gitlab.com/getting-started/personas/' +redirect_to: 'https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/' --- -The content of this document was moved into the [GitLab Design System](https://design.gitlab.com/). +This document was moved to [another location](https://about.gitlab.com/handbook/marketing/product-marketing/roles-personas/). |