diff options
Diffstat (limited to 'doc')
| -rw-r--r-- | doc/administration/audit_events.md | 4 | ||||
| -rw-r--r-- | doc/administration/gitaly/index.md | 1 | ||||
| -rw-r--r-- | doc/api/commits.md | 2 | ||||
| -rw-r--r-- | doc/ci/environments.md | 67 | ||||
| -rw-r--r-- | doc/ci/img/environment_auto_stop_v12_8.png | bin | 0 -> 43534 bytes | |||
| -rw-r--r-- | doc/ci/review_apps/index.md | 5 | ||||
| -rw-r--r-- | doc/ci/yaml/README.md | 25 | ||||
| -rw-r--r-- | doc/development/understanding_explain_plans.md | 16 | ||||
| -rw-r--r-- | doc/user/clusters/applications.md | 28 |
9 files changed, 141 insertions, 7 deletions
diff --git a/doc/administration/audit_events.md b/doc/administration/audit_events.md index fafd078c487..cf017c0167b 100644 --- a/doc/administration/audit_events.md +++ b/doc/administration/audit_events.md @@ -1,7 +1,3 @@ ---- -last_updated: 2019-09-16 ---- - # Audit Events **(STARTER)** GitLab offers a way to view the changes made within the GitLab server for owners and administrators on a [paid plan][ee]. diff --git a/doc/administration/gitaly/index.md b/doc/administration/gitaly/index.md index 030ed3bc96b..390e0ae05af 100644 --- a/doc/administration/gitaly/index.md +++ b/doc/administration/gitaly/index.md @@ -584,6 +584,7 @@ a few things that you need to do: 1. Configure [object storage for merge request diffs](../merge_request_diffs.md#using-object-storage). 1. Configure [object storage for packages](../packages/index.md#using-object-storage) (optional feature). 1. Configure [object storage for dependency proxy](../packages/dependency_proxy.md#using-object-storage) (optional feature). +1. Configure [object storage for Mattermost](https://docs.mattermost.com/administration/config-settings.html#file-storage) (optional feature). NOTE: **Note:** One current feature of GitLab that still requires a shared directory (NFS) is diff --git a/doc/api/commits.md b/doc/api/commits.md index eb3fb7b2195..ee635a009bf 100644 --- a/doc/api/commits.md +++ b/doc/api/commits.md @@ -18,7 +18,7 @@ GET /projects/:id/repository/commits | `all` | boolean | no | Retrieve every commit from the repository | | `with_stats` | boolean | no | Stats about each commit will be added to the response | | `first_parent` | boolean | no | Follow only the first parent commit upon seeing a merge commit | -| `order` | string | no | List commits in order. Possible value: [`topo`](https://git-scm.com/docs/git-log#Documentation/git-log.txt---topo-order). | +| `order` | string | no | List commits in order. Possible values: `default`, [`topo`](https://git-scm.com/docs/git-log#Documentation/git-log.txt---topo-order). Defaults to `default`, the commits are shown in reverse chronological order. | ```shell curl --header "PRIVATE-TOKEN: <your_access_token>" "https://gitlab.example.com/api/v4/projects/5/repository/commits" diff --git a/doc/ci/environments.md b/doc/ci/environments.md index eddda2031b0..65dc65f23f5 100644 --- a/doc/ci/environments.md +++ b/doc/ci/environments.md @@ -624,6 +624,73 @@ to automatically stop. You can read more in the [`.gitlab-ci.yml` reference](yaml/README.md#environmenton_stop). +#### Environments auto-stop + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/20956) in GitLab 12.8. + +You can set a expiry time to environments and stop them automatically after a certain period. + +For example, consider the use of this feature with Review Apps environments. +When you set up Review Apps, sometimes they keep running for a long time +because some merge requests are left as open. An example for this situation is when the author of the merge +request is not actively working on it, due to priority changes or a different approach was decided on, and the merge requests was simply forgotten. +Idle environments waste resources, therefore they +should be terminated as soon as possible. + +To address this problem, you can specify an optional expiration date for +Review Apps environments. When the expiry time is reached, GitLab will automatically trigger a job +to stop the environment, eliminating the need of manually doing so. In case an environment is updated, the expiration is renewed +ensuring that only active merge requests keep running Review Apps. + +To enable this feature, you need to specify the [`environment:auto_stop_in`](yaml/README.md#environmentauto_stop_in) keyword in `.gitlab-ci.yml`. +You can specify a human-friendly date as the value, such as `1 hour and 30 minutes` or `1 day`. +`auto_stop_in` uses the same format of [`artifacts:expire_in` docs](yaml/README.md#artifactsexpire_in). + +##### Auto-stop example + +In the following example, there is a basic review app setup that creates a new environment +per merge request. The `review_app` job is triggered by every push and +creates or updates an environment named `review/your-branch-name`. +The environment keeps running until `stop_review_app` is executed: + +```yaml +review_app: + script: deploy-review-app + environment: + name: review/$CI_COMMIT_REF_NAME + on_stop: stop_review_app + auto_stop_in: 1 week + +stop_review_app: + script: stop-review-app + environment: + name: review/$CI_COMMIT_REF_NAME + action: stop + when: manual +``` + +As long as a merge request is active and keeps getting new commits, +the review app will not stop, so developers don't need to worry about +re-initiating review app. + +On the other hand, since `stop_review_app` is set to `auto_stop_in: 1 week`, +if a merge request becomes inactive for more than a week, +GitLab automatically triggers the `stop_review_app` job to stop the environment. + +You can also check the expiration date of environments through the GitLab UI. To do so, +go to **Operations > Environments > Environment**. You can see the auto-stop period +at the left-top section and a pin-mark button at the right-top section. This pin-mark +button can be used to prevent auto-stopping the environment. By clicking this button, the `auto_stop_in` setting is over-written +and the environment will be active until it's stopped manually. + + + +NOTE: **NOTE** +Due to the resource limitation, a background worker for stopping environments only +runs once every hour. This means environments will not be stopped at the exact +timestamp as the specified period, but will be stopped when the hourly cron worker +detects expired environments. + ### Grouping similar environments > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/7015) in GitLab 8.14. diff --git a/doc/ci/img/environment_auto_stop_v12_8.png b/doc/ci/img/environment_auto_stop_v12_8.png Binary files differnew file mode 100644 index 00000000000..3a3c54ab62d --- /dev/null +++ b/doc/ci/img/environment_auto_stop_v12_8.png diff --git a/doc/ci/review_apps/index.md b/doc/ci/review_apps/index.md index cc081f2543a..bdef2eca1f2 100644 --- a/doc/ci/review_apps/index.md +++ b/doc/ci/review_apps/index.md @@ -80,6 +80,11 @@ you can copy and paste into `.gitlab-ci.yml` as a starting point. To do so: 1. Feel free to tune this template to your own needs. +## Review Apps auto-stop + +See how to [configure Review Apps environments to expire and auto-stop](../environments.md#environments-auto-stop) +after a given period of time. + ## Review Apps examples The following are example projects that demonstrate Review App configuration: diff --git a/doc/ci/yaml/README.md b/doc/ci/yaml/README.md index 3367fac5137..1a301481f05 100644 --- a/doc/ci/yaml/README.md +++ b/doc/ci/yaml/README.md @@ -105,7 +105,7 @@ The following table lists available parameters for jobs: | [`tags`](#tags) | List of tags which are used to select Runner. | | [`allow_failure`](#allow_failure) | Allow job to fail. Failed job doesn't contribute to commit status. | | [`when`](#when) | When to run job. Also available: `when:manual` and `when:delayed`. | -| [`environment`](#environment) | Name of an environment to which the job deploys. Also available: `environment:name`, `environment:url`, `environment:on_stop`, and `environment:action`. | +| [`environment`](#environment) | Name of an environment to which the job deploys. Also available: `environment:name`, `environment:url`, `environment:on_stop`, `environment:auto_stop_in` and `environment:action`. | | [`cache`](#cache) | List of files that should be cached between subsequent runs. Also available: `cache:paths`, `cache:key`, `cache:untracked`, and `cache:policy`. | | [`artifacts`](#artifacts) | List of files and directories to attach to a job on success. Also available: `artifacts:paths`, `artifacts:expose_as`, `artifacts:name`, `artifacts:untracked`, `artifacts:when`, `artifacts:expire_in`, `artifacts:reports`, and `artifacts:reports:junit`.<br><br>In GitLab [Enterprise Edition](https://about.gitlab.com/pricing/), these are available: `artifacts:reports:codequality`, `artifacts:reports:sast`, `artifacts:reports:dependency_scanning`, `artifacts:reports:container_scanning`, `artifacts:reports:dast`, `artifacts:reports:license_management`, `artifacts:reports:performance` and `artifacts:reports:metrics`. | | [`dependencies`](#dependencies) | Restrict which artifacts are passed to a specific job by providing a list of jobs to fetch artifacts from. | @@ -1453,6 +1453,29 @@ The `stop_review_app` job is **required** to have the following keywords defined - `stage` should be the same as the `review_app` in order for the environment to stop automatically when the branch is deleted +#### `environment:auto_stop_in` + +> [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/20956) in GitLab 12.8. + +The `auto_stop_in` keyword is for specifying life period of the environment, +that when expired, GitLab GitLab automatically stops them. + +For example, + +```yaml +review_app: + script: deploy-review-app + environment: + name: review/$CI_COMMIT_REF_NAME + auto_stop_in: 1 day +``` + +When `review_app` job is executed and a review app is created, a life period of +the environment is set to `1 day`. + +For more information, see +[the environments auto-stop documentation](../environments.md#environments-auto-stop) + #### `environment:kubernetes` > [Introduced](https://gitlab.com/gitlab-org/gitlab/issues/27630) in GitLab 12.6. diff --git a/doc/development/understanding_explain_plans.md b/doc/development/understanding_explain_plans.md index 8f4caf286fe..8b1a6df72c4 100644 --- a/doc/development/understanding_explain_plans.md +++ b/doc/development/understanding_explain_plans.md @@ -707,7 +707,7 @@ For more information about the available options, run: ### `#database-lab` -Another tool GitLab employees can use is a chatbot powered by [Joe](https://gitlab.com/postgres-ai/joe), available in the [`#database-lab`](https://gitlab.slack.com/archives/CLJMDRD8C) channel on Slack. +Another tool GitLab employees can use is a chatbot powered by [Joe](https://gitlab.com/postgres-ai/joe) which uses [Database Lab](https://gitlab.com/postgres-ai/database-lab) to instantly provide developers with their own clone of the production database. Joe is available in the [`#database-lab`](https://gitlab.slack.com/archives/CLJMDRD8C) channel on Slack. Unlike chatops, it gives you a way to execute DDL statements (like creating indexes and tables) and get query plan not only for `SELECT` but also `UPDATE` and `DELETE`. For example, in order to test new index you can do the following: @@ -742,6 +742,20 @@ For more information about the available options, run: help ``` +#### Tips & Tricks + +The database connection is now maintained during your whole session, so you can use `exec set ...` for any session variables (such as `enable_seqscan` or `work_mem`). These settings will be applied to all subsequent commands until you reset them. + +It is also possible to use transactions. This may be useful when you are working on statements that modify the data, for example INSERT, UPDATE, and DELETE. The `explain` command will perform `EXPLAIN ANALYZE`, which executes the statement. In order to run each `explain` starting from a clean state you can wrap it in a transaction, for example: + +```sql +exec BEGIN + +explain UPDATE some_table SET some_column = TRUE + +exec ROLLBACK +``` + ## Further reading A more extensive guide on understanding query plans can be found in diff --git a/doc/user/clusters/applications.md b/doc/user/clusters/applications.md index 55c51ef5fb6..c526f7339d5 100644 --- a/doc/user/clusters/applications.md +++ b/doc/user/clusters/applications.md @@ -488,6 +488,7 @@ Supported applications: - [GitLab Runner](#install-gitlab-runner-using-gitlab-ci) - [Cilium](#install-cilium-using-gitlab-ci) - [JupyterHub](#install-jupyterhub-using-gitlab-ci) +- [Elastic Stack](#install-elastic-stack-using-gitlab-ci) ### Usage @@ -791,6 +792,33 @@ project. Refer to the [chart reference](https://zero-to-jupyterhub.readthedocs.io/en/stable/reference.html) for the available configuration options. +### Install Elastic Stack using GitLab CI + +> [Introduced](https://gitlab.com/gitlab-org/cluster-integration/cluster-applications/-/merge_requests/45) in GitLab 12.8. + +Elastic Stack is installed using GitLab CI by defining configuration in +`.gitlab/managed-apps/config.yaml`. + +The following configuration is required to install Elastic Stack using GitLab CI: + +```yaml +elasticStack: + installed: true +``` + +Elastic Stack is installed into the `gitlab-managed-apps` namespace of your cluster. + +You can check the default [values.yaml](https://gitlab.com/gitlab-org/gitlab/-/blob/master/vendor/elastic_stack/values.yaml) we set for this chart. + +You can customize the installation of Elastic Stack by defining +`.gitlab/managed-apps/elastic-stack/values.yaml` file in your cluster +management project. Refer to the +[chart](https://github.com/helm/charts/blob/master/stable/elastic-stack/values.yaml) for the +available configuration options. + +NOTE: **Note:** +In this alpha implementation of installing Elastic Stack through CI, reading the environment pod logs through Elasticsearch is unsupported. This is supported if [installed via the UI](#elastic-stack). + ## Upgrading applications > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/24789) in GitLab 11.8. |
