mirror of
https://github.com/wahyd4/gitlabhq.git
synced 2026-08-09 04:36:11 +10:00
Fix a number of discovered typos, capitalization of developer and
product names, plus a couple of instances of bad Markdown markup.
This commit is contained in:
Ewan Edwards
+1
-1
@@ -56,7 +56,7 @@ Parameters:
|
||||
"title": "v1.0",
|
||||
"description": "",
|
||||
"due_date": "2012-07-20",
|
||||
"state": "reopenend",
|
||||
"state": "reopened",
|
||||
"updated_at": "2012-07-04T13:42:48Z",
|
||||
"created_at": "2012-07-04T13:42:48Z"
|
||||
},
|
||||
|
||||
+3
-3
@@ -4,7 +4,7 @@ OAuth2 is a protocol that enables us to get access to private details of user's
|
||||
|
||||
Before using the OAuth2 you should create an application in user's account. Each application getting unique App ID and App Secret parameters. You should not share them.
|
||||
|
||||
This functianolity is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper)
|
||||
This functionality is based on [doorkeeper gem](https://github.com/doorkeeper-gem/doorkeeper)
|
||||
|
||||
## Web Application Flow
|
||||
|
||||
@@ -15,7 +15,7 @@ This flow consists from 3 steps.
|
||||
|
||||
### 1. Registering the client
|
||||
|
||||
Creat an application in user's account profile.
|
||||
Create an application in user's account profile.
|
||||
|
||||
### 2. Requesting authorization
|
||||
|
||||
@@ -96,4 +96,4 @@ For testing you can use the oauth2 ruby gem:
|
||||
client = OAuth2::Client.new('the_client_id', 'the_client_secret', :site => "http://example.com")
|
||||
access_token = client.password.get_token('user@example.com', 'sekret')
|
||||
puts access_token.token
|
||||
```
|
||||
```
|
||||
|
||||
+1
-1
@@ -541,7 +541,7 @@ Parameters:
|
||||
}
|
||||
],
|
||||
"tree": "c68537c6534a02cc2b176ca1549f4ffa190b58ee",
|
||||
"message": "give caolan credit where it's due (up top)",
|
||||
"message": "give Caolan credit where it's due (up top)",
|
||||
"author": {
|
||||
"name": "Jeremy Ashkenas",
|
||||
"email": "jashkenas@example.com"
|
||||
|
||||
+7
-7
@@ -23,23 +23,23 @@ Delete GitLab CI service settings for a project.
|
||||
DELETE /projects/:id/services/gitlab-ci
|
||||
```
|
||||
|
||||
## Hipchat
|
||||
## HipChat
|
||||
|
||||
### Edit Hipchat service
|
||||
### Edit HipChat service
|
||||
|
||||
Set Hipchat service for project.
|
||||
Set HipChat service for project.
|
||||
|
||||
```
|
||||
PUT /projects/:id/services/hipchat
|
||||
```
|
||||
Parameters:
|
||||
|
||||
- `token` (required) - Hipchat token
|
||||
- `room` (required) - Hipchat room name
|
||||
- `token` (required) - HipChat token
|
||||
- `room` (required) - HipChat room name
|
||||
|
||||
### Delete Hipchat service
|
||||
### Delete HipChat service
|
||||
|
||||
Delete Hipchat service for a project.
|
||||
Delete HipChat service for a project.
|
||||
|
||||
```
|
||||
DELETE /projects/:id/services/hipchat
|
||||
|
||||
@@ -16,8 +16,8 @@ You can imagine GitLab as a physical office.
|
||||
They can be stored in a warehouse.
|
||||
This can be either a hard disk, or something more complex, such as a NFS filesystem;
|
||||
|
||||
**NginX** acts like the front-desk.
|
||||
Users come to NginX and request actions to be done by workers in the office;
|
||||
**Nginx** acts like the front-desk.
|
||||
Users come to Nginx and request actions to be done by workers in the office;
|
||||
|
||||
**The database** is a series of metal file cabinets with information on:
|
||||
- The goods in the warehouse (metadata, issues, merge requests etc);
|
||||
@@ -70,7 +70,7 @@ To summarize here's the [directory structure of the `git` user home directory](.
|
||||
|
||||
ps aux | grep '^git'
|
||||
|
||||
GitLab has several components to operate. As a system user (i.e. any user that is not the `git` user) it requires a persistent database (MySQL/PostreSQL) and redis database. It also uses Apache httpd or nginx to proxypass Unicorn. As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server running on port `8080` by default). Under the GitLab user there are normally 4 processes: `unicorn_rails master` (1 process), `unicorn_rails worker` (2 processes), `sidekiq` (1 process).
|
||||
GitLab has several components to operate. As a system user (i.e. any user that is not the `git` user) it requires a persistent database (MySQL/PostreSQL) and redis database. It also uses Apache httpd or Nginx to proxypass Unicorn. As the `git` user it starts Sidekiq and Unicorn (a simple ruby HTTP server running on port `8080` by default). Under the GitLab user there are normally 4 processes: `unicorn_rails master` (1 process), `unicorn_rails worker` (2 processes), `sidekiq` (1 process).
|
||||
|
||||
### Repository access
|
||||
|
||||
@@ -146,13 +146,13 @@ nginx
|
||||
|
||||
Apache httpd
|
||||
|
||||
- [Explanation of apache logs](http://httpd.apache.org/docs/2.2/logs.html).
|
||||
- [Explanation of Apache logs](http://httpd.apache.org/docs/2.2/logs.html).
|
||||
- `/var/log/apache2/` contains error and output logs (on Ubuntu).
|
||||
- `/var/log/httpd/` contains error and output logs (on RHEL).
|
||||
|
||||
redis
|
||||
|
||||
- `/var/log/redis/redis.log` there are also logrotated logs there.
|
||||
- `/var/log/redis/redis.log` there are also log-rotated logs there.
|
||||
|
||||
PostgreSQL
|
||||
|
||||
|
||||
@@ -26,7 +26,7 @@ We use [these build scripts](https://gitlab.com/gitlab-org/gitlab-ci/blob/master
|
||||
# Build configuration on [Semaphore](https://semaphoreapp.com/gitlabhq/gitlabhq/) for testing the [GitHub.com repo](https://github.com/gitlabhq/gitlabhq)
|
||||
|
||||
- Language: Ruby
|
||||
- Ruby verion: 2.1.2
|
||||
- Ruby version: 2.1.2
|
||||
- database.yml: pg
|
||||
|
||||
Build commands
|
||||
|
||||
@@ -7,7 +7,7 @@
|
||||
- Ubuntu
|
||||
- Debian
|
||||
- CentOS
|
||||
- RedHat Enterprise Linux (please use the CentOS packages and instructions)
|
||||
- Red Hat Enterprise Linux (please use the CentOS packages and instructions)
|
||||
- Scientific Linux (please use the CentOS packages and instructions)
|
||||
- Oracle Linux (please use the CentOS packages and instructions)
|
||||
|
||||
|
||||
@@ -13,7 +13,7 @@ Jenkins support is [available in GitLab EE](http://doc.gitlab.com/ee/integration
|
||||
|
||||
## Project services
|
||||
|
||||
Integration with services such as Campfire, Flowdock, Gemnasium, HipChat, PivotalTracker and Slack are available in the from of a Project Service.
|
||||
Integration with services such as Campfire, Flowdock, Gemnasium, HipChat, Pivotal Tracker, and Slack are available in the form of a Project Service.
|
||||
You can find these within GitLab in the Services page under Project Settings if you are at least a master on the project.
|
||||
Project Services are a bit like plugins in that they allow a lot of freedom in adding functionality to GitLab, for example there is also a service that can send an email every time someone pushes new commits.
|
||||
Because GitLab is open source we can ship with the code and tests for all plugins.
|
||||
|
||||
@@ -6,7 +6,7 @@ GitLab has a great issue tracker but you can also use an external issue tracker
|
||||
- clicking 'New issue' on the project dashboard creates a new JIRA issue;
|
||||
- To reference JIRA issue PROJECT-1234 in comments, use syntax PROJECT-1234. Commit messages get turned into HTML links to the corresponding JIRA issue.
|
||||
|
||||
|
||||
|
||||
|
||||
You can configure the integration in the gitlab.yml configuration file.
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# GitLab buttons in gmail
|
||||
# GitLab buttons in Gmail
|
||||
|
||||
GitLab supports [Google actions in email](https://developers.google.com/gmail/markup/actions/actions-overview).
|
||||
|
||||
@@ -25,4 +25,4 @@ If you receive "No errors detected" message from the tester you can send the ema
|
||||
|
||||
```bash
|
||||
bundle exec rake gitlab:mail_google_schema_whitelisting RAILS_ENV=production SEND=true
|
||||
``
|
||||
```
|
||||
|
||||
@@ -2,7 +2,7 @@
|
||||
|
||||
This documentation is for enabling shibboleth with gitlab-omnibus package.
|
||||
|
||||
In order to enable Shibboleth support in gitlab we need to use Apache instead of Nginx (It may be possible to use Nginx, however I did not found way to easily configure nginx that is bundled in gitlab-omnibus package). Apache uses mod_shib2 module for shibboleth authentication and can pass attributes as headers to omniauth-shibboleth provider.
|
||||
In order to enable Shibboleth support in gitlab we need to use Apache instead of Nginx (It may be possible to use Nginx, however I did not found way to easily configure Nginx that is bundled in gitlab-omnibus package). Apache uses mod_shib2 module for shibboleth authentication and can pass attributes as headers to omniauth-shibboleth provider.
|
||||
|
||||
|
||||
To enable the Shibboleth OmniAuth provider you must:
|
||||
@@ -10,7 +10,7 @@ To enable the Shibboleth OmniAuth provider you must:
|
||||
1. Configure Apache shibboleth module. Installation and configuration of module it self is out of scope of this document.
|
||||
Check https://wiki.shibboleth.net/ for more info.
|
||||
|
||||
1. You can find Apache config in gitlab-reciepes (https://github.com/gitlabhq/gitlab-recipes/blob/master/web-server/apache/gitlab-ssl.conf)
|
||||
1. You can find Apache config in gitlab-recipes (https://github.com/gitlabhq/gitlab-recipes/blob/master/web-server/apache/gitlab-ssl.conf)
|
||||
|
||||
Following changes are needed to enable shibboleth:
|
||||
|
||||
@@ -34,7 +34,7 @@ protect omniauth-shibboleth callback URL:
|
||||
```
|
||||
exclude shibboleth URLs from rewriting, add "RewriteCond %{REQUEST_URI} !/Shibboleth.sso" and "RewriteCond %{REQUEST_URI} !/shibboleth-sp", config should look like this:
|
||||
```
|
||||
#apache equivalent of nginx try files
|
||||
# Apache equivalent of Nginx try files
|
||||
RewriteEngine on
|
||||
RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
|
||||
RewriteCond %{REQUEST_URI} !/Shibboleth.sso
|
||||
@@ -50,7 +50,7 @@ File it should look like this:
|
||||
external_url 'https://gitlab.example.com'
|
||||
gitlab_rails['internal_api_url'] = 'https://gitlab.example.com'
|
||||
|
||||
# disable nginx
|
||||
# disable Nginx
|
||||
nginx['enable'] = false
|
||||
|
||||
gitlab_rails['omniauth_allow_single_sign_on'] = true
|
||||
|
||||
@@ -6,7 +6,7 @@
|
||||
|
||||
* [Newlines](#newlines)
|
||||
* [Multiple underscores in words](#multiple-underscores-in-words)
|
||||
* [URL autolinking](#url-autolinking)
|
||||
* [URL auto-linking](#url-autolinking)
|
||||
* [Code and Syntax Highlighting](#code-and-syntax-highlighting)
|
||||
* [Emoji](#emoji)
|
||||
* [Special GitLab references](#special-gitlab-references)
|
||||
@@ -40,7 +40,7 @@ You can use GFM in
|
||||
- milestones
|
||||
- wiki pages
|
||||
|
||||
You can also use other rich text files in GitLab. You might have to install a depency to do so. Please see the [github-markup gem readme](https://github.com/gitlabhq/markup#markups) for more information.
|
||||
You can also use other rich text files in GitLab. You might have to install a dependency to do so. Please see the [github-markup gem readme](https://github.com/gitlabhq/markup#markups) for more information.
|
||||
|
||||
## Newlines
|
||||
|
||||
@@ -68,7 +68,7 @@ It is not reasonable to italicize just _part_ of a word, especially when you're
|
||||
perform_complicated_task
|
||||
do_this_and_do_that_and_another_thing
|
||||
|
||||
## URL autolinking
|
||||
## URL auto-linking
|
||||
|
||||
GFM will autolink standard URLs you copy and paste into your text. So if you want to link to a URL (instead of a textural link), you can simply put the URL in verbatim and it will be turned into a link to that URL.
|
||||
|
||||
|
||||
@@ -4,16 +4,16 @@ __Project integrations with external services for continuous integration and mor
|
||||
|
||||
## Services
|
||||
|
||||
- Assemblia
|
||||
- [Atlassian Bamboo CI](bamboo.md) An Atlassian product for continous integration.
|
||||
- Assembla
|
||||
- [Atlassian Bamboo CI](bamboo.md) An Atlassian product for continuous integration.
|
||||
- Build box
|
||||
- Campfire
|
||||
- Emails on push
|
||||
- Flowdock
|
||||
- Gemnasium
|
||||
- GitLab CI
|
||||
- Hipchat
|
||||
- PivotalTracker
|
||||
- HipChat
|
||||
- Pivotal Tracker
|
||||
- Pushover
|
||||
- Slack
|
||||
- TeamCity
|
||||
- TeamCity
|
||||
|
||||
@@ -214,19 +214,19 @@ This is recommended to reduce cron spam.
|
||||
If your GitLab server contains a lot of Git repository data you may find the GitLab backup script to be too slow.
|
||||
In this case you can consider using filesystem snapshots as part of your backup strategy.
|
||||
|
||||
Example: Amazone EBS
|
||||
Example: Amazon EBS
|
||||
|
||||
> A GitLab server using omnibus-gitlab hosted on Amazon AWS.
|
||||
> An EBS drive containing an ext4 filesystem is mounted at `/var/opt/gitlab`.
|
||||
> In this case you could make an application backup by taking an EBS snapshot.
|
||||
> The backup includes all repositories, uploads and Postgres data.
|
||||
|
||||
Example: LVM snapshots + Rsync
|
||||
Example: LVM snapshots + rsync
|
||||
|
||||
> A GitLab server using omnibus-gitlab, with an LVM logical volume mounted at `/var/opt/gitlab`.
|
||||
> Replicating the `/var/opt/gitlab` directory usign Rsync would not be reliable because too many files would change while Rsync is running.
|
||||
> Replicating the `/var/opt/gitlab` directory using rsync would not be reliable because too many files would change while rsync is running.
|
||||
> Instead of rsync-ing `/var/opt/gitlab`, we create a temporary LVM snapshot, which we mount as a read-only filesystem at `/mnt/gitlab_backup`.
|
||||
> Now we can have a longer running Rsync job which will create a consistent replica on the remote server.
|
||||
> Now we can have a longer running rsync job which will create a consistent replica on the remote server.
|
||||
> The replica includes all repositories, uploads and Postgres data.
|
||||
|
||||
If you are running GitLab on a virtualized server you can possibly also create VM snapshots of the entire GitLab server.
|
||||
|
||||
@@ -104,7 +104,7 @@ bundle exec rake release["x.x.0.rc1"]
|
||||
```
|
||||
|
||||
Now developers can use master for merging new features.
|
||||
So you should use stable branch for future code chages related to release.
|
||||
So you should use stable branch for future code changes related to release.
|
||||
|
||||
|
||||
### 5. Release GitLab CI RC1
|
||||
|
||||
@@ -207,7 +207,7 @@ __3. Tweet to blog__
|
||||
Send out a tweet to share the good news with the world.
|
||||
List the most important features and link to the blog post.
|
||||
|
||||
Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE <link-to-blogpost> #gitlab"
|
||||
Proposed tweet "Release of GitLab X.X & CI Y.Y! FEATURE, FEATURE and FEATURE <link-to-blog-post> #gitlab"
|
||||
|
||||
Consider creating a post on Hacker News.
|
||||
|
||||
|
||||
@@ -4,6 +4,6 @@ Git is a distributed version control system (DVCS).
|
||||
This means that everyone that works with the source code has a local copy of the complete repository.
|
||||
In GitLab every project member that is not a guest (so reporters, developers and masters) can clone the repository to get a local copy.
|
||||
After obtaining this local copy the user can upload the full repository anywhere, including another project under their control or another server.
|
||||
The consequense is that you can't build access controls that prevent the intentional sharing of source code by users that have access to the source code.
|
||||
The consequence is that you can't build access controls that prevent the intentional sharing of source code by users that have access to the source code.
|
||||
This is an inherent feature of a DVCS and all git management systems have this limitation.
|
||||
Obviously you can take steps to prevent unintentional sharing and information destruction, this is why only some people are allowed to invite others and nobody can force push a protected branch.
|
||||
|
||||
@@ -15,8 +15,8 @@ System hooks can be used, e.g. for logging or changing information in a LDAP ser
|
||||
"name": "StoreCloud",
|
||||
"owner_email": "johnsmith@gmail.com",
|
||||
"owner_name": "John Smith",
|
||||
"path": "stormcloud",
|
||||
"path_with_namespace": "jsmith/stormcloud",
|
||||
"path": "storecloud",
|
||||
"path_with_namespace": "jsmith/storecloud",
|
||||
"project_id": 74,
|
||||
"project_visibility": "private",
|
||||
}
|
||||
@@ -126,10 +126,10 @@ System hooks can be used, e.g. for logging or changing information in a LDAP ser
|
||||
{
|
||||
"created_at": "2012-07-21T07:30:54Z",
|
||||
"event_name": "group_create",
|
||||
"name": "StormCloud",
|
||||
"name": "StoreCloud",
|
||||
"owner_email": "johnsmith@gmail.com",
|
||||
"owner_name": "John Smith",
|
||||
"path": "stormcloud",
|
||||
"path": "storecloud",
|
||||
"group_id": 78
|
||||
}
|
||||
```
|
||||
|
||||
@@ -22,29 +22,29 @@ sudo -u gitlab bundle exec rake db:migrate RAILS_ENV=production
|
||||
# !!! Config should be replaced with a new one. Check it after replace
|
||||
cp config/gitlab.yml.example config/gitlab.yml
|
||||
|
||||
# update gitolite hooks
|
||||
# update Gitolite hooks
|
||||
|
||||
# GITOLITE v2:
|
||||
# Gitolite v2:
|
||||
sudo cp ./lib/hooks/post-receive /home/git/share/gitolite/hooks/common/post-receive
|
||||
sudo chown git:git /home/git/share/gitolite/hooks/common/post-receive
|
||||
|
||||
# GITOLITE v3:
|
||||
# Gitolite v3:
|
||||
sudo cp ./lib/hooks/post-receive /home/git/.gitolite/hooks/common/post-receive
|
||||
sudo chown git:git /home/git/.gitolite/hooks/common/post-receive
|
||||
|
||||
# set valid path to hooks in gitlab.yml in git_host section
|
||||
# like this
|
||||
git_host:
|
||||
# gitolite 2
|
||||
# Gitolite 2
|
||||
hooks_path: /home/git/share/gitolite/hooks
|
||||
# gitolite 3
|
||||
# Gitolite 3
|
||||
hooks_path: /home/git/.gitolite/hooks/
|
||||
|
||||
|
||||
# Make some changes to gitolite config
|
||||
# Make some changes to Gitolite config
|
||||
# For more information visit https://github.com/gitlabhq/gitlabhq/pull/1719
|
||||
|
||||
# gitolite v2
|
||||
# Gitolite v2
|
||||
sudo -u git -H sed -i 's/\(GL_GITCONFIG_KEYS\s*=>*\s*\).\{2\}/\\1"\.\*"/g' /home/git/.gitolite.rc
|
||||
|
||||
# gitlite v3
|
||||
|
||||
@@ -111,7 +111,7 @@ sudo chmod -R u+rwX /home/git/gitlab/tmp/pids
|
||||
|
||||
```
|
||||
|
||||
## 6. Update init.d script and nginx config
|
||||
## 6. Update init.d script and Nginx config
|
||||
|
||||
```bash
|
||||
# init.d
|
||||
@@ -123,7 +123,7 @@ sudo chmod +x /etc/init.d/gitlab
|
||||
sudo -u git -H cp /home/git/gitlab/config/unicorn.rb /home/git/gitlab/config/unicorn.rb.old
|
||||
sudo -u git -H cp /home/git/gitlab/config/unicorn.rb.example /home/git/gitlab/config/unicorn.rb
|
||||
|
||||
#nginx
|
||||
# Nginx
|
||||
# Replace path from '/home/gitlab/' to '/home/git/'
|
||||
sudo vim /etc/nginx/sites-enabled/gitlab
|
||||
sudo service nginx restart
|
||||
@@ -137,7 +137,7 @@ sudo service gitlab start
|
||||
|
||||
# check if unicorn and sidekiq started
|
||||
# If not try to logout, also check replaced path from '/home/gitlab/' to '/home/git/'
|
||||
# in nginx, unicorn, init.d etc
|
||||
# in Nginx, unicorn, init.d etc
|
||||
ps aux | grep unicorn
|
||||
ps aux | grep sidekiq
|
||||
|
||||
|
||||
@@ -40,7 +40,7 @@ sudo -u git -H bundle exec rake gitlab:backup:create RAILS_ENV=production
|
||||
|
||||
The migrations in this update are very sensitive to incomplete or inconsistent data. If you have a long-running GitLab installation and some of the previous upgrades did not work out 100% correct this may bite you now. The following can help you have a more smooth upgrade.
|
||||
|
||||
### Find projets with invalid project names
|
||||
### Find projects with invalid project names
|
||||
|
||||
#### MySQL
|
||||
Login to MySQL:
|
||||
|
||||
@@ -35,7 +35,7 @@ sudo -u git -H git checkout v1.7.9 # Addresses multiple critical security vulner
|
||||
## 4. Install additional packages
|
||||
|
||||
```bash
|
||||
# Add support for lograte for better log file handling
|
||||
# Add support for logrotate for better log file handling
|
||||
sudo apt-get install logrotate
|
||||
```
|
||||
|
||||
|
||||
@@ -84,7 +84,7 @@ sudo -u git -H git checkout 7-7-stable-ee
|
||||
## 4. Install additional packages
|
||||
|
||||
```bash
|
||||
# Add support for lograte for better log file handling
|
||||
# Add support for logrotate for better log file handling
|
||||
sudo apt-get install logrotate
|
||||
|
||||
# Install pkg-config and cmake, which is needed for the latest versions of rugged
|
||||
@@ -217,13 +217,13 @@ mysql -u root -p
|
||||
# Convert all tables to use the InnoDB storage engine (added in GitLab 6.8)
|
||||
SELECT CONCAT('ALTER TABLE gitlabhq_production.', table_name, ' ENGINE=InnoDB;') AS 'Copy & run these SQL statements:' FROM information_schema.tables WHERE table_schema = 'gitlabhq_production' AND `ENGINE` <> 'InnoDB' AND `TABLE_TYPE` = 'BASE TABLE';
|
||||
|
||||
# If previous query returned results, copy & run all outputed SQL statements
|
||||
# If previous query returned results, copy & run all shown SQL statements
|
||||
|
||||
# Convert all tables to correct character set
|
||||
SET foreign_key_checks = 0;
|
||||
SELECT CONCAT('ALTER TABLE gitlabhq_production.', table_name, ' CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;') AS 'Copy & run these SQL statements:' FROM information_schema.tables WHERE table_schema = 'gitlabhq_production' AND `TABLE_COLLATION` <> 'utf8_unicode_ci' AND `TABLE_TYPE` = 'BASE TABLE';
|
||||
|
||||
# If previous query returned results, copy & run all outputed SQL statements
|
||||
# If previous query returned results, copy & run all shown SQL statements
|
||||
|
||||
# turn foreign key checks back on
|
||||
SET foreign_key_checks = 1;
|
||||
|
||||
@@ -114,13 +114,13 @@ mysql -u root -p
|
||||
# Convert all tables to use the InnoDB storage engine (added in GitLab 6.8)
|
||||
SELECT CONCAT('ALTER TABLE gitlabhq_production.', table_name, ' ENGINE=InnoDB;') AS 'Copy & run these SQL statements:' FROM information_schema.tables WHERE table_schema = 'gitlabhq_production' AND `ENGINE` <> 'InnoDB' AND `TABLE_TYPE` = 'BASE TABLE';
|
||||
|
||||
# If previous query returned results, copy & run all outputed SQL statements
|
||||
# If previous query returned results, copy & run all shown SQL statements
|
||||
|
||||
# Convert all tables to correct character set
|
||||
SET foreign_key_checks = 0;
|
||||
SELECT CONCAT('ALTER TABLE gitlabhq_production.', table_name, ' CONVERT TO CHARACTER SET utf8 COLLATE utf8_general_ci;') AS 'Copy & run these SQL statements:' FROM information_schema.tables WHERE table_schema = 'gitlabhq_production' AND `TABLE_COLLATION` <> 'utf8_unicode_ci' AND `TABLE_TYPE` = 'BASE TABLE';
|
||||
|
||||
# If previous query returned results, copy & run all outputed SQL statements
|
||||
# If previous query returned results, copy & run all shown SQL statements
|
||||
|
||||
# turn foreign key checks back on
|
||||
SET foreign_key_checks = 1;
|
||||
|
||||
@@ -13,4 +13,4 @@ Depending on the installation method and your GitLab version, there are multiple
|
||||
|
||||
## Miscellaneous
|
||||
|
||||
- [MySQL to PostgreSQL](mysql_to_postgresql.md) guides you through migrating your database from MySQL to PostrgreSQL.
|
||||
- [MySQL to PostgreSQL](mysql_to_postgresql.md) guides you through migrating your database from MySQL to PostgreSQL.
|
||||
|
||||
@@ -43,7 +43,7 @@ Since most tools automatically make the master branch the default one and displa
|
||||
The second problem of git flow is the complexity introduced by the hotfix and release branches.
|
||||
These branches can be a good idea for some organizations but are overkill for the vast majority of them.
|
||||
Nowadays most organizations practice continuous delivery which means that your default branch can be deployed.
|
||||
This means that hotfixed and release branches can be prevented including all the ceremony they introduce.
|
||||
This means that hotfix and release branches can be prevented including all the ceremony they introduce.
|
||||
An example of this ceremony is the merging back of release branches.
|
||||
Though specialized tools do exist to solve this, they require documentation and add complexity.
|
||||
Frequently developers make a mistake and for example changes are only merged into master and not into the develop branch.
|
||||
@@ -95,12 +95,12 @@ An 'extreme' version of environment branches are setting up an environment for e
|
||||
|
||||
## Release branches with GitLab flow
|
||||
|
||||
|
||||
|
||||
|
||||
Only in case you need to release software to the outside world you need to work with release branches.
|
||||
In this case, each branch contains a minor version (2-3-stable, 2-4-stable, etc.).
|
||||
The stable branch uses master as a starting point and is created as late as possible.
|
||||
By branching as late as possible you minimize the time you have to apply bugfixes to multiple branches.
|
||||
By branching as late as possible you minimize the time you have to apply bug fixes to multiple branches.
|
||||
After a release branch is announced, only serious bug fixes are included in the release branch.
|
||||
If possible these bug fixes are first merged into master and then cherry-picked into the release branch.
|
||||
This way you can't forget to cherry-pick them into master and encounter the same bug on subsequent releases.
|
||||
@@ -177,7 +177,7 @@ In GitLab this creates a comment in the issue that the merge requests mentions t
|
||||
And the merge request shows the linked issues.
|
||||
These issues are closed once code is merged into the default branch.
|
||||
|
||||
If you only want to make the reference without closing the issue you can also just mention it: "Ducktyping is preferred. #12".
|
||||
If you only want to make the reference without closing the issue you can also just mention it: "Duck typing is preferred. #12".
|
||||
|
||||
If you have an issue that spans across multiple repositories, the best thing is to create an issue for each repository and link all issues to a parent issue.
|
||||
|
||||
|
||||
@@ -3,7 +3,7 @@
|
||||
SVN stands for Subversion and is a version control system (VCS).
|
||||
Git is a distributed version control system.
|
||||
|
||||
There are some major differences between the two, for more information consult your favourite search engine.
|
||||
There are some major differences between the two, for more information consult your favorite search engine.
|
||||
|
||||
Git has tools for migrating SVN repositories to git, namely `git svn`. You can read more about this at
|
||||
[git documentation pages](http://git-scm.com/book/en/Git-and-Other-Systems-Git-and-Subversion).
|
||||
|
||||
@@ -24,14 +24,14 @@ Each of these settings have levels of notification:
|
||||
#### Global Settings
|
||||
|
||||
Global Settings are at the bottom of the hierarchy.
|
||||
Any setting set here will be overriden by a setting at the group or a project level.
|
||||
Any setting set here will be overridden by a setting at the group or a project level.
|
||||
|
||||
Group or Project settings can use `global` notification setting which will then use
|
||||
anything that is set at Global Settings.
|
||||
|
||||
#### Group Settings
|
||||
|
||||
Group Settings are taking presedence over Global Settings but are on a level below Project Settings.
|
||||
Group Settings are taking precedence over Global Settings but are on a level below Project Settings.
|
||||
This means that you can set a different level of notifications per group while still being able
|
||||
to have a finer level setting per project.
|
||||
Organization like this is suitable for users that belong to different groups but don't have the
|
||||
@@ -39,7 +39,7 @@ same need for being notified for every group they are member of.
|
||||
|
||||
#### Project Settings
|
||||
|
||||
Project Settings are at the top level and any setting placed at this level will take presedence of any
|
||||
Project Settings are at the top level and any setting placed at this level will take precedence of any
|
||||
other setting.
|
||||
This is suitable for users that have different needs for notifications per project basis.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user