Make child resource creation atomic when creating a k8s stack#1611
Make child resource creation atomic when creating a k8s stack#1611silvin-lubecki merged 1 commit intodocker:masterfrom
Conversation
b319212 to
6c3355d
Compare
Codecov Report
@@ Coverage Diff @@
## master #1611 +/- ##
=========================================
+ Coverage 55.16% 55.56% +0.4%
=========================================
Files 301 301
Lines 20384 20451 +67
=========================================
+ Hits 11244 11363 +119
+ Misses 8335 8270 -65
- Partials 805 818 +13 |
75439ed to
b712db3
Compare
|
@silvin-lubecki @vdemeester PTAL :) |
| assert.Equal(t, c.OwnerReferences[0].APIVersion, v1beta1.SchemeGroupVersion.String()) | ||
| s, err := secrets.Get("test", metav1.GetOptions{}) | ||
| assert.NilError(t, err) | ||
| assert.Equal(t, len(s.OwnerReferences), 1) |
There was a problem hiding this comment.
I think you can factorize the check on OwnerReferences with the next test.
silvin-lubecki
left a comment
There was a problem hiding this comment.
+12k for the vendoring... only for fakes... 😱
Are you sure it's mandatory?
|
Fakes are a VERY useful way to test integration with the Kubernetes API, which let us use the existing client-go abstractions without having to write our own fakes. There is a tradeoff there: vendoring the whole thing makes test setup far easier (and cleaner). We could also partially vendor fakes for supporting only the Core API (configs and secrets are in the Core API), but that would require some code change and a more complex test setup. We could also don't vendor the fakes and write our own (but I strongly discourage it). |
Signed-off-by: Simon Ferquel <simon.ferquel@docker.com>
b712db3 to
e16a875
Compare
- What I did
I made sure that configs and secrets created with the CLI are
- How I did it
- How to verify it
The PR comes with unit tests