kotovalexarian-likes-gitlab
/
gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

This commit is contained in:
GitLab Bot 2021-09-09 06:11:13 +00:00
parent c860067451
commit 8602c59966
17 changed files with 112 additions and 38 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
app/assets/javascripts/boards/components/board_card_inner.vue
View File

@ -218,6 +218,7 @@ export default {
:href="item.path || item.webUrl || ''"
:title="item.title"
:class="{ 'gl-text-gray-400!': item.isLoading }"
class="js-no-trigger"
@mousemove.stop
>{{ item.title }}</a
>

2
app/models/integrations/base_chat_notification.rb
View File

@ -253,3 +253,5 @@ module Integrations
end
end
end
Integrations::BaseChatNotification.prepend_mod_with('Integrations::BaseChatNotification')

4
app/models/repository.rb
View File

@ -632,7 +632,9 @@ class Repository
return if licensee_object.name.blank?
licensee_object
rescue Licensee::InvalidLicense
rescue Licensee::InvalidLicense => ex
Gitlab::ErrorTracking.track_exception(ex)
nil
end
memoize_method :license

9
db/migrate/20210707163659_add_vulnerability_events_to_integrations.rb Normal file
View File

@ -0,0 +1,9 @@
# frozen_string_literal: true
class AddVulnerabilityEventsToIntegrations < ActiveRecord::Migration[6.1]
include Gitlab::Database::MigrationHelpers
def change
add_column :integrations, :vulnerability_events, :boolean, default: false, null: false
end
end

1
db/schema_migrations/20210707163659 Normal file
View File

@ -0,0 +1 @@
ac14aa49830a3af9a1445c0c7680f5660247a8104c8e4c1ae542c4b368f7c9bf

1
db/structure.sql
View File

@ -14968,6 +14968,7 @@ CREATE TABLE integrations (
alert_events boolean,
group_id bigint,
type_new text,
vulnerability_events boolean DEFAULT false NOT NULL,
CONSTRAINT check_a948a0aa7e CHECK ((char_length(type_new) <= 255))
);

2
doc/api/oauth2.md
View File

@ -5,7 +5,7 @@ group: Access
info: To determine the technical writer assigned to the Stage/Group associated with this page, see https://about.gitlab.com/handbook/engineering/ux/technical-writing/#designated-technical-writers
---
# GitLab as an OAuth 2.0 provider
# GitLab as an OAuth 2.0 provider **(FREE)**
This document covers using the [OAuth2](https://oauth.net/2/) protocol to allow
other services to access GitLab resources on user's behalf.

4
doc/api/services.md
View File

@ -1153,6 +1153,8 @@ Parameters:
| `tag_push_events` | boolean | false | Enable notifications for tag push events |
| `wiki_page_channel` | string | false | The name of the channel to receive wiki page events notifications |
| `wiki_page_events` | boolean | false | Enable notifications for wiki page events |
| `vulnerability_channel` | string | false | **(ULTIMATE)** The name of the channel to receive vulnerability event notifications. |
| `vulnerability_events` | boolean | false | **(ULTIMATE)** Enable notifications for vulnerability events |
### Delete Slack service
@ -1250,6 +1252,7 @@ Parameters:
| `confidential_note_events` | boolean | false | Enable notifications for confidential note events |
| `pipeline_events` | boolean | false | Enable notifications for pipeline events |
| `wiki_page_events` | boolean | false | Enable notifications for wiki page events |
| `vulnerability_events` | boolean | false | **(ULTIMATE)** Enable notifications for vulnerability events |
| `push_channel` | string | false | The name of the channel to receive push events notifications |
| `issue_channel` | string | false | The name of the channel to receive issues events notifications |
| `confidential_issue_channel` | string | false | The name of the channel to receive confidential issues events notifications |
@ -1259,6 +1262,7 @@ Parameters:
| `tag_push_channel` | string | false | The name of the channel to receive tag push events notifications |
| `pipeline_channel` | string | false | The name of the channel to receive pipeline events notifications |
| `wiki_page_channel` | string | false | The name of the channel to receive wiki page events notifications |
| `vulnerability_channel` | string | false | **(ULTIMATE)** The name of the channel to receive vulnerability events notifications |
### Delete Mattermost notifications service

5
doc/topics/git/lfs/migrate_to_git_lfs.md
View File

@ -7,6 +7,11 @@ description: "How to migrate an existing Git repository to Git LFS with BFG."
# Migrate a Git repository into Git LFS with BFG
WARNING:
The following documentation is deprecated. We recommend using
[`git lfs migrate`](https://github.com/git-lfs/git-lfs/blob/main/docs/man/git-lfs-migrate.1.ronn)
instead of the method documented below.
Using Git LFS can help you to reduce the size of your Git
repository and improve its performance.

1
doc/topics/git/numerous_undo_possibilities_in_git/index.md
View File

@ -388,7 +388,6 @@ git filter-branch --tree-filter 'rm filename' HEAD
The `git filter-branch` command might be slow on large repositories.
Tools are available to execute Git commands more quickly.
An alternative is the open source community-maintained tool [BFG](https://rtyley.github.io/bfg-repo-cleaner/).
These tools are faster because they do not provide the same
feature set as `git filter-branch` does, but focus on specific use cases.

76
doc/topics/gitlab_flow.md
View File

@ -72,10 +72,20 @@ For example, many projects do releases but don't need to do hotfixes.
## GitHub flow as a simpler alternative
![Branch with feature branches merged in](img/gitlab_flow_github_flow.png)
In reaction to Git flow, GitHub created a simpler alternative.
[GitHub flow](https://guides.github.com/introduction/flow/index.html) has only feature branches and a `main` branch.
[GitHub flow](https://guides.github.com/introduction/flow/index.html) has only feature branches and a `main` branch:
```mermaid
graph TD
subgraph Feature branches in GitHub Flow
A[main branch] ===>B[main branch]
D[nav branch] --> |add navigation| B
B ===> C[main branch]
E[feature-branch] --> |add feature| C
C ==> F[main branch]
end
```
This flow is clean and straightforward, and many organizations have adopted it with great success.
Atlassian recommends [a similar strategy](https://www.atlassian.com/blog/git/simple-git-workflow-is-simple), although they rebase feature branches.
Merging everything into the `main` branch and frequently deploying means you minimize the amount of unreleased code. This approach is in line with lean and continuous delivery best practices.
@ -84,8 +94,6 @@ With GitLab flow, we offer additional guidance for these questions.
## Production branch with GitLab flow
![Branches with an arrow that indicates a deployment](img/gitlab_flow_production_branch.png)
GitHub flow assumes you can deploy to production every time you merge a feature branch.
While this is possible in some cases, such as SaaS applications, there are some cases where this is not possible, such as:
@ -95,7 +103,22 @@ While this is possible in some cases, such as SaaS applications, there are some
operations team is at full capacity - but you also merge code at other times.
In these cases, you can make a production branch that reflects the deployed code.
You can deploy a new version by merging `main` into the production branch.
You can deploy a new version by merging `development` into the production branch:
```mermaid
graph TD
subgraph Production branch in GitLab Flow
A[development] ==>B[development]
B ==> C[development]
C ==> D[development]
E[production] ====> F[production]
C --> |deployment| F
D ==> G[development]
F ==> H[production]
end
```
If you need to know what code is in production, you can check out the production branch to see.
The approximate time of deployment is visible as the merge commit in the version control system.
This time is pretty accurate if you automatically deploy your production branch.
@ -104,18 +127,41 @@ This flow prevents the overhead of releasing, tagging, and merging that happens
## Environment branches with GitLab flow
![Multiple branches with the code cascading from one to another](img/gitlab_flow_environment_branches.png)
It might be a good idea to have an environment that is automatically updated to the `main` branch.
It might be a good idea to have an environment that is automatically updated to the `staging` branch.
Only, in this case, the name of this environment might differ from the branch name.
Suppose you have a staging environment, a pre-production environment, and a production environment.
In this case, deploy the `main` branch to staging.
To deploy to pre-production, create a merge request from the `main` branch to the pre-production branch.
Go live by merging the pre-production branch into the production branch.
Suppose you have a staging environment, a pre-production environment, and a production environment:
```mermaid
graph LR
subgraph Environment branches in GitLab Flow
A[staging] ==> B[staging]
B ==> C[staging]
C ==> D[staging]
A --> |deploy to<br>pre-prod| G
F[pre-prod] ==> G[pre-prod]
G ==> H[pre-prod]
H ==> I[pre-prod]
C --> |deploy to<br>pre-prod| I
J[production] ==> K[production]
K ==> L[production]
G --> |production <br>deployment| K
end
```
In this case, deploy the `staging` branch to your staging environment.
To deploy to pre-production, create a merge request from the `staging` branch to the `pre-prod` branch.
Go live by merging the `pre-prod` branch into the `production` branch.
This workflow, where commits only flow downstream, ensures that everything is tested in all environments.
If you need to cherry-pick a commit with a hotfix, it is common to develop it on a feature branch and merge it into `main` with a merge request.
If you need to cherry-pick a commit with a hotfix, it is common to develop it on a feature branch and merge it into `production` with a merge request.
In this case, do not delete the feature branch yet.
If `main` passes automatic testing, you then merge the feature branch into the other branches.
If `production` passes automatic testing, you then merge the feature branch into the other branches.
If this is not possible because more manual testing is required, you can send merge requests from the feature branch to the downstream branches.
## Release branches with GitLab flow

BIN
doc/topics/img/gitlab_flow_environment_branches.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 12 KiB

BIN
doc/topics/img/gitlab_flow_github_flow.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 6.0 KiB

BIN
doc/topics/img/gitlab_flow_production_branch.png
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 7.1 KiB

27
doc/user/project/integrations/slack.md
View File

@ -59,19 +59,20 @@ Your Slack team now starts receiving GitLab event notifications as configured.
The following triggers are available for Slack notifications:
| Trigger name | Trigger event |
|------------------------|------------------------------------------------------|
| **Push** | A push to the repository. |
| **Issue** | An issue is created, updated, or closed. |
| **Confidential issue** | A confidential issue is created, updated, or closed. |
| **Merge request** | A merge request is created, updated, or merged. |
| **Note** | A comment is added. |
| **Confidential note** | A confidential note is added. |
| **Tag push** | A new tag is pushed to the repository. |
| **Pipeline** | A pipeline status changed. |
| **Wiki page** | A wiki page is created or updated. |
| **Deployment** | A deployment starts or finishes. |
| **Alert** | A new, unique alert is recorded. |
| Trigger name | Trigger event |
| ------------------------ | ------------------------------------------------------ |
| **Push** | A push to the repository. |
| **Issue** | An issue is created, updated, or closed. |
| **Confidential issue** | A confidential issue is created, updated, or closed. |
| **Merge request** | A merge request is created, updated, or merged. |
| **Note** | A comment is added. |
| **Confidential note** | A confidential note is added. |
| **Tag push** | A new tag is pushed to the repository. |
| **Pipeline** | A pipeline status changed. |
| **Wiki page** | A wiki page is created or updated. |
| **Deployment** | A deployment starts or finishes. |
| **Alert** | A new, unique alert is recorded. |
| **Vulnerability** | **(ULTIMATE)** A new, unique vulnerability is recorded. |
## Troubleshooting

14
locale/gitlab.pot
View File

@ -10345,6 +10345,9 @@ msgstr ""
msgid "DastProfiles|Manage profiles"
msgstr ""
msgid "DastProfiles|Manage site profiles"
msgstr ""
msgid "DastProfiles|Minimum = 0 (no timeout enabled), Maximum = 2880 minutes"
msgstr ""
@ -10489,7 +10492,7 @@ msgstr ""
msgid "DastProfiles|Website"
msgstr ""
msgid "DastProfiles|You can either choose a passive scan or validate the target site in your chosen site profile. %{docsLinkStart}Learn more about site validation.%{docsLinkEnd}"
msgid "DastProfiles|You can either choose a passive scan or validate the target site from the site profile management page. %{docsLinkStart}Learn more about site validation.%{docsLinkEnd}"
msgstr ""
msgid "DastProfiles|You cannot run an active scan against an unvalidated site."
@ -23472,12 +23475,6 @@ msgstr ""
msgid "OnDemandScans|Use existing site profile"
msgstr ""
msgid "OnDemandScans|You can either choose a passive scan or validate the target site in your chosen site profile. %{docsLinkStart}Learn more about site validation.%{docsLinkEnd}"
msgstr ""
msgid "OnDemandScans|You cannot run an active scan against an unvalidated site."
msgstr ""
msgid "OnDemandScans|You must create a repository within your project to run an on-demand scan."
msgstr ""
@ -26258,6 +26255,9 @@ msgstr ""
msgid "ProjectService|Trigger event when a new, unique alert is recorded."
msgstr ""
msgid "ProjectService|Trigger event when a new, unique vulnerability is recorded. (Note: This feature requires an Ultimate plan.)"
msgstr ""
msgid "ProjectService|Trigger event when a pipeline status changes."
msgstr ""

3
spec/models/repository_spec.rb
View File

@ -1340,6 +1340,9 @@ RSpec.describe Repository do
it 'returns nil when license_key is not recognized' do
expect(repository).to receive(:license_key).twice.and_return('not-recognized')
expect(Gitlab::ErrorTracking).to receive(:track_exception) do |ex|
expect(ex).to be_a(Licensee::InvalidLicense)
end
expect(repository.license).to be_nil
end