Commit e3821cfa authored by GitLab Bot's avatar GitLab Bot
Browse files

Add latest changes from gitlab-org/gitlab@master

parent f8c93588acfc
......@@ -92,7 +92,10 @@ def predefined_variables(project:, environment_name:, kubernetes_namespace: nil)
def calculate_reactive_cache_for(environment)
return unless enabled?
{ pods: read_pods(environment.deployment_namespace) }
pods = read_pods(environment.deployment_namespace)
# extract_relevant_pod_data avoids uploading all the pod info into ReactiveCaching
{ pods: extract_relevant_pod_data(pods) }
end
def terminals(environment, data)
......@@ -203,6 +206,21 @@ def prevent_modification
def nullify_blank_namespace
self.namespace = nil if namespace.blank?
end
def extract_relevant_pod_data(pods)
pods.map do |pod|
{
'metadata' => pod.fetch('metadata', {})
.slice('name', 'generateName', 'labels', 'annotations', 'creationTimestamp'),
'status' => pod.fetch('status', {}).slice('phase'),
'spec' => {
'containers' => pod.fetch('spec', {})
.fetch('containers', [])
.map { |c| c.slice('name') }
}
}
end
end
end
end
end
......
......@@ -128,10 +128,6 @@ def calculate_reactive_cache(request, opts)
end
end
def expire_issues_cache
Rails.cache.delete_matched(expand_cache_key('list_issues'))
end
# http://HOST/api/0/projects/ORG/PROJECT
# ->
# http://HOST/ORG/PROJECT
......@@ -148,12 +144,6 @@ def api_host
private
def expand_cache_key(resource_prefix)
klass_key = self.class.reactive_cache_key.call(self).join(':')
"#{klass_key}:#{resource_prefix}*"
end
def add_gitlab_issue_details(issue)
issue.gitlab_commit = match_gitlab_commit(issue.first_release_version)
issue.gitlab_commit_path = project_commit_path(project, issue.gitlab_commit) if issue.gitlab_commit
......
......@@ -2,12 +2,35 @@
module ErrorTracking
class IssueDetailsService < ErrorTracking::BaseService
include Gitlab::Routing
include Gitlab::Utils::StrongMemoize
private
def perform
response = project_error_tracking_setting.issue_details(issue_id: params[:issue_id])
compose_response(response)
compose_response(response) do
# The gitlab_issue attribute can contain an absolute GitLab url from the Sentry Client
# here we overwrite that in favor of our own data if we have it
response[:issue].gitlab_issue = gitlab_issue_url if gitlab_issue_url
end
end
def gitlab_issue_url
strong_memoize(:gitlab_issue_url) do
# Use the absolute url to match the GitLab issue url that the Sentry api provides
project_issue_url(project, gitlab_issue.iid) if gitlab_issue
end
end
def gitlab_issue
strong_memoize(:gitlab_issue) do
SentryIssueFinder
.new(project, current_user: current_user)
.execute(params[:issue_id])
&.issue
end
end
def parse_response(response)
......
......@@ -2,8 +2,6 @@
module ErrorTracking
class IssueUpdateService < ErrorTracking::BaseService
include ::Gitlab::Utils::StrongMemoize
private
def perform
......@@ -14,14 +12,14 @@ def perform
compose_response(response) do
response[:closed_issue_iid] = update_related_issue&.iid
project_error_tracking_setting.expire_issues_cache
end
end
def update_related_issue
return if related_issue.nil?
issue = related_issue
return unless issue
close_and_create_note(related_issue)
close_and_create_note(issue)
end
def close_and_create_note(issue)
......@@ -45,12 +43,10 @@ def create_system_note(issue)
end
def related_issue
strong_memoize(:related_issue) do
SentryIssueFinder
.new(project, current_user: current_user)
.execute(params[:issue_id])
&.issue
end
SentryIssueFinder
.new(project, current_user: current_user)
.execute(params[:issue_id])
&.issue
end
def resolving?
......
---
title: Include issues created in GitLab on error tracking details page
merge_request: 23605
author:
type: changed
......@@ -61,9 +61,9 @@ By default, a **Create issue** button is displayed:
![Error Details without Issue Link](img/error_details_v12_7.png)
If you create a GitLab issue from the error, the **Create issue** button will change to a **View issue** button:
If you create a GitLab issue from the error, the **Create issue** button will change to a **View issue** button and a link to the GitLab issue will surface within the error detail section:
![Error Details with Issue Link](img/error_details_with_issue_v12_7.png)
![Error Details with Issue Link](img/error_details_with_issue_v12_8.png)
## Taking Action on errors
......
......@@ -107,6 +107,16 @@ For private projects, the number of Releases is displayed to users with Reporter
[permissions](../../permissions.md#releases-permissions) or higher. For public projects,
it is displayed to every user regardless of their permission level.
### Upcoming Releases
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/issues/38105) in GitLab 12.1.
A Release may be created ahead of time by specifying a future `released_at` date. Until
the `released_at` date and time is reached, an **Upcoming Release** badge will appear next to the
Release tag. Once the `released_at` date and time has passed, the badge is automatically removed.
![An upcoming release](img/upcoming_release_v12_7.png)
## Editing a release
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26016) in GitLab 12.6.
......@@ -245,6 +255,19 @@ Please note that Release Evidence's data is collected regardless of this
feature flag, which only enables or disables the display of the data on the
Releases page.
### Scheduled Evidence creation
> [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/23697) in GitLab 12.8.
When the `released_at` date and time is not provided, the date and time of Release
creation is used. The Evidence collection background job is immediately executed.
If a future `released_at` is specified, the Release becomes an **Upcoming Release**. In this
case, the Evidence is scheduled to be collected at the `released_at` date and time, via a
background job.
If a past `released_at` is used, no Evidence is collected for the Release.
<!-- ## Troubleshooting
Include any troubleshooting steps that you can foresee. If you know beforehand what issues
......
......@@ -5,60 +5,56 @@ disqus_identifier: 'https://docs.gitlab.com/ee/workflow/forking_workflow.html'
# Project forking workflow
Forking a project to your own namespace is useful if you have no write
access to the project you want to contribute to. If you do have write
access to the project you want to contribute to. Even if you do have write
access or can request it, we recommend working together in the same
repository since it is simpler. See our [GitLab Flow](../../../topics/gitlab_flow.md)
document more information about using branches to work together.
## Creating a fork
Forking a project is in most cases a two-step process.
Forking a project is, in most cases, a two-step process.
1. Click on the fork button located in between the star and clone buttons on the project's home page.
1. On the project's home page, in the top right, click the **Fork** button.
![Fork button](img/forking_workflow_fork_button.png)
1. Once you do that, you'll be presented with a screen where you can choose
the namespace to fork to. Only namespaces (groups and your own
namespace) where you have write access to, will be shown. Click on the
namespace to create your fork there.
1. Click a namespace to fork to. Only namespaces you have Developer and higher [permissions](../../permissions.md) for are shown.
NOTE: **Note:**
The project path must be unique within the namespace.
![Choose namespace](img/forking_workflow_choose_namespace.png)
**Note:**
If the namespace you chose to fork the project to has another project with
the same path name, you will be presented with a warning that the forking
could not be completed. Try to resolve the error before repeating the forking
process.
The fork is created. The permissions you have in the namespace are the permissions you will have in the fork.
CAUTION: **CAUTION:**
In GitLab 12.6 and later, when project owners [reduce a project's visibility](../../../public_access/public_access.md#reducing-visibility),
it **removes the relationship** between a project and all its forks.
![Path taken error](img/forking_workflow_path_taken_error.png)
## Repository mirroring
After the forking is done, you can start working on the newly created
repository. There, you will have full [Owner](../../permissions.md)
access, so you can set it up as you please.
You can use [repository mirroring](repository_mirroring.md) to keep your fork synced with the original repository. You can also use `git remote add upstream` to achieve the same result.
CAUTION: **CAUTION:**
From GitLab 12.6 onward, if the [visibility of an upstream project is reduced](../../../public_access/public_access.md#reducing-visibility)
in any way, the fork relationship with all its forks will be removed.
The main difference is that with repository mirroring your remote fork will be automatically kept up-to-date.
Without mirroring, to work locally you'll have to user `git pull` to update your local repo with the fork on GitLab. You'll have to fetch locally and push it back to the remote repo to update it.
CAUTION: **Caution:**
[Repository mirroring](repository_mirroring.md) will help to keep your fork synced with the original repository.
Before approving a merge request you'll likely to be asked to sync before getting approval, hence automating it is recommend.
With mirroring, before approving a merge request you'll likely to be asked to sync, hence automating it is recommend.
Read more about [How to keep your fork up to date with its origin](https://about.gitlab.com/blog/2016/12/01/how-to-keep-your-fork-up-to-date-with-its-origin/).
## Merging upstream
Once you are ready to send your code back to the main project, you need
to create a merge request. Choose your forked project's main branch as
the source and the original project's main branch as the destination and
create the [merge request](../merge_requests/index.md).
When you are ready to send your code back to the upstream project,
[create a merge request](../merge_requests/creating_merge_requests.md). For **Source branch**,
choose your forked project's branch. For **Target branch**, choose the original project's branch.
![Selecting branches](img/forking_workflow_branch_select.png)
You can then assign the merge request to someone to have them review
your changes. Upon pressing the 'Submit Merge Request' button, your
changes will be added to the repository and branch you're merging into.
![New merge request](img/forking_workflow_merge_request.png)
Then you can add labels, a milestone, and assign the merge request to someone who can review
your changes. Then click **Submit merge request** to conclude the process. When successfully merged, your
changes are added to the repository and branch you're merging into.
## Removing a fork relationship
......
......@@ -6,7 +6,7 @@ module Gitlab
module Graphql
module QueryAnalyzers
class RecursionAnalyzer
IGNORED_FIELDS = %w(node edges ofType).freeze
IGNORED_FIELDS = %w(node edges nodes ofType).freeze
RECURSION_THRESHOLD = 2
def initial_value(query)
......
#!/bin/sh
output=`git grep -En '^<<<<<<< ' -- . ':(exclude)spec/lib/gitlab/conflict/file_spec.rb' ':(exclude)spec/lib/gitlab/git/conflict/parser_spec.rb'`
output=`git grep -En '^<<<<<<< '`
echo $output
test -z "$output"
......@@ -240,28 +240,30 @@ def visit_merge_request(project, merge)
end
shared_examples 'multiple tasks' do
it 'renders for description' do
it 'renders for description', :js do
visit_merge_request(project, merge)
wait_for_requests
expect(page).to have_selector('ul.task-list', count: 1)
expect(page).to have_selector('li.task-list-item', count: 6)
expect(page).to have_selector('ul input[checked]', count: 2)
end
it 'contains the required selectors' do
it 'contains the required selectors', :js do
visit_merge_request(project, merge)
wait_for_requests
container = '.detail-page-description .description.js-task-list-container'
expect(page).to have_selector(container)
expect(page).to have_selector("#{container} .md .task-list .task-list-item .task-list-item-checkbox")
expect(page).to have_selector("#{container} .js-task-list-field")
expect(page).to have_selector("#{container} .js-task-list-field", visible: false)
expect(page).to have_selector('form.js-issuable-update')
expect(page).to have_selector('a.btn-close')
end
it 'is only editable by author', :js do
visit_merge_request(project, merge)
wait_for_requests
expect(page).to have_selector('.js-task-list-container')
expect(page).to have_selector('li.task-list-item.enabled', count: 6)
......@@ -269,6 +271,7 @@ def visit_merge_request(project, merge)
logout(:user)
login_as(user2)
visit current_path
wait_for_requests
expect(page).not_to have_selector('.js-task-list-container')
expect(page).to have_selector('li.task-list-item.enabled', count: 0)
......@@ -297,8 +300,9 @@ def visit_merge_request(project, merge)
describe 'single incomplete task' do
let!(:merge) { create(:merge_request, :simple, description: singleIncompleteMarkdown, author: user, source_project: project) }
it 'renders for description' do
it 'renders for description', :js do
visit_merge_request(project, merge)
wait_for_requests
expect(page).to have_selector('ul.task-list', count: 1)
expect(page).to have_selector('li.task-list-item', count: 1)
......@@ -315,8 +319,9 @@ def visit_merge_request(project, merge)
describe 'single complete task' do
let!(:merge) { create(:merge_request, :simple, description: singleCompleteMarkdown, author: user, source_project: project) }
it 'renders for description' do
it 'renders for description', :js do
visit_merge_request(project, merge)
wait_for_requests
expect(page).to have_selector('ul.task-list', count: 1)
expect(page).to have_selector('li.task-list-item', count: 1)
......@@ -325,6 +330,7 @@ def visit_merge_request(project, merge)
it 'provides a summary on MergeRequests#index' do
visit project_merge_requests_path(project)
expect(page).to have_content("1 of 1 task completed")
end
end
......
......@@ -2,51 +2,11 @@ query allSchemaTypes {
__schema {
types {
fields {
type{
type {
fields {
type {
fields {
type {
fields {
type {
fields {
type {
fields {
type {
fields {
type {
fields {
type {
fields {
type {
fields {
type {
fields {
type {
fields {
type {
fields {
name
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
name
}
}
}
......@@ -54,4 +14,4 @@ query allSchemaTypes {
}
}
}
}
\ No newline at end of file
}
{
project(fullPath: "gitlab-org/gitlab") {
group {
projects {
edges {
node {
group {
projects {
edges {
node {
group {
description
}
}
}
}
}
}
}
}
}
}
}
{
project(fullPath: "gitlab-org/gitlab") {
group {
projects {
nodes {
group {
projects {
nodes {
group {
description
}
}
}
}
}
}
}
}
}
{
project(fullPath: "gitlab-org/gitlab-ce") {
group {
projects {
edges {
node {
group {
projects {
edges {
node {
group {
projects {
edges {
node {
group {
projects {
edges {
node {
group {
projects {
edges {
node {
group {
description
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
}
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