diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-09 03:08:14 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2020-03-09 03:08:14 +0300 |
commit | ed4df05ce917d6cf175aeb508b0485ae5f281a0a (patch) | |
tree | 9313abd8fd41a78eb2bf1ffd0f95f10b69cd25cb | |
parent | 1bdb3fe3821fc3d222361d8b2e2ec2fea2915372 (diff) |
Add latest changes from gitlab-org/gitlab@master
19 files changed, 132 insertions, 37 deletions
diff --git a/app/policies/group_policy.rb b/app/policies/group_policy.rb index 3bb7ab05be2..2e3abf2b75a 100644 --- a/app/policies/group_policy.rb +++ b/app/policies/group_policy.rb @@ -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 diff --git a/changelogs/unreleased/21811-group-delete-deploy-token.yml b/changelogs/unreleased/21811-group-delete-deploy-token.yml new file mode 100644 index 00000000000..9f359c7edcc --- /dev/null +++ b/changelogs/unreleased/21811-group-delete-deploy-token.yml @@ -0,0 +1,5 @@ +--- +title: Add API endpoint for deleting group deploy tokens +merge_request: 25222 +author: +type: added diff --git a/doc/administration/geo/disaster_recovery/background_verification.md b/doc/administration/geo/disaster_recovery/background_verification.md index 2caaaac2b9d..6852d08cc07 100644 --- a/doc/administration/geo/disaster_recovery/background_verification.md +++ b/doc/administration/geo/disaster_recovery/background_verification.md @@ -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: diff --git a/doc/administration/geo/disaster_recovery/planned_failover.md b/doc/administration/geo/disaster_recovery/planned_failover.md index bfeb202dd9a..8af60a42fbb 100644 --- a/doc/administration/geo/disaster_recovery/planned_failover.md +++ b/doc/administration/geo/disaster_recovery/planned_failover.md @@ -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. diff --git a/doc/administration/geo/replication/configuration.md b/doc/administration/geo/replication/configuration.md index 74ece38d793..1434eeb61af 100644 --- a/doc/administration/geo/replication/configuration.md +++ b/doc/administration/geo/replication/configuration.md @@ -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 diff --git a/doc/administration/geo/replication/database.md b/doc/administration/geo/replication/database.md index 48681d03838..f25aa0e5da8 100644 --- a/doc/administration/geo/replication/database.md +++ b/doc/administration/geo/replication/database.md @@ -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 \ diff --git a/doc/administration/geo/replication/troubleshooting.md b/doc/administration/geo/replication/troubleshooting.md index 2eeca41724e..6a62ce23d0d 100644 --- a/doc/administration/geo/replication/troubleshooting.md +++ b/doc/administration/geo/replication/troubleshooting.md @@ -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`. diff --git a/doc/administration/gitaly/reference.md b/doc/administration/gitaly/reference.md index 2c5e54743c3..6b6919247fe 100644 --- a/doc/administration/gitaly/reference.md +++ b/doc/administration/gitaly/reference.md @@ -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 diff --git a/doc/administration/high_availability/database.md b/doc/administration/high_availability/database.md index 596df656e2e..bb07fdbbb6e 100644 --- a/doc/administration/high_availability/database.md +++ b/doc/administration/high_availability/database.md @@ -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 diff --git a/doc/administration/high_availability/nfs.md b/doc/administration/high_availability/nfs.md index 18dbdf8d902..e8b6c9af879 100644 --- a/doc/administration/high_availability/nfs.md +++ b/doc/administration/high_availability/nfs.md @@ -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 diff --git a/doc/administration/high_availability/nfs_host_client_setup.md b/doc/administration/high_availability/nfs_host_client_setup.md index 75dec1eef29..ddc58fc0db7 100644 --- a/doc/administration/high_availability/nfs_host_client_setup.md +++ b/doc/administration/high_availability/nfs_host_client_setup.md @@ -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: diff --git a/doc/administration/high_availability/redis.md b/doc/administration/high_availability/redis.md index 79082fefdd9..8fb25f958ce 100644 --- a/doc/administration/high_availability/redis.md +++ b/doc/administration/high_availability/redis.md @@ -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. --- diff --git a/doc/administration/housekeeping.md b/doc/administration/housekeeping.md index ca3480f1146..4a2e2b9aac9 100644 --- a/doc/administration/housekeeping.md +++ b/doc/administration/housekeeping.md @@ -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. diff --git a/doc/administration/index.md b/doc/administration/index.md index 0028f7d8a1d..4ca03fa2669 100644 --- a/doc/administration/index.md +++ b/doc/administration/index.md @@ -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) diff --git a/doc/administration/integration/plantuml.md b/doc/administration/integration/plantuml.md index 9b8d3ac2efe..144076ccb79 100644 --- a/doc/administration/integration/plantuml.md +++ b/doc/administration/integration/plantuml.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. diff --git a/doc/administration/lfs/lfs_administration.md b/doc/administration/lfs/lfs_administration.md index 7900ec13c02..d8631b05c14 100644 --- a/doc/administration/lfs/lfs_administration.md +++ b/doc/administration/lfs/lfs_administration.md @@ -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 diff --git a/doc/api/deploy_tokens.md b/doc/api/deploy_tokens.md index ed05f46dae0..ec7c94a6a02 100644 --- a/doc/api/deploy_tokens.md +++ b/doc/api/deploy_tokens.md @@ -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" +``` diff --git a/lib/api/deploy_tokens.rb b/lib/api/deploy_tokens.rb index 3224157ca05..e10a12b6c46 100644 --- a/lib/api/deploy_tokens.rb +++ b/lib/api/deploy_tokens.rb @@ -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 diff --git a/spec/requests/api/deploy_tokens_spec.rb b/spec/requests/api/deploy_tokens_spec.rb index 9aa181db7fc..14153fae42f 100644 --- a/spec/requests/api/deploy_tokens_spec.rb +++ b/spec/requests/api/deploy_tokens_spec.rb @@ -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 |