kotovalexarian-likes-gitlab/gitlab-org--gitlab-foss
1
0
Fork 0
Code Releases Activity

Add latest changes from gitlab-org/gitlab@master

Browse source
This commit is contained in:
GitLab Bot 2020-09-14 00:09:36 +00:00
parent 41bdc6533b
commit 368d885879
26 changed files with 225 additions and 173 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
changelogs/unreleased/cnp-description.yml Normal file
View file

@ -0,0 +1,5 @@
---
title: Improve support for description field on CiliumNetworkPolicy
merge_request: 41722
author:
type: changed

2
doc/administration/environment_variables.md
View file

@ -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

2
doc/administration/geo/replication/index.md
View file

@ -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

4
doc/administration/index.md
View file

@ -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

2
doc/administration/instance_limits.md
View file

@ -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.

12
doc/administration/job_logs.md
View file

@ -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.

2
doc/administration/object_storage.md
View file

@ -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

4
doc/administration/packages/container_registry.md
View file

@ -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]

2
doc/administration/pages/source.md
View file

@ -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

12
doc/administration/server_hooks.md
View file

@ -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

4
doc/administration/troubleshooting/debug.md
View file

@ -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**

2
doc/development/fe_guide/frontend_faq.md
View file

@ -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

2
doc/development/telemetry/usage_ping.md
View file

@ -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<event_name>` should be enabled.

4
doc/install/aws/index.md
View file

@ -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/).

2
doc/install/installation.md
View file

@ -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

2
doc/operations/metrics/index.md
View file

@ -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

4
doc/policy/maintenance.md
View file

@ -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

8
doc/raketasks/backup_restore.md
View file

@ -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:

12
doc/user/admin_area/settings/sign_up_restrictions.md
View file

@ -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

45
doc/user/project/repository/web_editor.md
View file

@ -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.

47
lib/gitlab/kubernetes/cilium_network_policy.rb
View file

@ -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

28
lib/gitlab/kubernetes/network_policy.rb
View file

@ -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

19
lib/gitlab/kubernetes/network_policy_common.rb
View file

@ -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

99
spec/lib/gitlab/kubernetes/cilium_network_policy_spec.rb
View file

@ -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

59
spec/lib/gitlab/kubernetes/network_policy_spec.rb
View file

@ -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

14
spec/support/shared_examples/lib/gitlab/kubernetes/network_policy_common_shared_examples.rb
View file

@ -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
}