Add latest changes from gitlab-org/gitlab@master
This commit is contained in:
GitLab Bot
parent
8d94fb4ae1
commit
09fe75d837
|
|
@ -51,7 +51,7 @@ class Projects::IssuesController < Projects::ApplicationController
|
|||
real_time_feature_flag = :real_time_issue_sidebar
|
||||
real_time_enabled = Gitlab::ActionCable::Config.in_app? || Feature.enabled?(real_time_feature_flag, @project)
|
||||
|
||||
gon.push({ features: { real_time_feature_flag.to_s.camelize(:lower) => real_time_enabled } }, true)
|
||||
push_to_gon_features(real_time_feature_flag, real_time_enabled)
|
||||
|
||||
record_experiment_user(:invite_members_version_a)
|
||||
record_experiment_user(:invite_members_version_b)
|
||||
|
|
|
|||
|
|
@ -36,8 +36,8 @@ error, it's very important that you [**provide feedback**](https://gitlab.com/gi
|
|||
as possible so we can improve or fix it while behind a flag. When you upgrade
|
||||
GitLab to an earlier version, the feature flag status may change.
|
||||
|
||||
NOTE: **Note:**
|
||||
Mind that features deployed behind feature flags may not be ready for
|
||||
CAUTION: **Caution:**
|
||||
Features deployed behind feature flags may not be ready for
|
||||
production use. However, disabling features behind flags that were deployed
|
||||
enabled by default may also present a risk. If they're enabled, we recommend
|
||||
you leave them as-is.
|
||||
|
|
|
|||
|
|
@ -13,7 +13,6 @@ The [GitLab exporter](https://gitlab.com/gitlab-org/gitlab-exporter) enables you
|
|||
measure various GitLab metrics pulled from Redis and the database in Omnibus GitLab
|
||||
instances.
|
||||
|
||||
NOTE: **Note:**
|
||||
For installations from source you must install and configure it yourself.
|
||||
|
||||
To enable the GitLab exporter in an Omnibus GitLab instance:
|
||||
|
|
|
|||
|
|
@ -13,7 +13,6 @@ To enable the GitLab Prometheus metrics:
|
|||
1. Find the **Metrics - Prometheus** section, and click **Enable Prometheus Metrics**.
|
||||
1. [Restart GitLab](../../restart_gitlab.md#omnibus-gitlab-restart) for the changes to take effect.
|
||||
|
||||
NOTE: **Note:**
|
||||
For installations from source you must configure it yourself.
|
||||
|
||||
## Collecting the metrics
|
||||
|
|
|
|||
|
|
@ -31,7 +31,6 @@ dashboard tool like [Grafana](https://grafana.com).
|
|||
|
||||
## Configuring Prometheus
|
||||
|
||||
NOTE: **Note:**
|
||||
For installations from source, you must install and configure it yourself.
|
||||
|
||||
Prometheus and its exporters are on by default, starting with GitLab 9.0.
|
||||
|
|
@ -54,7 +53,7 @@ To disable Prometheus and all of its exporters, as well as any added in the futu
|
|||
|
||||
### Changing the port and address Prometheus listens on
|
||||
|
||||
NOTE: **Note:**
|
||||
CAUTION: **Caution:**
|
||||
The following change was added in [Omnibus GitLab 8.17](https://gitlab.com/gitlab-org/omnibus-gitlab/-/merge_requests/1261). Although possible,
|
||||
it's not recommended to change the port Prometheus listens
|
||||
on, as this might affect or conflict with other services running on the GitLab
|
||||
|
|
@ -178,7 +177,6 @@ The next step is to tell all the other nodes where the monitoring node is:
|
|||
1. Save the file and [reconfigure GitLab](../../restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to
|
||||
take effect.
|
||||
|
||||
NOTE: **Note:**
|
||||
After monitoring using Service Discovery is enabled with `consul['monitoring_service_discovery'] = true`,
|
||||
ensure that `prometheus['scrape_configs']` is not set in `/etc/gitlab/gitlab.rb`. Setting both
|
||||
`consul['monitoring_service_discovery'] = true` and `prometheus['scrape_configs']` in `/etc/gitlab/gitlab.rb`
|
||||
|
|
@ -186,7 +184,7 @@ will result in errors.
|
|||
|
||||
### Using an external Prometheus server
|
||||
|
||||
NOTE: **Note:**
|
||||
CAUTION: **Caution:**
|
||||
Prometheus and most exporters don't support authentication. We don't recommend exposing them outside the local network.
|
||||
|
||||
A few configuration changes are required to allow GitLab to be monitored by an external Prometheus server. External servers are recommended for [GitLab deployments with multiple nodes](../../reference_architectures/index.md).
|
||||
|
|
|
|||
|
|
@ -9,7 +9,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
The [node exporter](https://github.com/prometheus/node_exporter) enables you to measure
|
||||
various machine resources such as memory, disk and CPU utilization.
|
||||
|
||||
NOTE: **Note:**
|
||||
For installations from source you must install and configure it yourself.
|
||||
|
||||
To enable the node exporter:
|
||||
|
|
|
|||
|
|
@ -11,7 +11,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
The [PgBouncer exporter](https://github.com/prometheus-community/pgbouncer_exporter) enables
|
||||
you to measure various [PgBouncer](https://www.pgbouncer.org/) metrics.
|
||||
|
||||
NOTE: **Note:**
|
||||
For installations from source you must install and configure it yourself.
|
||||
|
||||
To enable the PgBouncer exporter:
|
||||
|
|
|
|||
|
|
@ -8,7 +8,6 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
|
||||
The [PostgreSQL Server Exporter](https://github.com/wrouesnel/postgres_exporter) allows you to export various PostgreSQL metrics.
|
||||
|
||||
NOTE: **Note:**
|
||||
For installations from source you must install and configure it yourself.
|
||||
|
||||
To enable the PostgreSQL Server Exporter:
|
||||
|
|
|
|||
|
|
@ -10,7 +10,6 @@ The [Redis exporter](https://github.com/oliver006/redis_exporter) enables you to
|
|||
various [Redis](https://redis.io) metrics. For more information on what is exported,
|
||||
[read the upstream documentation](https://github.com/oliver006/redis_exporter/blob/master/README.md#whats-exported).
|
||||
|
||||
NOTE: **Note:**
|
||||
For installations from source you must install and configure it yourself.
|
||||
|
||||
To enable the Redis exporter:
|
||||
|
|
|
|||
|
|
@ -116,7 +116,7 @@ See the section on [ETag mismatch errors](#etag-mismatch) for more details.
|
|||
gitlab_rails['object_store']['objects']['terraform_state']['bucket'] = '<terraform-state>'
|
||||
```
|
||||
|
||||
NOTE: For GitLab 9.4 or later, if you're using AWS IAM profiles, be sure to omit the
|
||||
For GitLab 9.4 or later, if you're using AWS IAM profiles, be sure to omit the
|
||||
AWS access key and secret access key/value pairs. For example:
|
||||
|
||||
```ruby
|
||||
|
|
@ -263,9 +263,9 @@ Here are the valid connection parameters for GCS:
|
|||
| `google_json_key_location` | The JSON key path | `/path/to/gcp-project-12345-abcde.json` |
|
||||
| `google_application_default` | Set to `true` to use [Google Cloud Application Default Credentials](https://cloud.google.com/docs/authentication/production#automatically) to locate service account credentials. |
|
||||
|
||||
NOTE: **Note:**
|
||||
The service account must have permission to access the bucket.
|
||||
[See more](https://cloud.google.com/storage/docs/authentication)
|
||||
The service account must have permission to access the bucket. Learn more
|
||||
in Google's
|
||||
[Cloud Storage authentication documentation](https://cloud.google.com/storage/docs/authentication).
|
||||
|
||||
##### Google example (consolidated form)
|
||||
|
||||
|
|
|
|||
|
|
@ -50,7 +50,6 @@ To configure the pseudonymizer, you need to:
|
|||
}
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
If you are using AWS IAM profiles, be sure to omit the AWS access key and secret access key/value pairs.
|
||||
|
||||
```ruby
|
||||
|
|
|
|||
|
|
@ -21,7 +21,6 @@ Automatic resolution is not yet implemented. If you have values that
|
|||
cannot be decrypted, you can follow steps to reset them, see our
|
||||
docs on what to do [when the secrets file is lost](../../raketasks/backup_restore.md#when-the-secrets-file-is-lost).
|
||||
|
||||
NOTE: **Note:**
|
||||
This can take a very long time, depending on the size of your
|
||||
database, as it checks all rows in all tables.
|
||||
|
||||
|
|
|
|||
|
|
@ -130,7 +130,6 @@ sudo gitlab-rake gitlab:check
|
|||
bundle exec rake gitlab:check RAILS_ENV=production
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
Use `SANITIZE=true` for `gitlab:check` if you want to omit project names from the output.
|
||||
|
||||
Example output:
|
||||
|
|
|
|||
|
|
@ -74,7 +74,7 @@ To have a summary and then a list of projects and their attachments using hashed
|
|||
|
||||
## Migrate to hashed storage
|
||||
|
||||
NOTE: **Note:**
|
||||
DANGER: **Deprecated:**
|
||||
In GitLab 13.0, [hashed storage](../repository_storage_types.md#hashed-storage)
|
||||
is enabled by default and the legacy storage is deprecated.
|
||||
Support for legacy storage will be removed in GitLab 14.0. If you're on GitLab
|
||||
|
|
@ -115,7 +115,6 @@ If you find it necessary, you can run this migration script again to schedule mi
|
|||
|
||||
Any error or warning will be logged in Sidekiq's log file.
|
||||
|
||||
NOTE: **Note:**
|
||||
If [Geo](../geo/index.md) is enabled, each project that is successfully migrated
|
||||
generates an event to replicate the changes on any **secondary** nodes.
|
||||
|
||||
|
|
@ -124,7 +123,7 @@ commands below that helps you inspect projects and attachments in both legacy an
|
|||
|
||||
## Rollback from hashed storage to legacy storage
|
||||
|
||||
NOTE: **Deprecated:**
|
||||
DANGER: **Deprecated:**
|
||||
In GitLab 13.0, [hashed storage](../repository_storage_types.md#hashed-storage)
|
||||
is enabled by default and the legacy storage is deprecated.
|
||||
Support for legacy storage will be removed in GitLab 14.0. If you're on GitLab
|
||||
|
|
|
|||
|
|
@ -16,11 +16,10 @@ There is a Rake task for migrating uploads between different storage types.
|
|||
After [configuring the object storage](../../uploads.md#using-object-storage) for GitLab's
|
||||
uploads, use this task to migrate existing uploads from the local storage to the remote storage.
|
||||
|
||||
Read more about using [object storage with GitLab](../../object_storage.md).
|
||||
|
||||
NOTE: **Note:**
|
||||
All of the processing will be done in a background worker and requires **no downtime**.
|
||||
|
||||
Read more about using [object storage with GitLab](../../object_storage.md).
|
||||
|
||||
### All-in-one Rake task
|
||||
|
||||
GitLab provides a wrapper Rake task that migrates all uploaded files (for example avatars, logos,
|
||||
|
|
@ -99,7 +98,6 @@ gitlab-rake "gitlab:uploads:migrate[DesignManagement::DesignV432x230Uploader, De
|
|||
|
||||
**Source Installation**
|
||||
|
||||
NOTE: **Note:**
|
||||
Use `RAILS_ENV=production` for every task.
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -91,9 +91,10 @@ The instructions make the assumption that you will be using the email address `i
|
|||
quit
|
||||
```
|
||||
|
||||
_**Note:** The `.` is a literal period on its own line._
|
||||
NOTE: **Note:**
|
||||
The `.` is a literal period on its own line.
|
||||
|
||||
_**Note:** If you receive an error after entering `rcpt to: incoming@localhost`
|
||||
If you receive an error after entering `rcpt to: incoming@localhost`
|
||||
then your Postfix `my_network` configuration is not correct. The error will
|
||||
say 'Temporary lookup failure'. See
|
||||
[Configure Postfix to receive email from the Internet](#configure-postfix-to-receive-email-from-the-internet)._
|
||||
|
|
@ -164,11 +165,11 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
q
|
||||
```
|
||||
|
||||
_**Note:** If `mail` returns an error `Maildir: Is a directory` then your
|
||||
If `mail` returns an error `Maildir: Is a directory` then your
|
||||
version of `mail` doesn't support Maildir style mailboxes. Install
|
||||
`heirloom-mailx` by running `sudo apt-get install heirloom-mailx`. Then,
|
||||
try the above steps again, substituting `heirloom-mailx` for the `mail`
|
||||
command._
|
||||
command.
|
||||
|
||||
1. Sign out of the `incoming` account, and go back to being `root`:
|
||||
|
||||
|
|
@ -271,7 +272,8 @@ Courier, which we will install later to add IMAP authentication, requires mailbo
|
|||
quit
|
||||
```
|
||||
|
||||
(Note: The `.` is a literal period on its own line)
|
||||
NOTE: **Note:**
|
||||
The `.` is a literal period on its own line.
|
||||
|
||||
1. Check if the `incoming` user received the email:
|
||||
|
||||
|
|
|
|||
|
|
@ -9,8 +9,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
Notification emails sent by GitLab can be signed with S/MIME for improved
|
||||
security.
|
||||
|
||||
NOTE: **Note:**
|
||||
Please be aware that S/MIME certificates and TLS/SSL certificates are not the
|
||||
Be aware that S/MIME certificates and TLS/SSL certificates are not the
|
||||
same and are used for different purposes: TLS creates a secure channel, whereas
|
||||
S/MIME signs and/or encrypts the message itself
|
||||
|
||||
|
|
@ -27,7 +26,7 @@ files must be provided:
|
|||
Optionally, you can also provide a bundle of CA certs (PEM-encoded) to be
|
||||
included on each signature. This will typically be an intermediate CA.
|
||||
|
||||
NOTE: **Note:**
|
||||
CAUTION: **Caution:**
|
||||
Be mindful of the access levels for your private keys and visibility to
|
||||
third parties.
|
||||
|
||||
|
|
@ -45,7 +44,6 @@ third parties.
|
|||
|
||||
1. Save the file and [reconfigure GitLab](restart_gitlab.md#omnibus-gitlab-reconfigure) for the changes to take effect.
|
||||
|
||||
NOTE: **Note:**
|
||||
The key needs to be readable by the GitLab system user (`git` by default).
|
||||
|
||||
**For installations from source:**
|
||||
|
|
@ -69,7 +67,6 @@ The key needs to be readable by the GitLab system user (`git` by default).
|
|||
|
||||
1. Save the file and [restart GitLab](restart_gitlab.md#installations-from-source) for the changes to take effect.
|
||||
|
||||
NOTE: **Note:**
|
||||
The key needs to be readable by the GitLab system user (`git` by default).
|
||||
|
||||
### How to convert S/MIME PKCS#12 / PFX format to PEM encoding
|
||||
|
|
|
|||
|
|
@ -21,7 +21,7 @@ To see all available time zones, run `bundle exec rake time:zones:all`.
|
|||
For Omnibus installations, run `gitlab-rake time:zones:all`.
|
||||
|
||||
NOTE: **Note:**
|
||||
Currently, this Rake task does not list timezones in TZInfo format required by Omnibus GitLab during a reconfigure: [#27209](https://gitlab.com/gitlab-org/gitlab/-/issues/27209).
|
||||
This Rake task does not list timezones in TZInfo format required by Omnibus GitLab during a reconfigure: [#27209](https://gitlab.com/gitlab-org/gitlab/-/issues/27209).
|
||||
|
||||
## Changing time zone in Omnibus installations
|
||||
|
||||
|
|
|
|||
|
|
@ -308,11 +308,11 @@ pp p.statistics # compare with earlier values
|
|||
|
||||
### Recreate
|
||||
|
||||
A Projects Wiki can be recreated by
|
||||
|
||||
NOTE: **Note:**
|
||||
CAUTION: **Caution:**
|
||||
This is a destructive operation, the Wiki will be empty.
|
||||
|
||||
A Projects Wiki can be recreated by this command:
|
||||
|
||||
```ruby
|
||||
p = Project.find_by_full_path('<username-or-group>/<project-name>') ### enter your projects path
|
||||
|
||||
|
|
|
|||
|
|
@ -70,8 +70,7 @@ and they will assist you with any issues you are having.
|
|||
kubectl logs <pod-name> --previous
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
No logs are kept in the containers/pods themselves, everything is written to stdout.
|
||||
No logs are kept in the containers/pods themselves. Everything is written to stdout.
|
||||
This is the principle of Kubernetes, read [Twelve-factor app](https://12factor.net/)
|
||||
for details.
|
||||
|
||||
|
|
|
|||
|
|
@ -18,7 +18,6 @@ If you are administering GitLab you are expected to know these commands for your
|
|||
of choice. If you are a GitLab Support Engineer, consider this a cross-reference to
|
||||
translate `yum` -> `apt-get` and the like.
|
||||
|
||||
Note: **Note:**
|
||||
Most of the commands below have not been labeled as to which distribution they work
|
||||
on. Contributions are welcome to help add them.
|
||||
|
||||
|
|
|
|||
|
|
@ -385,7 +385,7 @@ User.find_by(username: 'root')
|
|||
User.find_by_any_email('user@example.com')
|
||||
```
|
||||
|
||||
Note: `find_by_any_email` is a custom method added by GitLab developers rather
|
||||
The `find_by_any_email` method is a custom method added by GitLab developers rather
|
||||
than a Rails-provided default method.
|
||||
|
||||
**Get a collection of admin users:**
|
||||
|
|
@ -394,7 +394,7 @@ than a Rails-provided default method.
|
|||
User.admins
|
||||
```
|
||||
|
||||
Note: `admins` is a [scope convenience method](https://guides.rubyonrails.org/active_record_querying.html#scopes)
|
||||
`admins` is a [scope convenience method](https://guides.rubyonrails.org/active_record_querying.html#scopes)
|
||||
which does `where(admin: true)` under the hood.
|
||||
|
||||
**Get a project by its path:**
|
||||
|
|
@ -403,7 +403,7 @@ which does `where(admin: true)` under the hood.
|
|||
Project.find_by_full_path('group/subgroup/project')
|
||||
```
|
||||
|
||||
Note: `find_by_full_path` is a custom method added by GitLab developers rather
|
||||
`find_by_full_path` is a custom method added by GitLab developers rather
|
||||
than a Rails-provided default method.
|
||||
|
||||
**Get a project's issue or merge request by its numeric ID:**
|
||||
|
|
@ -414,7 +414,7 @@ project.issues.find_by(iid: 42)
|
|||
project.merge_requests.find_by(iid: 42)
|
||||
```
|
||||
|
||||
Note: `iid` means "internal ID" and is how we keep issue and merge request IDs
|
||||
`iid` means "internal ID" and is how we keep issue and merge request IDs
|
||||
scoped to each GitLab project.
|
||||
|
||||
**Get a group by its path:**
|
||||
|
|
@ -454,7 +454,7 @@ Ci::Pipeline.find(4151)
|
|||
Ci::Build.find(66124)
|
||||
```
|
||||
|
||||
Note: The pipeline and job #ID numbers increment globally across your GitLab
|
||||
The pipeline and job ID numbers increment globally across your GitLab
|
||||
instance, so there's no need to use an internal ID attribute to look them up,
|
||||
unlike with issues or merge requests.
|
||||
|
||||
|
|
|
|||
|
|
@ -148,4 +148,4 @@ It may take a little while to respond.
|
|||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
These are Omnibus settings. If an external database, such as a customer's PostgreSQL installation or Amazon RDS is being used, these values don't get set, and would have to be set externally.
|
||||
These are Omnibus GitLab settings. If an external database, such as a customer's PostgreSQL installation or Amazon RDS is being used, these values don't get set, and would have to be set externally.
|
||||
|
|
|
|||
|
|
@ -13,12 +13,10 @@ may be filling up. Users will notice when this happens because new branches
|
|||
may not show up and merge requests may not be updated. The following are some
|
||||
troubleshooting steps that will help you diagnose the bottleneck.
|
||||
|
||||
NOTE: **Note:**
|
||||
GitLab administrators/users should consider working through these
|
||||
debug steps with GitLab Support so the backtraces can be analyzed by our team.
|
||||
It may reveal a bug or necessary improvement in GitLab.
|
||||
|
||||
NOTE: **Note:**
|
||||
In any of the backtraces, be wary of suspecting cases where every
|
||||
thread appears to be waiting in the database, Redis, or waiting to acquire
|
||||
a mutex. This **may** mean there's contention in the database, for example,
|
||||
|
|
@ -133,7 +131,6 @@ corresponding Ruby code where this is happening.
|
|||
`gdb` can be another effective tool for debugging Sidekiq. It gives you a little
|
||||
more interactive way to look at each thread and see what's causing problems.
|
||||
|
||||
NOTE: **Note:**
|
||||
Attaching to a process with `gdb` will suspends the normal operation
|
||||
of the process (Sidekiq will not process jobs while `gdb` is attached).
|
||||
|
||||
|
|
@ -284,15 +281,15 @@ end
|
|||
|
||||
### Remove Sidekiq jobs for given parameters (destructive)
|
||||
|
||||
The general method to kill jobs conditionally is the following:
|
||||
The general method to kill jobs conditionally is the following command, which
|
||||
will remove jobs that are queued but not started. Running jobs will not be killed.
|
||||
|
||||
```ruby
|
||||
queue = Sidekiq::Queue.new('<queue name>')
|
||||
queue.each { |job| job.delete if <condition>}
|
||||
```
|
||||
|
||||
NOTE: **Note:**
|
||||
This will remove jobs that are queued but not started, running jobs will not be killed. Have a look at the section below for cancelling running jobs.
|
||||
Have a look at the section below for cancelling running jobs.
|
||||
|
||||
In the method above, `<queue-name>` is the name of the queue that contains the job(s) you want to delete and `<condition>` will decide which jobs get deleted.
|
||||
|
||||
|
|
@ -300,7 +297,6 @@ Commonly, `<condition>` references the job arguments, which depend on the type o
|
|||
|
||||
For example, `repository_import` has `project_id` as the job argument, while `update_merge_requests` has `project_id, user_id, oldrev, newrev, ref`.
|
||||
|
||||
NOTE: **Note:**
|
||||
Arguments need to be referenced by their sequence ID using `job.args[<id>]` because `job.args` is a list of all arguments provided to the Sidekiq job.
|
||||
|
||||
Here are some examples:
|
||||
|
|
|
|||
|
|
@ -631,7 +631,7 @@ GET /projects/:id/repository/commits/:sha/statuses
|
|||
| `sha` | string | yes | The commit SHA
|
||||
| `ref` | string | no | The name of a repository branch or tag or, if not given, the default branch
|
||||
| `stage` | string | no | Filter by [build stage](../ci/yaml/README.md#stages), e.g., `test`
|
||||
| `name` | string | no | Filter by [job name](../ci/yaml/README.md#introduction), e.g., `bundler:audit`
|
||||
| `name` | string | no | Filter by [job name](../ci/yaml/README.md#job-keywords), e.g., `bundler:audit`
|
||||
| `all` | boolean | no | Return all statuses, not only the latest ones
|
||||
|
||||
```shell
|
||||
|
|
|
|||
|
|
@ -34,8 +34,7 @@ currently being deployed or has been deployed on your servers.
|
|||
It's important to know that:
|
||||
|
||||
- Environments are like tags for your CI jobs, describing where code gets deployed.
|
||||
- Deployments are created when [jobs](../yaml/README.md#introduction) deploy versions of code to environments,
|
||||
so every environment can have one or more deployments.
|
||||
- Deployments are created when [GitLab CI/CD](../yaml/README.md) is used to deploy versions of code to environments.
|
||||
|
||||
GitLab:
|
||||
|
||||
|
|
|
|||
|
|
@ -140,7 +140,7 @@ new browser window interacting with your app as you specified.
|
|||
Which brings us to the exciting part: how do we run this in GitLab CI/CD? There are two things we
|
||||
need to do for this:
|
||||
|
||||
1. Set up [CI/CD jobs](../../yaml/README.md#introduction) that actually have a browser available.
|
||||
1. Set up [CI/CD jobs](../../yaml/README.md) that actually have a browser available.
|
||||
1. Update our WebdriverIO configuration to use those browsers to visit the review apps.
|
||||
|
||||
For the scope of this article, we've defined an additional [CI/CD stage](../../yaml/README.md#stages)
|
||||
|
|
|
|||
|
|
@ -17,6 +17,14 @@ Out-of-the-box management systems can decrease hours spent on maintaining toolch
|
|||
Watch our ["Mastering continuous software development"](https://about.gitlab.com/webcast/mastering-ci-cd/)
|
||||
webcast to learn about continuous methods and how GitLab’s built-in CI can help you simplify and scale software development.
|
||||
|
||||
> For some additional information about GitLab CI/CD:
|
||||
>
|
||||
> - <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch the [CI/CD Ease of configuration](https://www.youtube.com/embed/opdLqwz6tcE) video.
|
||||
> - Watch the [Making the case for CI/CD in your organization](https://about.gitlab.com/compare/github-actions-alternative/)
|
||||
> webcast to learn the benefits of CI/CD and how to measure the results of CI/CD automation.
|
||||
> - <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Learn how [Verizon reduced rebuilds](https://about.gitlab.com/blog/2019/02/14/verizon-customer-story/)
|
||||
> from 30 days to under 8 hours with GitLab.
|
||||
|
||||
## Introduction to CI/CD methodologies
|
||||
|
||||
The continuous methodologies of software development are based on
|
||||
|
|
|
|||
|
|
@ -27,7 +27,7 @@ CircleCI's `config.yml` configuration file defines scripts, jobs, and workflows
|
|||
|
||||
### Jobs
|
||||
|
||||
In CircleCI, jobs are a collection of steps to perform a specific task. In GitLab, [jobs](../yaml/README.md#introduction) are also a fundamental element in the configuration file. The `checkout` keyword is not necessary in GitLab CI/CD as the repository is automatically fetched.
|
||||
In CircleCI, jobs are a collection of steps to perform a specific task. In GitLab, [jobs](../pipelines/index.md#about-jobs) are also a fundamental element in the configuration file. The `checkout` keyword is not necessary in GitLab CI/CD as the repository is automatically fetched.
|
||||
|
||||
CircleCI example job definition:
|
||||
|
||||
|
|
|
|||
|
|
@ -68,7 +68,7 @@ Pipelines can be configured in many different ways:
|
|||
|
||||
Pipelines and their component jobs and stages are defined in the CI/CD pipeline configuration file for each project.
|
||||
|
||||
- Jobs are the [basic configuration](../yaml/README.md#introduction) component.
|
||||
- Jobs are the [basic configuration](#about-jobs) component.
|
||||
- Stages are defined by using the [`stages`](../yaml/README.md#stages) keyword.
|
||||
|
||||
For a list of configuration options in the CI pipeline file, see the [GitLab CI/CD Pipeline Configuration Reference](../yaml/README.md).
|
||||
|
|
@ -287,7 +287,36 @@ preserving deployment keys and other credentials from being unintentionally
|
|||
accessed. In order to ensure that jobs intended to be executed on protected
|
||||
runners do not use regular runners, they must be tagged accordingly.
|
||||
|
||||
## View jobs in a pipeline
|
||||
## About jobs
|
||||
|
||||
Pipeline configuration begins with jobs. Jobs are the most fundamental element of a `.gitlab-ci.yml` file.
|
||||
|
||||
Jobs are:
|
||||
|
||||
- Defined with constraints stating under what conditions they should be executed.
|
||||
- Top-level elements with an arbitrary name and must contain at least the [`script`](../yaml/README.md#script) clause.
|
||||
- Not limited in how many can be defined.
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
job1:
|
||||
script: "execute-script-for-job1"
|
||||
|
||||
job2:
|
||||
script: "execute-script-for-job2"
|
||||
```
|
||||
|
||||
The above example is the simplest possible CI/CD configuration with two separate
|
||||
jobs, where each of the jobs executes a different command.
|
||||
Of course a command can execute code directly (`./configure;make;make install`)
|
||||
or run a script (`test.sh`) in the repository.
|
||||
|
||||
Jobs are picked up by [runners](../runners/README.md) and executed within the
|
||||
environment of the runner. What is important is that each job is run
|
||||
independently from each other.
|
||||
|
||||
### View jobs in a pipeline
|
||||
|
||||
When you access a pipeline, you can see the related jobs for that pipeline.
|
||||
|
||||
|
|
|
|||
|
|
@ -13,7 +13,12 @@ GitLab offers a [continuous integration](https://about.gitlab.com/stages-devops-
|
|||
- Add a [`.gitlab-ci.yml` file](#creating-a-gitlab-ciyml-file) to your repository's root directory.
|
||||
- Ensure your project is configured to use a [runner](#configuring-a-runner).
|
||||
|
||||
The `.gitlab-ci.yml` file tells the runner what to do. A simple pipeline commonly has
|
||||
The `.gitlab-ci.yml` file defines the structure and order of the pipelines, and determines:
|
||||
|
||||
- What to execute using [GitLab Runner](https://docs.gitlab.com/runner/).
|
||||
- What decisions to make when specific conditions are encountered. For example, when a process succeeds or fails.
|
||||
|
||||
A simple pipeline commonly has
|
||||
three [stages](../yaml/README.md#stages):
|
||||
|
||||
- `build`
|
||||
|
|
|
|||
|
|
@ -225,7 +225,7 @@ should disable **Pipelines must succeed** so you can accept merge requests.
|
|||
|
||||
Pipeline configuration warnings are shown when you:
|
||||
|
||||
- [Validate configuration with the CI Lint tool](yaml/README.md#validate-the-gitlab-ciyml).
|
||||
- [Validate configuration with the CI Lint tool](yaml/README.md).
|
||||
- [Manually run a pipeline](pipelines/index.md#run-a-pipeline-manually).
|
||||
|
||||
### "Job may allow multiple pipelines to run for a single action" warning
|
||||
|
|
|
|||
|
|
@ -7,92 +7,16 @@ type: reference
|
|||
|
||||
# GitLab CI/CD pipeline configuration reference
|
||||
|
||||
GitLab CI/CD [pipelines](../pipelines/index.md) are configured using a YAML file called `.gitlab-ci.yml` within each project.
|
||||
This document lists the configuration options for your GitLab `.gitlab-ci.yml` file.
|
||||
|
||||
The `.gitlab-ci.yml` file defines the structure and order of the pipelines and determines:
|
||||
|
||||
- What to execute using [GitLab Runner](https://docs.gitlab.com/runner/).
|
||||
- What decisions to make when specific conditions are encountered. For example, when a process succeeds or fails.
|
||||
|
||||
This topic covers CI/CD pipeline configuration. For other CI/CD configuration information, see:
|
||||
|
||||
- [GitLab CI/CD Variables](../variables/README.md), for configuring the environment the pipelines run in.
|
||||
- [GitLab Runner advanced configuration](https://docs.gitlab.com/runner/configuration/advanced-configuration.html), for configuring GitLab Runner.
|
||||
|
||||
We have complete examples of configuring pipelines:
|
||||
|
||||
- For a quick introduction to GitLab CI/CD, follow our [quick start guide](../quick_start/README.md).
|
||||
- For a quick introduction to GitLab CI/CD, follow the [quick start guide](../quick_start/README.md).
|
||||
- For a collection of examples, see [GitLab CI/CD Examples](../examples/README.md).
|
||||
- To see a large `.gitlab-ci.yml` file used in an enterprise, see the [`.gitlab-ci.yml` file for `gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
|
||||
- To view a large `.gitlab-ci.yml` file used in an enterprise, see the [`.gitlab-ci.yml` file for `gitlab`](https://gitlab.com/gitlab-org/gitlab/blob/master/.gitlab-ci.yml).
|
||||
|
||||
> For some additional information about GitLab CI/CD:
|
||||
>
|
||||
> - <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Watch the [CI/CD Ease of configuration](https://www.youtube.com/embed/opdLqwz6tcE) video.
|
||||
> - Watch the [Making the case for CI/CD in your organization](https://about.gitlab.com/compare/github-actions-alternative/)
|
||||
> webcast to learn the benefits of CI/CD and how to measure the results of CI/CD automation.
|
||||
> - <i class="fa fa-youtube-play youtube" aria-hidden="true"></i> Learn how [Verizon reduced rebuilds](https://about.gitlab.com/blog/2019/02/14/verizon-customer-story/)
|
||||
> from 30 days to under 8 hours with GitLab.
|
||||
|
||||
If you have a [mirrored repository that GitLab pulls from](../../user/project/repository/repository_mirroring.md#pulling-from-a-remote-repository),
|
||||
you may need to enable pipeline triggering. Go to your project's **Settings > Repository > Pull from a remote repository > Trigger pipelines for mirror updates**.
|
||||
|
||||
## Introduction
|
||||
|
||||
Pipeline configuration begins with jobs. Jobs are the most fundamental element of a `.gitlab-ci.yml` file.
|
||||
|
||||
Jobs are:
|
||||
|
||||
- Defined with constraints stating under what conditions they should be executed.
|
||||
- Top-level elements with an arbitrary name and must contain at least the [`script`](#script) clause.
|
||||
- Not limited in how many can be defined.
|
||||
|
||||
For example:
|
||||
|
||||
```yaml
|
||||
job1:
|
||||
script: "execute-script-for-job1"
|
||||
|
||||
job2:
|
||||
script: "execute-script-for-job2"
|
||||
```
|
||||
|
||||
The above example is the simplest possible CI/CD configuration with two separate
|
||||
jobs, where each of the jobs executes a different command.
|
||||
Of course a command can execute code directly (`./configure;make;make install`)
|
||||
or run a script (`test.sh`) in the repository.
|
||||
|
||||
Jobs are picked up by [runners](../runners/README.md) and executed within the
|
||||
environment of the runner. What is important is that each job is run
|
||||
independently from each other.
|
||||
|
||||
### Validate the `.gitlab-ci.yml`
|
||||
|
||||
Each instance of GitLab CI/CD has an embedded debug tool called Lint, which validates the
|
||||
content of your `.gitlab-ci.yml` files. You can find the Lint under the page `ci/lint` of your
|
||||
While you are authoring your `.gitlab-ci.yml` file, you can validate it
|
||||
by using the [CI Lint](../lint.md) tool.
|
||||
project namespace. For example, `https://gitlab.example.com/gitlab-org/project-123/-/ci/lint`.
|
||||
|
||||
### Unavailable names for jobs
|
||||
|
||||
Each job must have a unique name, but there are a few **reserved `keywords` that
|
||||
can't be used as job names**:
|
||||
|
||||
- `image`
|
||||
- `services`
|
||||
- `stages`
|
||||
- `types`
|
||||
- `before_script`
|
||||
- `after_script`
|
||||
- `variables`
|
||||
- `cache`
|
||||
- `include`
|
||||
|
||||
### Using reserved keywords
|
||||
|
||||
If you get validation error when using specific values (for example, `true` or `false`), try to:
|
||||
|
||||
- Quote them.
|
||||
- Change them to a different form. For example, `/bin/true`.
|
||||
|
||||
## Job keywords
|
||||
|
||||
A job is defined as a list of keywords that define the job's behavior.
|
||||
|
|
@ -130,10 +54,32 @@ The following table lists available keywords for jobs:
|
|||
| [`variables`](#variables) | Define job variables on a job level. |
|
||||
| [`when`](#when) | When to run job. Also available: `when:manual` and `when:delayed`. |
|
||||
|
||||
### Unavailable names for jobs
|
||||
|
||||
Each job must have a unique name, but there are a few **reserved `keywords` that
|
||||
can't be used as job names**:
|
||||
|
||||
- `image`
|
||||
- `services`
|
||||
- `stages`
|
||||
- `types`
|
||||
- `before_script`
|
||||
- `after_script`
|
||||
- `variables`
|
||||
- `cache`
|
||||
- `include`
|
||||
|
||||
## Global keywords
|
||||
|
||||
Some keywords must be defined at a global level, affecting all jobs in the pipeline.
|
||||
|
||||
### Using reserved keywords
|
||||
|
||||
If you get validation error when using specific values (for example, `true` or `false`), try to:
|
||||
|
||||
- Quote them.
|
||||
- Change them to a different form. For example, `/bin/true`.
|
||||
|
||||
### Global defaults
|
||||
|
||||
Some keywords can be set globally as the default for all jobs using the
|
||||
|
|
|
|||
|
|
@ -48,7 +48,7 @@ An instance of Editor Lite accepts the following configuration options:
|
|||
| `blobPath` | `false` | `String`: the name of a file to render in the editor. It is used to identify the correct syntax highlighter to use with that or another file type. Can accept wildcard as in `*.js` when the actual filename isn't known or doesn't play any role |
|
||||
| `blobContent` | `false` | `String`: the initial content to be rendered in the editor |
|
||||
| `extensions` | `false` | `Array`: extensions to use in this instance |
|
||||
| `blobGlobalId` | `false` | `String`: auto-generated property.</br>**Note:** this prop might go away in the future. Do not pass `blobGlobalId` unless you know what you're doing.|
|
||||
| `blobGlobalId` | `false` | `String`: auto-generated property.<br>**Note:** this prop might go away in the future. Do not pass `blobGlobalId` unless you know what you're doing.|
|
||||
| [Editor Options](https://microsoft.github.io/monaco-editor/api/enums/monaco.editor.editoroption.html) | `false` | `Object(s)`: any prop outside of the list above is treated as an Editor Option for this particular instance. This way, one can override global Editor Options on the instance level. |
|
||||
|
||||
## API
|
||||
|
|
|
|||
|
|
@ -7,7 +7,7 @@ info: To determine the technical writer assigned to the Stage/Group associated w
|
|||
# Security scanner integration
|
||||
|
||||
Integrating a security scanner into GitLab consists of providing end users
|
||||
with a [CI job definition](../../ci/yaml/README.md#introduction)
|
||||
with a [CI job definition](../../ci/yaml/README.md)
|
||||
they can add to their CI configuration files to scan their GitLab projects.
|
||||
This CI job should then output its results in a GitLab-specified format. These results are then
|
||||
automatically presented in various places in GitLab, such as the Pipeline view, Merge Request
|
||||
|
|
|
|||
|
|
@ -83,14 +83,6 @@ GitLab version 13.6, use version 13.6.x versions of `agentk`.
|
|||
The available `agentk` versions can be found in
|
||||
[its container registry](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/container_registry/eyJuYW1lIjoiZ2l0bGFiLW9yZy9jbHVzdGVyLWludGVncmF0aW9uL2dpdGxhYi1hZ2VudC9hZ2VudGsiLCJ0YWdzX3BhdGgiOiIvZ2l0bGFiLW9yZy9jbHVzdGVyLWludGVncmF0aW9uL2dpdGxhYi1hZ2VudC9yZWdpc3RyeS9yZXBvc2l0b3J5LzEyMjMyMDUvdGFncz9mb3JtYXQ9anNvbiIsImlkIjoxMjIzMjA1LCJjbGVhbnVwX3BvbGljeV9zdGFydGVkX2F0IjpudWxsfQ==).
|
||||
|
||||
### Upgrades and Version compatibility
|
||||
|
||||
As the GitLab Kubernetes Agent is a new product, we are constantly adding new features to it. As a result, while shipped features are production ready, it's internal API is not stable nor versioned yet. For this reason, we only guarantee compatibility between corresponding major.minor versions of GitLab and its cluster side component, `agentk`. Please, upgrade your agent installations together with GitLab upgrades.
|
||||
|
||||
Example: having GitLab 13.6 installed, please use version 13.6.x versions of `agentk`.
|
||||
|
||||
The available `agentk` versions can be found in [its container registry](https://gitlab.com/gitlab-org/cluster-integration/gitlab-agent/container_registry/eyJuYW1lIjoiZ2l0bGFiLW9yZy9jbHVzdGVyLWludGVncmF0aW9uL2dpdGxhYi1hZ2VudC9hZ2VudGsiLCJ0YWdzX3BhdGgiOiIvZ2l0bGFiLW9yZy9jbHVzdGVyLWludGVncmF0aW9uL2dpdGxhYi1hZ2VudC9yZWdpc3RyeS9yZXBvc2l0b3J5LzEyMjMyMDUvdGFncz9mb3JtYXQ9anNvbiIsImlkIjoxMjIzMjA1LCJjbGVhbnVwX3BvbGljeV9zdGFydGVkX2F0IjpudWxsfQ==).
|
||||
|
||||
### Install the Kubernetes Agent Server
|
||||
|
||||
The GitLab Kubernetes Agent Server (KAS) can be deployed using [Omnibus
|
||||
|
|
|
|||
Binary file not shown.
|
Before Width: | Height: | Size: 78 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 42 KiB |
Binary file not shown.
|
Before Width: | Height: | Size: 11 KiB |
Binary file not shown.
|
After Width: | Height: | Size: 69 KiB |
|
|
@ -130,7 +130,7 @@ give a user access to all projects in the group with one action.
|
|||
|
||||
Add members to a group by navigating to the group's dashboard and clicking **Members**.
|
||||
|
||||
|
||||
|
||||
|
||||
Select the [permission level](../permissions.md#permissions), and add the new member. You can also set the expiring date for that user; this is the date on which they will no longer have access to your group.
|
||||
|
||||
|
|
@ -375,9 +375,9 @@ In GitLab [8.15](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/822) and
|
|||
|
||||
1. Go to your group's **Members** page.
|
||||
1. Select the pencil icon in the row for the user you are editing.
|
||||
1. Select the orange `Change permissions` button.
|
||||
1. Select the brown `Edit permissions` button in the modal.
|
||||
|
||||
|
||||
|
||||
|
||||
Now you will be able to edit the user's permissions from the **Members** page.
|
||||
|
||||
|
|
|
|||
|
|
@ -137,3 +137,9 @@ Feature.disable(:generic_packages)
|
|||
# For a single project
|
||||
Feature.disable(:generic_packages, Project.find(<project id>))
|
||||
```
|
||||
|
||||
### Generic package sample project
|
||||
|
||||
The [Write CI-CD Variables in Pipeline](https://gitlab.com/guided-explorations/cfg-data/write-ci-cd-variables-in-pipeline) project contains a working example you can use to create, upload, and download generic packages in GitLab CI/CD.
|
||||
|
||||
It also demonstrates how to manage a semantic version for the generic package: storing it in a CI/CD variable, retrieving it, incrementing it, and writing it back to the CI/CD variable when tests for the download work correctly.
|
||||
|
|
|
|||
|
|
@ -158,9 +158,8 @@ When it succeeds, go to **Settings > Pages** to view the URL where your site
|
|||
is now available.
|
||||
|
||||
If you want to do more advanced tasks, you can update your `.gitlab-ci.yml` file
|
||||
with [any of the available settings](../../../../ci/yaml/README.md). See
|
||||
[Validate the `.gitlab-ci.yml`](../../../../ci/yaml/README.md#validate-the-gitlab-ciyml)
|
||||
for instructions on validating your YAML file with the Lint tool included with GitLab.
|
||||
with [any of the available settings](../../../../ci/yaml/README.md). You can validate
|
||||
your `.gitlab-ci.yml` file with the [CI Lint](../../../../ci/lint.md) tool that's included with GitLab.
|
||||
|
||||
After successful execution of this `pages` job, a special `pages:deploy` job appears in the
|
||||
pipeline view. It prepares the content of the website for GitLab Pages daemon. GitLab executes it in
|
||||
|
|
|
|||
|
|
@ -58,9 +58,13 @@ module Gitlab
|
|||
# args - Any additional arguments to pass to `Feature.enabled?`. This allows
|
||||
# you to check if a flag is enabled for a particular user.
|
||||
def push_frontend_feature_flag(name, *args, **kwargs)
|
||||
var_name = name.to_s.camelize(:lower)
|
||||
enabled = Feature.enabled?(name, *args, **kwargs)
|
||||
|
||||
push_to_gon_features(name, enabled)
|
||||
end
|
||||
|
||||
def push_to_gon_features(name, enabled)
|
||||
var_name = name.to_s.camelize(:lower)
|
||||
# Here the `true` argument signals gon that the value should be merged
|
||||
# into any existing ones, instead of overwriting them. This allows you to
|
||||
# use this method to push multiple feature flags.
|
||||
|
|
|
|||
Loading…
Reference in New Issue