Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
0b48416b38
commit
6efe8f9dc1
|
|
@ -365,21 +365,26 @@ You may be able to avoid timeouts and data loss using `actimeo=0` and `lookupcac
|
|||
we expect the performance reduction will still be significant. As noted above, we strongly recommend upgrading to
|
||||
[Gitaly Cluster](gitaly/praefect.md) as soon as possible.
|
||||
|
||||
### Avoid using AWS's Elastic File System (EFS)
|
||||
### Avoid using cloud-based file systems
|
||||
|
||||
GitLab strongly recommends against using AWS Elastic File System (EFS).
|
||||
Our support team will not be able to assist on performance issues related to
|
||||
file system access.
|
||||
GitLab strongly recommends against using cloud-based file systems such as:
|
||||
|
||||
Customers and users have reported that AWS EFS does not perform well for the GitLab
|
||||
use-case. Workloads where many small files are written in a serialized manner, like `git`,
|
||||
are not well-suited for EFS. EBS with an NFS server on top will perform much better.
|
||||
- AWS Elastic File System (EFS).
|
||||
- Google Cloud Filestore.
|
||||
- Azure Files.
|
||||
|
||||
If you do choose to use EFS, avoid storing GitLab log files (e.g. those in `/var/log/gitlab`)
|
||||
Our support team cannot assist with performance issues related to cloud-based file system access.
|
||||
|
||||
Customers and users have reported that these file systems don't perform well for
|
||||
the file system access GitLab requires. Workloads where many small files are written in
|
||||
a serialized manner, like `git`, are not well suited to cloud-based file systems.
|
||||
|
||||
If you do choose to use these, avoid storing GitLab log files (for example, those in `/var/log/gitlab`)
|
||||
there because this will also affect performance. We recommend that the log files be
|
||||
stored on a local volume.
|
||||
|
||||
For more details on another person's experience with EFS, see this [Commit Brooklyn 2019 video](https://youtu.be/K6OS8WodRBQ?t=313).
|
||||
For more details on the experience of using a cloud-based file systems with GitLab,
|
||||
see this [Commit Brooklyn 2019 video](https://youtu.be/K6OS8WodRBQ?t=313).
|
||||
|
||||
### Avoid using CephFS and GlusterFS
|
||||
|
||||
|
|
|
|||
|
|
@ -584,7 +584,7 @@ Let's create an EC2 instance where we'll install Gitaly:
|
|||
1. Finally, acknowledge that you have access to the selected private key file or create a new one. Click **Launch Instances**.
|
||||
|
||||
NOTE:
|
||||
Instead of storing configuration _and_ repository data on the root volume, you can also choose to add an additional EBS volume for repository storage. Follow the same guidance as above. See the [Amazon EBS pricing](https://aws.amazon.com/ebs/pricing/). We do not recommend using EFS as it may negatively impact the performance of GitLab. You can review the [relevant documentation](../../administration/nfs.md#avoid-using-awss-elastic-file-system-efs) for more details.
|
||||
Instead of storing configuration _and_ repository data on the root volume, you can also choose to add an additional EBS volume for repository storage. Follow the same guidance as above. See the [Amazon EBS pricing](https://aws.amazon.com/ebs/pricing/). We do not recommend using EFS as it may negatively impact the performance of GitLab. You can review the [relevant documentation](../../administration/nfs.md#avoid-using-cloud-based-file-systems) for more details.
|
||||
|
||||
Now that we have our EC2 instance ready, follow the [documentation to install GitLab and set up Gitaly on its own server](../../administration/gitaly/index.md#run-gitaly-on-its-own-server). Perform the client setup steps from that document on the [GitLab instance we created](#install-gitlab) above.
|
||||
|
||||
|
|
|
|||
|
|
@ -110,7 +110,8 @@ Apart from a local hard drive you can also mount a volume that supports the netw
|
|||
If you have enough RAM and a recent CPU the speed of GitLab is mainly limited by hard drive seek times. Having a fast drive (7200 RPM and up) or a solid state drive (SSD) will improve the responsiveness of GitLab.
|
||||
|
||||
NOTE:
|
||||
Since file system performance may affect the overall performance of GitLab, [we don't recommend using AWS EFS for storage](../administration/nfs.md#avoid-using-awss-elastic-file-system-efs).
|
||||
Since file system performance may affect the overall performance of GitLab,
|
||||
[we don't recommend using cloud-based file systems for storage](../administration/nfs.md#avoid-using-cloud-based-file-systems).
|
||||
|
||||
### CPU
|
||||
|
||||
|
|
|
|||
|
|
@ -629,7 +629,7 @@ directory that you want to copy the tarballs to is the root of your mounted
|
|||
directory, use `.` instead.
|
||||
|
||||
Because file system performance may affect overall GitLab performance,
|
||||
[GitLab doesn't recommend using EFS for storage](../administration/nfs.md#avoid-using-awss-elastic-file-system-efs).
|
||||
[GitLab doesn't recommend using cloud-based file systems for storage](../administration/nfs.md#avoid-using-cloud-based-file-systems).
|
||||
|
||||
For Omnibus GitLab packages:
|
||||
|
||||
|
|
|
|||
|
|
@ -430,30 +430,26 @@ To restore a group that is marked for deletion:
|
|||
Prevent projects in a group from [sharing
|
||||
a project with another group](../project/members/share_project_with_groups.md) to enable tighter control over project access.
|
||||
|
||||
For example, let's say you have two distinct teams (Group A and Group B) working together in a project, and to inherit the group membership, you share the project between the
|
||||
two groups A and B. **Share with group lock** prevents any project in
|
||||
the group from being shared with another group,
|
||||
guaranteeing that only the right group members have access to those projects.
|
||||
|
||||
To prevent a project from being shared with groups:
|
||||
To prevent a project from being shared with other groups:
|
||||
|
||||
1. Go to the group's **Settings > General** page.
|
||||
1. Select **Share with group lock**.
|
||||
1. Select **Save the group**.
|
||||
1. Expand the **Permissions, LFS, 2FA** section.
|
||||
1. Select **Prevent sharing a project within <group_name> with other groups**.
|
||||
1. Select **Save changes**.
|
||||
|
||||
## Prevent members from being added to a group **(PREMIUM)**
|
||||
|
||||
Member lock lets a group owner prevent any new project membership to all of the
|
||||
As a group owner, you can prevent any new project membership for all
|
||||
projects in a group, allowing tighter control over project membership.
|
||||
|
||||
For example, if you want to lock the group for an [Audit Event](../../administration/audit_events.md),
|
||||
enable member lock to guarantee that project membership cannot be modified during the audit.
|
||||
you can guarantee that project membership cannot be modified during the audit.
|
||||
|
||||
To prevent members from being added to a group:
|
||||
|
||||
1. Go to the group's **Settings > General** page.
|
||||
1. Expand the **Permissions, LFS, 2FA** section.
|
||||
1. Select **Member lock**.
|
||||
1. Under **Member lock**, select **Prevent adding new members to project membership within this group**.
|
||||
1. Select **Save changes**.
|
||||
|
||||
All users who previously had permissions can no longer add members to a group.
|
||||
|
|
@ -470,29 +466,24 @@ users cannot perform Git operations through SSH, or access projects in the UI.
|
|||
For more information, [see this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/271673).
|
||||
|
||||
To ensure only people from your organization can access particular
|
||||
resources, you can restrict access to groups and their
|
||||
underlying subgroups, projects, issues, and so on, by IP address. This can help ensure that
|
||||
particular content doesn't leave the premises, while not blocking off access to
|
||||
the entire instance. IP access restrictions can only be configured at the group level.
|
||||
resources, you can restrict access to groups by IP address. This setting applies to all subgroups,
|
||||
projects, issues, and so on.
|
||||
|
||||
Add one or more allowed IP subnets using CIDR notation to the group settings and anyone
|
||||
coming from a different IP address won't be able to access the restricted
|
||||
content.
|
||||
IP access restrictions can be configured at the group level only.
|
||||
|
||||
Restriction currently applies to:
|
||||
This restriction applies to:
|
||||
|
||||
- UI.
|
||||
- [From GitLab 12.3](https://gitlab.com/gitlab-org/gitlab/-/issues/12874), API access.
|
||||
- [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/-/issues/32113), Git actions via SSH.
|
||||
- The GitLab UI.
|
||||
- [In GitLab 12.3 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/12874), the API.
|
||||
- [In GitLab 12.4 and later](https://gitlab.com/gitlab-org/gitlab/-/issues/32113), Git actions via SSH.
|
||||
|
||||
To avoid accidental lock-out, admins and group owners are able to access
|
||||
the group regardless of the IP restriction.
|
||||
Administrators and group owners are able to access the group regardless of the IP restriction.
|
||||
|
||||
To restrict group access by IP address:
|
||||
|
||||
1. Go to the group’s **Settings > General** page.
|
||||
1. Expand the **Permissions, LFS, 2FA** section.
|
||||
1. In the **Allow access to the following IP addresses** field, enter IP address ranges.
|
||||
1. In the **Allow access to the following IP addresses** field, enter IP address ranges in CIDR notation.
|
||||
1. Select **Save changes**.
|
||||
|
||||
|
||||
|
|
@ -540,20 +531,20 @@ You can configure this feature for both subgroups and immediate parent groups. A
|
|||
in a subgroup has access to the templates for that subgroup, as well as
|
||||
any immediate parent groups.
|
||||
|
||||
To enable group file templates:
|
||||
|
||||
1. Go to the group settings page.
|
||||
1. Expand the **Templates** section.
|
||||
1. Choose a project to act as the template repository.
|
||||
1. Select **Save group**.
|
||||
|
||||
To learn how to create templates for issues and merge requests, see
|
||||
[Description templates](../project/description_templates.md).
|
||||
|
||||
### Group-level project templates **(PREMIUM)**
|
||||
|
||||
Define project templates at a group level by setting a group as the template source.
|
||||
[Learn more about group-level project templates](custom_project_templates.md).
|
||||
[Learn more about group-level project templates](custom_project_templates.md). **(PREMIUM)**
|
||||
|
||||
### Enable group file template **(PREMIUM)**
|
||||
|
||||
To enable group file templates:
|
||||
|
||||
1. Go to the group's **Settings > General** page.
|
||||
1. Expand the **Templates** section.
|
||||
1. Choose a project to act as the template repository.
|
||||
1. Select **Save changes**.
|
||||
|
||||
## Disable email notifications
|
||||
|
||||
|
|
@ -616,7 +607,8 @@ Optionally, on [Premium](https://about.gitlab.com/pricing/) or higher tiers,
|
|||
you can prevent the projects in a group from being forked outside of the current top-level group.
|
||||
|
||||
Previously this setting was available only for groups enforcing group managed account. This setting will be
|
||||
removed from SAML setting page and migrated to group setting, but in the interim period of changes both of those settings will be taken into consideration, if even one is set to `true` then it will be assumed group does not allow forking projects outside.
|
||||
removed from SAML setting page and migrated to group settings. In the interim period, both of these settings are taken into consideration.
|
||||
If even one is set to `true` then it will be assumed the group does not allow forking projects outside.
|
||||
|
||||
To enable prevent project forking:
|
||||
|
||||
|
|
@ -647,8 +639,7 @@ The group's new subgroups have push rules set for them based on either:
|
|||
## Related topics
|
||||
|
||||
- [Maximum artifacts size](../admin_area/settings/continuous_integration.md#maximum-artifacts-size). **(FREE SELF)**
|
||||
- [Repositories analytics](repositories_analytics/index.md): View overall activity of all projects with code coverage.
|
||||
[Introduced](https://gitlab.com/gitlab-org/gitlab/-/issues/263478) in GitLab 13.6. **(PREMIUM)**
|
||||
- [Repositories analytics](repositories_analytics/index.md): View overall activity of all projects with code coverage. **(PREMIUM)**
|
||||
- [Contribution analytics](contribution_analytics/index.md): View the contributions (pushes, merge requests,
|
||||
and issues) of group members. **(PREMIUM)**
|
||||
- [Issue analytics](issues_analytics/index.md): View a bar chart of your group's number of issues per month. **(PREMIUM)**
|
||||
|
|
|
|||
|
|
@ -79,6 +79,18 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
|
|||
|
||||
subject(:execute_service) { chat_service.execute(data) }
|
||||
|
||||
shared_examples 'calls the service API with the event message' do |event_message|
|
||||
specify do
|
||||
expect_next_instance_of(Slack::Messenger) do |messenger|
|
||||
expect(messenger).to receive(:ping).with(event_message, anything).and_call_original
|
||||
end
|
||||
|
||||
execute_service
|
||||
|
||||
expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
|
||||
end
|
||||
end
|
||||
|
||||
context 'with username for slack configured' do
|
||||
let(:chat_service_params) { { username: 'slack_username' } }
|
||||
|
||||
|
|
@ -92,11 +104,7 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
|
|||
context 'push events' do
|
||||
let(:data) { Gitlab::DataBuilder::Push.build_sample(project, user) }
|
||||
|
||||
it "calls #{service_name} API for push events" do
|
||||
execute_service
|
||||
|
||||
expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
|
||||
end
|
||||
it_behaves_like 'calls the service API with the event message', /pushed to branch/
|
||||
|
||||
context 'with event channel' do
|
||||
let(:chat_service_params) { { push_channel: 'random' } }
|
||||
|
|
@ -109,15 +117,20 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
|
|||
end
|
||||
end
|
||||
|
||||
context 'tag_push events' do
|
||||
let(:oldrev) { Gitlab::Git::BLANK_SHA }
|
||||
let(:newrev) { '8a2a6eb295bb170b34c24c76c49ed0e9b2eaf34b' } # gitlab-test: git rev-parse refs/tags/v1.1.0
|
||||
let(:ref) { 'refs/tags/v1.1.0' }
|
||||
let(:data) { Git::TagHooksService.new(project, user, change: { oldrev: oldrev, newrev: newrev, ref: ref }).send(:push_data) }
|
||||
|
||||
it_behaves_like 'calls the service API with the event message', /pushed new tag/
|
||||
end
|
||||
|
||||
context 'issue events' do
|
||||
let_it_be(:issue) { create(:issue) }
|
||||
let(:data) { issue.to_hook_data(user) }
|
||||
|
||||
it "calls #{service_name} API for issue events" do
|
||||
execute_service
|
||||
|
||||
expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
|
||||
end
|
||||
it_behaves_like 'calls the service API with the event message', /Issue (.*?) opened by/
|
||||
|
||||
context 'whith event channel' do
|
||||
let(:chat_service_params) { { issue_channel: 'random' } }
|
||||
|
|
@ -156,11 +169,7 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
|
|||
let_it_be(:merge_request) { create(:merge_request) }
|
||||
let(:data) { merge_request.to_hook_data(user) }
|
||||
|
||||
it "calls #{service_name} API for merge requests events" do
|
||||
execute_service
|
||||
|
||||
expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
|
||||
end
|
||||
it_behaves_like 'calls the service API with the event message', /opened merge request/
|
||||
|
||||
context 'with event channel' do
|
||||
let(:chat_service_params) { { merge_request_channel: 'random' } }
|
||||
|
|
@ -177,11 +186,7 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
|
|||
let_it_be(:wiki_page) { create(:wiki_page, wiki: project.wiki, message: 'user created page: Awesome wiki_page') }
|
||||
let(:data) { Gitlab::DataBuilder::WikiPage.build(wiki_page, user, 'create') }
|
||||
|
||||
it "calls #{service_name} API for wiki page events" do
|
||||
execute_service
|
||||
|
||||
expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
|
||||
end
|
||||
it_behaves_like 'calls the service API with the event message', / created (.*?)wikis\/(.*?)|wiki page> in/
|
||||
|
||||
context 'with event channel' do
|
||||
let(:chat_service_params) { { wiki_page_channel: 'random' } }
|
||||
|
|
@ -198,22 +203,14 @@ RSpec.shared_examples 'slack or mattermost notifications' do |service_name|
|
|||
let_it_be(:deployment) { create(:deployment) }
|
||||
let(:data) { Gitlab::DataBuilder::Deployment.build(deployment) }
|
||||
|
||||
it "calls #{service_name} API for deployment events" do
|
||||
execute_service
|
||||
|
||||
expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
|
||||
end
|
||||
it_behaves_like 'calls the service API with the event message', /Deploy to (.*?) created/
|
||||
end
|
||||
|
||||
context 'note event' do
|
||||
let_it_be(:issue_note) { create(:note_on_issue, project: project, note: "issue note") }
|
||||
let(:data) { Gitlab::DataBuilder::Note.build(issue_note, user) }
|
||||
|
||||
it "calls #{service_name} API for note events" do
|
||||
execute_service
|
||||
|
||||
expect(WebMock).to have_requested(:post, stubbed_resolved_hostname).once
|
||||
end
|
||||
it_behaves_like 'calls the service API with the event message', /commented on issue/
|
||||
|
||||
context 'with event channel' do
|
||||
let(:chat_service_params) { { note_channel: 'random' } }
|
||||
|
|
|
|||
Loading…
Reference in New Issue