Commit ed4df05c authored by GitLab Bot's avatar GitLab Bot

Add latest changes from gitlab-org/gitlab@master

parent 1bdb3fe3
......@@ -93,6 +93,7 @@ class GroupPolicy < BasePolicy
enable :create_cluster
enable :update_cluster
enable :admin_cluster
enable :destroy_deploy_token
end
rule { owner }.policy do
......
---
title: Add API endpoint for deleting group deploy tokens
merge_request: 25222
author:
type: added
......@@ -17,7 +17,7 @@ You can restore it from backup or remove it from the **primary** node to resolve
If verification succeeds on the **primary** node but fails on the **secondary** node,
this indicates that the object was corrupted during the replication process.
Geo actively try to correct verification failures marking the repository to
be resynced with a backoff period. If you want to reset the verification for
be resynced with a back-off period. If you want to reset the verification for
these failures, so you should follow [these instructions][reset-verification].
If verification is lagging significantly behind replication, consider giving
......@@ -114,9 +114,9 @@ Feature.enable('geo_repository_reverification')
## Reset verification for projects where verification has failed
Geo actively try to correct verification failures marking the repository to
be resynced with a backoff period. If you want to reset them manually, this
be resynced with a back-off period. If you want to reset them manually, this
rake task marks projects where verification has failed or the checksum mismatch
to be resynced without the backoff period:
to be resynced without the back-off period:
For repositories:
......
......@@ -36,7 +36,7 @@ Repository-centric strategies for using `rsync` effectively can be found in the
be adapted for use with any other file-based data, such as GitLab Pages (to
be found in `/var/opt/gitlab/gitlab-rails/shared/pages` if using Omnibus).
## Pre-flight checks
## Preflight checks
Follow these steps before scheduling a planned failover to ensure the process
will go smoothly.
......
......@@ -107,7 +107,7 @@ keys must be manually replicated to the **secondary** node.
scp root@<primary_node_fqdn>:/etc/ssh/ssh_host_*_key* /etc/ssh
```
If you only have access through a user with **sudo** privileges:
If you only have access through a user with `sudo` privileges:
```shell
# Run this from your primary node:
......@@ -153,7 +153,7 @@ keys must be manually replicated to the **secondary** node.
NOTE: **Note:**
The output for private keys and public keys command should generate the same fingerprint.
1. Restart sshd on your **secondary** node:
1. Restart `sshd` on your **secondary** node:
```shell
# Debian or Ubuntu installations
......
......@@ -469,7 +469,7 @@ work:
1. On the **primary** Geo database, enter the PostgreSQL on the console as an
admin user. If you are using an Omnibus-managed database, log onto the **primary**
node that is running the PostgreSQL database (the default Omnibus database name is gitlabhq_production):
node that is running the PostgreSQL database (the default Omnibus database name is `gitlabhq_production`):
```shell
sudo \
......
......@@ -290,7 +290,7 @@ sudo gitlab-ctl \
This will give the initial replication up to six hours to complete, rather than
the default thirty minutes. Adjust as required for your installation.
### Message: "PANIC: could not write to file 'pg_xlog/xlogtemp.123': No space left on device"
### Message: "PANIC: could not write to file `pg_xlog/xlogtemp.123`: No space left on device"
Determine if you have any unused replication slots in the **primary** database. This can cause large amounts of
log data to build up in `pg_xlog`. Removing the unused slots can reduce the amount of space used in the `pg_xlog`.
......
......@@ -233,7 +233,7 @@ The following values configure logging in Gitaly under the `[logging]` section.
| `sentry_environment` | string | no | [Sentry Environment](https://docs.sentry.io/enriching-error-data/environments/) for exception monitoring. |
| `ruby_sentry_dsn` | string | no | Sentry DSN for `gitaly-ruby` exception monitoring. |
While the main Gitaly application logs go to stdout, there are some extra log
While the main Gitaly application logs go to `stdout`, there are some extra log
files that go to a configured directory, like the GitLab Shell logs.
GitLab Shell does not support `panic` or `trace` level logs. `panic` will fall
back to `error`, while `trace` will fall back to `debug`. Any other invalid log
......
......@@ -163,7 +163,7 @@ Similarly, PostgreSQL access is controlled based on the network source.
This is why you will need:
- IP address of each nodes network interface. This can be set to `0.0.0.0` to
listen on all interfaces. It cannot be set to the loopack address `127.0.0.1`.
listen on all interfaces. It cannot be set to the loopback address `127.0.0.1`.
- Network Address. This can be in subnet (i.e. `192.168.0.0/255.255.255.0`)
or CIDR (i.e. `192.168.0.0/24`) form.
......@@ -383,7 +383,7 @@ Select one node as a primary node.
* master | HOSTNAME | | host=HOSTNAME user=gitlab_repmgr dbname=gitlab_repmgr
```
1. Note down the hostname/ip in the connection string: `host=HOSTNAME`. We will
1. Note down the hostname or IP address in the connection string: `host=HOSTNAME`. We will
refer to the hostname in the next section as `MASTER_NODE_NAME`. If the value
is not an IP address, it will need to be a resolvable name (via DNS or
`/etc/hosts`)
......@@ -535,7 +535,7 @@ Here is a list and description of each machine and the assigned IP:
- `10.6.0.33`: PostgreSQL secondary
- `10.6.0.41`: GitLab application
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes and the external_url for GitLab is `http://gitlab.example.com`.
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes and the `external_url` for GitLab is `http://gitlab.example.com`.
Please note that after the initial configuration, if a failover occurs, the PostgresSQL master will change to one of the available secondaries until it is failed back.
......@@ -739,7 +739,7 @@ Here is a list and description of each machine and the assigned IP:
All passwords are set to `toomanysecrets`, please do not use this password or derived hashes.
The external_url for GitLab is `http://gitlab.example.com`
The `external_url` for GitLab is `http://gitlab.example.com`
Please note that after the initial configuration, if a failover occurs, the PostgresSQL master will change to one of the available secondaries until it is failed back.
......@@ -944,7 +944,7 @@ repmgr['trust_auth_cidr_addresses'] = %w(192.168.1.44/32 db2.example.com)
##### MD5 Authentication
If you are running on an untrusted network, repmgr can use md5 authentication
with a [.pgpass file](https://www.postgresql.org/docs/9.6/libpq-pgpass.html)
with a [`.pgpass` file](https://www.postgresql.org/docs/9.6/libpq-pgpass.html)
to authenticate.
You can specify by IP address, FQDN, or by subnet, using the same format as in
......
......@@ -149,7 +149,7 @@ Note there are several options that you should consider using:
## A single NFS mount
It's recommended to nest all GitLab data dirs within a mount, that allows automatic
It's recommended to nest all GitLab data directories within a mount, that allows automatic
restore of backups without manually moving existing data.
```plaintext
......
......@@ -25,7 +25,7 @@ Using EFS may negatively impact performance. Please review the [relevant documen
### Step 1 - Install NFS Server on Host
Installing the nfs-kernel-server package allows you to share directories with the clients running the GitLab application.
Installing the `nfs-kernel-server` package allows you to share directories with the clients running the GitLab application.
```shell
apt-get update
......@@ -61,7 +61,7 @@ inside your HA environment to the NFS server configured above.
### Step 1 - Install NFS Common on Client
The nfs-common provides NFS functionality without installing server components which
The `nfs-common` provides NFS functionality without installing server components which
we don't need running on the application nodes.
```shell
......@@ -126,7 +126,7 @@ by a firewall, then you will need to reconfigure that firewall to allow NFS comm
[This guide from TDLP](http://tldp.org/HOWTO/NFS-HOWTO/security.html#FIREWALLS)
covers the basics of using NFS in a firewalled environment. Additionally, we encourage you to
search for and review the specific documentation for your OS/distro and your firewall software.
search for and review the specific documentation for your operating system or distribution and your firewall software.
Example for Ubuntu:
......
......@@ -14,7 +14,7 @@ The following are the requirements for providing your own Redis instance:
[Merge Trains](../../ci/merge_request_pipelines/pipelines_for_merged_results/merge_trains/index.md).
- Standalone Redis or Redis high availability with Sentinel are supported. Redis
Cluster is not supported.
- Managed Redis from cloud providers such as AWS Elasticache will work. If these
- Managed Redis from cloud providers such as AWS ElastiCache will work. If these
services support high availability, be sure it is not the Redis Cluster type.
Note the Redis node's IP address or hostname, port, and password (if required).
......@@ -862,7 +862,7 @@ mailroom['enable'] = false
redis['master'] = false
```
You can find the relevant attributes defined in [gitlab_rails.rb][omnifile].
You can find the relevant attributes defined in [`gitlab_rails.rb`][omnifile].
## Troubleshooting
......@@ -936,7 +936,7 @@ and `redis['master_pasword']` as you defined for your sentinel node.
The way the Redis connector `redis-rb` works with sentinel is a bit
non-intuitive. We try to hide the complexity in omnibus, but it still requires
a few extra configs.
a few extra configurations.
---
......
......@@ -15,7 +15,7 @@ The housekeeping function runs `repack` or `gc` depending on the
For example in the following scenario a `git repack -d` will be executed:
- Project: pushes since gc counter (`pushes_since_gc`) = `10`
- Project: pushes since GC counter (`pushes_since_gc`) = `10`
- Git GC period = `200`
- Full repack period = `50`
......@@ -23,7 +23,7 @@ When the `pushes_since_gc` value is 50 a `repack -A -d --pack-kept-objects` will
the `pushes_since_gc` value is 200 a `git gc` will be run.
- `git gc` ([man page](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-gc.html)) runs a number of housekeeping tasks,
such as compressing filerevisions (to reduce disk space and increase performance)
such as compressing file revisions (to reduce disk space and increase performance)
and removing unreachable objects which may have been created from prior invocations of
`git add`.
- `git repack` ([man page](https://mirrors.edge.kernel.org/pub/software/scm/git/docs/git-repack.html)) re-organize existing packs into a single, more efficient pack.
......
......@@ -38,7 +38,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
- [Installing GitLab HA on Amazon Web Services (AWS)](../install/aws/index.md): Set up GitLab High Availability on Amazon AWS.
- [Geo](geo/replication/index.md): Replicate your GitLab instance to other geographic locations as a read-only fully operational version. **(PREMIUM ONLY)**
- [Disaster Recovery](geo/disaster_recovery/index.md): Quickly fail-over to a different site with minimal effort in a disaster situation. **(PREMIUM ONLY)**
- [Pivotal Tile](../install/pivotal/index.md): Deploy GitLab as a pre-configured appliance using Ops Manager (BOSH) for Pivotal Cloud Foundry. **(PREMIUM ONLY)**
- [Pivotal Tile](../install/pivotal/index.md): Deploy GitLab as a preconfigured appliance using Ops Manager (BOSH) for Pivotal Cloud Foundry. **(PREMIUM ONLY)**
- [Add License](../user/admin_area/license.md): Upload a license at install time to unlock features that are in paid tiers of GitLab. **(STARTER ONLY)**
### Configuring GitLab
......@@ -86,7 +86,7 @@ Learn how to install, configure, update, and maintain your GitLab instance.
- [GitLab versions and maintenance policy](../policy/maintenance.md): Understand GitLab versions and releases (Major, Minor, Patch, Security), as well as update recommendations.
- [Update GitLab](../update/README.md): Update guides to upgrade your installation to a new version.
- [Downtimeless updates](../update/README.md#upgrading-without-downtime): Upgrade to a newer major, minor, or patch version of GitLab without taking your GitLab instance offline.
- [Upgrading without downtime](../update/README.md#upgrading-without-downtime): Upgrade to a newer major, minor, or patch version of GitLab without taking your GitLab instance offline.
- [Migrate your GitLab CI/CD data to another version of GitLab](../migrate_ci_to_ce/README.md): If you have an old GitLab installation (older than 8.0), follow this guide to migrate your existing GitLab CI/CD data to another version of GitLab.
### Upgrading or downgrading GitLab
......@@ -227,6 +227,6 @@ who are aware of the risks.
- [GitLab Developer Docs](../development/README.md)
- [Repairing and recovering broken Git repositories](https://git.seveas.net/repairing-and-recovering-broken-git-repositories.html)
- [Testing with OpenSSL](https://www.feistyduck.com/library/openssl-cookbook/online/ch-testing-with-openssl.html)
- [Strace zine](https://wizardzines.com/zines/strace/)
- [`Strace` zine](https://wizardzines.com/zines/strace/)
- GitLab.com-specific resources:
- [Group SAML/SCIM setup](troubleshooting/group_saml_scim.md)
......@@ -149,9 +149,9 @@ our AsciiDoc snippets, wikis and repos using delimited blocks:
Alice -> Bob: hi
```
You can also use the `uml::` directive for compatibility with [sphinxcontrib-plantuml](https://pypi.org/project/sphinxcontrib-plantuml/), but please note that we currently only support the `caption` option.
You can also use the `uml::` directive for compatibility with [`sphinxcontrib-plantuml`](https://pypi.org/project/sphinxcontrib-plantuml/), but please note that we currently only support the `caption` option.
The above blocks will be converted to an HTML img tag with source pointing to the
The above blocks will be converted to an HTML image tag with source pointing to the
PlantUML instance. If the PlantUML server is correctly configured, this should
render a nice diagram instead of the block:
......@@ -172,7 +172,7 @@ Some parameters can be added to the AsciiDoc block definition:
- *format*: Can be either `png` or `svg`. Note that `svg` is not supported by
all browsers so use with care. The default is `png`.
- *id*: A CSS id added to the diagram HTML tag.
- *width*: Width attribute added to the img tag.
- *height*: Height attribute added to the img tag.
- *width*: Width attribute added to the image tag.
- *height*: Height attribute added to the image tag.
Markdown does not support any parameters and will always use PNG format.
......@@ -63,13 +63,13 @@ GitLab provides two different options for the uploading mechanism: "Direct uploa
**Option 1. Direct upload**
1. User pushes an lfs file to the GitLab instance
1. User pushes an `lfs` file to the GitLab instance
1. GitLab-workhorse uploads the file directly to the external object storage
1. GitLab-workhorse notifies GitLab-rails that the upload process is complete
**Option 2. Background upload**
1. User pushes an lfs file to the GitLab instance
1. User pushes an `lfs` file to the GitLab instance
1. GitLab-rails stores the file in the local file storage
1. GitLab-rails then uploads the file to the external object storage asynchronously
......@@ -127,7 +127,7 @@ Here is a configuration example with Rackspace Cloud Files.
NOTE: **Note:**
Regardless of whether the container has public access enabled or disabled, Fog will
use the TempURL method to grant access to LFS objects. If you see errors in logs referencing
instantiating storage with a temp-url-key, ensure that you have set they key properly
instantiating storage with a temp-url-key, ensure that you have set the key properly
on the Rackspace API and in `gitlab.rb`. You can verify the value of the key Rackspace
has set by sending a GET request with token header to the service access endpoint URL
and comparing the output of the returned headers.
......@@ -261,7 +261,7 @@ See more information in [!19581](https://gitlab.com/gitlab-org/gitlab-foss/-/mer
## Known limitations
- Support for removing unreferenced LFS objects was added in 8.14 onwards.
- Support for removing unreferenced LFS objects was added in 8.14 onward.
- LFS authentications via SSH was added with GitLab 8.12.
- Only compatible with the Git LFS client versions 1.1.0 and up, or 1.0.2.
- The storage statistics currently count each LFS object multiple times for
......
......@@ -71,3 +71,26 @@ Example response:
}
]
```
## Group deploy tokens
These endpoints require group maintainer access or higher.
### Delete a group deploy token
Removes a deploy token from the group.
```
DELETE /groups/:id/deploy_tokens/:token_id
```
| Attribute | Type | Required | Description |
| --------- | ---- | -------- | ----------- |
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
| `token_id` | integer | yes | The ID of the deploy token |
Example request:
```shell
curl --request DELETE --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/groups/5/deploy_tokens/13"
```
......@@ -34,5 +34,22 @@ module API
present paginate(user_project.deploy_tokens), with: Entities::DeployToken
end
end
params do
requires :id, type: Integer, desc: 'The ID of a group'
end
resource :groups, requirements: API::NAMESPACE_OR_PROJECT_REQUIREMENTS do
desc 'Delete a group deploy token' do
detail 'This feature was introduced in GitLab 12.9'
end
delete ':id/deploy_tokens/:token_id' do
authorize!(:destroy_deploy_token, user_group)
deploy_token = user_group.group_deploy_tokens
.find_by_deploy_token_id!(params[:token_id])
destroy_conditionally!(deploy_token)
end
end
end
end
......@@ -3,10 +3,12 @@
require 'spec_helper'
describe API::DeployTokens do
let(:user) { create(:user) }
let(:creator) { create(:user) }
let(:project) { create(:project, creator_id: creator.id) }
let_it_be(:user) { create(:user) }
let_it_be(:creator) { create(:user) }
let_it_be(:project) { create(:project, creator_id: creator.id) }
let_it_be(:group) { create(:group) }
let!(:deploy_token) { create(:deploy_token, projects: [project]) }
let!(:group_deploy_token) { create(:deploy_token, :group, groups: [group]) }
describe 'GET /deploy_tokens' do
subject do
......@@ -84,4 +86,51 @@ describe API::DeployTokens do
end
end
end
describe 'DELETE /groups/:id/deploy_tokens/:token_id' do
subject do
delete api("/groups/#{group.id}/deploy_tokens/#{group_deploy_token.id}", user)
response
end
context 'when unauthenticated' do
let(:user) { nil }
it { is_expected.to have_gitlab_http_status(:forbidden) }
end
context 'when authenticated as non-admin user' do
before do
group.add_developer(user)
end
it { is_expected.to have_gitlab_http_status(:forbidden) }
end
context 'when authenticated as maintainer' do
before do
group.add_maintainer(user)
end
it 'deletes the deploy token' do
expect { subject }.to change { group.deploy_tokens.count }.by(-1)
expect(group.deploy_tokens).to be_empty
end
context 'invalid request' do
it 'returns bad request with invalid group id' do
delete api("/groups/bad_id/deploy_tokens/#{group_deploy_token.id}", user)
expect(response).to have_gitlab_http_status(:bad_request)
end
it 'returns not found with invalid deploy token id' do
delete api("/groups/#{group.id}/deploy_tokens/bad_id", user)
expect(response).to have_gitlab_http_status(:not_found)
end
end
end
end
end
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment