diff options
author | GitLab Bot <gitlab-bot@gitlab.com> | 2019-11-26 15:06:18 +0300 |
---|---|---|
committer | GitLab Bot <gitlab-bot@gitlab.com> | 2019-11-26 15:06:18 +0300 |
commit | 6a4ffad42050949fcf08e78147575734ae99627e (patch) | |
tree | 723bb2480948ba4ec29ca9ac10f8728dc2a831b6 /doc | |
parent | 23d237110e6a646dec08e1f5b4696d2d9c51cfef (diff) |
Add latest changes from gitlab-org/gitlab@master
Diffstat (limited to 'doc')
-rw-r--r-- | doc/administration/monitoring/performance/img/performance_bar.png | bin | 71317 -> 58439 bytes | |||
-rw-r--r-- | doc/administration/monitoring/performance/performance_bar.md | 1 | ||||
-rw-r--r-- | doc/administration/pages/index.md | 17 | ||||
-rw-r--r-- | doc/policy/maintenance.md | 4 | ||||
-rw-r--r-- | doc/user/gitlab_com/index.md | 1 | ||||
-rw-r--r-- | doc/user/project/clusters/add_remove_clusters.md | 42 | ||||
-rw-r--r-- | doc/user/project/integrations/jira.md | 11 | ||||
-rw-r--r-- | doc/user/project/repository/repository_mirroring.md | 15 |
8 files changed, 63 insertions, 28 deletions
diff --git a/doc/administration/monitoring/performance/img/performance_bar.png b/doc/administration/monitoring/performance/img/performance_bar.png Binary files differindex acad60f863e..73f2ccbe4bb 100644 --- a/doc/administration/monitoring/performance/img/performance_bar.png +++ b/doc/administration/monitoring/performance/img/performance_bar.png diff --git a/doc/administration/monitoring/performance/performance_bar.md b/doc/administration/monitoring/performance/performance_bar.md index a52b6227e14..caddc87d8c1 100644 --- a/doc/administration/monitoring/performance/performance_bar.md +++ b/doc/administration/monitoring/performance/performance_bar.md @@ -19,6 +19,7 @@ It allows you to see (from left to right): - a link to add a request's details to the performance bar; the request can be added by its full URL (authenticated as the current user), or by the value of its `X-Request-Id` header +- a link to download the raw JSON used to generate the Performance Bar reports On the far right is a request selector that allows you to view the same metrics (excluding the page timing and line profiler) for any requests made while the diff --git a/doc/administration/pages/index.md b/doc/administration/pages/index.md index f51c375860b..eb3fc07d7c9 100644 --- a/doc/administration/pages/index.md +++ b/doc/administration/pages/index.md @@ -321,6 +321,23 @@ pages: 1. [Reconfigure GitLab][reconfigure] for the changes to take effect. +### Using a custom Certificate Authority (CA) with Access Control + +When using certificates issued by a custom CA, Access Control on GitLab Pages may fail to work if the custom CA is not recognized. + +This usually results in this error: +`Post /oauth/token: x509: certificate signed by unknown authority`. + +For GitLab Pages Access Control with TLS/SSL certs issued by an internal or custom CA: + +1. Copy the certificate bundle to `/opt/gitlab/embedded/ssl/certs/` in `.pem` format. + +1. [Restart](../restart_gitlab.md) the GitLab Pages Daemon. For GitLab Omnibus instances: + + ```bash + sudo gitlab-ctl restart gitlab-pages + ``` + ## Activate verbose logging for daemon Verbose logging was [introduced](https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/2533) in diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md index ef94236d711..49f2b61a497 100644 --- a/doc/policy/maintenance.md +++ b/doc/policy/maintenance.md @@ -48,8 +48,8 @@ incremental upgrades (and installations) are as simple as possible. review process a new change goes through. 1. Ensuring that tests pass on older release is a considerable challenge in some cases, and as such is very time consuming. -Including new features in patch releases is not possible as that would break [Semantic Versioning]. -Breaking [Semantic Versioning] has the following consequences for users that +Including new features in patch releases is not possible as that would break [Semantic Versioning](https://semver.org/). +Breaking [Semantic Versioning](https://semver.org/) has the following consequences for users that have to adhere to various internal requirements (e.g. org. compliance, verifying new features and similar): 1. Inability to quickly upgrade to leverage bug fixes included in patch versions. diff --git a/doc/user/gitlab_com/index.md b/doc/user/gitlab_com/index.md index 5912fc8e9f9..38ffd07a737 100644 --- a/doc/user/gitlab_com/index.md +++ b/doc/user/gitlab_com/index.md @@ -63,6 +63,7 @@ Below are the current settings regarding [GitLab CI/CD](../../ci/README.md). | ----------- | ----------------- | ------------- | | Artifacts maximum size (uncompressed) | 1G | 100M | | Artifacts [expiry time](../../ci/yaml/README.md#artifactsexpire_in) | kept forever | deleted after 30 days unless otherwise specified | +| Scheduled Pipeline Cron | `*/5 * * * *` | `*/19 * * * *` | ## Repository size limit diff --git a/doc/user/project/clusters/add_remove_clusters.md b/doc/user/project/clusters/add_remove_clusters.md index c73368fbbd2..ad5a0c2273b 100644 --- a/doc/user/project/clusters/add_remove_clusters.md +++ b/doc/user/project/clusters/add_remove_clusters.md @@ -34,7 +34,7 @@ namespace. This service account will be: -- Added to the installed Helm Tiller +- Added to the installed Helm Tiller. - Used by Helm to install and run [GitLab managed applications](index.md#installing-applications). Helm will also create additional service accounts and other resources for each @@ -111,6 +111,11 @@ If you don't want to use GitLab Runner in privileged mode, either: ## Add new cluster +New clusters can be added using GitLab for: + +- Google Kubernetes Engine. +- Amazon Elastic Kubernetes Service. + ### GKE cluster GitLab supports: @@ -206,43 +211,30 @@ 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. +- Self-managed GitLab instances have the `create_eks_clusters` feature flag enabled. - 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: +##### Enable the `create_eks_clusters` feature flag **(CORE ONLY)** -```sh -# Omnibus GitLab -gitlab-rails console +Self-managed instances must have the feature flag `create_eks_clusters` enabled to create +EKS clusters. To enable EKS cluster creation, ask a GitLab administrator with Rails console access +to run the following command: -# 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: - -``` +```ruby Feature.enable(:create_eks_clusters) ``` -You can also enable the feature flag only for specific projects with: +To have it enabled for a specific project only, ask a GitLab administrator to run the following +command using a Rails console: -``` +```ruby Feature.enable(:create_eks_clusters, Project.find_by_full_path('my_group/my_project')) ``` -Run the following command to disable the feature flag: +To have this feature disabled, ask a GitLab administrator to run the following command: -``` +```ruby Feature.disable(:create_eks_clusters) ``` diff --git a/doc/user/project/integrations/jira.md b/doc/user/project/integrations/jira.md index 874a1092b73..d08c8699eba 100644 --- a/doc/user/project/integrations/jira.md +++ b/doc/user/project/integrations/jira.md @@ -20,7 +20,7 @@ Here's how the integration responds when you take the following actions in GitLa - **Mention a Jira issue ID** in a commit message or MR (merge request). - GitLab hyperlinks to the Jira issue. - The Jira issue adds an issue link to the commit/MR in GitLab. - - The Jira issue adds a comment reflecting the comment made in GitLab, the comment author, and a link to the commit/MR in GitLab. + - The Jira issue adds a comment reflecting the comment made in GitLab, the comment author, and a link to the commit/MR in GitLab, unless this commenting to Jira is [disabled](#disabling-comments-on-jira-issues). - **Mention that a commit or MR 'closes', 'resolves', or 'fixes' a Jira issue ID**. When the commit is made on the project's default branch (usually master) or the change is merged to the default branch: - GitLab's merge request page displays a note that it "Closed" the Jira issue, with a link to the issue. (Note: Before the merge, an MR will display that it "Closes" the Jira issue.) - The Jira issue shows the activity and the Jira issue is closed, or otherwise transitioned. @@ -95,6 +95,15 @@ with all Jira projects in your Jira instance and you'll see the Jira link on the ![Jira service page](img/jira_service_page_v12_2.png) +### Disabling comments on Jira issues + +When you reference a Jira issue, it will always link back to the source commit/MR in GitLab, however, you can control whether GitLab will also cross-post a comment to the Jira issue. That functionality is enabled by default. + +To disable the automated commenting on Jira issues: + +1. Open the [Integrations page](project_services.md#accessing-the-project-services) and select **Jira**. +1. In the **Event Action** section, uncheck **Comment**. + ## Jira issues By now you should have [configured Jira](#configuring-jira) and enabled the diff --git a/doc/user/project/repository/repository_mirroring.md b/doc/user/project/repository/repository_mirroring.md index a682983ab83..7d49aecb603 100644 --- a/doc/user/project/repository/repository_mirroring.md +++ b/doc/user/project/repository/repository_mirroring.md @@ -143,6 +143,7 @@ Changes pushed to the upstream repository will be pulled into the GitLab reposit CAUTION: **Caution:** If you do manually update a branch in the GitLab repository, the branch will become diverged from upstream and GitLab will no longer automatically update this branch to prevent any changes from being lost. +Also note that deleted branches and tags in the upstream repository will not be reflected in the GitLab repository. ### How it works @@ -247,6 +248,10 @@ If you need to change the key at any time, you can remove and re-add the mirror to generate a new key. You'll have to update the other repository with the new key to keep the mirror running. +NOTE: **Note:** +The generated keys are stored in the GitLab database, not in the filesystem. Therefore, +SSH public key authentication for mirrors cannot be used in a pre-receive hook. + ### Overwrite diverged branches **(STARTER)** > [Introduced](https://gitlab.com/gitlab-org/gitlab/merge_requests/4559) in [GitLab Starter](https://about.gitlab.com/pricing/) 10.6. @@ -362,6 +367,7 @@ proxy_push() branch=$(expr "$refname" : "refs/heads/\(.*\)") if [ "$whitelisted" = "$branch" ]; then + unset GIT_QUARANTINE_PATH # handle https://git-scm.com/docs/git-receive-pack#_quarantine_environment error="$(git push --quiet $TARGET_REPO $NEWREV:$REFNAME 2>&1)" fail=$? @@ -396,6 +402,15 @@ else fi ``` +Note that this sample has a few limitations: + +- This example may not work verbatim for your use case and might need modification. + - It does not regard different types of authentication mechanisms for the mirror. + - It does not work with forced updates (rewriting history). + - Only branches that match the `whitelisted` patterns will be proxy pushed. +- The script circumvents the git hook quarantine environment because the update of `$TARGET_REPO` + is seen as a ref update and git will complain about it. + ### Mirroring with Perforce Helix via Git Fusion **(STARTER)** CAUTION: **Warning:** |