GitLab FOSS merge requestshttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests2017-10-04T16:10:49Zhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14614Add a GitLab QA test to ensure backups are created2017-10-04T16:10:49ZStan HuAdd a GitLab QA test to ensure backups are createdThis is a very basic test to ensure that the Rake task even creates a backup with `rake gitlab:backup:create`.
Start of gitlab-qa#22This is a very basic test to ensure that the Rake task even creates a backup with `rake gitlab:backup:create`.
Start of gitlab-qa#2210.1https://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14574WIP: Repo Editor Blob viewer2017-10-06T21:41:47Zusername-removed-502136WIP: Repo Editor Blob viewerBased on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13770Based on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1377010.1Douwe MaanDouwe Maanhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14570Improve internationalization docs2017-10-24T23:58:04ZJames RamsayImprove internationalization docs## What does this MR do?
Add more information about the process of internationalization and how community members can contribute.
- externalization (anyone)
- translation (anyone)
- proof reading (managed in CrowdIn)
- release (...## What does this MR do?
Add more information about the process of internationalization and how community members can contribute.
- externalization (anyone)
- translation (anyone)
- proof reading (managed in CrowdIn)
- release (managed in GitLab)10.1Achilleas PipinellisAchilleas Pipinellishttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14567WIP: Convert Icons in CI to SVG Sprite Icons2017-11-03T05:07:13ZTim ZallmannWIP: Convert Icons in CI to SVG Sprite Icons## What does this MR do?
It simply converts some of the icons to svg sprite icons.
## Are there points in the code the reviewer needs to double check?
Does everything look the same?
## Why was this MR needed?
To make ever...## What does this MR do?
It simply converts some of the icons to svg sprite icons.
## Are there points in the code the reviewer needs to double check?
Does everything look the same?
## Why was this MR needed?
To make everything faster and better with SVG Sprites
## Does this MR meet the acceptance criteria?
- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) added, if necessary
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/doc_styleguide.html)
- [ ] API support added
- [ ] Tests added for this feature/bug
- Review
- [ ] Has been reviewed by UX
- [ ] Has been reviewed by Frontend
- [ ] Has been reviewed by Backend
- [ ] Has been reviewed by Database
- [ ] Conform by the [merge request performance guides](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
#3623110.1Tim ZallmannTim Zallmannhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14528Move all API authentication code to APIGuard2017-10-25T00:07:40ZDouwe MaanMove all API authentication code to APIGuardDepends on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14525.Depends on https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14525.10.1Douwe MaanDouwe Maanhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14527WIP: Simplify ApplicationController ldap_security_check2017-09-27T16:28:41ZDouwe MaanWIP: Simplify ApplicationController ldap_security_check10.1Douwe MaanDouwe Maanhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14512WIP: Refactor the testing documentation and divide it into multiple pages2017-10-25T00:07:32Zusername-removed-128633WIP: Refactor the testing documentation and divide it into multiple pagesSee the general Documentation guidelines http://docs.gitlab.com/ce/development/doc_styleguide.html
## What does this MR do?
(briefly describe what this MR is about)
## Moving docs to a new location?
See the guidelines: http://docs.gi...See the general Documentation guidelines http://docs.gitlab.com/ce/development/doc_styleguide.html
## What does this MR do?
(briefly describe what this MR is about)
## Moving docs to a new location?
See the guidelines: http://docs.gitlab.com/ce/development/doc_styleguide.html#changing-document-location
- [ ] Make sure the old link is not removed and has its contents replaced with a link to the new location.
- [ ] Make sure internal links pointing to the document in question are not broken.
- [ ] Search and replace any links referring to old docs in GitLab Rails app, specifically under the `app/views/` directory.
- [ ] If working on CE, submit an MR to EE with the changes as well.10.1username-removed-128633username-removed-128633https://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14510Remove sidebar mini header.2017-10-05T16:47:05ZJacob SchatzRemove sidebar mini header.## What does this MR do?
Removes the tree panel header for now. Until we have new file and folder.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
## Screenshots (if relevant)
## ...## What does this MR do?
Removes the tree panel header for now. Until we have new file and folder.
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) added, if necessary
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/doc_styleguide.html)
- [ ] API support added
- [ ] Tests added for this feature/bug
- Review
- [ ] Has been reviewed by UX
- [ ] Has been reviewed by Frontend
- [ ] Has been reviewed by Backend
- [ ] Has been reviewed by Database
- [ ] Conform by the [merge request performance guides](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
See #3836310.1Jacob SchatzJacob Schatzhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14486Adjust display settings for MR widget source branch removal components2017-10-06T05:20:19Zusername-removed-408230Adjust display settings for MR widget source branch removal components## What does this MR do?
1. In the MR Widget, when user can't remove source branch, we hide the checkbox
1. In the MR Create/Edit View, when user can't remove source branch, we hide the checkbox
1. In the MR Widget, when the user ca...## What does this MR do?
1. In the MR Widget, when user can't remove source branch, we hide the checkbox
1. In the MR Create/Edit View, when user can't remove source branch, we hide the checkbox
1. In the MR Widget, when the user can't remove the source branch **and** the source branch will be removed, show a message in the MR Widget that says "Removes source branch".
1. Update existing specs and add new ones for the "Removes source branch" status message
1. Adds some logic to the spec helper method `mountComponent` to support passing plain Vue config objects
## Are there points in the code the reviewer needs to double check?
## Why was this MR needed?
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) added, if necessary
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/doc_styleguide.html)
- [ ] API support added
- [ ] Tests added for this feature/bug
- Review
- [ ] Has been reviewed by UX
- [ ] Has been reviewed by Frontend
- [ ] Has been reviewed by Backend
- [ ] Has been reviewed by Database
- [ ] Conform by the [merge request performance guides](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Closes #3326410.1https://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14479WIP: Prune unreferenced git LFS objects2017-10-06T16:43:16ZJames EJWIP: Prune unreferenced git LFS objects## What
Tracks LFS pointer blobs and uses these to remove LFS objects which are no longer referenced
## Why
When references to large files have been removed they shouldn't be kept around
## ReferenceChange approach
On push:
1. Store...## What
Tracks LFS pointer blobs and uses these to remove LFS objects which are no longer referenced
## Why
When references to large files have been removed they shouldn't be kept around
## ReferenceChange approach
On push:
1. Store the name and `newrev` of the updated ref (`000->abc master`)
2. Schedule worker to find new LFS pointers from that change
Update LfsPointer worker:
- Find new blobs by using `rev-list` to identify blobs in the branch which are not included in already processed refs.
- Limit list of processed refs to the latest for each ref name and to N latest overall to avoid handling thousands of refs.
- Clean up entries past the 100 most recent to avoid the table becoming too large
- Find new LFS pointers from those blobs and store them in the database
On Gc:
1. Ignore projects with reference changes to process
2. Ignore projects which havent't had existing pointers processed
3. Remove LfsPointers which no longer exist in the project
4. Remove LfsObjectProjects/LfsObjects which are no longer referenced by pointers
### Rational
The main trade off is memory+database space vs extra blob lookups on the NFS disk.
Storing the list of processed refs allows us to eliminate blobs in commits which have already been checked for LFS pointers. This also works for objects introduced by similar commits as any objects introduced by both `C` and and `C'` can be eliminated by `rev-list C' --not C --objects`. When a new branch is pushed only new objects are checked for the same reason.
This approach guarantees both that blob lookups are kept to a minimum, and that all pointers have been found by default. It holds that if all pushes / `RefrenceChange`s have been processed that all Lfs pointers have been found, making it safe to delete those which are in the database but no longer on disk. Without this there could be LfsObjects in a project for which we have found one pointer but not another, and end up deleting a LfsObjects which are still referenced by unfound pointers.
## ~~OldRev NewRev approach~~
<strike>
Instead of storing reference changes we could schedule the worker by passing `oldrev` and `newrev`. On initial push of a branch we'd check if it was the `default_branch` and scan all objects reachable from `newrev` for that branch or all objects reachable but not included in that branch for other pushes.
</strike>
<strike>
We might need to track if the default branch has been scanned in this approach, as well as being extremely careful with changes to the default branch. Failure to do so could result in additional pointers not having been added to the db, and consequently cause the LfsObject to be deleted when one known pointer is removed.
</strike>
<strike>
This approach would be simpler but can end up rescanning blobs for every push in some cases. See https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/14479#note_42252165
</strike>
<strike>
Additionally a mechanism would be needed to prevent garbage collection / cleanup while there are unprocessed pushes. This could be an exclusive lock around the push, or storing oldrev/newrev in the database temporarily in a similar manner to the `ReferenceChange` approach. The second scenario uses the database as a queue and would delete old records once processed. Either way, we’d need to be 100% sure that these actually get processed otherwise we’d end up deleting LFS objects.
</strike>
## Are there points in the code the reviewer needs to double check?
## Todo
- [ ] Find all pointers of first push
- [ ] Clean up `RecentLfsPush` entries past the 100 most recent to avoid the table becoming too large
- [ ] Mysql for finding 100 most recent refs
- [ ] Add indices for columns used in queries
- [x] Add database checklist
- [ ] Add performance testing plan to description (towards making a case why this won’t perform badly on production)
- [ ] Ping someone for Gitaly review
- [ ] Ping someone for database review
- [ ] Performance review
### Things I'll MR open discussions
- [ ] What happens if multiple pushes occur before/during first run? Would we have multiple workers scanning the whole project? Could we benefit from a lock around `UpdateLfsPointersWorker` per project?
- [x] `Gitlab::Git::Blob.batch_lfs_metadata` should bypass gitaly
- [ ] Better way to get all blobs? Possible to get all blobs within size range?
## Performance
TODO
Ideas:
- Generate 10,000s of LfsObjectProject, etc and test
- Set up test instance and find memory characteristics
- Add one LFS object to linux project and test it
- Lookup current count of LfsObjectProject items to find current scale
### Benchmarks
TODO
## Database checklist
For added migrations:
- [ ] Updated `db/schema.rb`
- [ ] Added a `down` method so the migration can be reverted
- [ ] Added the output of the migration(s) to the MR body
- [ ] Added the execution time of the migration(s) to the MR body
- [ ] Added tests for the migration in `spec/migrations` if necessary (e.g. when
migrating data)
- [ ] Made sure the migration won't interfere with a running GitLab cluster,
for example by disabling transactions for long running migrations
For added tables:
- [ ] Ordered columns based on their type sizes in descending order
- [ ] Added foreign keys if necessary
- [ ] Added indexes if necessary
- [ ] Described the need for these indexes in the MR body
- [ ] Made sure existing indexes can not be reused instead
For potentially slow queries:
- [ ] Included the raw SQL queries of the relevant queries
- [ ] Included the output of `EXPLAIN ANALYZE` and execution timings of the
relevant queries
## Acceptance criteria
- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) added, if necessary
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/doc_styleguide.html)
- [ ] Tests added for this feature/bug
- Review
- [ ] Has been reviewed by UX
- [ ] Has been reviewed by Frontend
- [ ] Has been reviewed by Backend
- [ ] Has been reviewed by Database
- [ ] Conform by the [merge request performance guides](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
## Related
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/3063910.1James EJJames EJhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14466Setting Unicorn Worker memory limit in gitlab.rb2017-09-26T00:52:17Zusername-removed-260236abuango@live.comSetting Unicorn Worker memory limit in gitlab.rbAdding more documentation about setting Unicorn Memory threshold. See: https://about.gitlab.com/2015/06/05/how-gitlab-uses-unicorn-and-unicorn-worker-killer/Adding more documentation about setting Unicorn Memory threshold. See: https://about.gitlab.com/2015/06/05/how-gitlab-uses-unicorn-and-unicorn-worker-killer/10.1username-removed-260236abuango@live.comusername-removed-260236abuango@live.comhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14439WIP: DRY and refactor CI/CD Variables2017-10-05T11:50:29ZGrzegorz BizonWIP: DRY and refactor CI/CD Variables## What does this MR do?
This MR refactors how we handle CI/CD Variables collections.
## Why was this MR needed?
We have a lot of duplication regarding CI/CD variables what causes some problems and productivity loss.
## Does ...## What does this MR do?
This MR refactors how we handle CI/CD Variables collections.
## Why was this MR needed?
We have a lot of duplication regarding CI/CD variables what causes some problems and productivity loss.
## Does this MR meet the acceptance criteria?
- [ ] Tests added for this feature/bug
- [ ] Has been reviewed by Backend
## What are the relevant issue numbers?
Related gitlab-org/gitlab-ce#3304210.1https://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14375lossless image optimization2017-10-05T13:51:15Zusername-removed-1118608lossless image optimizationthis is a replacement for https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/13857this is a replacement for https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/1385710.1Jacob SchatzJacob Schatzhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14344Move metrics library to index.md to generate the proper breadcrumbs - docs2017-09-26T08:35:18ZJoshua LambertMove metrics library to index.md to generate the proper breadcrumbs - docsMoves the Prometheus Metric Library documentation to `index.html` and links back from old location.
Closes #38009Moves the Prometheus Metric Library documentation to `index.html` and links back from old location.
Closes #3800910.1Joshua LambertJoshua Lamberthttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14337Use gitlab-styles which provides shared RuboCop config and cops2017-09-19T16:27:21Zusername-removed-128633Use gitlab-styles which provides shared RuboCop config and cops## What does this MR do?
This uses https://gitlab.com/gitlab-org/gitlab-styles which includes a shared RuboCop config and custom cops that can be reused by multiple projects.
Will allow to solve #37711.
## Are there points in the code...## What does this MR do?
This uses https://gitlab.com/gitlab-org/gitlab-styles which includes a shared RuboCop config and custom cops that can be reused by multiple projects.
Will allow to solve #37711.
## Are there points in the code the reviewer needs to double check?
We can still define custom cops as before, and regularly migrate them to the gem if this is more practical (or for testing/debugging purpose).
## Why was this MR needed?
So that we can avoid duplicating our RuboCop config and custop cops.
## Does this MR meet the acceptance criteria?
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/doc_styleguide.html)
- Review
- [ ] Has been reviewed by Backend
- [ ] Conform by the [merge request performance guides](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?10.1username-removed-128633username-removed-128633https://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14308Include the changes in issuable webhook payloads2017-10-25T00:00:24Zusername-removed-128633Include the changes in issuable webhook payloads## What does this MR do?
This adds a `changes` key to the issuable webhook payloads, e.g.:
```json
"changes": {
"updated_by_id": {
"previous": null,
"current": 1
},
"updated_at": {
"previous":...## What does this MR do?
This adds a `changes` key to the issuable webhook payloads, e.g.:
```json
"changes": {
"updated_by_id": {
"previous": null,
"current": 1
},
"updated_at": {
"previous": "2017-09-15 16:50:55 UTC",
"current": "2017-09-15 16:52:00 UTC"
},
"labels": {
"previous": [{
"id": 206,
"title": "API",
"color": "#ffffff",
"project_id": 14,
"created_at": "2013-12-03T17:15:43Z",
"updated_at": "2013-12-03T17:15:43Z",
"template": false,
"description": "API related issues",
"type": "ProjectLabel",
"group_id": 41
}],
"current": [{
"id": 205,
"title": "Platform",
"color": "#123123",
"project_id": 14,
"created_at": "2013-12-03T17:15:43Z",
"updated_at": "2013-12-03T17:15:43Z",
"template": false,
"description": "Platform related issues",
"type": "ProjectLabel",
"group_id": 41
}]
}
}
```
## Are there points in the code the reviewer needs to double check?
1. I've decided to always include the `assignees` key since issues and merge requests respond to it, and because MR will soon support multiple assignees, so it doesn't hurt to start returning `assignees` for MR too. The `assignee` key is still present for MR, but deprecated.
1. In the new `changes` hash, I only included `assignees` (no `assignee`) since there is no back-compat to keep here).
## Why was this MR needed?
Because some projects need this, see #34284.
## Does this MR meet the acceptance criteria?
- [x] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) added, if necessary
- [x] [Documentation created/updated](https://docs.gitlab.com/ee/development/doc_styleguide.html)
- [x] Tests added for this feature/bug
- Review
- [ ] Has been reviewed by Backend
- [ ] Has been reviewed by Database
- [x] Conform by the [merge request performance guides](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [x] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [x] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Closes #3428410.1username-removed-128633username-removed-128633https://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14290Upload img dimensions2017-09-28T14:44:12ZTim ZallmannUpload img dimensions## What does this MR do?
It improves the lazy loading experience for future uploads.
* If it is an image it takes from dropzone.js the image width + height and appends it to the URL as request parameters
* Markdown Lazy Image L...## What does this MR do?
It improves the lazy loading experience for future uploads.
* If it is an image it takes from dropzone.js the image width + height and appends it to the URL as request parameters
* Markdown Lazy Image Load Transformer is enhanced to look out for the query parameters + sets then the JS based on this
## Are there points in the code the reviewer needs to double check?
* Ninja CSS for keeping the size in the aspect ratio
## Why was this MR needed?
* So that the transition while loading a lazy image is smoother, this is done by setting the size already on image placeholder which makes it much smoother during loading.
## Does this MR meet the acceptance criteria?
- [ ] [Changelog entry](https://docs.gitlab.com/ee/development/changelog.html) added, if necessary
- [ ] [Documentation created/updated](https://docs.gitlab.com/ee/development/doc_styleguide.html)
- [ ] API support added
- [ ] Tests added for this feature/bug
- Review
- [ ] Has been reviewed by UX
- [ ] Has been reviewed by Frontend
- [ ] Has been reviewed by Backend
- [ ] Has been reviewed by Database
- [ ] Conform by the [merge request performance guides](https://docs.gitlab.com/ee/development/merge_request_performance_guidelines.html)
- [ ] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [ ] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?10.1Tim ZallmannTim Zallmannhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14287Kubernetes CPU metrics should number of cores2017-09-15T04:42:52ZJoshua LambertKubernetes CPU metrics should number of cores
Closes #37895
Closes #3789510.1https://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14271Cleanup Deployments table2017-09-28T11:26:08ZZeger-Jan van de Wegzegerjan@gitlab.comCleanup Deployments table## Does this MR meet the acceptance criteria?
- [X] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added, if necessary
- [-] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/d...## Does this MR meet the acceptance criteria?
- [X] [Changelog entry](https://docs.gitlab.com/ce/development/changelog.html) added, if necessary
- [-] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [-] API support added
- [-] Tests added for this feature/bug
- Review
- [-] Has been reviewed by UX
- [-] Has been reviewed by Frontend
- [-] Has been reviewed by Backend
- [ ] Has been reviewed by Database
- [-] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/development/merge_request_performance_guidelines.html)
- [-] Conform by the [style guides](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CONTRIBUTING.md#style-guides)
- [-] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Part of gitlab-org/gitlab-ce#31803 (Skipped changes that required the application to change)10.1Zeger-Jan van de Wegzegerjan@gitlab.comZeger-Jan van de Wegzegerjan@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/14229WIP: Add alerts to doc styleguide2017-09-19T11:56:19ZAchilleas PipinellisWIP: Add alerts to doc styleguide## What does this MR do?
Add alerts styleguide now that the docs site supports them. See https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/133.
Review App: http://docs-alerts-styleguide-built-from-ce-ee.178.62.207.141.xip.io...## What does this MR do?
Add alerts styleguide now that the docs site supports them. See https://gitlab.com/gitlab-com/gitlab-docs/merge_requests/133.
Review App: http://docs-alerts-styleguide-built-from-ce-ee.178.62.207.141.xip.io/ce/development/doc_styleguide.html#alerts10.1Achilleas PipinellisAchilleas Pipinellis