Add function list_namespaced_persistent_volume_claim_by_pattern

devopsspiral / KubeLibrary

Kubernetes library for Robot Framework

MIT License

139 stars 38 forks source link

Add function list_namespaced_persistent_volume_claim_by_pattern #112

Closed siaomingjeng closed 2 years ago

siaomingjeng commented 2 years ago

\<Add function list_namespaced_persistent_volume_claim_by_pattern>

Fixes #\<#110>

Before merge following needs to be applied:

[x] At least one example testcase added in testcases/
[x] Library Documentation regenerated according to Generate docs
[x] PR entry added in CHANGELOG.md in In progress section
[x] All new testcases tagged as prerelease along other tags to exclude it from execution until released on PyPI
[x] Coverage threshold increased in .coveragerc if new coverage is higher than actual, see the lint-and-coverage step in CI
```
fail_under = 86
```

siaomingjeng commented 2 years ago

Please review and let me know if any further changes are needed. Thanks! I have a number of functions to be added after this. It is better to add 1 function each time for easy debugging.

siaomingjeng commented 2 years ago

Just feel the All checks are not stable. For my last 3 changes, I actually changed nothing, but to trigger the rerun of All checks. However, some passed all the checks, some not.

m-wcislo commented 2 years ago

Changes looks good, if you have more functions to add you can include it in this PR, until you really want to split those for some reason.

As for tests unstability just noticed it and seems it fails on different stages, let's observe what is going on and possibly address it in another PR.

siaomingjeng commented 2 years ago

Changes looks good, if you have more functions to add you can include it in this PR, until you really want to split those for some reason.

As for tests unstability just noticed it and seems it fails on different stages, let's observe what is going on and possibly address it in another PR.

Thank you for your reply! Would you mind merging this PR first?

I prefer 1 PR for 1 issue. It is much clearer and easier for debugging and management. (Also considering the current tests unstability.)