root
/
gitlab-ce
mirror of https://gitlab.com/free-releases/gitlab-ce.git
1
0
Fork 0
Code Issues Actions Packages Projects Releases Wiki Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2021-01-11 00:10:36 +00:00
parent e940cc19e2
commit 0edf1c816d
5 changed files with 56 additions and 53 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
GITALY_SERVER_VERSION
View File

@ -1 +1 @@
a3f30273065e69dba8bebea04ed119b5e3f16793
9ebe59be4f07dc2f5362e64c264fd4edc08ff57e

2
doc/development/fe_guide/style/javascript.md
View File

@ -7,7 +7,7 @@ disqus_identifier: 'https://docs.gitlab.com/ee/development/fe_guide/style_guide_
# JavaScript style guide
We use [Airbnb's JavaScript Style Guide](https://github.com/airbnb/javascript) and it's accompanying
We use [Airbnb's JavaScript Style Guide](https://github.com/airbnb/javascript) and its accompanying
linter to manage most of our JavaScript style guidelines.
In addition to the style guidelines set by Airbnb, we also have a few specific rules

44
doc/development/gitaly.md
View File

@ -27,8 +27,9 @@ have changed since then, it should still serve as a good introduction.
## 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 set up Gitaly, the various components of Gitaly and what they do, and how to run its test suites.
[Beginner's guide to Gitaly contributions](https://gitlab.com/gitlab-org/gitaly/-/blob/master/doc/beginners_guide.md).
It describes how to set up Gitaly, the various components of Gitaly and what
they do, and how to run its test suites.
## Developing new Git features
@ -36,33 +37,17 @@ To read or write Git data, a request has to be made to Gitaly. This means that
if you're developing a new feature where you need data that's not yet available
in `lib/gitlab/git` changes have to be made to Gitaly.
> This is a new process that is not clearly defined yet. If you want
to contribute a Git feature and you're getting stuck, reach out to the
Gitaly team or `@jacobvosmaer-gitlab`.
There should be no new code that touches Git repositories via disk access (for example,
Rugged, `git`, `rm -rf`) anywhere in the `gitlab` repository. Anything that
needs direct access to the Git repository *must* be implemented in Gitaly, and
exposed via an RPC.
By 'new feature' we mean any method or class in `lib/gitlab/git` that is
called from outside `lib/gitlab/git`. For new methods that are called
from inside `lib/gitlab/git`, see 'Modifying existing Git features'
below.
It's often easier to develop a new feature in Gitaly if you make the changes to
GitLab that will use the new feature in a separate merge request, to be merged
immediately after the Gitaly one. This allows you to test your changes before
they are merged.
There should be no new code that touches Git repositories via
disk access (e.g. Rugged, `git`, `rm -rf`) anywhere outside
`lib/gitlab/git`.
The process for adding new Gitaly features is:
- exploration / prototyping
- design and create a new Gitaly RPC in [`gitaly-proto`](https://gitlab.com/gitlab-org/gitaly-proto)
- release a new version of `gitaly-proto`
- write implementation and tests for the RPC [in Gitaly](https://gitlab.com/gitlab-org/gitaly), in Go or Ruby
- release a new version of Gitaly
- write client code in GitLab CE/EE, GitLab Workhorse or GitLab Shell that calls the new Gitaly RPC
These steps often overlap. It is possible to use an unreleased version
of Gitaly and `gitaly-proto` during testing and development.
- See the [Gitaly repository](https://gitlab.com/gitlab-org/gitaly/blob/master/CONTRIBUTING.md#development-and-testing-with-a-custom-gitaly-proto) for instructions on writing server side code with an unreleased protocol.
- See [below](#running-tests-with-a-locally-modified-version-of-gitaly) for instructions on running GitLab CE tests with a modified version of Gitaly.
- See [below](#running-tests-with-a-locally-modified-version-of-gitaly) for instructions on running GitLab tests with a modified version of Gitaly.
- In GDK run `gdk install` and restart `gdk run` (or `gdk run app`) to use a locally modified Gitaly version for development
### `gitaly-ruby`
@ -208,7 +193,7 @@ to manually run `make` again.
Note that CI tests do not use your locally modified version of
Gitaly. To use a custom Gitaly version in CI you need to update
GITALY_SERVER_VERSION as described at the beginning of this paragraph.
GITALY_SERVER_VERSION as described at the beginning of this section.
To use a different Gitaly repository, e.g., if your changes are present
on a fork, you can specify a `GITALY_REPO_URL` environment variable when
@ -244,6 +229,9 @@ the branch with the changes (`new-feature-branch`, for example):
1. Run `bundle install` to use the modified RPC client.
Re-run `bundle install` in the `gitlab` project each time the Gitaly branch
changes to embed a new SHA in the `Gemfile.lock` file.
---
[Return to Development documentation](README.md)

59
doc/subscriptions/self_managed/index.md
View File

@ -11,6 +11,16 @@ You can install, administer, and maintain your own GitLab instance.
This page covers the details of your GitLab self-managed subscription.
GitLab subscription management requires access to the Customers Portal.
## Customers Portal
GitLab provides the [Customers Portal](../index.md#customers-portal) where you can
manage your subscriptions and your account details.
Customers of resellers do not have access to this portal and should contact their reseller for any
changes to their subscription.
## Subscription
The cost of a GitLab self-managed subscription is determined by the following:
@ -95,10 +105,10 @@ It also displays the following important statistics:
| Field | Description |
|:-------------------|:------------|
| Users in License | The number of users you've paid for in the current license loaded on the system. This does not include the amount you've paid for `Users over license` during renewal. |
| Billable users | The daily count of billable users on your system. |
| Maximum users | The highest number of billable users on your system during the term of the loaded license. If this number exceeds your users in license count at any point, you incur users over license. |
| Users over license | The number of users that exceed the `Users in License` for the current license term. Charges for this number of users are incurred at the next renewal. |
| Users in License | The number of users you've paid for in the current license loaded on the system. The number does not change unless you [add seats](#add-seats-to-a-subscription) during your current subscription period. |
| Billable users | The daily count of billable users on your system. The count may change as you block or add users to your instance. |
| Maximum users | The highest number of billable users on your system during the term of the loaded license. |
| Users over license | Calculated as `Maximum users` - `Users in License` for the current license term. This number incurs a retroactive charge that needs to be paid for at renewal. |
## Renew your subscription
@ -122,28 +132,38 @@ the contact person who manages your subscription.
It's important to regularly review your user accounts, because:
- A GitLab subscription is based on the number of users. You pay more than you should if you renew
for too many users, while the renewal fails if you attempt to renew a subscription for too few
users.
- Stale user accounts that are not blocked count as billable users. You may pay more than you should
if you renew for too many users.
- Stale user accounts can be a security risk. A regular review helps reduce this risk.
#### Users over License
A GitLab subscription is valid for a specific number of users. For details, see
[Billable users](#billable-users). If the billable user
count exceeds the number included in the subscription, known as the number of
_users over license_, you must pay for the excess number of users either before
renewal, or at the time of renewal. This is also known as the _true up_ process.
A GitLab subscription is valid for a specific number of seats. The number of users over license
is the number of _Maximum users_ that exceed the _Users in License_ for the current license term.
You must pay for this number of users either before renewal, or at the time of renewal. This is
known as the _true up_ process.
To view the number of _Users over License_ go to the **Admin Area**.
To view the number of _users over license_ go to the **Admin Area**.
### Add users to a subscription
##### Users over license example
Self-managed instances can add users to a subscription any time during the
subscription period. The cost of additional users added during the subscription
You purchase a license for 10 users.
| Event | Billable members | Maximum users |
|:---------------------------------------------------|:-----------------|:--------------|
| Ten people (users) occupy all 10 seats. | 10 | 10 |
| Two new people join. | 12 | 12 |
| Three people leave and their accounts are removed. | 9 | 12 |
Users over license = 12 - 10 (Maximum users - users in license)
### Add seats to a subscription
The users in license count can be increased by adding seats to a subscription any time during the
subscription period. The cost of seats added during the subscription
period is prorated from the date of purchase through the end of the subscription period.
To add users to a subscription:
To add seats to a subscription:
1. Log in to the [Customers Portal](https://customers.gitlab.com/).
1. Navigate to the **Manage Purchases** page.
@ -312,11 +332,6 @@ only.
However, if you remove the license, you immediately revert to Core
features, and the instance become read / write again.
## Customers Portal
GitLab provides the [Customers Portal](../index.md#customers-portal) where you can
manage your subscriptions and your account details.
## Contact Support
Learn more about:

2
qa/qa/specs/features/browser_ui/6_release/pages/pages_pipeline_spec.rb
View File

@ -37,7 +37,7 @@ module QA
end
Page::Project::Job::Show.perform do |show|
expect(show).to have_passed
expect(show).to have_passed(timeout: 300)
end
end
end