tektoncd
Improve/Add Unittest helpers for expected/observed yaml comparissons
At present, in the transformer unit tests assertions are not uniform.
The end transformation is verified in each tests based on the logic of the transformer. This means, knowledge of the internal working of the transformer is needed to write the assertion part of each unit test.
examples:
- https://github.com/tektoncd/operator/blob/4a5e82f67daa2f1a52fcd36b794af43a785d988f/pkg/reconciler/common/transformers_test.go#L440
- https://github.com/tektoncd/operator/blob/4a5e82f67daa2f1a52fcd36b794af43a785d988f/pkg/reconciler/common/transformers_test.go#L83
- https://github.com/tektoncd/operator/blob/4a5e82f67daa2f1a52fcd36b794af43a785d988f/pkg/reconciler/common/transformers_test.go#L346
How can we improve this?
If we source control a pair of initial and transformed manifests as yaml files for each of the transformer tests, then the assertion will become a simple yaml comparison.
This means that the assertion part of all these unit tests will be standardized. In addition, this will make writing unit tests easier as knowledge of the internal working of a transformer will not be necessary to write test focused on initlal and final yaml comparisson.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale with a justification.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle stale
Send feedback to tektoncd/plumbing.
Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten with a justification.
Rotten issues close after an additional 30d of inactivity.
If this issue is safe to close now please do so with /close with a justification.
If this issue should be exempted, mark the issue as frozen with /lifecycle frozen with a justification.
/lifecycle rotten
Send feedback to tektoncd/plumbing.
Hey! This is highly desirable by my side... Any time frame on it going merged? Or anyway of using this feature as a tester @jonathanrainer ? @andre-lx maybe you can describe what you did to test the solution? (i.e. build Dockerfile etc.) That would really help me and my case 😄
EDIT: Managed to get it to work (sorry for my noobishness). My use case was that a app from vendor required a storageClass but the problem was that every iteration of the app or version bump a new namespace was created, therefore creating a new EFS AP without the needed files on the previous AP path. This ensured that there was no data lost across every iteration or namespace.
I'm still in the process of finishing the implementation but I'm fairly confident that it should work. Thank you for this! 🥂
@tekton-robot: Closing this issue.
In response to this:
Rotten issues close after 30d of inactivity. Reopen the issue with
/reopenwith a justification. Mark the issue as fresh with/remove-lifecycle rottenwith a justification. If this issue should be exempted, mark the issue as frozen with/lifecycle frozenwith a justification./close
Send feedback to tektoncd/plumbing.
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.