Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
427a082f7d
commit
033c2c5acd
20 changed files with 163 additions and 80 deletions
|
|
@ -170,7 +170,7 @@ class Group < Namespace
|
|||
notification_settings.find { |n| n.notification_email.present? }&.notification_email
|
||||
end
|
||||
|
||||
def to_reference(_from = nil, full: nil)
|
||||
def to_reference(_from = nil, target_project: nil, full: nil)
|
||||
"#{self.class.reference_prefix}#{full_path}"
|
||||
end
|
||||
|
||||
|
|
|
|||
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Fix moving an issue when there is a group reference
|
||||
merge_request: 30185
|
||||
author:
|
||||
type: fixed
|
||||
5
changelogs/unreleased/dz-remove-legacy-routes.yml
Normal file
5
changelogs/unreleased/dz-remove-legacy-routes.yml
Normal file
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Remove project routes that were deprecated before 12.1
|
||||
merge_request: 26808
|
||||
author:
|
||||
type: removed
|
||||
|
|
@ -0,0 +1,6 @@
|
|||
---
|
||||
title: Update GitLab-managed helm from 2.16.3 to 2.16.6, improving the reliability
|
||||
of GitLab's Kubernetes integration
|
||||
merge_request: 30067
|
||||
author:
|
||||
type: changed
|
||||
|
|
@ -467,11 +467,7 @@ constraints(::Constraints::ProjectUrlConstrainer.new) do
|
|||
# Legacy routes.
|
||||
# Introduced in 12.0.
|
||||
# Should be removed with https://gitlab.com/gitlab-org/gitlab/issues/28848.
|
||||
Gitlab::Routing.redirect_legacy_paths(self, :settings, :branches, :tags,
|
||||
:network, :graphs, :autocomplete_sources,
|
||||
:project_members, :deploy_keys, :deploy_tokens,
|
||||
:labels, :milestones, :services, :boards, :releases,
|
||||
:forks, :group_links, :import, :avatar, :mirror,
|
||||
Gitlab::Routing.redirect_legacy_paths(self, :mirror,
|
||||
:cycle_analytics, :mattermost, :variables, :triggers,
|
||||
:environments, :protected_environments, :error_tracking, :alert_management,
|
||||
:serverless, :clusters, :audit_events, :wikis, :merge_requests,
|
||||
|
|
|
|||
|
|
@ -175,6 +175,9 @@ and expands the `environment:url` value with variables defined in the dotenv fil
|
|||
To use this feature, specify the
|
||||
[`artifacts:reports:dotenv`](yaml/README.md#artifactsreportsdotenv) keyword in `.gitlab-ci.yml`.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an overview, see [Set dynamic URLs after a job finished](https://youtu.be/70jDXtOf4Ig).
|
||||
|
||||
##### Example of setting dynamic environment URLs
|
||||
|
||||
The following example shows a Review App that creates a new environment
|
||||
|
|
|
|||
|
|
@ -43,6 +43,9 @@ Child pipelines work well with other GitLab CI/CD features:
|
|||
All of this will work with the [`include:`](yaml/README.md#include) feature so you can compose
|
||||
the child pipeline configuration.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an overview, see [Parent-Child Pipelines feature demo](https://youtu.be/n8KpBSqZNbk).
|
||||
|
||||
## Examples
|
||||
|
||||
The simplest case is [triggering a child pipeline](yaml/README.md#trigger) using a
|
||||
|
|
@ -136,6 +139,9 @@ your own script to generate a YAML file, which is then [used to trigger a child
|
|||
This technique can be very powerful in generating pipelines targeting content that changed or to
|
||||
build a matrix of targets and architectures.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an overview, see [Create child pipelines using dynamically generated configurations](https://youtu.be/nMdfus2JWHM).
|
||||
|
||||
In GitLab 12.9, the child pipeline could fail to be created in certain cases, causing the parent pipeline to fail.
|
||||
This is [resolved in GitLab 12.10](https://gitlab.com/gitlab-org/gitlab/-/issues/209070).
|
||||
|
||||
|
|
|
|||
|
|
@ -311,10 +311,30 @@ workflow:
|
|||
> - Available for Starter, Premium and Ultimate since 10.6.
|
||||
> - [Moved](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/21603) to GitLab Core in 11.4.
|
||||
|
||||
Using the `include` keyword, you can allow the inclusion of external YAML files.
|
||||
Using the `include` keyword allows the inclusion of external YAML files. This helps
|
||||
to break down the CI/CD configuration into multiple files and increases readability for long configuration files.
|
||||
It is also possible to have template files stored in a central repository and projects include their
|
||||
configuration files. This helps avoid duplicated configuration, for example, global default variables for all projects.
|
||||
|
||||
`include` requires the external YAML file to have the extensions `.yml` or `.yaml`,
|
||||
otherwise the external file will not be included.
|
||||
|
||||
`include` supports the following inclusion methods:
|
||||
|
||||
| Method | Description |
|
||||
|:--------------------------------|:------------------------------------------------------------------|
|
||||
| [`local`](#includelocal) | Include a file from the local project repository. |
|
||||
| [`file`](#includefile) | Include a file from a different project repository. |
|
||||
| [`remote`](#includeremote) | Include a file from a remote URL. Must be publicly accessible. |
|
||||
| [`template`](#includetemplate) | Include templates which are provided by GitLab. |
|
||||
|
||||
See [usage examples](#include-examples).
|
||||
|
||||
NOTE: **Note:**
|
||||
`.gitlab-ci.yml` configuration included by all methods is evaluated at pipeline creation.
|
||||
The configuration is a snapshot in time and persisted in the database. Any changes to
|
||||
referenced `.gitlab-ci.yml` configuration will not be reflected in GitLab until the next pipeline is created.
|
||||
|
||||
The files defined in `include` are:
|
||||
|
||||
- Deep merged with those in `.gitlab-ci.yml`.
|
||||
|
|
@ -330,20 +350,6 @@ Using YAML aliases across different YAML files sourced by `include` is not
|
|||
supported. You must only refer to aliases in the same file. Instead
|
||||
of using YAML anchors, you can use the [`extends` keyword](#extends).
|
||||
|
||||
`include` supports four include methods:
|
||||
|
||||
- [`local`](#includelocal)
|
||||
- [`file`](#includefile)
|
||||
- [`template`](#includetemplate)
|
||||
- [`remote`](#includeremote)
|
||||
|
||||
See [usage examples](#include-examples).
|
||||
|
||||
NOTE: **Note:**
|
||||
`.gitlab-ci.yml` configuration included by all methods is evaluated at pipeline creation.
|
||||
The configuration is a snapshot in time and persisted in the database. Any changes to
|
||||
referenced `.gitlab-ci.yml` configuration will not be reflected in GitLab until the next pipeline is created.
|
||||
|
||||
#### `include:local`
|
||||
|
||||
`include:local` includes a file from the same repository as `.gitlab-ci.yml`.
|
||||
|
|
@ -366,6 +372,15 @@ include:
|
|||
- local: '/templates/.gitlab-ci-template.yml'
|
||||
```
|
||||
|
||||
TIP: **Tip:**
|
||||
Local includes can be used as a replacement for symbolic links which are not followed.
|
||||
|
||||
This can be defined as a short local include:
|
||||
|
||||
```yaml
|
||||
include: '.gitlab-ci-production.yml'
|
||||
```
|
||||
|
||||
#### `include:file`
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/53903) in GitLab 11.7.
|
||||
|
|
@ -401,6 +416,21 @@ All [nested includes](#nested-includes) will be executed in the scope of the tar
|
|||
so it is possible to use local (relative to target project), project, remote
|
||||
or template includes.
|
||||
|
||||
#### `include:remote`
|
||||
|
||||
`include:remote` can be used to include a file from a different location,
|
||||
using HTTP/HTTPS, referenced by using the full URL. The remote file must be
|
||||
publicly accessible through a simple GET request as authentication schemas
|
||||
in the remote URL are not supported. For example:
|
||||
|
||||
```yaml
|
||||
include:
|
||||
- remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'
|
||||
```
|
||||
|
||||
All [nested includes](#nested-includes) will be executed without context as public user, so only another remote
|
||||
or public project, or template, is allowed.
|
||||
|
||||
#### `include:template`
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/53445) in GitLab 11.7.
|
||||
|
|
@ -427,21 +457,6 @@ include:
|
|||
All [nested includes](#nested-includes) will be executed only with the permission of the user,
|
||||
so it is possible to use project, remote or template includes.
|
||||
|
||||
#### `include:remote`
|
||||
|
||||
`include:remote` can be used to include a file from a different location,
|
||||
using HTTP/HTTPS, referenced by using the full URL. The remote file must be
|
||||
publicly accessible through a simple GET request as authentication schemas
|
||||
in the remote URL is not supported. For example:
|
||||
|
||||
```yaml
|
||||
include:
|
||||
- remote: 'https://gitlab.com/awesome-project/raw/master/.gitlab-ci-template.yml'
|
||||
```
|
||||
|
||||
All nested includes will be executed without context as public user, so only another remote,
|
||||
or public project, or template is allowed.
|
||||
|
||||
#### Nested includes
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/56836) in GitLab 11.9.
|
||||
|
|
|
|||
|
|
@ -118,8 +118,32 @@ It's encouraged to only have the `idempotent!` call in the top-most worker class
|
|||
the `perform` method is defined in another class or module.
|
||||
|
||||
NOTE: **Note:**
|
||||
Note that a cop will fail if the worker class is not marked as idempotent.
|
||||
Consider skipping the cop if you're not confident your job can safely run multiple times.
|
||||
If the worker class is not marked as idempotent, a cop will fail.
|
||||
Consider skipping the cop if you're not confident your job can safely
|
||||
run multiple times.
|
||||
|
||||
### Deduplication
|
||||
|
||||
When a job for an idempotent worker is enqueued while another
|
||||
unstarted job is already in the queue, GitLab drops the second
|
||||
job. The work is skipped because the same work would be
|
||||
done by the job that was scheduled first; by the time the second
|
||||
job executed, the first job would do nothing.
|
||||
|
||||
For example, `AuthorizedProjectsWorker` takes a user ID. When the
|
||||
worker runs, it recalculates a user's authorizations. GitLab schedules
|
||||
this job each time an action potentially changes a user's
|
||||
authorizations. If the same user is added to two projects at the
|
||||
same time, the second job can be skipped if the first job hasn't
|
||||
begun, because when the first job runs, it creates the
|
||||
authorizations for both projects.
|
||||
|
||||
GitLab doesn't skip jobs scheduled in the future, as we assume that
|
||||
the state will have changed by the time the job is scheduled to
|
||||
execute.
|
||||
|
||||
More [deduplication strategies have been suggested](https://gitlab.com/gitlab-com/gl-infra/scalability/issues/195). If you are implementing a worker that
|
||||
could benefit from a different strategy, please comment in the issue.
|
||||
|
||||
## Job urgency
|
||||
|
||||
|
|
|
|||
|
|
@ -9,11 +9,18 @@ to simplify the setup and execution of a mature & modern software development li
|
|||
|
||||
## Overview
|
||||
|
||||
With Auto DevOps, the software development process becomes easier to set up
|
||||
as every project can have a complete workflow from verification to monitoring
|
||||
with minimal configuration. Just push your code and GitLab takes
|
||||
care of everything else. This makes it easier to start new projects and brings
|
||||
consistency to how applications are set up throughout a company.
|
||||
You can spend a lot of effort to set up the workflow and processes required to
|
||||
build, deploy. and monitor your project. It gets worse when your company has
|
||||
hundreds, if not thousands, of projects to maintain. With new projects
|
||||
constantly starting up, the entire software development process becomes
|
||||
impossibly complex to manage.
|
||||
|
||||
Auto DevOps provides you a seamless software development process by
|
||||
automatically detecting all dependencies and language technologies required to
|
||||
test, build, package, deploy, and monitor every project with minimal
|
||||
configuration. Automation enables consistency across your projects, seamless
|
||||
management of processes, and faster creation of new projects: push your code,
|
||||
and GitLab does the rest, improving your productivity and efficiency.
|
||||
|
||||
For an introduction to Auto DevOps, watch [AutoDevOps in GitLab 11.0](https://youtu.be/0Tc0YYBxqi4).
|
||||
|
||||
|
|
|
|||
Binary file not shown.
|
After Width: | Height: | Size: 50 KiB |
|
|
@ -314,6 +314,16 @@ To change your WAF's mode:
|
|||
1. Under **Global default**, select your desired mode.
|
||||
1. Click **Save changes**.
|
||||
|
||||
##### WAF version updates
|
||||
|
||||
Enabling, disabling, or changing the logging mode for **ModSecurity** is only allowed within same version of [Ingress](#ingress) due to limitations in [Helm](https://helm.sh/) which might be overcome in future releases.
|
||||
|
||||
**ModSecurity** UI controls are disabled if the version deployed differs from the one available in GitLab, while actions at the [Ingress](#ingress) level, such as uninstalling, can still be performed:
|
||||
|
||||
|
||||
|
||||
Updating [Ingress](#ingress) to the most recent version enables you to take advantage of bug fixes, security fixes, and performance improvements. To update [Ingress application](#ingress), you must first uninstall it, and then re-install it as described in [Install ModSecurity](../../topics/web_application_firewall/quick_start_guide.md).
|
||||
|
||||
##### Viewing Web Application Firewall traffic
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/14707) in [GitLab Ultimate](https://about.gitlab.com/pricing/) 12.9.
|
||||
|
|
@ -487,7 +497,11 @@ and you will have access to more advanced querying capabilities.
|
|||
|
||||
Log data is automatically deleted after 30 days using [Curator](https://www.elastic.co/guide/en/elasticsearch/client/curator/5.5/about.html).
|
||||
|
||||
To enable log shipping, install Elastic Stack into the cluster with the **Install** button.
|
||||
To enable log shipping:
|
||||
|
||||
1. Navigate to **{cloud-gear}** **Operations > Kubernetes**.
|
||||
1. In **Kubernetes Cluster**, select a cluster.
|
||||
1. In the **Applications** section, find **Elastic Stack** and click **Install**.
|
||||
|
||||
NOTE: **Note:**
|
||||
The [`stable/elastic-stack`](https://github.com/helm/charts/tree/master/stable/elastic-stack)
|
||||
|
|
@ -790,10 +804,12 @@ available configuration options.
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/22) in GitLab 12.8.
|
||||
|
||||
[Cilium](https://cilium.io/) is a networking plugin for Kubernetes
|
||||
that you can use to implement support for
|
||||
[NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
|
||||
resources. For more information on [Network Policies](../../topics/autodevops/stages.md#network-policy), see the documentation.
|
||||
[Cilium](https://cilium.io/) is a networking plugin for Kubernetes that you can use to implement
|
||||
support for [NetworkPolicy](https://kubernetes.io/docs/concepts/services-networking/network-policies/)
|
||||
resources. For more information, see [Network Policies](../../topics/autodevops/stages.md#network-policy).
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an overview, see the [Container Network Security Demo for GitLab 12.8](https://www.youtube.com/watch?v=pgUEdhdhoUI).
|
||||
|
||||
Enable Cilium in the `.gitlab/managed-apps/config.yaml` file to install it:
|
||||
|
||||
|
|
|
|||
|
|
@ -4,7 +4,7 @@
|
|||
> - [Moved](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25455) to [GitLab Core](https://about.gitlab.com/pricing/) 12.9.
|
||||
|
||||
GitLab makes it easy to view the logs of running pods in [connected Kubernetes clusters](index.md).
|
||||
By displaying the logs directly in GitLab, developers can avoid having to manage console tools or jump to a different interface.
|
||||
By displaying the logs directly in GitLab in the **Log Explorer**, developers can avoid having to manage console tools or jump to a different interface.
|
||||
|
||||
NOTE: **Kubernetes + GitLab**
|
||||
Everything you need to build, test, deploy, and run your app at scale.
|
||||
|
|
@ -12,10 +12,14 @@ Everything you need to build, test, deploy, and run your app at scale.
|
|||
|
||||
## Overview
|
||||
|
||||
[Kubernetes](https://kubernetes.io) logs can be viewed directly within GitLab.
|
||||
[Kubernetes](https://kubernetes.io) logs can be viewed directly within GitLab with
|
||||
the **Log Explorer**.
|
||||
|
||||
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
To learn more, see [APM - Log Explorer](https://www.youtube.com/watch?v=hWclZHA7Dgw).
|
||||
|
||||
## Requirements
|
||||
|
||||
[Deploying to a Kubernetes environment](../deploy_boards.md#enabling-deploy-boards) is required in order to be able to use Logs.
|
||||
|
|
@ -30,7 +34,8 @@ You can access them in two ways.
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/22011) in GitLab 12.5.
|
||||
|
||||
Go to **{cloud-gear}** **Operations > Logs** on the sidebar menu.
|
||||
Go to **{cloud-gear}** **Operations > Pod logs** on the sidebar menu to display
|
||||
the **Log Explorer**.
|
||||
|
||||
|
||||
|
||||
|
|
@ -42,11 +47,11 @@ Logs can be displayed by clicking on a specific pod from [Deploy Boards](../depl
|
|||
1. On the **Environments** page, you should see the status of the environment's pods with [Deploy Boards](../deploy_boards.md).
|
||||
1. When mousing over the list of pods, a tooltip will appear with the exact pod name and status.
|
||||
|
||||
1. Click on the desired pod to bring up the logs view.
|
||||
1. Click on the desired pod to display the **Log Explorer**.
|
||||
|
||||
### Logs view
|
||||
|
||||
The logs view lets you filter the logs by:
|
||||
The **Log Explorer** lets you filter the logs by:
|
||||
|
||||
- Pods.
|
||||
- [From GitLab 12.4](https://gitlab.com/gitlab-org/gitlab/issues/5769), environments.
|
||||
|
|
@ -63,9 +68,10 @@ Support for historical data is coming [in a future release](https://gitlab.com/g
|
|||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/197879) in GitLab 12.8.
|
||||
|
||||
When you enable [Elastic Stack](../../clusters/applications.md#elastic-stack) on your cluster, you can filter by date.
|
||||
When you enable [Elastic Stack](../../clusters/applications.md#elastic-stack) on your cluster,
|
||||
you can filter logs displayed in the **Log Explorer** by date.
|
||||
|
||||
Click on **Show last** to see the available options.
|
||||
Click **Show last** in the **Log Explorer** to see the available options.
|
||||
|
||||
### Full text search
|
||||
|
||||
|
|
|
|||
|
|
@ -107,6 +107,9 @@ push images to your Container Registry.
|
|||
A deploy token created at the group level can be used across all projects that
|
||||
belong either to the specific group or to one of its subgroups.
|
||||
|
||||
<i class="fa fa-youtube-play youtube" aria-hidden="true"></i>
|
||||
For an overview, see [Group Deploy Tokens](https://youtu.be/8kxTJvaD9ks).
|
||||
|
||||
To use a group deploy token:
|
||||
|
||||
1. [Create](#creating-a-deploy-token) a deploy token for a group.
|
||||
|
|
|
|||
|
|
@ -49,7 +49,7 @@ For instance, consider the following workflow:
|
|||
feature in your app faster.
|
||||
1. With Code Quality reports, they analyze how their implementation is impacting
|
||||
the code quality.
|
||||
1. The metrics show that their code degrade the quality in 10 points.
|
||||
1. The metrics show that their code degrades the quality by 10 points.
|
||||
1. You ask a co-worker to help them with this modification.
|
||||
1. They both work on the changes until Code Quality report displays no
|
||||
degradations, only improvements.
|
||||
|
|
|
|||
|
|
@ -61,7 +61,7 @@ according to the type of domain you want to use with your Pages site:
|
|||
- [For both](#for-both-root-and-subdomains).
|
||||
|
||||
NOTE: **Note:**
|
||||
You can [configure IPv6 on self-managed instances].(../../../../administration/pages/index.md#advanced-configuration),
|
||||
You can [configure IPv6 on self-managed instances](../../../../administration/pages/index.md#advanced-configuration),
|
||||
but IPv6 is not currently configured for Pages on GitLab.com.
|
||||
Follow [this issue](https://gitlab.com/gitlab-org/gitlab/-/issues/214718) for details.
|
||||
|
||||
|
|
|
|||
|
|
@ -3,7 +3,7 @@
|
|||
module Gitlab
|
||||
module Kubernetes
|
||||
module Helm
|
||||
HELM_VERSION = '2.16.3'
|
||||
HELM_VERSION = '2.16.6'
|
||||
KUBECTL_VERSION = '1.13.12'
|
||||
NAMESPACE = 'gitlab-managed-apps'
|
||||
NAMESPACE_LABELS = { 'app.gitlab.com/managed_by' => :gitlab }.freeze
|
||||
|
|
|
|||
|
|
@ -147,6 +147,18 @@ describe Gitlab::Gfm::ReferenceRewriter do
|
|||
it { is_expected.to eq text }
|
||||
end
|
||||
|
||||
context 'when referring to a group' do
|
||||
let(:text) { "group @#{group.full_path}" }
|
||||
|
||||
it { is_expected.to eq text }
|
||||
end
|
||||
|
||||
context 'when referring to a user' do
|
||||
let(:text) { "user @#{user.full_path}" }
|
||||
|
||||
it { is_expected.to eq text }
|
||||
end
|
||||
|
||||
context 'when referable has a nil reference' do
|
||||
before do
|
||||
create(:milestone, title: '9.0', project: old_project)
|
||||
|
|
|
|||
|
|
@ -32,7 +32,7 @@ describe Gitlab::Kubernetes::Helm::Pod do
|
|||
it 'generates the appropriate specifications for the container' do
|
||||
container = subject.generate.spec.containers.first
|
||||
expect(container.name).to eq('helm')
|
||||
expect(container.image).to eq('registry.gitlab.com/gitlab-org/cluster-integration/helm-install-image/releases/2.16.3-kube-1.13.12')
|
||||
expect(container.image).to eq('registry.gitlab.com/gitlab-org/cluster-integration/helm-install-image/releases/2.16.6-kube-1.13.12')
|
||||
expect(container.env.count).to eq(3)
|
||||
expect(container.env.map(&:name)).to match_array([:HELM_VERSION, :TILLER_NAMESPACE, :COMMAND_SCRIPT])
|
||||
expect(container.command).to match_array(["/bin/sh"])
|
||||
|
|
|
|||
|
|
@ -143,8 +143,6 @@ describe 'project routing' do
|
|||
expect(get("/gitlab/gitlabhq/-/autocomplete_sources/#{action}")).to route_to("projects/autocomplete_sources##{action}", namespace_id: 'gitlab', project_id: 'gitlabhq')
|
||||
end
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/autocomplete_sources/labels", "/gitlab/gitlabhq/-/autocomplete_sources/labels"
|
||||
end
|
||||
|
||||
# pages_project_wikis GET /:project_id/wikis/pages(.:format) projects/wikis#pages
|
||||
|
|
@ -220,8 +218,6 @@ describe 'project routing' do
|
|||
expect(delete('/gitlab/gitlabhq/-/branches/feature%2B45/foo/bar/baz')).to route_to('projects/branches#destroy', namespace_id: 'gitlab', project_id: 'gitlabhq', id: 'feature+45/foo/bar/baz')
|
||||
expect(delete('/gitlab/gitlabhq/-/branches/feature@45/foo/bar/baz')).to route_to('projects/branches#destroy', namespace_id: 'gitlab', project_id: 'gitlabhq', id: 'feature@45/foo/bar/baz')
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/branches", "/gitlab/gitlabhq/-/branches"
|
||||
end
|
||||
|
||||
describe Projects::TagsController, 'routing' do
|
||||
|
|
@ -249,8 +245,6 @@ describe 'project routing' do
|
|||
let(:controller) { 'deploy_keys' }
|
||||
let(:controller_path) { '/-/deploy_keys' }
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/deploy_keys", "/gitlab/gitlabhq/-/deploy_keys"
|
||||
end
|
||||
|
||||
# project_protected_branches GET /:project_id/protected_branches(.:format) protected_branches#index
|
||||
|
|
@ -487,7 +481,6 @@ describe 'project routing' do
|
|||
let(:controller_path) { '/-/project_members' }
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/project_members", "/gitlab/gitlabhq/-/project_members"
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/-/settings/members", "/gitlab/gitlabhq/-/project_members"
|
||||
end
|
||||
|
||||
|
|
@ -509,8 +502,6 @@ describe 'project routing' do
|
|||
it 'to #promote' do
|
||||
expect(post('/gitlab/gitlabhq/-/milestones/1/promote')).to route_to('projects/milestones#promote', namespace_id: 'gitlab', project_id: 'gitlabhq', id: "1")
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/milestones", "/gitlab/gitlabhq/-/milestones"
|
||||
end
|
||||
|
||||
# project_labels GET /:project_id/labels(.:format) labels#index
|
||||
|
|
@ -518,8 +509,6 @@ describe 'project routing' do
|
|||
it 'to #index' do
|
||||
expect(get('/gitlab/gitlabhq/-/labels')).to route_to('projects/labels#index', namespace_id: 'gitlab', project_id: 'gitlabhq')
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/labels", "/gitlab/gitlabhq/-/labels"
|
||||
end
|
||||
|
||||
# sort_project_issues POST /:project_id/issues/sort(.:format) issues#sort
|
||||
|
|
@ -723,8 +712,6 @@ describe 'project routing' do
|
|||
expect(get('/gitlab/gitlabhq/-/network/ends-with.json')).to route_to('projects/network#show', namespace_id: 'gitlab', project_id: 'gitlabhq', id: 'ends-with.json')
|
||||
expect(get('/gitlab/gitlabhq/-/network/master?format=json')).to route_to('projects/network#show', namespace_id: 'gitlab', project_id: 'gitlabhq', id: 'master', format: 'json')
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/network/master", "/gitlab/gitlabhq/-/network/master"
|
||||
end
|
||||
|
||||
describe Projects::GraphsController, 'routing' do
|
||||
|
|
@ -733,8 +720,6 @@ describe 'project routing' do
|
|||
expect(get('/gitlab/gitlabhq/-/graphs/ends-with.json')).to route_to('projects/graphs#show', namespace_id: 'gitlab', project_id: 'gitlabhq', id: 'ends-with.json')
|
||||
expect(get('/gitlab/gitlabhq/-/graphs/master?format=json')).to route_to('projects/graphs#show', namespace_id: 'gitlab', project_id: 'gitlabhq', id: 'master', format: 'json')
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/graphs/master", "/gitlab/gitlabhq/-/graphs/master"
|
||||
end
|
||||
|
||||
describe Projects::ForksController, 'routing' do
|
||||
|
|
@ -745,8 +730,6 @@ describe 'project routing' do
|
|||
it 'to #create' do
|
||||
expect(post('/gitlab/gitlabhq/-/forks')).to route_to('projects/forks#create', namespace_id: 'gitlab', project_id: 'gitlabhq')
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/forks", "/gitlab/gitlabhq/-/forks"
|
||||
end
|
||||
|
||||
# project_avatar DELETE /project/avatar(.:format) projects/avatars#destroy
|
||||
|
|
@ -755,8 +738,6 @@ describe 'project routing' do
|
|||
expect(delete('/gitlab/gitlabhq/-/avatar')).to route_to(
|
||||
'projects/avatars#destroy', namespace_id: 'gitlab', project_id: 'gitlabhq')
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/avatar", "/gitlab/gitlabhq/-/avatar"
|
||||
end
|
||||
|
||||
describe Projects::PagesDomainsController, 'routing' do
|
||||
|
|
@ -802,8 +783,6 @@ describe 'project routing' do
|
|||
expect(get('/gitlab/gitlabhq/-/settings/repository')).to route_to('projects/settings/repository#show', namespace_id: 'gitlab', project_id: 'gitlabhq')
|
||||
end
|
||||
|
||||
it_behaves_like 'redirecting a legacy project path', "/gitlab/gitlabhq/settings/repository", "/gitlab/gitlabhq/-/settings/repository"
|
||||
|
||||
it 'to repository#create_deploy_token' do
|
||||
expect(post('gitlab/gitlabhq/-/settings/ci_cd/deploy_token/create')).to route_to('projects/settings/repository#create_deploy_token', namespace_id: 'gitlab', project_id: 'gitlabhq')
|
||||
end
|
||||
|
|
|
|||
Loading…
Reference in a new issue