doc/ci/environments/img/environments_dashboard_v12_5.png

30.3 KiB

......@@ -1539,9 +1539,14 @@ cache:
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/18986) in GitLab v12.5.
If `cache:key:files` is added, one or two files must be defined with it. The cache `key`
will be a SHA computed from the most recent commits (one or two) that changed the
given files. If neither file was changed in any commits, the key will be `default`.
The `cache:key:files` keyword extends the `cache:key` functionality by making it easier
to reuse some caches, and rebuild them less often, which will speed up subsequent pipeline
runs.
When you include `cache:key:files`, you must also list the project files that will be used to generate the key, up to a maximum of two files.
The cache `key` will be a SHA checksum computed from the most recent commits (up to two, if two files are listed)
that changed the given files. If neither file was changed in any commits,
the fallback key will be `default`.
```yaml
cache:
......@@ -1554,20 +1559,26 @@ cache:
- node_modules
```
In this example we are creating a cache for Ruby and Nodejs dependencies that
is tied to current versions of the `Gemfile.lock` and `package.json` files. Whenever one of
these files changes, a new cache key is computed and a new cache is created. Any future
job runs using the same `Gemfile.lock` and `package.json` with `cache:key:files` will
use the new cache, instead of rebuilding the dependencies.
##### `cache:key:prefix`
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/18986) in GitLab v12.5.
The `prefix` parameter adds extra functionality to `key:files` by allowing the key to
be composed of the given `prefix` combined with the SHA computed for `cache:key:files`.
For example, adding a `prefix` of `rspec`, will
cause keys to look like: `rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`. If neither
file was changed in any commits, the prefix is added to `default`, so the key in the
example would be `rspec-default`.
For example, adding a `prefix` of `test`, will cause keys to look like: `test-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5`.
If neither file was changed in any commits, the prefix is added to `default`, so the
key in the example would be `test-default`.
`prefix` follows the same restrictions as `key`, so it can use any of the
[predefined variables](../variables/README.md). Similarly, the `/` character or the
equivalent URI-encoded `%2F`, or a value made only of `.` or `%2E`, is not allowed.
Like `cache:key`, `prefix` can use any of the [predefined variables](../variables/README.md),
but the following are not allowed:
- the `/` character (or the equivalent URI-encoded `%2F`)
- a value made only of `.` (or the equivalent URI-encoded `%2E`)
```yaml
cache:
......@@ -1577,8 +1588,20 @@ cache:
prefix: ${CI_JOB_NAME}
paths:
- vendor/ruby
rspec:
script:
- bundle exec rspec
```
For example, adding a `prefix` of `$CI_JOB_NAME` will
cause the key to look like: `rspec-feef9576d21ee9b6a32e30c5c79d0a0ceb68d1e5` and
the job cache is shared across different branches. If a branch changes
`Gemfile.lock`, that branch will have a new SHA checksum for `cache:key:files`. A new cache key
will be generated, and a new cache will be created for that key.
If `Gemfile.lock` is not found, the prefix is added to
`default`, so the key in the example would be `rspec-default`.
#### `cache:untracked`
Set `untracked: true` to cache all files that are untracked in your Git
......
......
......@@ -108,9 +108,10 @@ When visiting one of these views, you can now hover over a code reference to see
Sourcegraph powered code intelligence will be incrementally rolled out on GitLab.com.
It will eventually become available for all public projects, but for now, it is only
available for some specific [`gitlab-org` projects](https://gitlab.com/gitlab-org/).
This means that you can see it working and use it to dig into the code of these projects,
but you cannot use it on your own project on GitLab.com yet.
available for some specific projects within the [`gitlab-org`](https://gitlab.com/gitlab-org/)
group, e.g., <https://gitlab.com/gitlab-org/gitlab>. This means that you can see
it working and use it to dig into the code of these projects, but you cannot use
it on your own project on GitLab.com yet.
If you would like to use it in your own projects as of GitLab 12.5, you can do so by
setting up a self-managed GitLab instance.
......
......
......@@ -161,6 +161,11 @@ but commented out to help encourage others to add to it in the future. -->
## Required pipeline configuration **(PREMIUM ONLY)**
CAUTION: **Caution:**
The Required Pipeline Configuration feature is deprecated and will be removed when an
[improved compliance solution](https://gitlab.com/gitlab-org/gitlab/issues/34830)
is added to GitLab. It is recommended to avoid using this feature.
GitLab administrators can force a pipeline configuration to run on every
pipeline.
......
......
......@@ -15,7 +15,7 @@ SAST supports the following official analyzers:
- [`bandit`](https://gitlab.com/gitlab-org/security-products/analyzers/bandit) (Bandit)
- [`brakeman`](https://gitlab.com/gitlab-org/security-products/analyzers/brakeman) (Brakeman)
- [`eslint`](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) (ESLint (JavaScript))
- [`eslint`](https://gitlab.com/gitlab-org/security-products/analyzers/eslint) (ESLint (JavaScript and React))
- [`flawfinder`](https://gitlab.com/gitlab-org/security-products/analyzers/flawfinder) (Flawfinder)
- [`gosec`](https://gitlab.com/gitlab-org/security-products/analyzers/gosec) (Gosec)
- [`nodejs-scan`](https://gitlab.com/gitlab-org/security-products/analyzers/nodejs-scan) (NodeJsScan)
......
......
......@@ -76,6 +76,7 @@ The following table shows which languages, package managers and frameworks are s
| Node.js | [NodeJsScan](https://github.com/ajinabraham/NodeJsScan) | 11.1 |
| PHP | [phpcs-security-audit](https://github.com/FloeDesignTechnologies/phpcs-security-audit) | 10.8 |
| Python ([pip](https://pip.pypa.io/en/stable/)) | [bandit](https://github.com/PyCQA/bandit) | 10.3 |
| React | [ESLint react plugin](https://github.com/yannickcr/eslint-plugin-react) | 12.5 |
| Ruby on Rails | [brakeman](https://brakemanscanner.org) | 10.3 |
| Scala ([Ant](https://ant.apache.org/), [Gradle](https://gradle.org/), [Maven](https://maven.apache.org/) and [SBT](https://www.scala-sbt.org/)) | [SpotBugs](https://spotbugs.github.io/) with the [find-sec-bugs](https://find-sec-bugs.github.io/) plugin | 11.0 (SBT) & 11.9 (Ant, Gradle, Maven) |
| TypeScript | [TSLint config security](https://github.com/webschik/tslint-config-security/) | 11.9 |
......
......
......@@ -71,7 +71,7 @@ Once you're on the dashboard, at the top you should see a series of filters for:
- Report type
- Project
To the right of the filters, you should see a **Hide dismissed** toggle button ([available in GitLab Ultimate 12.5](https://gitlab.com/gitlab-org/gitlab/issues/9102)).
To the right of the filters, you should see a **Hide dismissed** toggle button ([available for GitLab.com Gold, planned for GitLab Ultimate 12.6](https://gitlab.com/gitlab-org/gitlab/issues/9102)).
NOTE: **Note:**
The dashboard only shows projects with [security reports](#supported-reports) enabled in a group.
......
......
......@@ -417,6 +417,18 @@ install Crossplane using the
[`values.yaml`](https://github.com/crossplaneio/crossplane/blob/master/cluster/charts/crossplane/values.yaml.tmpl)
file.
#### Enabling installation
This is a preliminary release of Crossplane as a GitLab-managed application. By default,
the ability to install it is disabled.
To allow installation of Crossplane as a GitLab-managed application, ask a GitLab
administrator to run following command within a Rails console:
```ruby
Feature.enable(:enable_cluster_application_crossplane)
```
## Upgrading applications
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/merge_requests/24789) in GitLab 11.8.
......
......
......@@ -50,14 +50,17 @@ Any issue that belongs to a project in the epic's group, or any of the epic's
subgroups, are eligible to be added. New issues appear at the top of the list of issues in the **Epics and Issues** tab.
An epic contains a list of issues and an issue can be associated with at most
one epic. When you add an issue to an epic that is already associated with another epic,
the issue is automatically removed from the previous epic.
one epic. When you add an issue that is already linked to an epic,
the issue is automatically unlinked from its current parent.
To add an issue to an epic:
1. Click **Add an issue**.
1. Paste the link of the issue.
- Press <kbd>Spacebar</kbd> and repeat this step if there are multiple issues.
1. Identify the issue to be added, using either of the following methods:
- Paste the link of the issue.
- Search for the desired issue by entering part of the issue's title, then selecting the desired match. ([From GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/issues/9126))
If there are multiple issues to be added, press <kbd>Spacebar</kbd> and repeat this step.
1. Click **Add**.
To remove an issue from an epic:
......@@ -72,17 +75,19 @@ To remove an issue from an epic:
Any epic that belongs to a group, or subgroup of the parent epic's group, is
eligible to be added. New child epics appear at the top of the list of epics in the **Epics and Issues** tab.
When you add a child epic that is already associated with another epic,
that epic is automatically removed from the previous epic.
When you add an epic that is already linked to a parent epic, the link to its current parent is removed.
An epic can have multiple child epics with
the maximum depth being 5.
To add a child epic:
To add a child epic to an epic:
1. Click **Add an epic**.
1. Paste the link of the epic.
- Press <kbd>Spacebar</kbd> and repeat this step if there are multiple issues.
1. Identify the epic to be added, using either of the following methods:
- Paste the link of the epic.
- Search for the desired issue by entering part of the epic's title, then selecting the desired match. ([From GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/issues/9126))
If there are multiple epics to be added, press <kbd>Spacebar</kbd> and repeat this step.
1. Click **Add**.
To remove a child epic from a parent epic:
......
......
......@@ -23,6 +23,8 @@ To add a project to the dashboard:
Once added, the dashboard will display the project's number of active alerts,
last commit, pipeline status, and when it was last deployed.
The Operations and [Environments](../../ci/environments/environments_dashboard.md) dashboards share the same list of projects. Adding or removing a project from one adds or removes the project from the other.
![Operations Dashboard with projects](img/index_operations_dashboard_with_projects.png)
## Arranging projects on a dashboard
......
......
......@@ -206,9 +206,46 @@ GitLab supports:
Before creating your first cluster on Amazon EKS with GitLab's integration,
make sure the following requirements are met:
- Enable the `create_eks_clusters` feature flag for your GitLab instance.
- An [Amazon Web Services](https://aws.amazon.com/) account is set up and you are able to log in.
- You have permissions to manage IAM resources.
#### Enable the `create_eks_clusters` feature flag **(CORE ONLY)**
NOTE: **Note:**
If you are running a self-managed instance, EKS cluster creation will not be available
unless the feature flag `create_eks_clusters` is enabled. This can be done from the Rails console
by instance administrators.
Use these commands to start the Rails console:
```sh
# Omnibus GitLab
gitlab-rails console
# Installation from source
cd /home/git/gitlab
sudo -u git -H bin/rails console RAILS_ENV=production
```
Then run the following command to enable the feature flag:
```
Feature.enable(:create_eks_clusters)
```
You can also enable the feature flag only for specific projects with:
```
Feature.enable(:create_eks_clusters, Project.find_by_full_path('my_group/my_project'))
```
Run the following command to disable the feature flag:
```
Feature.disable(:create_eks_clusters)
```
##### Additional requirements for self-managed instances
If you are using a self-managed GitLab instance, GitLab must first
......
......
......@@ -157,6 +157,8 @@ The plain text title and description of the issue fill the top center of the iss
The description fully supports [GitLab Flavored Markdown](../../markdown.md#gitlab-flavored-markdown-gfm),
allowing many formatting options.
> [Since GitLab 12.5](https://gitlab.com/gitlab-org/gitlab/issues/10103), changes to an issue's description are listed in the [issue history](#23-issue-history).**(STARTER)**
#### 17. Mentions
You can mention a user or a group present in your GitLab instance with `@username` or
......
......
......@@ -147,7 +147,7 @@ You can also edit an existing tag to add release notes:
## Release Evidence
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26019) in GitLab 12.5.
> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/26019) in GitLab 12.6.
Each time a new release is created, specific related data is collected in
parallel. This dataset will be a snapshot this new release (including linked
......@@ -155,7 +155,7 @@ milestones and issues) at moment of creation. Such collection of data will
provide a chain of custody and facilitate processes like external audits, for example.
The gathered Evidence data is stored in the database upon creation of a new
release as a JSON object. In GitLab 12.5, a link to
release as a JSON object. In GitLab 12.6, a link to
the Evidence data is provided for [each Release](#releases-list).
Here's what this object can look like:
......
......
......@@ -191,6 +191,7 @@ module API
optional :path, type: String, desc: 'The path of the repository'
optional :default_branch, type: String, desc: 'The default branch of the project'
use :optional_project_params
use :optional_create_project_params
use :create_params
end
# rubocop: disable CodeReuse/ActiveRecord
......
......
# frozen_string_literal: true
module Gitlab
module ExceptionLogFormatter
def self.format!(exception, payload)
return unless exception
# Elasticsearch/Fluentd don't handle nested structures well.
# Use periods to flatten the fields.
payload.merge!(
'exception.class' => exception.class.name,
'exception.message' => exception.message
)
if exception.backtrace
payload['exception.backtrace'] = Gitlab::Profiler.clean_backtrace(exception.backtrace)
end
end
end
end
......@@ -11,19 +11,11 @@ module Gitlab
# precedence so the logger never sees it. We need to
# store and retrieve the exception from the environment.
exception = request.env[::API::Helpers::API_EXCEPTION_ENV]
data = {}
return {} unless exception.is_a?(Exception)
return data unless exception.is_a?(Exception)
data = {
exception: {
class: exception.class.to_s,
message: exception.message
}
}
if exception.backtrace
data[:exception][:backtrace] = Gitlab::Profiler.clean_backtrace(exception.backtrace)
end
Gitlab::ExceptionLogFormatter.format!(exception, data)
data
end
......
......
......@@ -327,7 +327,12 @@ module Gitlab
end
def find_or_create_object!
return relation_class.find_or_create_by(project_id: @project.id) if UNIQUE_RELATIONS.include?(@relation_name)
if UNIQUE_RELATIONS.include?(@relation_name)
unique_relation_object = relation_class.find_or_create_by(project_id: @project.id)
unique_relation_object.assign_attributes(parsed_relation_hash)
return unique_relation_object
end
# Can't use IDs as validation exists calling `group` or `project` attributes
finder_hash = parsed_relation_hash.tap do |hash|
......
......
......@@ -36,6 +36,10 @@ module Quality
workers
elastic_integration
],
migration: %w[
migrations
lib/gitlab/background_migration
],
integration: %w[
controllers
mailers
......@@ -62,6 +66,10 @@ module Quality
def level_for(file_path)
case file_path
# Detect migration first since some background migration tests are under
# spec/lib/gitlab/background_migration and tests under spec/lib are unit by default
when regexp(:migration)
:migration
when regexp(:unit)
:unit
when regexp(:integration)
......
......
......@@ -7209,15 +7209,15 @@
}
],
"project_feature": {
"builds_access_level": 0,
"builds_access_level": 10,
"created_at": "2014-12-26T09:26:45.000Z",
"id": 2,
"issues_access_level": 0,
"merge_requests_access_level": 20,
"issues_access_level": 10,
"merge_requests_access_level": 10,
"project_id": 4,
"snippets_access_level": 20,
"snippets_access_level": 10,
"updated_at": "2016-09-23T11:58:28.000Z",
"wiki_access_level": 20
"wiki_access_level": 10
},
"custom_attributes": [
{
......@@ -7257,6 +7257,9 @@
"image_url": "http://www.example.com"
}
],
"ci_cd_settings": {
"group_runners_enabled": false
},
"boards": [
{
"id": 29,
......
......
......@@ -75,4 +75,21 @@ describe Projects::ErrorTrackingHelper do
end
end
end
describe '#error_details_data' do
let(:issue_id) { 1234 }
let(:route_params) { [project.owner, project, issue_id, { format: :json }] }
let(:details_path) { details_namespace_project_error_tracking_index_path(*route_params) }
let(:stack_trace_path) { stack_trace_namespace_project_error_tracking_index_path(*route_params) }
let(:result) { helper.error_details_data(project, issue_id) }
it 'returns the correct details path' do
expect(result['issue-details-path']).to eq details_path
end
it 'returns the correct stack trace path' do
expect(result['issue-stack-trace-path']).to eq stack_trace_path
end
end
end