Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
parent
98c4335e70
commit
f7ead77657
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Remove vulnerability counter from security tab
|
||||
merge_request: 20800
|
||||
author:
|
||||
type: changed
|
|
@ -0,0 +1,5 @@
|
|||
---
|
||||
title: Fix error when linking already linked issue to epic
|
||||
merge_request: 21213
|
||||
author:
|
||||
type: fixed
|
|
@ -760,6 +760,7 @@ GET /projects/:id/search
|
|||
| `id` | integer/string | yes | The ID or [URL-encoded path of the project](README.md#namespaced-path-encoding) owned by the authenticated user |
|
||||
| `scope` | string | yes | The scope to search in |
|
||||
| `search` | string | yes | The search query |
|
||||
| `ref` | string | no | The name of a repository branch or tag to search on. The project's default branch is used by default. This is only applicable for scopes: commits, blobs, and wiki_blobs. |
|
||||
|
||||
Search the expression within the specified scope. Currently these scopes are supported: issues, merge_requests, milestones, notes, wiki_blobs, commits, blobs, users.
|
||||
|
||||
|
@ -1058,7 +1059,7 @@ Blobs searches are performed on both filenames and contents. Search results:
|
|||
times in the content.
|
||||
|
||||
```bash
|
||||
curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/6/search?scope=blobs&search=installation
|
||||
curl --request GET --header "PRIVATE-TOKEN: <your_access_token>" https://gitlab.example.com/api/v4/projects/6/search?scope=blobs&search=installation&ref=feature
|
||||
```
|
||||
|
||||
Example response:
|
||||
|
@ -1072,7 +1073,7 @@ Example response:
|
|||
"path": "README.md",
|
||||
"filename": "README.md",
|
||||
"id": null,
|
||||
"ref": "master",
|
||||
"ref": "feature",
|
||||
"startline": 46,
|
||||
"project_id": 6
|
||||
}
|
||||
|
|
Binary file not shown.
Before Width: | Height: | Size: 51 KiB |
Binary file not shown.
After Width: | Height: | Size: 58 KiB |
|
@ -42,7 +42,7 @@ At the pipeline level, the Security Dashboard displays the vulnerabilities prese
|
|||
|
||||
Visit the page for any pipeline which has run any of the [supported reports](#supported-reports). Click the **Security** tab to view the Security Dashboard.
|
||||
|
||||
![Pipeline Security Dashboard](img/pipeline_security_dashboard_v12_3.png)
|
||||
![Pipeline Security Dashboard](img/pipeline_security_dashboard_v12_6.png)
|
||||
|
||||
## Project Security Dashboard
|
||||
|
||||
|
|
|
@ -13,7 +13,7 @@ GitLab supports several ways deploy Serverless applications in both Kubernetes E
|
|||
|
||||
Currently we support:
|
||||
|
||||
- [Knative](#knative): Build Knative applications with Knative and gitlabktl on GKE.
|
||||
- [Knative](#knative): Build Knative applications with Knative and `gitlabktl` on GKE.
|
||||
- [AWS Lambda](aws.md): Create serverless applications via the Serverless Framework and GitLab CI.
|
||||
|
||||
## Knative
|
||||
|
@ -36,10 +36,12 @@ With GitLab Serverless, you can deploy both functions-as-a-service (FaaS) and se
|
|||
To run Knative on GitLab, you will need:
|
||||
|
||||
1. **Existing GitLab project:** You will need a GitLab project to associate all resources. The simplest way to get started:
|
||||
|
||||
- If you are planning on deploying functions, clone the [functions example project](https://gitlab.com/knative-examples/functions) to get started.
|
||||
- If you are planning on deploying a serverless application, clone the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get started.
|
||||
|
||||
- If you are planning on [deploying functions](#deploying-functions),
|
||||
clone the [functions example project](https://gitlab.com/knative-examples/functions) to get
|
||||
started.
|
||||
- If you are planning on [deploying a serverless application](#deploying-serverless-applications),
|
||||
clone the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get
|
||||
started.
|
||||
1. **Kubernetes Cluster:** An RBAC-enabled Kubernetes cluster is required to deploy Knative.
|
||||
The simplest way to get started is to add a cluster using [GitLab's GKE integration](../add_remove_clusters.md#gke-cluster).
|
||||
The set of minimum recommended cluster specifications to run Knative is 3 nodes, 6 vCPUs, and 22.50 GB memory.
|
||||
|
@ -58,7 +60,7 @@ To run Knative on GitLab, you will need:
|
|||
1. **`serverless.yml`** (for [functions only](#deploying-functions)): When using serverless to deploy functions, the `serverless.yml` file
|
||||
will contain the information for all the functions being hosted in the repository as well as a reference to the
|
||||
runtime being used.
|
||||
1. **`Dockerfile`** (for [applications only](#deploying-serverless-applications): Knative requires a
|
||||
1. **`Dockerfile`** (for [applications only](#deploying-serverless-applications)): Knative requires a
|
||||
`Dockerfile` in order to build your applications. It should be included at the root of your
|
||||
project's repo and expose port `8080`. `Dockerfile` is not require if you plan to build serverless functions
|
||||
using our [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes).
|
||||
|
@ -231,26 +233,40 @@ Or:
|
|||
|
||||
## Supported runtimes
|
||||
|
||||
Serverless functions for GitLab can be written in 6 supported languages:
|
||||
Serverless functions for GitLab can be run using:
|
||||
|
||||
- NodeJS and Ruby, with GitLab-managed and OpenFaas runtimes.
|
||||
- C#, Go, PHP, and Python with OpenFaaS runtimes only.
|
||||
- [GitLab-managed](#gitlab-managed-runtimes) runtimes.
|
||||
- [OpenFaaS](#openfaas-runtimes) runtimes.
|
||||
|
||||
### GitLab managed runtimes
|
||||
If a runtime is not available for the required programming language, consider deploying a
|
||||
[serverless application](#deploying-serverless-applications).
|
||||
|
||||
Currently the following [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes) are offered:
|
||||
### GitLab-managed runtimes
|
||||
|
||||
- ruby
|
||||
- node.js
|
||||
- Dockerfile
|
||||
Currently the following GitLab-managed [runtimes](https://gitlab.com/gitlab-org/serverless/runtimes)
|
||||
are available:
|
||||
|
||||
`Dockerfile` presence is assumed when a runtime is not specified.
|
||||
- `go` (proof of concept)
|
||||
- `nodejs`
|
||||
- `ruby`
|
||||
|
||||
You must provide a `Dockerfile` to run serverless functions if no runtime is specified.
|
||||
|
||||
### OpenFaaS runtimes
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/29253) in GitLab 12.5.
|
||||
|
||||
[OpenFaaS classic runtimes](https://github.com/openfaas/templates#templates-in-store) can be used with GitLab serverless.
|
||||
|
||||
OpenFaas runtimes are available for the following languages:
|
||||
|
||||
- C#
|
||||
- Go
|
||||
- NodeJS
|
||||
- PHP
|
||||
- Python
|
||||
- Ruby
|
||||
|
||||
Runtimes are specified using the pattern: `openfaas/classic/<template_name>`. The following
|
||||
example shows how to define a function in `serverless.yml` using an OpenFaaS runtime:
|
||||
|
||||
|
@ -441,9 +457,10 @@ To run a function locally:
|
|||
|
||||
> Introduced in GitLab 11.5.
|
||||
|
||||
Serverless applications are the building block of serverless functions. They are useful in scenarios where an existing
|
||||
runtime does not meet the needs of an application, such as one written in a language that has no runtime available. Note
|
||||
though that serverless applications should be stateless!
|
||||
Serverless applications are an alternative to [serverless functions](#deploying-functions).
|
||||
They are useful in scenarios where an existing runtime does not meet the needs of an application,
|
||||
such as one written in a language that has no runtime available. Note though that serverless
|
||||
applications should be stateless!
|
||||
|
||||
NOTE: **Note:**
|
||||
You can reference and import the sample [Knative Ruby App](https://gitlab.com/knative-examples/knative-ruby-app) to get started.
|
||||
|
|
|
@ -98,7 +98,7 @@ back to both GitLab and GitHub when completed.
|
|||
|
||||
1. The result of the job will be visible directly from the pipeline view:
|
||||
|
||||
![Security Dashboard](../../application_security/security_dashboard/img/pipeline_security_dashboard_v12_3.png)
|
||||
![Security Dashboard](../../application_security/security_dashboard/img/pipeline_security_dashboard_v12_6.png)
|
||||
|
||||
NOTE: **Note:**
|
||||
If you don't commit very often to your project, you may want to use
|
||||
|
|
Loading…
Reference in New Issue