Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
e3e139096e
commit
37a0fef392
|
|
@ -75,3 +75,5 @@ class PostReceiveService
|
|||
::MergeRequests::GetUrlsService.new(project).execute(params[:changes])
|
||||
end
|
||||
end
|
||||
|
||||
PostReceiveService.prepend_if_ee('EE::PostReceiveService')
|
||||
|
|
|
|||
|
|
@ -0,0 +1,19 @@
|
|||
# frozen_string_literal: true
|
||||
|
||||
class AddIndexesToPackageFile < ActiveRecord::Migration[6.0]
|
||||
include Gitlab::Database::MigrationHelpers
|
||||
|
||||
DOWNTIME = false
|
||||
|
||||
disable_ddl_transaction!
|
||||
|
||||
def up
|
||||
add_concurrent_index :packages_package_files, :verification_failure, where: "(verification_failure IS NOT NULL)", name: "packages_packages_verification_failure_partial"
|
||||
add_concurrent_index :packages_package_files, :verification_checksum, where: "(verification_checksum IS NOT NULL)", name: "packages_packages_verification_checksum_partial"
|
||||
end
|
||||
|
||||
def down
|
||||
remove_concurrent_index :packages_package_files, :verification_failure
|
||||
remove_concurrent_index :packages_package_files, :verification_checksum
|
||||
end
|
||||
end
|
||||
|
|
@ -10544,6 +10544,10 @@ CREATE INDEX note_mentions_temp_index ON public.notes USING btree (id, noteable_
|
|||
|
||||
CREATE UNIQUE INDEX one_canonical_wiki_page_slug_per_metadata ON public.wiki_page_slugs USING btree (wiki_page_meta_id) WHERE (canonical = true);
|
||||
|
||||
CREATE INDEX packages_packages_verification_checksum_partial ON public.packages_package_files USING btree (verification_checksum) WHERE (verification_checksum IS NOT NULL);
|
||||
|
||||
CREATE INDEX packages_packages_verification_failure_partial ON public.packages_package_files USING btree (verification_failure) WHERE (verification_failure IS NOT NULL);
|
||||
|
||||
CREATE INDEX partial_index_ci_builds_on_scheduled_at_with_scheduled_jobs ON public.ci_builds USING btree (scheduled_at) WHERE ((scheduled_at IS NOT NULL) AND ((type)::text = 'Ci::Build'::text) AND ((status)::text = 'scheduled'::text));
|
||||
|
||||
CREATE INDEX partial_index_deployments_for_legacy_successful_deployments ON public.deployments USING btree (id) WHERE ((finished_at IS NULL) AND (status = 2));
|
||||
|
|
@ -13065,6 +13069,7 @@ COPY "schema_migrations" (version) FROM STDIN;
|
|||
20200217210353
|
||||
20200217223651
|
||||
20200217225719
|
||||
20200218113721
|
||||
20200219105209
|
||||
20200219133859
|
||||
20200219135440
|
||||
|
|
|
|||
|
|
@ -73,7 +73,7 @@ To disable NFS server delegation, do the following:
|
|||
#### Important notes
|
||||
|
||||
The kernel bug may be fixed in
|
||||
[more recent kernels with this commit](https://github.om/torvalds/linux/commit/95da1b3a5aded124dd1bda1e3cdb876184813140).
|
||||
[more recent kernels with this commit](https://github.com/torvalds/linux/commit/95da1b3a5aded124dd1bda1e3cdb876184813140).
|
||||
|
||||
Red Hat Enterprise 7 [shipped a kernel update](https://access.redhat.com/errata/RHSA-2019:2029)
|
||||
on August 6, 2019 that may also have resolved this problem.
|
||||
|
|
|
|||
|
|
@ -155,6 +155,9 @@ configuration option in `gitlab.yml`. These metrics are served from the
|
|||
| `geo_repositories_retrying_verification_count` | Gauge | 11.2 | Number of repositories verification failures that Geo is actively trying to correct on secondary | url |
|
||||
| `geo_wikis_retrying_verification_count` | Gauge | 11.2 | Number of wikis verification failures that Geo is actively trying to correct on secondary | url |
|
||||
| `global_search_bulk_cron_queue_size` | Gauge | 12.10 | Number of database records waiting to be synchronized to Elasticsearch | |
|
||||
| `package_files_count` | Gauge | 13.0 | Number of package files on primary | url |
|
||||
| `package_files_checksummed_count` | Gauge | 13.0 | Number of package files checksummed on primary | url |
|
||||
| `package_files_checksum_failed_count` | Gauge | 13.0 | Number of package files failed to calculate the checksum on primary
|
||||
|
||||
## Database load balancing metrics **(PREMIUM ONLY)**
|
||||
|
||||
|
|
|
|||
|
|
@ -364,6 +364,9 @@ Example response:
|
|||
"last_successful_status_check_timestamp": 1510125024,
|
||||
"version": "10.3.0",
|
||||
"revision": "33d33a096a",
|
||||
"package_files_count": 10,
|
||||
"package_files_checksummed_count": 10,
|
||||
"package_files_checksum_failed_count": 0
|
||||
},
|
||||
{
|
||||
"geo_node_id": 2,
|
||||
|
|
@ -431,7 +434,10 @@ Example response:
|
|||
"cursor_last_event_timestamp": 1509681166,
|
||||
"last_successful_status_check_timestamp": 1510125024,
|
||||
"version": "10.3.0",
|
||||
"revision": "33d33a096a"
|
||||
"revision": "33d33a096a",
|
||||
"package_files_count": 10,
|
||||
"package_files_checksummed_count": 10,
|
||||
"package_files_checksum_failed_count": 0
|
||||
}
|
||||
]
|
||||
```
|
||||
|
|
|
|||
|
|
@ -84,10 +84,8 @@ module Geo
|
|||
model_record.file
|
||||
end
|
||||
|
||||
private
|
||||
|
||||
# Specify the model this replicator belongs to
|
||||
def model
|
||||
def self.model
|
||||
::Packages::PackageFile
|
||||
end
|
||||
end
|
||||
|
|
@ -182,8 +180,8 @@ For example, to add support for files referenced by a `Widget` model with a
|
|||
end
|
||||
```
|
||||
|
||||
1. Add a partial index on `verification_failure` to ensure re-verification can
|
||||
be performed efficiently:
|
||||
1. Add a partial index on `verification_failure` and `verification_checksum` to ensure
|
||||
re-verification can be performed efficiently:
|
||||
|
||||
```ruby
|
||||
# frozen_string_literal: true
|
||||
|
|
@ -197,10 +195,12 @@ For example, to add support for files referenced by a `Widget` model with a
|
|||
|
||||
def up
|
||||
add_concurrent_index :widgets, :verification_failure, where: "(verification_failure IS NOT NULL)", name: "widgets_verification_failure_partial"
|
||||
add_concurrent_index :widgets, :verification_checksum, where: "(verification_checksum IS NOT NULL)", name: "widgets_verification_checksum_partial"
|
||||
end
|
||||
|
||||
def down
|
||||
remove_concurrent_index :widgets, :verification_failure
|
||||
remove_concurrent_index :widgets, :verification_checksum
|
||||
end
|
||||
end
|
||||
```
|
||||
|
|
@ -351,3 +351,30 @@ For example, to add support for files referenced by a `Widget` model with a
|
|||
```
|
||||
|
||||
Widget files should now be replicated and verified by Geo!
|
||||
|
||||
### Verification statistics with Blob Replicator Strategy
|
||||
|
||||
GitLab Geo stores statistic data in the `geo_node_statuses` table.
|
||||
|
||||
1. Add fields `widget_count`, `widget_checksummed_count`, and `widget_checksum_failed_count`
|
||||
to `GeoNodeStatus#RESOURCE_STATUS_FIELDS` array in `ee/app/models/geo_node_status.rb`.
|
||||
1. Add the same fields to `GeoNodeStatus#PROMETHEUS_METRICS` hash in
|
||||
`ee/app/models/geo_node_status.rb`.
|
||||
1. Add the same fields to `Sidekiq metrics` table in
|
||||
`doc/administration/monitoring/prometheus/gitlab_metrics.md`.
|
||||
1. Add the same fields to `GET /geo_nodes/status` example response in `doc/api/geo_nodes.md`.
|
||||
1. Modify `GeoNodeStatus#load_verification_data` to make sure the fields mantioned above
|
||||
are set:
|
||||
|
||||
```ruby
|
||||
self.widget_count = Geo::WidgetReplicator.model.count
|
||||
self.widget_checksummed_count = Geo::WidgetReplicator.checksummed.count
|
||||
self.widget_checksum_failed_count = Geo::WidgetReplicator.checksum_failed.count
|
||||
```
|
||||
|
||||
1. Make sure `Widget` model has `checksummed` and `checksum_failed` scopes.
|
||||
1. Update `ee/spec/fixtures/api/schemas/public_api/v4/geo_node_status.json` with new fields.
|
||||
1. Update `GeoNodeStatus#PROMETHEUS_METRICS` hash in `ee/app/models/geo_node_status.rb` with new fields.
|
||||
1. Update `Sidekiq metrics` table in `doc/administration/monitoring/prometheus/gitlab_metrics.md` with new fields.
|
||||
1. Update `GET /geo_nodes/status` example response in `doc/api/geo_nodes.md` with new fields.
|
||||
1. Update `ee/spec/models/geo_node_status_spec.rb` and `ee/spec/factories/geo_node_statuses.rb` with new fields.
|
||||
|
|
|
|||
|
|
@ -1,4 +1,4 @@
|
|||
# Security Guidelines
|
||||
# Secure Coding Guidelines
|
||||
|
||||
This document contains descriptions and guidelines for addressing security
|
||||
vulnerabilities commonly identified in the GitLab codebase. They are intended
|
||||
|
|
@ -74,7 +74,7 @@ text = "foo\nbar"
|
|||
p text.match /^bar$/
|
||||
```
|
||||
|
||||
The output of this example is `#<MatchData "bar">`, as Ruby treats the input `text` line by line. In order to match the whole __string__ the Regex anchors `\A` and `\z` should be used according to [Rubular](https://rubular.com/).
|
||||
The output of this example is `#<MatchData "bar">`, as Ruby treats the input `text` line by line. In order to match the whole __string__ the Regex anchors `\A` and `\z` should be used.
|
||||
|
||||
#### Impact
|
||||
|
||||
|
|
@ -104,9 +104,58 @@ Here `params[:ip]` should not contain anything else but numbers and dots. Howeve
|
|||
|
||||
In most cases the anchors `\A` for beginning of text and `\z` for end of text should be used instead of `^` and `$`.
|
||||
|
||||
### Further Links
|
||||
## Denial of Service (ReDoS)
|
||||
|
||||
[ReDoS](https://owasp.org/www-community/attacks/Regular_expression_Denial_of_Service_-_ReDoS) is a possible attack if the attacker knows
|
||||
or controls the regular expression (regex) used, and is able to enter user input to match against the bad regular expression.
|
||||
|
||||
### Impact
|
||||
|
||||
The resource, for example Unicorn, Puma, or Sidekiq, can be made to hang as it takes a long time to evaulate the bad regex match.
|
||||
|
||||
### Examples
|
||||
|
||||
GitLab-specific examples can be found in the following merge requests:
|
||||
|
||||
- [MR25314](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25314)
|
||||
- [MR25122](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/25122#note_289087459)
|
||||
|
||||
Consider the following example application, which defines a check using a regular expression. A user entering `user@aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa!.com` as the email on a form will hang the web server.
|
||||
|
||||
```ruby
|
||||
class Email < ApplicationRecord
|
||||
DOMAIN_MATCH = Regexp.new('([a-zA-Z0-9]+)+\.com')
|
||||
|
||||
validates :domain_matches
|
||||
|
||||
private
|
||||
|
||||
def domain_matches
|
||||
errors.add(:email, 'does not match') if email =~ DOMAIN_MATCH
|
||||
end
|
||||
```
|
||||
|
||||
### Mitigation
|
||||
|
||||
GitLab has `Gitlab::UntrustedRegexp` which internally uses the [`re2`](https://github.com/google/re2/wiki/Syntax) library.
|
||||
By utilizing `re2`, we get a strict limit on total execution time, and a smaller subset of available regex features.
|
||||
|
||||
All user-provided regexes should use `Gitlab::UntrustedRegexp`.
|
||||
|
||||
For other regexes, here are a few guidelines:
|
||||
|
||||
- Remove unnecessary backtracking.
|
||||
- Avoid nested quantifiers if possible.
|
||||
- Try to be as precise as possible in your regex and avoid the `.` if something else can be used (e.g.: Use `_[^_]+_` instead of `_.*_` to match `_text here_`).
|
||||
|
||||
An example can be found [in this commit](https://gitlab.com/gitlab-org/gitlab/commit/717824144f8181bef524592eab882dd7525a60ef).
|
||||
|
||||
## Further Links
|
||||
|
||||
- [Rubular](https://rubular.com/) is a nice online tool to fiddle with Ruby Regexps.
|
||||
- [Runaway Regular Expressions](https://www.regular-expressions.info/catastrophic.html)
|
||||
- [The impact of regular expression denial of service (ReDoS) in practice: an empirical study at the ecosystem scale](http://people.cs.vt.edu/~davisjam/downloads/publications/DavisCoghlanServantLee-EcosystemREDOS-ESECFSE18.pdf). This research paper discusses approaches to automatically detect ReDoS vulnerabilities.
|
||||
- [Freezing the web: A study of redos vulnerabilities in JavaScript-based web servers](https://www.usenix.org/system/files/conference/usenixsecurity18/sec18-staicu.pdf). Another research paper about detecting ReDoS vulnerabilities.
|
||||
|
||||
## Server Side Request Forgery (SSRF)
|
||||
|
||||
|
|
|
|||
|
|
@ -352,14 +352,6 @@ The following table lists variables related to the database.
|
|||
| `POSTGRES_DB` | The PostgreSQL database name. Defaults to the value of [`$CI_ENVIRONMENT_SLUG`](../../ci/variables/README.md#predefined-environment-variables). Set it to use a custom database name. |
|
||||
| `POSTGRES_VERSION` | Tag for the [`postgres` Docker image](https://hub.docker.com/_/postgres) to use. Defaults to `9.6.2`. |
|
||||
|
||||
### Security tools
|
||||
|
||||
The following table lists variables related to security tools.
|
||||
|
||||
| **Variable** | **Description** |
|
||||
|-----------------------------------------|------------------------------------|
|
||||
| `SAST_CONFIDENCE_LEVEL` | Minimum confidence level of security issues you want to be reported; `1` for Low, `2` for Medium, `3` for High. Defaults to `3`. |
|
||||
|
||||
### Disable jobs
|
||||
|
||||
The following table lists variables used to disable jobs.
|
||||
|
|
|
|||
|
|
@ -1,47 +1,47 @@
|
|||
# Stages of Auto DevOps
|
||||
|
||||
The following sections describe the stages of Auto DevOps. Read them carefully
|
||||
to understand how each one works.
|
||||
The following sections describe the stages of [Auto DevOps](index.md).
|
||||
Read them carefully to understand how each one works.
|
||||
|
||||
## Auto Build
|
||||
|
||||
Auto Build creates a build of the application using an existing `Dockerfile` or
|
||||
Heroku buildpacks.
|
||||
|
||||
Either way, the resulting Docker image is automatically pushed to the
|
||||
[Container Registry](../../user/packages/container_registry/index.md) and tagged with the commit SHA or tag.
|
||||
Heroku buildpacks. The resulting Docker image is pushed to the
|
||||
[Container Registry](../../user/packages/container_registry/index.md), and tagged
|
||||
with the commit SHA or tag.
|
||||
|
||||
### Auto Build using a Dockerfile
|
||||
|
||||
If a project's repository contains a `Dockerfile` at its root, Auto Build will use
|
||||
If a project's repository contains a `Dockerfile` at its root, Auto Build uses
|
||||
`docker build` to create a Docker image.
|
||||
|
||||
If you are also using Auto Review Apps and Auto Deploy and choose to provide
|
||||
your own `Dockerfile`, make sure you expose your application to port
|
||||
`5000` as this is the port assumed by the
|
||||
[default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app). Alternatively you can override the default values by [customizing the Auto Deploy Helm chart](customize.md#custom-helm-chart)
|
||||
If you're also using Auto Review Apps and Auto Deploy, and you choose to provide
|
||||
your own `Dockerfile`, you must expose your application to port `5000`, as the
|
||||
[default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app) assumes
|
||||
this port is available. You can override the default values by
|
||||
[customizing the Auto Deploy Helm chart](customize.md#custom-helm-chart).
|
||||
|
||||
### Auto Build using Heroku buildpacks
|
||||
|
||||
Auto Build builds an application using a project's `Dockerfile` if present, or
|
||||
otherwise it will use [Herokuish](https://github.com/gliderlabs/herokuish)
|
||||
Auto Build builds an application using a project's `Dockerfile` if present. If no
|
||||
`Dockerfile` is present, it uses [Herokuish](https://github.com/gliderlabs/herokuish)
|
||||
and [Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks)
|
||||
to automatically detect and build the application into a Docker image.
|
||||
to detect and build the application into a Docker image.
|
||||
|
||||
Each buildpack requires certain files to be in your project's repository for
|
||||
Auto Build to successfully build your application. For example, the following
|
||||
files are required at the root of your application's repository, depending on
|
||||
the language:
|
||||
Each buildpack requires your project's repository to contain certain files for
|
||||
Auto Build to build your application successfully. For example, your application's
|
||||
root directory must contain the appropriate file for your application's
|
||||
language:
|
||||
|
||||
- A `Pipfile` or `requirements.txt` file for Python projects.
|
||||
- A `Gemfile` or `Gemfile.lock` file for Ruby projects.
|
||||
- For Python projects, a `Pipfile` or `requirements.txt` file.
|
||||
- For Ruby projects, a `Gemfile` or `Gemfile.lock` file.
|
||||
|
||||
For the requirements of other languages and frameworks, read the
|
||||
[buildpacks docs](https://devcenter.heroku.com/articles/buildpacks#officially-supported-buildpacks).
|
||||
[Heroku buildpacks documentation](https://devcenter.heroku.com/articles/buildpacks#officially-supported-buildpacks).
|
||||
|
||||
TIP: **Tip:**
|
||||
If Auto Build fails despite the project meeting the buildpack requirements, set
|
||||
a project variable `TRACE=true` to enable verbose logging, which may help to
|
||||
a project variable `TRACE=true` to enable verbose logging, which may help you
|
||||
troubleshoot.
|
||||
|
||||
### Auto Build using Cloud Native Buildpacks (beta)
|
||||
|
|
@ -73,12 +73,12 @@ yet part of the Cloud Native Buildpack specification. For more information, see
|
|||
|
||||
## Auto Test
|
||||
|
||||
Auto Test automatically runs the appropriate tests for your application using
|
||||
[Herokuish](https://github.com/gliderlabs/herokuish) and [Heroku
|
||||
buildpacks](https://devcenter.heroku.com/articles/buildpacks) by analyzing
|
||||
Auto Test runs the appropriate tests for your application using
|
||||
[Herokuish](https://github.com/gliderlabs/herokuish) and
|
||||
[Heroku buildpacks](https://devcenter.heroku.com/articles/buildpacks) by analyzing
|
||||
your project to detect the language and framework. Several languages and
|
||||
frameworks are detected automatically, but if your language is not detected,
|
||||
you may succeed with a [custom buildpack](customize.md#custom-buildpacks). Check the
|
||||
create a [custom buildpack](customize.md#custom-buildpacks). Check the
|
||||
[currently supported languages](index.md#currently-supported-languages).
|
||||
|
||||
Auto Test uses tests you already have in your application. If there are no
|
||||
|
|
@ -88,8 +88,8 @@ tests, it's up to you to add them.
|
|||
|
||||
Auto Code Quality uses the
|
||||
[Code Quality image](https://gitlab.com/gitlab-org/ci-cd/codequality) to run
|
||||
static analysis and other code checks on the current code. The report is
|
||||
created, and is uploaded as an artifact which you can later download and check
|
||||
static analysis and other code checks on the current code. After creating the
|
||||
report, it's uploaded as an artifact which you can later download and check
|
||||
out.
|
||||
|
||||
Any differences between the source and target branches are also
|
||||
|
|
@ -101,14 +101,16 @@ Any differences between the source and target branches are also
|
|||
|
||||
Static Application Security Testing (SAST) uses the
|
||||
[SAST Docker image](https://gitlab.com/gitlab-org/security-products/sast) to run static
|
||||
analysis on the current code and checks for potential security issues. The
|
||||
Auto SAST stage will be skipped on licenses other than Ultimate and requires GitLab Runner 11.5 or above.
|
||||
analysis on the current code, and checks for potential security issues. The
|
||||
Auto SAST stage will be skipped on licenses other than
|
||||
[Ultimate](https://about.gitlab.com/pricing/), and requires GitLab Runner 11.5 or above.
|
||||
|
||||
Once the report is created, it's uploaded as an artifact which you can later download and
|
||||
check out.
|
||||
After creating the report, it's uploaded as an artifact which you can later
|
||||
download and check out.
|
||||
|
||||
Any security warnings are also shown in the merge request widget. Read more how
|
||||
[SAST works](../../user/application_security/sast/index.md).
|
||||
Any security warnings are also shown in the merge request widget. To learn more
|
||||
about [how SAST works](../../user/application_security/sast/index.md), see the
|
||||
documentation.
|
||||
|
||||
## Auto Dependency Scanning **(ULTIMATE)**
|
||||
|
||||
|
|
@ -161,7 +163,7 @@ Any security warnings are also shown in the merge request widget. Read more how
|
|||
|
||||
## Auto Review Apps
|
||||
|
||||
This is an optional step, since many projects do not have a Kubernetes cluster
|
||||
This is an optional step, since many projects don't have a Kubernetes cluster
|
||||
available. If the [requirements](index.md#requirements) are not met, the job will
|
||||
silently be skipped.
|
||||
|
||||
|
|
@ -196,7 +198,7 @@ Your apps should *not* be manipulated outside of Helm (using Kubernetes directly
|
|||
This can cause confusion with Helm not detecting the change and subsequent
|
||||
deploys with Auto DevOps can undo your changes. Also, if you change something
|
||||
and want to undo it by deploying again, Helm may not detect that anything changed
|
||||
in the first place, and thus not realize that it needs to re-apply the old config.
|
||||
in the first place, and thus not realize that it needs to re-apply the old configuration.
|
||||
|
||||
## Auto DAST **(ULTIMATE)**
|
||||
|
||||
|
|
@ -223,7 +225,8 @@ To use a custom target instead of the auto-deployed review apps,
|
|||
set a `DAST_WEBSITE` environment variable to the URL for DAST to scan.
|
||||
|
||||
NOTE: **Note:**
|
||||
If [DAST Full Scan](../../user/application_security/dast/index.md#full-scan) is enabled, it is strongly advised **not**
|
||||
If [DAST Full Scan](../../user/application_security/dast/index.md#full-scan) is
|
||||
enabled, GitLab strongly advises **not**
|
||||
to set `DAST_WEBSITE` to any staging or production environment. DAST Full Scan
|
||||
actively attacks the target, which can take down the application and lead to
|
||||
data loss or corruption.
|
||||
|
|
@ -252,7 +255,7 @@ Any performance differences between the source and target branches are also
|
|||
|
||||
## Auto Deploy
|
||||
|
||||
This is an optional step, since many projects do not have a Kubernetes cluster
|
||||
This is an optional step, since many projects don't have a Kubernetes cluster
|
||||
available. If the [requirements](index.md#requirements) are not met, the job will
|
||||
silently be skipped.
|
||||
|
||||
|
|
@ -261,7 +264,7 @@ After a branch or merge request is merged into the project's default branch (usu
|
|||
the Kubernetes cluster, with a namespace based on the project name and unique
|
||||
project ID, for example `project-4321`.
|
||||
|
||||
Auto Deploy doesn't include deployments to staging or canary by default, but the
|
||||
Auto Deploy does not include deployments to staging or canary by default, but the
|
||||
[Auto DevOps template](https://gitlab.com/gitlab-org/gitlab/blob/master/lib/gitlab/ci/templates/Auto-DevOps.gitlab-ci.yml) contains job definitions for these tasks if you want to
|
||||
enable them.
|
||||
|
||||
|
|
@ -284,7 +287,7 @@ Your apps should *not* be manipulated outside of Helm (using Kubernetes directly
|
|||
This can cause confusion with Helm not detecting the change and subsequent
|
||||
deploys with Auto DevOps can undo your changes. Also, if you change something
|
||||
and want to undo it by deploying again, Helm may not detect that anything changed
|
||||
in the first place, and thus not realize that it needs to re-apply the old config.
|
||||
in the first place, and thus not realize that it needs to re-apply the old configuration.
|
||||
|
||||
> [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/19507) in GitLab 11.0.
|
||||
|
||||
|
|
@ -292,11 +295,11 @@ For internal and private projects a [GitLab Deploy Token](../../user/project/dep
|
|||
will be automatically created, when Auto DevOps is enabled and the Auto DevOps settings are saved. This Deploy Token
|
||||
can be used for permanent access to the registry. When the GitLab Deploy Token has been manually revoked, it won't be automatically created.
|
||||
|
||||
If the GitLab Deploy Token cannot be found, `CI_REGISTRY_PASSWORD` is
|
||||
If the GitLab Deploy Token can't be found, `CI_REGISTRY_PASSWORD` is
|
||||
used. Note that `CI_REGISTRY_PASSWORD` is only valid during deployment.
|
||||
This means that Kubernetes will be able to successfully pull the
|
||||
container image during deployment but in cases where the image needs to
|
||||
be pulled again, e.g. after pod eviction, Kubernetes will fail to do so
|
||||
be pulled again, such as after pod eviction, Kubernetes will fail to do so
|
||||
as it will be attempting to fetch the image using
|
||||
`CI_REGISTRY_PASSWORD`.
|
||||
|
||||
|
|
@ -310,7 +313,7 @@ The default value of `extensions/v1beta1` for the `deploymentApiVersion` setting
|
|||
deprecated, and is scheduled to be changed to a new default of `apps/v1` in
|
||||
[GitLab 13.0](https://gitlab.com/gitlab-org/charts/auto-deploy-app/issues/47).
|
||||
|
||||
In Kubernetes 1.16 onwards, a number of [APIs were removed](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/),
|
||||
In Kubernetes 1.16 and later, a number of [APIs were removed](https://kubernetes.io/blog/2019/07/18/api-deprecations-in-1-16/),
|
||||
including support for `Deployment` in the `extensions/v1beta1` version.
|
||||
|
||||
To use Auto Deploy on a Kubernetes 1.16+ cluster, you must:
|
||||
|
|
@ -351,7 +354,7 @@ GitLab will deploy a second release with the application deployment as
|
|||
normal.
|
||||
|
||||
Note that a post-install hook means that if any deploy succeeds,
|
||||
`DB_INITIALIZE` will not be processed thereafter.
|
||||
`DB_INITIALIZE` won't be processed thereafter.
|
||||
|
||||
If present, `DB_MIGRATE` will be run as a shell command within an application pod as
|
||||
a Helm pre-upgrade hook.
|
||||
|
|
@ -362,21 +365,21 @@ For example, in a Rails application in an image built with
|
|||
- `DB_INITIALIZE` can be set to `RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:setup`
|
||||
- `DB_MIGRATE` can be set to `RAILS_ENV=production /bin/herokuish procfile exec bin/rails db:migrate`
|
||||
|
||||
Unless you have a `Dockerfile` in your repo, your image is built with
|
||||
Unless your repository contains a `Dockerfile`, your image is built with
|
||||
Herokuish, and you must prefix commands run in these images with `/bin/herokuish
|
||||
procfile exec` to replicate the environment where your application will run.
|
||||
|
||||
### Workers
|
||||
|
||||
Some web applications need to run extra deployments for "worker processes". For
|
||||
example, it is common in a Rails application to have a separate worker process
|
||||
example, Rails applications commonly have a separate worker process
|
||||
to run background tasks like sending emails.
|
||||
|
||||
The [default Helm chart](https://gitlab.com/gitlab-org/charts/auto-deploy-app)
|
||||
used in Auto Deploy [has support for running worker
|
||||
processes](https://gitlab.com/gitlab-org/charts/auto-deploy-app/-/merge_requests/9).
|
||||
|
||||
In order to run a worker, you'll need to ensure that it is able to respond to
|
||||
In order to run a worker, you'll need to ensure the worker can respond to
|
||||
the standard health checks, which expect a successful HTTP response on port
|
||||
`5000`. For [Sidekiq](https://github.com/mperham/sidekiq), you could make use of
|
||||
the [`sidekiq_alive` gem](https://rubygems.org/gems/sidekiq_alive) to do this.
|
||||
|
|
@ -389,7 +392,7 @@ need to:
|
|||
- Set a CI variable `K8S_SECRET_REDIS_URL`, which the URL of this instance to
|
||||
ensure it's passed into your deployments.
|
||||
|
||||
Once you have configured your worker to respond to health checks, run a Sidekiq
|
||||
After configuring your worker to respond to health checks, run a Sidekiq
|
||||
worker for your Rails application. You can enable workers by setting the
|
||||
following in the [`.gitlab/auto-deploy-values.yaml` file](customize.md#customize-values-for-helm-chart):
|
||||
|
||||
|
|
@ -500,8 +503,8 @@ ingress:
|
|||
### Running commands in the container
|
||||
|
||||
Applications built with [Auto Build](#auto-build) using Herokuish, the default
|
||||
unless you have [a custom Dockerfile](#auto-build-using-a-dockerfile), may require
|
||||
commands to be wrapped as follows:
|
||||
unless your repository contains [a custom Dockerfile](#auto-build-using-a-dockerfile),
|
||||
may require commands to be wrapped as follows:
|
||||
|
||||
```shell
|
||||
/bin/herokuish procfile exec $COMMAND
|
||||
|
|
|
|||
|
|
@ -30,10 +30,6 @@ module API
|
|||
project.http_url_to_repo
|
||||
end
|
||||
|
||||
def ee_post_receive_response_hook(response)
|
||||
# Hook for EE to add messages
|
||||
end
|
||||
|
||||
def check_allowed(params)
|
||||
# This is a separate method so that EE can alter its behaviour more
|
||||
# easily.
|
||||
|
|
@ -216,8 +212,6 @@ module API
|
|||
|
||||
response = PostReceiveService.new(actor.user, repository, project, params).execute
|
||||
|
||||
ee_post_receive_response_hook(response)
|
||||
|
||||
present response, with: Entities::InternalPostReceive::Response
|
||||
end
|
||||
end
|
||||
|
|
|
|||
|
|
@ -89,7 +89,7 @@ RSpec.shared_examples 'a blob replicator' do
|
|||
end
|
||||
|
||||
describe '#model' do
|
||||
let(:invoke_model) { replicator.send(:model) }
|
||||
let(:invoke_model) { replicator.class.model }
|
||||
|
||||
it 'is implemented' do
|
||||
expect do
|
||||
|
|
|
|||
Loading…
Reference in New Issue