Docs: Realign more CE docs that diverged from EE unnecessarily (second MR)
This commit is contained in:
Marcel Amirault
Achilleas Pipinellis
parent
8d7ed982ef
commit
9d6a8003e0
13 changed files with 87 additions and 17 deletions
|
|
@ -831,6 +831,29 @@ should remain working as-is when EE is running without a license.
|
|||
|
||||
Instead place EE specs in the `ee/spec` folder.
|
||||
|
||||
### Code in `spec/factories`
|
||||
|
||||
Use `FactoryBot.modify` to extend factories already defined in CE.
|
||||
|
||||
Note that you cannot define new factories (even nested ones) inside the `FactoryBot.modify` block. You can do so in a
|
||||
separate `FactoryBot.define` block as shown in the example below:
|
||||
|
||||
```ruby
|
||||
# ee/spec/factories/notes.rb
|
||||
FactoryBot.modify do
|
||||
factory :note do
|
||||
trait :on_epic do
|
||||
noteable { create(:epic) }
|
||||
project nil
|
||||
end
|
||||
end
|
||||
end
|
||||
|
||||
FactoryBot.define do
|
||||
factory :note_on_epic, parent: :note, traits: [:on_epic]
|
||||
end
|
||||
```
|
||||
|
||||
## JavaScript code in `assets/javascripts/`
|
||||
|
||||
To separate EE-specific JS-files we should also move the files into an `ee` folder.
|
||||
|
|
|
|||
|
|
@ -24,7 +24,7 @@ Our current CI parallelization setup is as follows:
|
|||
uploaded to S3.
|
||||
|
||||
After that, the next pipeline will use the up-to-date
|
||||
`knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` file.
|
||||
`knapsack/${CI_PROJECT_NAME}/rspec_report-master.json` file.
|
||||
|
||||
### Monitoring
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@ comments: false
|
|||
description: Read through the GitLab installation methods.
|
||||
---
|
||||
|
||||
# Installation
|
||||
# Installation **[CORE ONLY]**
|
||||
|
||||
GitLab can be installed in most GNU/Linux distributions and in a number
|
||||
of cloud providers. To get the best experience from GitLab you need to balance
|
||||
|
|
|
|||
|
|
@ -108,7 +108,7 @@ sudo apt-get install -y libcurl4-openssl-dev libexpat1-dev gettext libz-dev libs
|
|||
|
||||
# Download and compile from source
|
||||
cd /tmp
|
||||
curl --remote-name --progress https://www.kernel.org/pub/software/scm/git/git-2.18.0.tar.gz
|
||||
curl --remote-name --location --progress https://www.kernel.org/pub/software/scm/git/git-2.18.0.tar.gz
|
||||
echo '94faf2c0b02a7920b0b46f4961d8e9cad08e81418614102898a55f980fa3e7e4 git-2.18.0.tar.gz' | shasum -a256 -c - && tar -xzf git-2.18.0.tar.gz
|
||||
cd git-2.18.0/
|
||||
./configure
|
||||
|
|
|
|||
|
|
@ -9,13 +9,13 @@ comments: false
|
|||
Create projects and groups.
|
||||
|
||||
- [Create a new project](../gitlab-basics/create-project.md)
|
||||
- [Create a new group](../gitlab-basics/create-group.md)
|
||||
- [Create a new group](../user/group/index.md#create-a-new-group)
|
||||
|
||||
## Prioritize
|
||||
|
||||
Create issues, labels, milestones, cast your vote, and review issues.
|
||||
|
||||
- [Create a new issue](../user/project/issues/index.md#new-issue)
|
||||
- [Create an issue](../user/project/issues/create_new_issue.md)
|
||||
- [Assign labels to issues](../user/project/labels.md)
|
||||
- [Use milestones as an overview of your project's tracker](../user/project/milestones/index.md)
|
||||
- [Use voting to express your like/dislike to issues and merge requests](../workflow/award_emoji.md)
|
||||
|
|
|
|||
|
|
@ -247,6 +247,17 @@ Public SSH keys need to be unique to GitLab, as they will bind to your account.
|
|||
Your SSH key is the only identifier you'll have when pushing code via SSH,
|
||||
that's why it needs to uniquely map to a single user.
|
||||
|
||||
## Per-repository SSH keys
|
||||
|
||||
If you want to use different keys depending on the repository you are working
|
||||
on, you can issue the following command while inside your repository:
|
||||
|
||||
```sh
|
||||
git config core.sshCommand "ssh -o IdentitiesOnly=yes -i ~/.ssh/private-key-filename-for-this-repository -F /dev/null"
|
||||
```
|
||||
|
||||
This will not use the SSH Agent and requires at least Git 2.10.
|
||||
|
||||
## Deploy keys
|
||||
|
||||
### Per-repository deploy keys
|
||||
|
|
|
|||
|
|
@ -138,7 +138,7 @@ Please refer to `group_rename` and `user_rename` for that case.
|
|||
"created_at": "2012-07-21T07:30:56Z",
|
||||
"updated_at": "2012-07-21T07:38:22Z",
|
||||
"event_name": "user_add_to_team",
|
||||
"project_access": "Maintainer",
|
||||
"access_level": "Maintainer",
|
||||
"project_id": 74,
|
||||
"project_name": "StoreCloud",
|
||||
"project_path": "storecloud",
|
||||
|
|
|
|||
|
|
@ -5,15 +5,15 @@ update guides.
|
|||
|
||||
There are currently 3 official ways to install GitLab:
|
||||
|
||||
- Omnibus packages
|
||||
- Source installation
|
||||
- Docker installation
|
||||
- [Omnibus packages](#omnibus-packages)
|
||||
- [Source installation](#installation-from-source)
|
||||
- [Docker installation](#installation-using-docker)
|
||||
|
||||
Based on your installation, choose a section below that fits your needs.
|
||||
|
||||
## Omnibus Packages
|
||||
|
||||
- The [Omnibus update guide](http://docs.gitlab.com/omnibus/update/README.html)
|
||||
- The [Omnibus update guide][omni-update]
|
||||
contains the steps needed to update an Omnibus GitLab package.
|
||||
|
||||
## Installation from source
|
||||
|
|
@ -36,7 +36,7 @@ can still be found in the Git repository:
|
|||
|
||||
GitLab provides official Docker images for both Community and Enterprise
|
||||
editions. They are based on the Omnibus package and instructions on how to
|
||||
update them are in [a separate document][omnidocker].
|
||||
update them are in [a separate document][omni-docker].
|
||||
|
||||
## Upgrading without downtime
|
||||
|
||||
|
|
@ -103,6 +103,10 @@ migrations this could potentially lead to hours of downtime, depending on the
|
|||
size of your database. To work around this you will have to use PostgreSQL and
|
||||
meet the other online upgrade requirements mentioned above.
|
||||
|
||||
### Steps
|
||||
|
||||
Steps to [upgrade without downtime][omni-zero-downtime].
|
||||
|
||||
## Upgrading between editions
|
||||
|
||||
GitLab comes in two flavors: [Community Edition][ce] which is MIT licensed,
|
||||
|
|
@ -150,3 +154,6 @@ possible.
|
|||
[ce]: https://about.gitlab.com/features/#community
|
||||
[ee]: https://about.gitlab.com/features/#enterprise
|
||||
[omni-ce-ee]: https://docs.gitlab.com/omnibus/update/README.html#updating-community-edition-to-enterprise-edition
|
||||
[omni-docker]: https://docs.gitlab.com/omnibus/docker/README.html
|
||||
[omni-update]: https://docs.gitlab.com/omnibus/update/README.html
|
||||
[omni-zero-downtime]: https://docs.gitlab.com/omnibus/update/README.html#zero-downtime-updates
|
||||
|
|
|
|||
|
|
@ -3,4 +3,7 @@
|
|||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-ce/merge_requests/20379)
|
||||
> in [GitLab Core](https://about.gitlab.com/pricing/) 11.1
|
||||
|
||||
The display of third party offers can be controlled in the Admin Area -> Settings page.
|
||||
Within GitLab, we inform users of available third-party offers they might find valuable in order to enhance the development of their projects.
|
||||
An example is the Google Cloud Platform free credit for using [Google Kubernetes Engine](https://cloud.google.com/kubernetes-engine/).
|
||||
|
||||
The display of third-party offers can be toggled in the Admin area on the Settings page.
|
||||
|
|
|
|||
|
|
@ -57,7 +57,10 @@ and default views of your dashboard and the projects' landing pages.
|
|||
### Layout width
|
||||
|
||||
GitLab can be set up to use different widths depending on your liking. Choose
|
||||
between the fixed (max. 1200px) and the fluid (100%) application layout.
|
||||
between the fixed (max. `1280px`) and the fluid (`100%`) application layout.
|
||||
|
||||
NOTE: **Note:**
|
||||
While `1280px` is the standard max width when using fixed layout, some pages still use 100% width, depending on the content.
|
||||
|
||||
### Default dashboard
|
||||
|
||||
|
|
|
|||
|
|
@ -22,12 +22,37 @@ a new issue is created. You can configure webhooks to listen for specific events
|
|||
like pushes, issues or merge requests. GitLab will send a POST request with data
|
||||
to the webhook URL.
|
||||
|
||||
In most cases, you'll need to set up your own [webhook receiver](#example-webhook-receiver)
|
||||
to receive information from GitLab, and send it to another app, according to your needs.
|
||||
We already have a [built-in receiver](http://docs.gitlab.com/ce/project_services/slack.html)
|
||||
for sending [Slack](https://api.slack.com/incoming-webhooks) notifications _per project_.
|
||||
|
||||
## Overview
|
||||
|
||||
[Webhooks](https://en.wikipedia.org/wiki/Webhook) are "_user-defined HTTP
|
||||
callbacks_". They are usually triggered by some
|
||||
event, such as pushing code to a repository or a comment being posted to a blog.
|
||||
When that event occurs, the source app makes an HTTP request to the URI
|
||||
configured for the webhook. The action taken may be anything.
|
||||
Common uses are to trigger builds with continuous integration systems or to
|
||||
notify bug tracking systems.
|
||||
|
||||
Webhooks can be used to update an external issue tracker, trigger CI jobs,
|
||||
update a backup mirror, or even deploy to your production server.
|
||||
They are available **per project** for GitLab Community Edition,
|
||||
and **per project and per group** for **GitLab Enterprise Edition**.
|
||||
|
||||
Navigate to the webhooks page by going to your project's
|
||||
**Settings ➔ Integrations**.
|
||||
|
||||
## Use-cases
|
||||
|
||||
- You can set up a webhook in GitLab to send a notification to
|
||||
[Slack](https://api.slack.com/incoming-webhooks) every time a build fails, for example
|
||||
- You can [integrate with Twilio to be notified via SMS](https://www.datadoghq.com/blog/send-alerts-sms-customizable-webhooks-twilio/)
|
||||
every time an issue is created for a specific project or group within GitLab
|
||||
- You can use them to [automatically assign labels to merge requests](https://about.gitlab.com/2016/08/19/applying-gitlab-labels-automatically/).
|
||||
|
||||
## Webhook endpoint tips
|
||||
|
||||
If you are writing your own endpoint (web server) that will receive
|
||||
|
|
|
|||
|
|
@ -33,13 +33,13 @@ easy for you.
|
|||
|
||||
|
||||
|
||||
When clicking on either `LICENSE` or `.gitignore`, a dropdown will be displayed
|
||||
When clicking on either `LICENSE` or `.gitignore`, etc., a dropdown will be displayed
|
||||
to provide you with a template which might be suitable for your project.
|
||||
|
||||
|
||||
|
||||
The license, changelog, contribution guide, or `.gitlab-ci.yml` file could also
|
||||
be added through a button on the project page. In the example below the license
|
||||
be added through a button on the project page. In the example below, the license
|
||||
has already been created, which creates a link to the license itself.
|
||||
|
||||
|
||||
|
|
|
|||
|
|
@ -61,8 +61,6 @@ Currently the following names are reserved as top level groups:
|
|||
- favicon.ico
|
||||
- favicon.png
|
||||
- groups
|
||||
- header_logo_dark.png
|
||||
- header_logo_light.png
|
||||
- health_check
|
||||
- help
|
||||
- import
|
||||
|
|
|
|||
Loading…
Reference in a new issue