diff --git a/changelogs/unreleased/cnp-description.yml b/changelogs/unreleased/cnp-description.yml new file mode 100644 index 00000000000..bdc571f6f25 --- /dev/null +++ b/changelogs/unreleased/cnp-description.yml @@ -0,0 +1,5 @@ +--- +title: Improve support for description field on CiliumNetworkPolicy +merge_request: 41722 +author: +type: changed diff --git a/doc/administration/environment_variables.md b/doc/administration/environment_variables.md index ebc3848017f..d48a47e9645 100644 --- a/doc/administration/environment_variables.md +++ b/doc/administration/environment_variables.md @@ -32,7 +32,7 @@ Variable | Type | Description `GITLAB_EMAIL_SUBJECT_SUFFIX` | string | The e-mail subject suffix used in e-mails sent by GitLab `GITLAB_UNICORN_MEMORY_MIN` | integer | The minimum memory threshold (in bytes) for the Unicorn worker killer `GITLAB_UNICORN_MEMORY_MAX` | integer | The maximum memory threshold (in bytes) for the Unicorn worker killer -`GITLAB_SHARED_RUNNERS_REGISTRATION_TOKEN` | string | Sets the initial registration token used for GitLab Runners +`GITLAB_SHARED_RUNNERS_REGISTRATION_TOKEN` | string | Sets the initial registration token used for runners `UNSTRUCTURED_RAILS_LOG` | string | Enables the unstructured log in addition to JSON logs (defaults to `true`) ## Complete database variables diff --git a/doc/administration/geo/replication/index.md b/doc/administration/geo/replication/index.md index f1cc9f0df8b..058c96fb24a 100644 --- a/doc/administration/geo/replication/index.md +++ b/doc/administration/geo/replication/index.md @@ -281,7 +281,7 @@ This list of limitations only reflects the latest version of GitLab. If you are - [Selective synchronization](configuration.md#selective-synchronization) applies only to files and repositories. Other datasets are replicated to the **secondary** node in full, making it inappropriate for use as an access control mechanism. - Object pools for forked project deduplication work only on the **primary** node, and are duplicated on the **secondary** node. - [External merge request diffs](../../merge_request_diffs.md) will not be replicated if they are on-disk, and viewing merge requests will fail. However, external MR diffs in object storage **are** supported. The default configuration (in-database) does work. -- GitLab Runners cannot register with a **secondary** node. Support for this is [planned for the future](https://gitlab.com/gitlab-org/gitlab/-/issues/3294). +- Runners cannot register with a **secondary** node. Support for this is [planned for the future](https://gitlab.com/gitlab-org/gitlab/-/issues/3294). ### Limitations on replication/verification diff --git a/doc/administration/index.md b/doc/administration/index.md index 63965e201a8..c972a957303 100644 --- a/doc/administration/index.md +++ b/doc/administration/index.md @@ -157,8 +157,8 @@ Learn how to install, configure, update, and maintain your GitLab instance. - [External Pipeline Validation](external_pipeline_validation.md): Enable, disable and configure external pipeline validation. - [Job artifacts](job_artifacts.md): Enable, disable, and configure job artifacts (a set of files and directories which are outputted by a job when it completes successfully). - [Job logs](job_logs.md): Information about the job logs. -- [Register Runners](../ci/runners/README.md#types-of-runners): Learn how to register and configure Runners. -- [Shared Runners pipelines quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota): Limit the usage of pipeline minutes for Shared Runners. **(STARTER ONLY)** +- [Register runners](../ci/runners/README.md#types-of-runners): Learn how to register and configure runners. +- [Shared runners pipelines quota](../user/admin_area/settings/continuous_integration.md#shared-runners-pipeline-minutes-quota): Limit the usage of pipeline minutes for shared runners. **(STARTER ONLY)** - [Enable/disable Auto DevOps](../topics/autodevops/index.md#enablingdisabling-auto-devops): Enable or disable Auto DevOps for your instance. ## Snippet settings diff --git a/doc/administration/instance_limits.md b/doc/administration/instance_limits.md index 8e2bbd22a8b..abd98002934 100644 --- a/doc/administration/instance_limits.md +++ b/doc/administration/instance_limits.md @@ -319,7 +319,7 @@ Plan.default.actual_limits.update!(ci_instance_level_variables: 30) > [Introduced](https://gitlab.com/gitlab-org/gitlab/-/merge_requests/37226) in GitLab 13.3. Job artifacts defined with [`artifacts:reports`](../ci/pipelines/job_artifacts.md#artifactsreports) -that are uploaded by the Runner are rejected if the file size exceeds the maximum +that are uploaded by the runner are rejected if the file size exceeds the maximum file size limit. The limit is determined by comparing the project's [maximum artifact size setting](../user/admin_area/settings/continuous_integration.md#maximum-artifacts-size) with the instance limit for the given artifact type, and choosing the smaller value. diff --git a/doc/administration/job_logs.md b/doc/administration/job_logs.md index 4cc664416ca..c34035e3c0c 100644 --- a/doc/administration/job_logs.md +++ b/doc/administration/job_logs.md @@ -9,7 +9,7 @@ type: reference > [Renamed from job traces to job logs](https://gitlab.com/gitlab-org/gitlab/-/issues/29121) in GitLab 12.5. -Job logs are sent by GitLab Runner while it's processing a job. You can see +Job logs are sent by a runner while it's processing a job. You can see logs in job pages, pipelines, email notifications, etc. ## Data flow @@ -19,8 +19,8 @@ In the following table you can see the phases a log goes through: | Phase | State | Condition | Data flow | Stored path | | -------------- | ------------ | ----------------------- | -----------------------------------------| ----------- | -| 1: patching | log | When a job is running | GitLab Runner => Puma => file storage | `#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log` | -| 2: overwriting | log | When a job is finished | GitLab Runner => Puma => file storage | `#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log` | +| 1: patching | log | When a job is running | Runner => Puma => file storage | `#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log` | +| 2: overwriting | log | When a job is finished | Runner => Puma => file storage | `#{ROOT_PATH}/gitlab-ci/builds/#{YYYY_mm}/#{project_id}/#{job_id}.log` | | 3: archiving | archived log | After a job is finished | Sidekiq moves log to artifacts folder | `#{ROOT_PATH}/gitlab-rails/shared/artifacts/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log` | | 4: uploading | archived log | After a log is archived | Sidekiq moves archived log to [object storage](#uploading-logs-to-object-storage) (if configured) | `#{bucket_name}/#{disk_hash}/#{YYYY_mm_dd}/#{job_id}/#{job_artifact_id}/job.log` | @@ -102,8 +102,8 @@ The data are stored in the following Redis namespace: `Gitlab::Redis::SharedStat Here is the detailed data flow: -1. GitLab Runner picks a job from GitLab -1. GitLab Runner sends a piece of log to GitLab +1. The runner picks a job from GitLab +1. The runner sends a piece of log to GitLab 1. GitLab appends the data to Redis 1. Once the data in Redis reach 128KB, the data is flushed to a persistent store (object storage or the database). 1. The above steps are repeated until the job is finished. @@ -160,7 +160,7 @@ In some cases, having data stored on Redis could incur data loss: 1. **Case 1: When all data in Redis are accidentally flushed** - On going incremental logs could be recovered by re-sending logs (this is - supported by all versions of the GitLab Runner). + supported by all versions of GitLab Runner). - Finished jobs which have not archived incremental logs will lose the last part (~128KB) of log data. diff --git a/doc/administration/object_storage.md b/doc/administration/object_storage.md index db1c16cb95c..39365ffe404 100644 --- a/doc/administration/object_storage.md +++ b/doc/administration/object_storage.md @@ -512,7 +512,7 @@ supported by consolidated configuration form, refer to the following guides: | [Packages](packages/index.md#using-object-storage) (optional feature) **(PREMIUM ONLY)** | Yes | | [Dependency Proxy](packages/dependency_proxy.md#using-object-storage) (optional feature) **(PREMIUM ONLY)** | Yes | | [Pseudonymizer](pseudonymizer.md#configuration) (optional feature) **(ULTIMATE ONLY)** | No | -| [Autoscale Runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | No | +| [Autoscale runner caching](https://docs.gitlab.com/runner/configuration/autoscale.html#distributed-runners-caching) (optional for improved performance) | No | | [Terraform state files](terraform_state.md#using-object-storage) | Yes | ### Other alternatives to filesystem storage diff --git a/doc/administration/packages/container_registry.md b/doc/administration/packages/container_registry.md index c1230a81fb8..74af5c8149b 100644 --- a/doc/administration/packages/container_registry.md +++ b/doc/administration/packages/container_registry.md @@ -992,8 +992,8 @@ thus the error above. While GitLab doesn't support using self-signed certificates with Container Registry out of the box, it is possible to make it work by [instructing the Docker daemon to trust the self-signed certificates](https://docs.docker.com/registry/insecure/#use-self-signed-certificates), -mounting the Docker daemon and setting `privileged = false` in the Runner's -`config.toml`. Setting `privileged = true` takes precedence over the Docker daemon: +mounting the Docker daemon and setting `privileged = false` in the GitLab Runner +`config.toml` file. Setting `privileged = true` takes precedence over the Docker daemon: ```toml [runners.docker] diff --git a/doc/administration/pages/source.md b/doc/administration/pages/source.md index 998cab0dfa3..87217b141a4 100644 --- a/doc/administration/pages/source.md +++ b/doc/administration/pages/source.md @@ -61,7 +61,7 @@ Before proceeding with the Pages configuration, make sure that: Pages artifacts. 1. (Optional) You have a **wildcard certificate** for the Pages domain if you decide to serve Pages (`*.example.io`) under HTTPS. -1. (Optional but recommended) You have configured and enabled the [Shared Runners](../../ci/runners/README.md) +1. (Optional but recommended) You have configured and enabled the [shared runners](../../ci/runners/README.md) so that your users don't have to bring their own. ### DNS configuration diff --git a/doc/administration/server_hooks.md b/doc/administration/server_hooks.md index ab808fc28d8..b0d17e35e4e 100644 --- a/doc/administration/server_hooks.md +++ b/doc/administration/server_hooks.md @@ -158,18 +158,18 @@ them as they can change. ## Transition to Go -> Introduced in GitLab 13.2 using feature flags. +> - Introduced in GitLab 13.2 using feature flags. +> - In GitLab 13.4, `update` Ruby [implementation removed](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2501). +> - In GitLab 13.4, `post-receive` Go implementation [made default](https://gitlab.com/gitlab-org/gitaly/-/merge_requests/2502). The following server hooks have been re-implemented in Go: - `pre-receive`, with the Go implementation used by default. To use the Ruby implementation instead, [disable](feature_flags.md#enable-or-disable-the-feature) the `:gitaly_go_preceive_hook` feature flag. -- `update`, with the Go implementation used by default. To use the Ruby implementation instead, - [disable](feature_flags.md#enable-or-disable-the-feature) the `:gitaly_go_update_hook` feature - flag. -- `post-receive`, however the Ruby implementation is used by default. To use the Go implementation - instead, [enable](feature_flags.md#enable-or-disable-the-feature) the +- `update`, with Go implementation always used. No Ruby implementation is available. +- `post-receive`, with the Go implementation used by default. To use the Ruby implementation + instead, [disable](feature_flags.md#enable-or-disable-the-feature) the `:gitaly_go_postreceive_hook` feature flag. ## Custom error messages diff --git a/doc/administration/troubleshooting/debug.md b/doc/administration/troubleshooting/debug.md index 5daf34c1011..a1b4df9b94e 100644 --- a/doc/administration/troubleshooting/debug.md +++ b/doc/administration/troubleshooting/debug.md @@ -64,10 +64,10 @@ easy to copy and save for future reference, you can run: puts Readline::HISTORY.to_a ``` -## Using the Rails Runner +## Using the Rails runner If you need to run some Ruby code in the context of your GitLab production -environment, you can do so using the [Rails Runner](https://guides.rubyonrails.org/command_line.html#rails-runner). When executing a script file, the script must be accessible by the `git` user. +environment, you can do so using the [Rails runner](https://guides.rubyonrails.org/command_line.html#rails-runner). When executing a script file, the script must be accessible by the `git` user. **For Omnibus installations** diff --git a/doc/development/fe_guide/frontend_faq.md b/doc/development/fe_guide/frontend_faq.md index 71436a7c7fb..0a26fdba934 100644 --- a/doc/development/fe_guide/frontend_faq.md +++ b/doc/development/fe_guide/frontend_faq.md @@ -162,7 +162,7 @@ To return to the normal development mode: 1. Open `gitlab.yaml` located in your `gitlab` installation folder, scroll down to the `webpack` section and change back `dev_server` to `enabled: true`. 1. Run `yarn clean` to remove the production assets and free some space (optional). 1. Start webpack again: `gdk start webpack`. -1. Restart GDK: `gdk-restart rails-web`. +1. Restart GDK: `gdk restart rails-web`. ### 8. Babel polyfills diff --git a/doc/development/telemetry/usage_ping.md b/doc/development/telemetry/usage_ping.md index 04206e1fae0..17cc5cfe609 100644 --- a/doc/development/telemetry/usage_ping.md +++ b/doc/development/telemetry/usage_ping.md @@ -318,7 +318,7 @@ Implemented using Redis methods [PFADD](https://redis.io/commands/pfadd) and [PF Tracking events using the `UsageData` API requires the `usage_data_api` feature flag to be enabled, which is disabled by default. - API requests are protected by checking of a valid CSRF token. + API requests are protected by checking for a valid CSRF token. In order to be able to increment the values the related feature `usage_data` should be enabled. diff --git a/doc/install/aws/index.md b/doc/install/aws/index.md index 797721aca0d..7c18ce66fe4 100644 --- a/doc/install/aws/index.md +++ b/doc/install/aws/index.md @@ -718,10 +718,10 @@ For more information on how to set it up, visit the GitLab also has various [health check endpoints](../../user/admin_area/monitoring/health_check.md) that you can ping and get reports. -## GitLab Runners +## GitLab Runner If you want to take advantage of [GitLab CI/CD](../../ci/README.md), you have to -set up at least one [GitLab Runner](https://docs.gitlab.com/runner/). +set up at least one [runner](https://docs.gitlab.com/runner/). Read more on configuring an [autoscaling GitLab Runner on AWS](https://docs.gitlab.com/runner/configuration/runner_autoscale_aws/). diff --git a/doc/install/installation.md b/doc/install/installation.md index 3e5668be18a..13b6fe5b379 100644 --- a/doc/install/installation.md +++ b/doc/install/installation.md @@ -937,7 +937,7 @@ See the [OmniAuth integration documentation](../integration/omniauth.md). ### Build your projects -GitLab can build your projects. To enable that feature, you need GitLab Runners to do that for you. +GitLab can build your projects. To enable that feature, you need runners to do that for you. See the [GitLab Runner section](https://about.gitlab.com/stages-devops-lifecycle/continuous-integration/#gitlab-runner) to install it. ### Adding your Trusted Proxies diff --git a/doc/operations/metrics/index.md b/doc/operations/metrics/index.md index 0ee1927a512..742e6acef0e 100644 --- a/doc/operations/metrics/index.md +++ b/doc/operations/metrics/index.md @@ -46,7 +46,7 @@ For GitLab-managed Prometheus, you can set up [Auto DevOps](../../topics/autodev to quickly create a deployment: 1. Navigate to your project's **Operations > Kubernetes** page. -1. Ensure that, in addition to Prometheus, you also have Runner and Ingress +1. Ensure that, in addition to Prometheus, you also have GitLab Runner and Ingress installed. 1. After installing Ingress, copy its endpoint. 1. Navigate to your project's **Settings > CI/CD** page. In the diff --git a/doc/policy/maintenance.md b/doc/policy/maintenance.md index 08ab9fdf7b7..d2e556f3c8d 100644 --- a/doc/policy/maintenance.md +++ b/doc/policy/maintenance.md @@ -93,8 +93,8 @@ It's also important to ensure that any background migrations have been fully com before upgrading to a new major version. To see the current size of the `background_migration` queue, [Check for background migrations before upgrading](../update/README.md#checking-for-background-migrations-before-upgrading). -If your GitLab instance has any GitLab Runners associated with it, it is very -important to upgrade the GitLab Runners to match the GitLab minor version that was +If your GitLab instance has any runners associated with it, it is very +important to upgrade GitLab Runner to match the GitLab minor version that was upgraded to. This is to ensure [compatibility with GitLab versions](https://docs.gitlab.com/runner/#compatibility-with-gitlab-versions). ### Version 12 onward: Extra step for major upgrades diff --git a/doc/raketasks/backup_restore.md b/doc/raketasks/backup_restore.md index e0e613f4c9a..68b076258ce 100644 --- a/doc/raketasks/backup_restore.md +++ b/doc/raketasks/backup_restore.md @@ -781,7 +781,7 @@ from source). This file contains the database encryption key, [CI/CD variables](../ci/variables/README.md#gitlab-cicd-environment-variables), and variables used for [two-factor authentication](../user/profile/account/two_factor_authentication.md). If you fail to restore this encryption key file along with the application data -backup, users with two-factor authentication enabled and GitLab Runners will +backup, users with two-factor authentication enabled and GitLab Runner will lose access to your GitLab server. You may also want to restore any TLS keys, certificates, or [SSH host keys](https://superuser.com/questions/532040/copy-ssh-keys-from-one-server-to-another-server/532079#532079). @@ -1061,14 +1061,14 @@ including (but not restricted to): - [Project mirroring](../user/project/repository/repository_mirroring.md) - [Web hooks](../user/project/integrations/webhooks.md) -In cases like CI/CD variables and Runner authentication, you might +In cases like CI/CD variables and runner authentication, you might experience some unexpected behavior such as: - Stuck jobs. - 500 errors. In this case, you are required to reset all the tokens for CI/CD variables -and Runner Authentication, which is described in more detail below. After +and runner authentication, which is described in more detail below. After resetting the tokens, you should be able to visit your project and the jobs will have started running again. Use the information in the following sections at your own risk. @@ -1125,7 +1125,7 @@ and then users will have to reactivate 2FA from scratch. 1. You may need to reconfigure or restart GitLab for the changes to take effect. -#### Reset Runner registration tokens +#### Reset runner registration tokens 1. Enter the DB console: diff --git a/doc/user/admin_area/settings/sign_up_restrictions.md b/doc/user/admin_area/settings/sign_up_restrictions.md index 99fc82f94ed..80092102091 100644 --- a/doc/user/admin_area/settings/sign_up_restrictions.md +++ b/doc/user/admin_area/settings/sign_up_restrictions.md @@ -6,14 +6,12 @@ type: reference You can use sign-up restrictions to: -- Disable new signups. +- Disable new sign-ups. - Require user email confirmation. - Denylist or allowlist email addresses belonging to specific domains. NOTE: **Note:** -These restrictions are only applied during sign-up from an external user. An admin is -able to add a user through the admin panel with a disallowed domain. Also -note that the users can change their email addresses after signup to +These restrictions are only applied during sign-up from an external user. An admin can add a user through the admin panel with a disallowed domain. Also, note that the users can change their email addresses after sign-up to disallowed domains. ## Disable new signups @@ -26,8 +24,8 @@ You can restrict new users from signing up by themselves for an account in your ### Recommendations -For customers running public facing GitLab instances, we highly recommend that you -consider disabling new signups if you do not expect public users to sign up for an +For customers running public-facing GitLab instances, we highly recommend that you +consider disabling new sign-ups if you do not expect public users to sign up for an account. Alternatively, you could also consider setting up a @@ -52,7 +50,7 @@ the minimum number of characters a user must have in their password using the Gi > [Introduced](https://gitlab.com/gitlab-org/gitlab-foss/-/merge_requests/598) in GitLab 7.11.0 -You can restrict users to only sign up using email addresses matching the given +You can restrict users only to sign up using email addresses matching the given domains list. ## Denylist email domains diff --git a/doc/user/project/repository/web_editor.md b/doc/user/project/repository/web_editor.md index 452955b327c..af0daaaeca2 100644 --- a/doc/user/project/repository/web_editor.md +++ b/doc/user/project/repository/web_editor.md @@ -8,8 +8,8 @@ type: howto # GitLab Web Editor Sometimes it's easier to make quick changes directly from the GitLab interface -than to clone the project and use the Git command line tool. In this feature -highlight we look at how you can create a new file, directory, branch or +than to clone the project and use the Git command-line tool. In this feature +highlight, we look at how you can create a new file, directory, branch, or tag from the file browser. All of these actions are available from a single dropdown menu. @@ -17,13 +17,12 @@ dropdown menu. From a project's files page, click the '+' button to the right of the branch selector. Choose **New file** from the dropdown. - ![New file dropdown menu](img/web_editor_new_file_dropdown.png) -Enter a file name in the **File name** box. Then, add file content in the editor +Enter a file name in the **Filename** box. Then, add file content in the editor area. Add a descriptive commit message and choose a branch. The branch field will default to the branch you were viewing in the file browser. If you enter -a new branch name, a checkbox will appear allowing you to start a new merge +a new branch name, a checkbox will appear, allowing you to start a new merge request after you commit the changes. When you are satisfied with your new file, click **Commit Changes** at the bottom. @@ -32,14 +31,14 @@ When you are satisfied with your new file, click **Commit Changes** at the botto ### Template dropdowns -When starting a new project, there are some common files which the new project +When starting a new project, there are some common files that the new project might need too. Therefore a message will be displayed by GitLab to make this easy for you. ![First file for your project](img/web_editor_template_dropdown_first_file.png) -When clicking on either `LICENSE` or `.gitignore`, etc., a dropdown will be displayed -to provide you with a template which might be suitable for your project. +When clicking on either `LICENSE` or `.gitignore` and so on, a dropdown will be displayed +to provide you with a template that might be suitable for your project. ![MIT license selected](img/web_editor_template_dropdown_mit_license.png) @@ -56,16 +55,16 @@ least add a file in order for the button to show up. ## Upload a file The ability to create a file is great when the content is text. However, this -doesn't work well for binary data such as images, PDFs or other file types. In -this case you need to upload a file. +doesn't work well for binary data such as images, PDFs, or other file types. In +this case, you need to upload a file. From a project's files page, click the '+' button to the right of the branch selector. Choose **Upload file** from the dropdown. ![Upload file dropdown menu](img/web_editor_upload_file_dropdown.png) -Once the upload dialog pops up there are two ways to upload your file. Either -drag and drop a file on the pop up or use the **click to upload** link. A file +Once the upload dialog pops up, there are two ways to upload your file. Either +drag and drop a file on the popup or use the **click to upload** link. A file preview will appear once you have selected a file to upload. Enter a commit message, choose a branch, and click **Upload file** when you are @@ -83,7 +82,7 @@ Choose **New directory** from the dropdown. ![New directory dropdown](img/web_editor_new_directory_dropdown.png) -In the new directory dialog enter a directory name, a commit message and choose +In the new directory dialog, enter a directory name, a commit message, and choose the target branch. Click **Create directory** to finish. ![New directory dialog](img/web_editor_new_directory_dialog.png) @@ -108,7 +107,7 @@ name or a referenced merge request or your project has an active fork relationship. If you would like to make this button appear, a possible workaround is to [remove your project's fork relationship](../settings/index.md#removing-a-fork-relationship). Once removed, the fork -relationship cannot be restored and you will no longer be able to send merge requests to the source. +relationship cannot be restored, and you will no longer be able to send merge requests to the source. ![Create Button](img/web_editor_new_branch_from_issue_create_button_v12_6.png) @@ -117,9 +116,9 @@ This dropdown contains the options **Create merge request and branch** and **Cre ![New Branch Button](img/web_editor_new_branch_from_issue_v_12_6.png) Once you choose one of these options, a new branch or branch and merge request -will be created, based on the default -branch of your project, by default `master`. The branch name will be based on -the title of the issue and as a prefix, it will have its internal ID. Thus, the example +will be created based on the default +branch of your project (by default, `master`). The branch name will be based on +the title of the issue, and as a prefix, it will have its internal ID. Thus, the example screenshot above will create a branch named `2-make-static-site-auto-deploy-and-serve`. @@ -141,13 +140,13 @@ merge request is merged. ### Create a new branch from a project's dashboard If you want to make changes to several files before creating a new merge -request, you can create a new branch up front. From a project's files page, +request, you can create a new branch upfront. From a project's files page, choose **New branch** from the dropdown. ![New branch dropdown](img/web_editor_new_branch_dropdown.png) Enter a new **Branch name**. Optionally, change the **Create from** field -to choose which branch, tag or commit SHA this new branch will originate from. +to choose which branch, tag, or commit SHA this new branch will originate from. This field will autocomplete if you start typing an existing branch or tag. Click **Create branch** and you will be returned to the file browser on this new branch. @@ -155,7 +154,7 @@ branch. ![New branch page](img/web_editor_new_branch_page.png) You can now make changes to any files, as needed. When you're ready to merge -the changes back to master you can use the widget at the top of the screen. +the changes back to master, you can use the widget at the top of the screen. This widget only appears for a period of time after you create the branch or modify files. @@ -172,15 +171,15 @@ SHA. From a project's files page, choose **New tag** from the dropdown. Give the tag a name such as `v1.0.0`. Choose the branch or SHA from which you would like to create this new tag. You can optionally add a message and release notes. The release notes section supports Markdown format and you can -also upload an attachment. Click **Create tag** and you will be taken to the tag +also upload an attachment. Click **Create tag**, and you will be taken to the tag list page. ![New tag page](img/web_editor_new_tag_page.png) ## Tips -When creating or uploading a new file, or creating a new directory, you can -trigger a new merge request rather than committing directly to master. Enter +When creating or uploading a new file or creating a new directory, you can +trigger a new merge request rather than committing directly to `master`. Enter a new branch name in the **Target branch** field. You will notice a checkbox appear that is labeled **Start a new merge request with these changes**. After you commit the changes you will be taken to a new merge request form. diff --git a/lib/gitlab/kubernetes/cilium_network_policy.rb b/lib/gitlab/kubernetes/cilium_network_policy.rb index e5d7a88533c..9043932bbe5 100644 --- a/lib/gitlab/kubernetes/cilium_network_policy.rb +++ b/lib/gitlab/kubernetes/cilium_network_policy.rb @@ -9,8 +9,12 @@ module Gitlab API_VERSION = "cilium.io/v2" KIND = 'CiliumNetworkPolicy' - def initialize(name:, namespace:, selector:, ingress:, resource_version: nil, labels: nil, creation_timestamp: nil, egress: nil) + # We are modeling existing kubernetes resource and don't have + # control over amount of parameters. + # rubocop:disable Metrics/ParameterLists + def initialize(name:, namespace:, selector:, ingress:, resource_version: nil, description: nil, labels: nil, creation_timestamp: nil, egress: nil) @name = name + @description = description @namespace = namespace @labels = labels @creation_timestamp = creation_timestamp @@ -19,15 +23,7 @@ module Gitlab @ingress = ingress @egress = egress end - - def generate - ::Kubeclient::Resource.new.tap do |resource| - resource.kind = KIND - resource.apiVersion = API_VERSION - resource.metadata = metadata - resource.spec = spec - end - end + # rubocop:enable Metrics/ParameterLists def self.from_yaml(manifest) return unless manifest @@ -39,6 +35,7 @@ module Gitlab spec = policy[:spec] self.new( name: metadata[:name], + description: policy[:description], namespace: metadata[:namespace], resource_version: metadata[:resourceVersion], labels: metadata[:labels], @@ -58,6 +55,7 @@ module Gitlab spec = resource[:spec].to_h self.new( name: metadata[:name], + description: resource[:description], namespace: metadata[:namespace], resource_version: metadata[:resourceVersion], labels: metadata[:labels]&.to_h, @@ -68,26 +66,39 @@ module Gitlab ) end + override :resource + def resource + resource = { + apiVersion: API_VERSION, + kind: KIND, + metadata: metadata, + spec: spec + } + resource[:description] = description if description + resource + end + private - attr_reader :name, :namespace, :labels, :creation_timestamp, :resource_version, :ingress, :egress + attr_reader :name, :description, :namespace, :labels, :creation_timestamp, :resource_version, :ingress, :egress def selector @selector ||= {} end - override :spec + def metadata + meta = { name: name, namespace: namespace } + meta[:labels] = labels if labels + meta[:resourceVersion] = resource_version if resource_version + meta + end + def spec { endpointSelector: selector, ingress: ingress, egress: egress - }.compact! - end - - override :kind - def kind - KIND + }.compact end end end diff --git a/lib/gitlab/kubernetes/network_policy.rb b/lib/gitlab/kubernetes/network_policy.rb index 65817f2a4ba..c8e9b987443 100644 --- a/lib/gitlab/kubernetes/network_policy.rb +++ b/lib/gitlab/kubernetes/network_policy.rb @@ -19,13 +19,6 @@ module Gitlab @egress = egress end - def generate - ::Kubeclient::Resource.new.tap do |resource| - resource.metadata = metadata - resource.spec = spec - end - end - def self.from_yaml(manifest) return unless manifest @@ -65,6 +58,15 @@ module Gitlab ) end + override :resource + def resource + { + kind: KIND, + metadata: metadata, + spec: spec + } + end + private attr_reader :name, :namespace, :labels, :creation_timestamp, :policy_types, :ingress, :egress @@ -73,7 +75,12 @@ module Gitlab @selector ||= {} end - override :spec + def metadata + meta = { name: name, namespace: namespace } + meta[:labels] = labels if labels + meta + end + def spec { podSelector: selector, @@ -82,11 +89,6 @@ module Gitlab egress: egress } end - - override :kind - def kind - KIND - end end end end diff --git a/lib/gitlab/kubernetes/network_policy_common.rb b/lib/gitlab/kubernetes/network_policy_common.rb index 9340e140240..99517454508 100644 --- a/lib/gitlab/kubernetes/network_policy_common.rb +++ b/lib/gitlab/kubernetes/network_policy_common.rb @@ -5,6 +5,10 @@ module Gitlab module NetworkPolicyCommon DISABLED_BY_LABEL = :'network-policy.gitlab.com/disabled_by' + def generate + ::Kubeclient::Resource.new(resource) + end + def as_json(opts = nil) { name: name, @@ -46,23 +50,12 @@ module Gitlab private - def metadata - meta = { name: name, namespace: namespace } - meta[:labels] = labels if labels - meta[:resourceVersion] = resource_version if defined?(resource_version) - meta - end - - def spec - raise NotImplementedError - end - - def kind + def resource raise NotImplementedError end def manifest - YAML.dump({ kind: kind, metadata: metadata, spec: spec }.deep_stringify_keys) + YAML.dump(resource.deep_stringify_keys) end end end diff --git a/spec/lib/gitlab/kubernetes/cilium_network_policy_spec.rb b/spec/lib/gitlab/kubernetes/cilium_network_policy_spec.rb index 877ca28e994..3f5661d4ca6 100644 --- a/spec/lib/gitlab/kubernetes/cilium_network_policy_spec.rb +++ b/spec/lib/gitlab/kubernetes/cilium_network_policy_spec.rb @@ -7,23 +7,27 @@ RSpec.describe Gitlab::Kubernetes::CiliumNetworkPolicy do described_class.new( name: name, namespace: namespace, - creation_timestamp: '2020-04-14T00:08:30Z', - endpoint_selector: endpoint_selector, + description: description, + selector: selector, ingress: ingress, egress: egress, - description: description + labels: labels, + resource_version: resource_version ) end let(:resource) do ::Kubeclient::Resource.new( - kind: partial_class_name, - apiVersion: "cilium.io/v2", + apiVersion: Gitlab::Kubernetes::CiliumNetworkPolicy::API_VERSION, + kind: Gitlab::Kubernetes::CiliumNetworkPolicy::KIND, metadata: { name: name, namespace: namespace, resourceVersion: resource_version }, - spec: { endpointSelector: endpoint_selector, ingress: ingress } + spec: { endpointSelector: endpoint_selector, ingress: ingress, egress: egress }, + description: description ) end + let(:selector) { endpoint_selector } + let(:labels) { nil } let(:name) { 'example-name' } let(:namespace) { 'example-namespace' } let(:endpoint_selector) { { matchLabels: { role: 'db' } } } @@ -48,34 +52,14 @@ RSpec.describe Gitlab::Kubernetes::CiliumNetworkPolicy do ] end - include_examples 'network policy common specs' do - let(:selector) { endpoint_selector} - let(:policy) do - described_class.new( - name: name, - namespace: namespace, - selector: selector, - ingress: ingress, - labels: labels, - resource_version: resource_version - ) - end - - let(:spec) { { endpointSelector: selector, ingress: ingress } } - let(:metadata) { { name: name, namespace: namespace, resourceVersion: resource_version } } - end - - describe '#generate' do - subject { policy.generate } - - it { is_expected.to eq(resource) } - end + include_examples 'network policy common specs' describe '.from_yaml' do let(:manifest) do <<~POLICY apiVersion: cilium.io/v2 kind: CiliumNetworkPolicy + description: example-description metadata: name: example-name namespace: example-namespace @@ -88,6 +72,9 @@ RSpec.describe Gitlab::Kubernetes::CiliumNetworkPolicy do - fromEndpoints: - matchLabels: project: myproject + egress: + - ports: + - port: 5978 POLICY end @@ -167,18 +154,20 @@ RSpec.describe Gitlab::Kubernetes::CiliumNetworkPolicy do describe '.from_resource' do let(:resource) do ::Kubeclient::Resource.new( + description: description, metadata: { name: name, namespace: namespace, creationTimestamp: '2020-04-14T00:08:30Z', labels: { app: 'foo' }, resourceVersion: resource_version }, - spec: { endpointSelector: endpoint_selector, ingress: ingress, egress: nil, labels: nil, description: nil } + spec: { endpointSelector: endpoint_selector, ingress: ingress, egress: nil, labels: nil } ) end let(:generated_resource) do ::Kubeclient::Resource.new( - kind: partial_class_name, - apiVersion: "cilium.io/v2", + apiVersion: Gitlab::Kubernetes::CiliumNetworkPolicy::API_VERSION, + kind: Gitlab::Kubernetes::CiliumNetworkPolicy::KIND, + description: description, metadata: { name: name, namespace: namespace, resourceVersion: resource_version, labels: { app: 'foo' } }, spec: { endpointSelector: endpoint_selector, ingress: ingress } ) @@ -197,7 +186,7 @@ RSpec.describe Gitlab::Kubernetes::CiliumNetworkPolicy do context 'with resource without metadata' do let(:resource) do ::Kubeclient::Resource.new( - spec: { endpointSelector: endpoint_selector, ingress: ingress, egress: nil, labels: nil, description: nil } + spec: { endpointSelector: endpoint_selector, ingress: ingress, egress: nil, labels: nil } ) end @@ -214,4 +203,50 @@ RSpec.describe Gitlab::Kubernetes::CiliumNetworkPolicy do it { is_expected.to be_nil } end end + + describe '#resource' do + subject { policy.resource } + + let(:resource) do + { + apiVersion: Gitlab::Kubernetes::CiliumNetworkPolicy::API_VERSION, + kind: Gitlab::Kubernetes::CiliumNetworkPolicy::KIND, + metadata: { name: name, namespace: namespace, resourceVersion: resource_version }, + spec: { endpointSelector: endpoint_selector, ingress: ingress, egress: egress }, + description: description + } + end + + it { is_expected.to eq(resource) } + + context 'with labels' do + let(:labels) { { app: 'foo' } } + + before do + resource[:metadata][:labels] = { app: 'foo' } + end + + it { is_expected.to eq(resource) } + end + + context 'without resource_version' do + let(:resource_version) { nil } + + before do + resource[:metadata].delete(:resourceVersion) + end + + it { is_expected.to eq(resource) } + end + + context 'with nil egress' do + let(:egress) { nil } + + before do + resource[:spec].delete(:egress) + end + + it { is_expected.to eq(resource) } + end + end end diff --git a/spec/lib/gitlab/kubernetes/network_policy_spec.rb b/spec/lib/gitlab/kubernetes/network_policy_spec.rb index 5d1dd5dec59..d3640c61d94 100644 --- a/spec/lib/gitlab/kubernetes/network_policy_spec.rb +++ b/spec/lib/gitlab/kubernetes/network_policy_spec.rb @@ -7,21 +7,22 @@ RSpec.describe Gitlab::Kubernetes::NetworkPolicy do described_class.new( name: name, namespace: namespace, - creation_timestamp: '2020-04-14T00:08:30Z', - selector: pod_selector, - policy_types: %w(Ingress Egress), + selector: selector, ingress: ingress, - egress: egress + labels: labels ) end let(:resource) do ::Kubeclient::Resource.new( + kind: Gitlab::Kubernetes::NetworkPolicy::KIND, metadata: { name: name, namespace: namespace }, spec: { podSelector: pod_selector, policyTypes: %w(Ingress), ingress: ingress, egress: nil } ) end + let(:selector) { pod_selector } + let(:labels) { nil } let(:name) { 'example-name' } let(:namespace) { 'example-namespace' } let(:pod_selector) { { matchLabels: { role: 'db' } } } @@ -44,27 +45,7 @@ RSpec.describe Gitlab::Kubernetes::NetworkPolicy do ] end - include_examples 'network policy common specs' do - let(:selector) { pod_selector } - let(:policy) do - described_class.new( - name: name, - namespace: namespace, - selector: selector, - ingress: ingress, - labels: labels - ) - end - - let(:spec) { { podSelector: selector, policyTypes: ["Ingress"], ingress: ingress, egress: nil } } - let(:metadata) { { name: name, namespace: namespace } } - end - - describe '#generate' do - subject { policy.generate } - - it { is_expected.to eq(resource) } - end + include_examples 'network policy common specs' describe '.from_yaml' do let(:manifest) do @@ -180,6 +161,7 @@ RSpec.describe Gitlab::Kubernetes::NetworkPolicy do let(:generated_resource) do ::Kubeclient::Resource.new( + kind: Gitlab::Kubernetes::NetworkPolicy::KIND, metadata: { name: name, namespace: namespace, labels: { app: 'foo' } }, spec: { podSelector: pod_selector, policyTypes: %w(Ingress), ingress: ingress, egress: nil } ) @@ -215,4 +197,31 @@ RSpec.describe Gitlab::Kubernetes::NetworkPolicy do it { is_expected.to be_nil } end end + + describe '#resource' do + subject { policy.resource } + + let(:resource) do + { + kind: Gitlab::Kubernetes::NetworkPolicy::KIND, + metadata: { name: name, namespace: namespace }, + spec: { podSelector: pod_selector, policyTypes: %w(Ingress), ingress: ingress, egress: nil } + } + end + + it { is_expected.to eq(resource) } + + context 'with labels' do + let(:labels) { { app: 'foo' } } + let(:resource) do + { + kind: Gitlab::Kubernetes::NetworkPolicy::KIND, + metadata: { name: name, namespace: namespace, labels: { app: 'foo' } }, + spec: { podSelector: pod_selector, policyTypes: %w(Ingress), ingress: ingress, egress: nil } + } + end + + it { is_expected.to eq(resource) } + end + end end diff --git a/spec/support/shared_examples/lib/gitlab/kubernetes/network_policy_common_shared_examples.rb b/spec/support/shared_examples/lib/gitlab/kubernetes/network_policy_common_shared_examples.rb index 4fac7119cb8..f018ece0d46 100644 --- a/spec/support/shared_examples/lib/gitlab/kubernetes/network_policy_common_shared_examples.rb +++ b/spec/support/shared_examples/lib/gitlab/kubernetes/network_policy_common_shared_examples.rb @@ -5,19 +5,19 @@ RSpec.shared_examples 'network policy common specs' do let(:namespace) { 'example-namespace' } let(:labels) { nil } + describe '#generate' do + subject { policy.generate } + + it { is_expected.to eq(Kubeclient::Resource.new(policy.resource)) } + end + describe 'as_json' do let(:json_policy) do { name: name, namespace: namespace, creation_timestamp: nil, - manifest: YAML.dump( - { - kind: described_class::KIND, - metadata: metadata, - spec: spec - }.deep_stringify_keys - ), + manifest: YAML.dump(policy.resource.deep_stringify_keys), is_autodevops: false, is_enabled: true }