gitlab-runner merge requestshttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests2016-11-21T13:28:36Zhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/367Use correct constant for kubernetes ressource limits.2016-11-21T13:28:36Zusername-removed-810624Use correct constant for kubernetes ressource limits.## What does this MR do?
Fixes the Issue #1836. Use correct constants for limit names.
## Why was this MR needed?
Wrong constant for limit names were used.
## Are there points in the code the reviewer needs to double check?...## What does this MR do?
Fixes the Issue #1836. Use correct constants for limit names.
## Why was this MR needed?
Wrong constant for limit names were used.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Fixes #1836v1.8https://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/335Add PullPolicy config option for kubernetes2016-11-21T22:24:44Zusername-removed-357684Add PullPolicy config option for kubernetes## What does this MR do?
Allows the user so specify a image pull policy for build-images used (like with the docker executor).
## Why was this MR needed?
May speed up CI steps when using versioned build images (rather than :latest)
...## What does this MR do?
Allows the user so specify a image pull policy for build-images used (like with the docker executor).
## Why was this MR needed?
May speed up CI steps when using versioned build images (rather than :latest)
## Are there points in the code the reviewer needs to double check?
I'm unsure about the code duplication in `common/config.go`. Maybe it would be better/more clean to map the docker syntax for `pull_policy` to kubernetes values?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.8https://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/422Refactorize tests for Kubernetes node selector feature2016-12-21T20:47:04ZTomasz Maczukintomasz@gitlab.comRefactorize tests for Kubernetes node selector feature## What does this MR do?
Refactorize tests added in !328
## Why was this MR needed?
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/update...## What does this MR do?
Refactorize tests added in !328
## Why was this MR needed?
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.9Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/420Push prebuilt images to dockerhub2016-12-22T11:07:19ZTomasz Maczukintomasz@gitlab.comPush prebuilt images to dockerhub## What does this MR do?
Adds a release step, that pushes gitlab-runner-helper do docker hub. This is a first step to make prebuilt images available for Kubernetes executor.
## Why was this MR needed?
Please read !275 for a refe...## What does this MR do?
Adds a release step, that pushes gitlab-runner-helper do docker hub. This is a first step to make prebuilt images available for Kubernetes executor.
## Why was this MR needed?
Please read !275 for a reference.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Successor of !275v1.9Kamil TrzcińśkiKamil Trzcińśkihttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/426Tag and push 'latest' version of gitlab/gitlab-runner-helper image2016-12-22T11:57:45ZTomasz Maczukintomasz@gitlab.comTag and push 'latest' version of gitlab/gitlab-runner-helper image## What does this MR do?
Adds the `-latest` version of image introduced in !420
## Why was this MR needed?
`-latest` versions of images will be used, for example, as default images for Kubernetes executor if an image marked with revis...## What does this MR do?
Adds the `-latest` version of image introduced in !420
## Why was this MR needed?
`-latest` versions of images will be used, for example, as default images for Kubernetes executor if an image marked with revision will be not found (please read https://gitlab.com/gitlab-org/gitlab-ci-multi-runner/merge_requests/425#note_20382762 for a reference)
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.9Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/328Kubernete Node Selector2016-12-22T15:51:56Zusername-removed-256401luke@mallon.ioKubernete Node Selector## What does this MR do?
Allow users to limit runners to running on Kubernetes nodes with a set of specific labels
## Why was this MR needed?
I required the ability to do this
## Does this MR meet the acceptance criteria?
- [x] Docume...## What does this MR do?
Allow users to limit runners to running on Kubernetes nodes with a set of specific labels
## Why was this MR needed?
I required the ability to do this
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [x] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)v1.9https://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/425Kubernetes pre-build container2017-01-17T08:39:03Zusername-removed-182855Kubernetes pre-build containerThis MR builds on top of !338 after !420 has been merged.
Currently the default image is hardcoded to be x86_64, but can be overridden through runner config if running on ARM. We should later add some form of detection to this, or more ...This MR builds on top of !338 after !420 has been merged.
Currently the default image is hardcoded to be x86_64, but can be overridden through runner config if running on ARM. We should later add some form of detection to this, or more likely, a runner config parameter specifying architecture. It won't be possible to detect the architecture of the node before hand as the build pod won't be scheduled until after the Pod type is created (a chicken-egg situation).
Hopeful this can be merged in for the 1.9 release today, but might be a *bit* late!
@jayme-github @tmaczukin @ayufan @nick.thomas
## What does this MR do?
## Why was this MR needed?
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.9https://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/384Add poll interval and timeout parameters for Kubernetes runner2017-01-17T08:39:03Zusername-removed-838134Add poll interval and timeout parameters for Kubernetes runner## What does this MR do?
This MR adds two new parameters that can be specified in the `[runners.kubernetes]` configuration:
* `poll_interval`: How frequently, in seconds, the runner will poll the Kubernetes cluster to check on the sta...## What does this MR do?
This MR adds two new parameters that can be specified in the `[runners.kubernetes]` configuration:
* `poll_interval`: How frequently, in seconds, the runner will poll the Kubernetes cluster to check on the status of the container it has attempted to create. [Default: 3]
* `poll_timeout`: The amount of time, in seconds, that needs to pass before the runner will timeout attempting to connect to the container it has just tried to create. [Default: 180]
## Why was this MR needed?
These parameters help with the use case whereby you have a Kubernetes cluster that has potential for high workload, and there isn't enough resources to run every task as soon as they come in (i.e. the Kubernetes scheduler could be reporting that that pod hasn't started because there isn't enough resources to run the container). Currently, there are some magic constants that define that the runner will poll Kubernetes every 3 seconds, at most 60 times, before timing out, but it allows for more functionality if these values can be configured.
This is not the perfect solution for this situation; ideally GitLab CI would be able to talk to the Kubernetes scheduler when it was about to run a Kubernetes task, and hold off on actually scheduling the task if it knew there wasn't resources currently available. However, this seems like a much more complex undertaking, and may go against the GitLab CI flow quite a bit (but if people think this is possible in future, I can open an issue for it).
In the meantime, the addition of these parameters should help those in use cases like myself where there's a potential for backlog due to full resources, and don't want the tasks timing out too early.
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)v1.10Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/383Kubernetes termination grace period2017-01-17T08:39:03Zusername-removed-357684Kubernetes termination grace period## What does this MR do?
Add a configuration option for the termination grace period of build pods.
## Why was this MR needed?
When a build is finished (e.g. Pod is deleted) Kubernetes will send SIGTERM to applications in the containers...## What does this MR do?
Add a configuration option for the termination grace period of build pods.
## Why was this MR needed?
When a build is finished (e.g. Pod is deleted) Kubernetes will send SIGTERM to applications in the containers of the Pod, which can be handled in order to effect graceful termination. SIGKILL is sent a configurable number of seconds later if the application does not terminate sooner (defaults to 30 seconds, controlled by `spec.terminationGracePeriodSeconds`).
Lots of fast, parallel builds will leave Pods of finished builds behind for 30 seconds, blocking cluster resources. With a lower (or even `0`) `terminationGracePeriodSeconds`, Pods of finished builds will be cleaned up immediately.
## Are there points in the code the reviewer needs to double check?
@munnerz could you give me a hint on how to integrate that into the existing tests?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.10https://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/449Pass ImagePullSecrets2017-01-21T20:43:04ZKamil TrzcińśkiPass ImagePullSecrets> This is a general Merge Request template. Consider to choose a template
> from the list above if it will match your case more.
## What does this MR do?
It adds support for `ImagePullSecrets` which allows to use private docker registri...> This is a general Merge Request template. Consider to choose a template
> from the list above if it will match your case more.
## What does this MR do?
It adds support for `ImagePullSecrets` which allows to use private docker registries.
Refer to this documentation: https://kubernetes.io/docs/user-guide/images/
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.10Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/444Kubernetes Namespace Overwrite2017-01-22T00:07:27ZTomasz Maczukintomasz@gitlab.comKubernetes Namespace Overwrite## What does this MR do?
Successor of !389.
This MR gives more flexibility for CI pipelines based on Kubernetes Runner. It adds a environment variable to overwrite the target Kubernetes namespace. Therefore, you can for instance, use H...## What does this MR do?
Successor of !389.
This MR gives more flexibility for CI pipelines based on Kubernetes Runner. It adds a environment variable to overwrite the target Kubernetes namespace. Therefore, you can for instance, use Helm/Landscaper to install Charts and create the set of services/pods that are required to execute the CI pipeline step, and also the ability to clean-up by deleting an namespace completely.
The namespace can only be overwritten if matches a configured regular expression (added to the runner configuration), to guarantee only designed namespace names can be employed. When this configuration is empty, this whole overwrite behavior is disabled.
## Why was this MR needed?
To create more flexible CI runs, to include `Helm` packages in a brand new namespace which will be deleted altogether afterwards. Using an overwrite mechanism avoid an extra steps to achieve the same goal.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.10Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/477Fix offense reported by vet. Add vet to 'code style` job.2017-03-11T13:39:59ZTomasz Maczukintomasz@gitlab.comFix offense reported by vet. Add vet to 'code style` job.## What does this MR do?
Fixes an offense reported by `vet` in `executors/kubernetes/executor_kubertnetes_test.go`.
## Why was this MR needed?
## Are there points in the code the reviewer needs to double check?
## Does this MR meet t...## What does this MR do?
Fixes an offense reported by `vet` in `executors/kubernetes/executor_kubertnetes_test.go`.
## Why was this MR needed?
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v1.11Kamil TrzcińśkiKamil Trzcińśkihttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/391Add configuration options for kubernetss resource requests2017-03-20T14:20:30Zusername-removed-357684Add configuration options for kubernetss resource requests## What does this MR do?
Adds configuration options for container resource requirements (http://kubernetes.io/docs/user-guide/compute-resources/) similar to how resource limits are implemented.
## Why was this MR needed?
Setting res...## What does this MR do?
Adds configuration options for container resource requirements (http://kubernetes.io/docs/user-guide/compute-resources/) similar to how resource limits are implemented.
## Why was this MR needed?
Setting resource limits will throttle builds, even if the node running the build pod has free resources.
With resource requests one can tell the kubernetes scheduler the minimum requirements for a container/pod without actually limiting it's resource consumption (i.e. faster builds when node/cluster is idle).
## Are there points in the code the reviewer needs to double check?
I've prefixed the currently used options for limits (`cpus`, `memory`) with "limits_" to help distinguish limits and requests. This is a breaking change so maybe a more clever solution is needed.
I'm happy to update docs when we're sure about the option names.
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Closes #2019 v1.10Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/521Remove deprecated kubernetes executor configuration fields2017-03-22T15:48:23ZTomasz Maczukintomasz@gitlab.comRemove deprecated kubernetes executor configuration fields## What does this MR do?
Follows up !391 and removes deprecated configuration fields for Kubernetes executor.
## Why was this MR needed?
With !391 we've added a way to configure both limits and resources for containers. We've al...## What does this MR do?
Follows up !391 and removes deprecated configuration fields for Kubernetes executor.
## Why was this MR needed?
With !391 we've added a way to configure both limits and resources for containers. We've also changed names of configuration fields leaving a fallback mechanism for old names and a deprecation note.
In %v9.0 we're cleaning this up removing previously deprecated fields and the fallback mechanism.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Closes #2032v9.0Kamil TrzcińśkiKamil Trzcińśkihttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/520Kubernetes private credentials2017-04-12T06:05:52ZKamil TrzcińśkiKubernetes private credentialsThis adds an image pull secrets for Docker Registry credentials that are passed with GitLab Runner payload.
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
...This adds an image pull secrets for Docker Registry credentials that are passed with GitLab Runner payload.
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Closes https://gitlab.com/gitlab-org/gitlab-ce/issues/27763v9.0Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/558Add PodLabels field to Kubernetes config structure2017-04-28T15:15:48Zusername-removed-182855Add PodLabels field to Kubernetes config structure> This is a general Merge Request template. Consider to choose a template
> from the list above if it will match your case more.
## What does this MR do?
Adds a PodLabels field to the Kubernetes config structure, so build pods can be s...> This is a general Merge Request template. Consider to choose a template
> from the list above if it will match your case more.
## What does this MR do?
Adds a PodLabels field to the Kubernetes config structure, so build pods can be specifically labelled by the operator
## Why was this MR needed?
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
#2376v9.2https://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/554adding support for kubernetes service account and override on gitlab-ci.yaml2017-05-12T20:55:00Zusername-removed-1261797adding support for kubernetes service account and override on gitlab-ci.yaml## What does this MR do?
Adds support to specify and override the kubernetes system account of the kubernetes executor pod
## Why was this MR needed?
In a cluster with RBAC installed, if the namespace is overwritten via `KUBERNETES_NA...## What does this MR do?
Adds support to specify and override the kubernetes system account of the kubernetes executor pod
## Why was this MR needed?
In a cluster with RBAC installed, if the namespace is overwritten via `KUBERNETES_NAMESPACE_OVERWRITE` the job will fail because the SA of the runner won't be available on the target namespace.
## Are there points in the code the reviewer needs to double check?
No
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [x] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?v9.2Tomasz Maczukintomasz@gitlab.comTomasz Maczukintomasz@gitlab.comhttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/516Kubernetes volumes2017-07-05T15:33:23ZZeger-Jan van de Wegzegerjan@gitlab.comKubernetes volumesContinuing the work of @jon-walton, to support Kubernetes volumes.
## What does this MR do?
This MR adds basic volume support to the Kubernetes runner. Kubernetes volumes work differently to docker such that it's possible to mount ma...Continuing the work of @jon-walton, to support Kubernetes volumes.
## What does this MR do?
This MR adds basic volume support to the Kubernetes runner. Kubernetes volumes work differently to docker such that it's possible to mount many different types of storage into the container. To reflect this and to make it easy to implement other sources into the runner in the future, I've implemented the source and the container mount as separate config items (the structure is very similar to a kubernetes config file).
For now, only `HostPathVolumeSource` is supported
An example config.toml would be:
```toml
concurrent = 2
[[runners]]
name = "Kubernetes Runner"
url = "https://gitlab.com/ci"
token = "TOKEN"
executor = "kubernetes"
[runners.kubernetes]
namespace = "gitlab"
privileged = true
[[runners.kubernetes.mounts]]
name = "docker"
mount_path = "/var/run/docker.sock"
[[runners.kubernetes.volumes.host_paths]]
name = "docker"
path = "/var/run/docker.sock"
[[runners.kubernetes.mounts]]
name = "cache"
mount_path = "/cache/"
[[runners.kubernetes.volumes.host_paths]]
name = "cache"
path = "/tmp/gitlab-ci-cache/"
[runners.cache]
Insecure = false
```
Any `mounts` configured must have a matching `volumes`
## Why was this MR needed?
I have a requirement to bind the docker socket into the build pods because I do not want to use docker:dind. Binding the socket gains me local image caching and no risk of name conflicts because kubernetes appends a random string to each pod's name
## Are there points in the code the reviewer needs to double check?
This is my first look into golang, so please let me know if I've done anything wrong. If the general direction is sound, I will go ahead and add documentation.
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [x] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Closes #1876, #1759, !3319.3Kamil TrzcińśkiKamil Trzcińśkihttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/596Support for extended docker configuration in gitlab-ci.yml2017-09-27T17:22:39ZTomasz Maczukintomasz@gitlab.comSupport for extended docker configuration in gitlab-ci.yml## What does this MR do?
Adds support for some Docker configuration options set with `.gitlab-ci.yml` file. Needs gitlab-org/gitlab-ce!8578 to work, because `.gitlab-ci.yml` is parsed in GitLab CE/EE and then job configuration is send...## What does this MR do?
Adds support for some Docker configuration options set with `.gitlab-ci.yml` file. Needs gitlab-org/gitlab-ce!8578 to work, because `.gitlab-ci.yml` is parsed in GitLab CE/EE and then job configuration is send to Runner. This MR adds support for new configuration options available in job's payload.
## Why was this MR needed?
Please look into: #1466, #1421, #1284 for reference.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [ ] Documentation created/updated
- Tests
- [ ] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Closes #1466, #1421, #12849.4Kamil TrzcińśkiKamil Trzcińśkihttps://staging.gitlab.com/gitlab-org/gitlab-runner/-/merge_requests/625Improve kubernetes volumes support2017-10-06T11:00:31ZTomasz Maczukintomasz@gitlab.comImprove kubernetes volumes support## What does this MR do?
Adds some improvements to recently added Kubernetes Volumes support.
## Why was this MR needed?
With !516 (released with v9.3.0) and !606 (planned for v9.4.0) we've added support for volumes configuration for ...## What does this MR do?
Adds some improvements to recently added Kubernetes Volumes support.
## Why was this MR needed?
With !516 (released with v9.3.0) and !606 (planned for v9.4.0) we've added support for volumes configuration for Kubernetes executor. This MR adds some improvements:
- selecting keys from _configMap_ that should be added with a volume,
- selecting keys from _secret_ that should be added with a volume,
- configuring a host path - different from `mount_path` - that should be mounted inside of container (in current implementation `hostPath` needed to be the same path that was used inside of container, so it was impossible to mount host's `/path/one` as container's `/path/two`).
This MR improves also documentation related to Kubernetes volumes support.
## Are there points in the code the reviewer needs to double check?
## Does this MR meet the acceptance criteria?
- [x] Documentation created/updated
- Tests
- [x] Added for this feature/bug
- [ ] All builds are passing
- [ ] Branch has no merge conflicts with `master` (if you do - rebase it please)
## What are the relevant issue numbers?
Fixes #2573Kamil TrzcińśkiKamil Trzcińśki