| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
| |
Took it from https://gitlab.com/gitlab-com/www-gitlab-com/merge_requests/3232
[ci skip]
|
| |\
| |
| |
| |
| |
| |
| | |
Add Approve and Remove approval to UX Guide terminology table
Updating UX Guide page on terminology to include guidance on 'Approve' and 'Remove approval'.
See merge request !7632
|
| | | |
|
| |\ \
| |/
|/|
| |
| |
| |
| |
| |
| | |
Object state models docs
Object state models docs for issues and merge requests.
This is to start documenting object models, focused more on users and how they experience the product.
See merge request !7544
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |/
|
|
|
|
|
|
| |
This would fix long standing failures running tests on
my development machine, which set `Gitlab.config.gitlab.host`
to another host because it's not my local computer. Now I
finally cannot withstand it and decided to fix them once and
for all.
|
| |
|
|
|
|
|
|
|
|
| |
Update examples and labels to use sentence case.
Update copy.md [ci skip]
Update copy.md [ci skip]
Update copy.md
|
| |\
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Decide on and document a convention for singletons
> The singleton pattern is a design pattern that restricts the instantiation of a class to one object. This is useful when exactly one object is needed to coordinate actions across the system.
The simplest implementation uses an object literal to contain the logic.
```javascript
gl.MyThing = {
prop1: 'hello',
method1: () => {}
};
```
A live example of this is [GfmAutoComplete](https://gitlab.com/gitlab-org/gitlab-ce/blob/172aab108b875e8dc9a5f1d3c2d53018eff76ea1/app/assets/javascripts/gfm_auto_complete.js.es6)
Another approach makes use of ES6 `class` syntax.
```javascript
let singleton;
class MyThing {
constructor() {
if (!singleton) {
singleton = this;
singleton.init();
}
return singleton;
}
init() {
this.prop1 = 'hello';
}
method1() {}
}
gl.MyThing = MyThing;
```
A live example of this is [Sidebar](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/sidebar.js.es6)
Another functional approach to define Singleton using `Javascript Revealing Module Pattern` is like below
```javascript
/**
* 1. It instantiates only a single object
* 2. It is safe – it keeps the reference to the singleton inside a variable, which lives inside a lexical closure, so it is not accessible by the outside world
* 3. It allows privacy – you can define all private methods of your singleton inside the lexical closure of the first module pattern
* 4. No this keyword trap (no wrong context referring)
* 5. No use of new keyword
* 6. Easy to write test code
*/
//
const Singleton = (function () {
// Instance stores a reference to the Singleton
var instance;
function init() {
// Singleton
// Private methods and variables
function privateMethod(){
console.log( "I am private" );
}
var privateVariable = "Im also private";
var privateRandomNumber = Math.random();
return {
// Public methods and variables
publicMethod: function () {
console.log( "The public can see me!" );
},
publicProperty: "I am also public",
getRandomNumber: function() {
return privateRandomNumber;
}
};
};
return {
// Get the Singleton instance if one exists
// or create one if it doesn't
getInstance: function () {
if ( !instance ) {
instance = init();
}
return instance;
}
};
})();
const singletonObj = Singleton.getInstance()
```
## Are there points in the code the reviewer needs to double check?
## What does this MR do?
Creates a space for discussion and contribution for interested devs.
## Why was this MR needed?
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [x] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [x] All builds are passing
(http://docs.gitlab.com/ce/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?
See merge request !6620
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
| |
| |
| | |
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
| |
| |
| |
| |
| | |
Related to https://gitlab.com/gitlab-org/gitlab-ce/issues/24341
Signed-off-by: Rémy Coutable <remy@rymai.me>
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Add new file for copy (messaging) guidelines
Update copy guidelines
Fix typo
Add forms to guidelines
Simplify Copy heading
Refine copy page. Add images and table
Fix toc link on Copy page
|
| | |
| |
| |
| | |
[ci skip]
|
| | |
| |
| |
| | |
[ci skip]
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Block out pages needed for ux_guide
Add resources stub to ux_guide home
Fill out principles and basics
Add TOC to basics
Move all of UI guide to new UX guide structure
Add first level structure on ux-guide pages
Add more details to buttons
Add button images. Update link on development
Renamed surfaces to templates. Add tooltip details
Update typography and icons on Basics page
Add images for color. First draft of voice and tone
Delete findings page
Refine pages. Fill out Surfaces pages
Clean up layout on basics, surfaces, features. Add anchorlinks and counts to components
Fill out components page
Add item title and system info block
Fill out Features page
Switch tooltip placement image
|
| | |
| |
| |
| | |
[ci skip]
|
| | |
| |
| |
| | |
[ci skip]
|
| | |
| |
| |
| | |
[ci skip]
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Fixups to "Round-robin repository storage"
## What does this MR do?
* Simplifies a method in application_settings.rb
* Correctly marks a migration as needing downtime
* Documents the requirement for renamed columns to be
## Are there points in the code the reviewer needs to double check?
Should any of these changes be split out? Ideally we'd get this into the same point release as !7273
## Why was this MR needed?
Post-facto review of !7273
## Screenshots (if relevant)
## Does this MR meet the acceptance criteria?
- [ ] [CHANGELOG](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/CHANGELOG.md) entry added
- [X] [Documentation created/updated](https://gitlab.com/gitlab-org/gitlab-ce/blob/master/doc/development/doc_styleguide.md)
- [X] API support added
- Tests
- [X] Added for this feature/bug
- [x] All builds are passing
- [X] Conform by the [merge request performance guides](http://docs.gitlab.com/ce/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] Branch has no merge conflicts with `master` (if it does - rebase it please)
- [X] [Squashed related commits together](https://git-scm.com/book/en/Git-Tools-Rewriting-History#Squashing-Commits)
## What are the relevant issue numbers?
Related to #24059
/cc @yorickpeterse @rspeicher
See merge request !7287
|
| | | | |
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | | |
Update rdoc to `~> 4.2`
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/2814
See merge request !7261
|
| | | |
| | |
| | |
| | |
| | | |
This was the only thing using the `sdoc` gem, which was blocking another
gem from updating.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Fix Docs links
This fixes some links in the docs to either be relative or to use HTTPS and docs.gitlab.com.
See merge request !7280
|
| | | | | |
|
| |/ / / |
|
| |/ /
| |
| |
| | |
[ci skip]
|
| | | |
|
| | |
| |
| |
| | |
[ci skip]
|
| |\ \
| | |
| | |
| | |
| | | |
Add a bin/changelog script and changelog documentation
See merge request !7098
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Add Rake task to create/repair GitLab Shell hooks symlinks
## What does this MR do?
Adds a Rake task wrapper around `gitlab-shell` `bin/create_hooks` script. This makes it easier for an administrator to repair hooks symlinks without worrying about where repository data is located, etc. Just run this task and it takes care of everything based on current configuration.
## Are there points in the code the reviewer needs to double check?
No.
## Why was this MR needed?
`bin/create_hooks` was not well-documented. It requires parameters specifying where repository data is located. It also needs to be run by the `git` user. Wrapping it in a Rake task allows us to take current configuration in to account and makes it easier on the administrator.
See merge request !5634
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | |
| | |
| | |
| | | |
Support for post deployment migrations
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/22133
See merge request !6572
|
| | |/
| |
| |
| |
| |
| |
| |
| | |
These are regular Rails migrations that are executed by default. A user
can opt-out of these migrations by setting an environment variable
during the deployment process.
Fixes gitlab-org/gitlab-ce#22133
|
