Chainsaw, developed by Kyverno, is an advanced end-to-end testing tool for Kubernetes. Our community plays a crucial role in shaping the project by reporting bugs, suggesting features, and improving documentation.
We aim to make our issue tracker, discussion board, and documentation well-structured and easy to navigate. By following our guidelines, you can help us address your requests efficiently.
Before interacting within the project, please consider the following questions to ensure you're using the correct issue template and providing all necessary information.
Issues, discussions, and comments are forever
Please note that everything you write is permanent and will remain for everyone to read – forever. Therefore, please always be nice and constructive, follow our contribution guidelines, and comply with our Code of Conduct.
Is the topic a question for our discussion board, or is it a bug report or change request that should be raised on our [issue tracker]?
Is there an open discussion on the topic of your request? If the answer is yes, does your question match the direction of the discussion, or should you open a new discussion?
Did you provide our community with all the necessary information to understand your question and help you quickly, or can you make it easier to help you?
Is your comment relevant to the topic of the current page, post, issue, or discussion, or is it better to create a new issue or discussion?
Does your comment add value to the conversation? Is it constructive and respectful to our community and maintainers? Could you just use a reaction instead?
As maintainers, we are entrusted with the responsibility to moderate communication within our community, including the authority to close, remove, reject, or edit issues, discussions, comments, commits, and to block users who do not align with our contribution guidelines and our Code of Conduct. This role requires us to be actively involved in maintaining the integrity and positive atmosphere of our community. Upholding these standards decisively ensures a respectful and inclusive environment for all members.
Our Code of Conduct outlines the expectation for all community members to treat one another with respect, employing inclusive and welcoming language. Our commitment is to foster a positive and supportive environment, free of inappropriate, offensive, or harmful behavior.
We take any violations seriously and will take appropriate action in response to uphold these values.1
We have invested significant time and effort in the setup of our contribution process, ensuring that we assess the essential requirements for reviewing and responding to issues effectively. Each field in our issue templates is thoughtfully designed to help us fully understand your concerns and the nature of your matter. We encourage all members to utilize the search function before submitting new issues or starting discussions to help avoid duplicates. Your cooperation is crucial in keeping our community's discussions constructive and organized.
Mandatory completion of issue templates: We need all of the information required in our issue templates because it ensures that every user and maintainer, regardless of their experience, can understand the content and severity of your bug report or change request.
Closing incomplete issues: We reserve the right to close issues lacking essential information, such as but not limited to [minimal reproductions] or those not adhering to the quality standards and requirements specified in our issue templates. Such issues can be reopened once the missing information has been provided.
Handling duplicates: To maintain organized and efficient communication within our [issue tracker] and discussion board, we reserve the right to close any duplicated issues or lock duplicated discussions. Opening multiple channels to ask the same question or report the same issue across different forums hinders our ability to manage and address community concerns effectively. This approach is vital for efficient time management, as duplicated questions can consume the time of multiple team members simultaneously. Ensuring that each issue or discussion is unique and progresses with new information helps us to maintain focus and support our community.
We further reserve the right to immediately close discussions or issues that are reopened without providing new information or simply because users have not yet received a response to their issue/question, as the issue is marked as incomplete.
Limitations of automated tools: While we believe in the value and efficiency that automated tools bring to identifying potential issues (such as those identified by Lighthouse, Accessibility tools, and others), simply submitting an issue generated by these tools does not constitute a complete bug report. These tools sometimes produce verbose outputs and may include false positives, which necessitate a critical evaluation. You are of course welcome to attach generated reports to your issue. However, this does not substitute the requirement for a minimal reproduction or a thorough discussion of the findings. We reserve the right to mark these issues as incomplete and close them. This practice ensures that we are addressing genuine concerns with precision and clarity, rather than navigating through extensive automated outputs.
Warning and blocking policy: Given the increasing popularity of our project and our commitment to a healthy community, we've defined clear guidelines on how we proceed with violations:
1.1. First warning: Users displaying repeated inappropriate, offensive, or harmful behavior will receive a first warning. This warning serves as a formal notice that their behavior is not in alignment with our community standards and Code of Conduct. The first warning is permanent.
1.2. Second warning and opportunity for resolution: If the behavior persists, a second warning will be issued. Upon receiving the second warning, the user will be given a 5-day period for reflection, during which they are encouraged to publicly explain or apologize for their actions. This period is designed to offer an opportunity for openly clearing out any misunderstanding.
1.3. Blocking: Should there be no response or improvement in behavior following the second warning, we reserve the right to block the user from the community and repository. Blocking is considered a last resort, used only when absolutely necessary to protect the community's integrity and positive atmosphere.
Blocking has been an exceptionally rare necessity in our overwhelmingly positive community, highlighting our preference for constructive dialogue and mutual respect. It aims to protect our community members and team. ↩
\ No newline at end of file
+ Contributing - Chainsaw
Chainsaw, developed by Kyverno, is an advanced end-to-end testing tool for Kubernetes. Our community plays a crucial role in shaping the project by reporting bugs, suggesting features, and improving documentation.
We aim to make our issue tracker, discussion board, and documentation well-structured and easy to navigate. By following our guidelines, you can help us address your requests efficiently.
Before interacting within the project, please consider the following questions to ensure you're using the correct issue template and providing all necessary information.
Issues, discussions, and comments are forever
Please note that everything you write is permanent and will remain for everyone to read – forever. Therefore, please always be nice and constructive, follow our contribution guidelines, and comply with our Code of Conduct.
Is the topic a question for our discussion board, or is it a bug report or change request that should be raised on our [issue tracker]?
Is there an open discussion on the topic of your request? If the answer is yes, does your question match the direction of the discussion, or should you open a new discussion?
Did you provide our community with all the necessary information to understand your question and help you quickly, or can you make it easier to help you?
Is your comment relevant to the topic of the current page, post, issue, or discussion, or is it better to create a new issue or discussion?
Does your comment add value to the conversation? Is it constructive and respectful to our community and maintainers? Could you just use a reaction instead?
As maintainers, we are entrusted with the responsibility to moderate communication within our community, including the authority to close, remove, reject, or edit issues, discussions, comments, commits, and to block users who do not align with our contribution guidelines and our Code of Conduct. This role requires us to be actively involved in maintaining the integrity and positive atmosphere of our community. Upholding these standards decisively ensures a respectful and inclusive environment for all members.
Our Code of Conduct outlines the expectation for all community members to treat one another with respect, employing inclusive and welcoming language. Our commitment is to foster a positive and supportive environment, free of inappropriate, offensive, or harmful behavior.
We take any violations seriously and will take appropriate action in response to uphold these values.1
We have invested significant time and effort in the setup of our contribution process, ensuring that we assess the essential requirements for reviewing and responding to issues effectively. Each field in our issue templates is thoughtfully designed to help us fully understand your concerns and the nature of your matter. We encourage all members to utilize the search function before submitting new issues or starting discussions to help avoid duplicates. Your cooperation is crucial in keeping our community's discussions constructive and organized.
Mandatory completion of issue templates: We need all of the information required in our issue templates because it ensures that every user and maintainer, regardless of their experience, can understand the content and severity of your bug report or change request.
Closing incomplete issues: We reserve the right to close issues lacking essential information, such as but not limited to [minimal reproductions] or those not adhering to the quality standards and requirements specified in our issue templates. Such issues can be reopened once the missing information has been provided.
Handling duplicates: To maintain organized and efficient communication within our [issue tracker] and discussion board, we reserve the right to close any duplicated issues or lock duplicated discussions. Opening multiple channels to ask the same question or report the same issue across different forums hinders our ability to manage and address community concerns effectively. This approach is vital for efficient time management, as duplicated questions can consume the time of multiple team members simultaneously. Ensuring that each issue or discussion is unique and progresses with new information helps us to maintain focus and support our community.
We further reserve the right to immediately close discussions or issues that are reopened without providing new information or simply because users have not yet received a response to their issue/question, as the issue is marked as incomplete.
Limitations of automated tools: While we believe in the value and efficiency that automated tools bring to identifying potential issues (such as those identified by Lighthouse, Accessibility tools, and others), simply submitting an issue generated by these tools does not constitute a complete bug report. These tools sometimes produce verbose outputs and may include false positives, which necessitate a critical evaluation. You are of course welcome to attach generated reports to your issue. However, this does not substitute the requirement for a minimal reproduction or a thorough discussion of the findings. We reserve the right to mark these issues as incomplete and close them. This practice ensures that we are addressing genuine concerns with precision and clarity, rather than navigating through extensive automated outputs.
Warning and blocking policy: Given the increasing popularity of our project and our commitment to a healthy community, we've defined clear guidelines on how we proceed with violations:
1.1. First warning: Users displaying repeated inappropriate, offensive, or harmful behavior will receive a first warning. This warning serves as a formal notice that their behavior is not in alignment with our community standards and Code of Conduct. The first warning is permanent.
1.2. Second warning and opportunity for resolution: If the behavior persists, a second warning will be issued. Upon receiving the second warning, the user will be given a 5-day period for reflection, during which they are encouraged to publicly explain or apologize for their actions. This period is designed to offer an opportunity for openly clearing out any misunderstanding.
1.3. Blocking: Should there be no response or improvement in behavior following the second warning, we reserve the right to block the user from the community and repository. Blocking is considered a last resort, used only when absolutely necessary to protect the community's integrity and positive atmosphere.
Blocking has been an exceptionally rare necessity in our overwhelmingly positive community, highlighting our preference for constructive dialogue and mutual respect. It aims to protect our community members and team. ↩
\ No newline at end of file
diff --git a/main/community/index.html b/main/community/index.html
index d2aab7729..dd505f6a5 100644
--- a/main/community/index.html
+++ b/main/community/index.html
@@ -1 +1 @@
- Community - Chainsaw
Chainsaw has a growing community and we would definitely love to see you join and contribute.
Everyone is welcome to make suggestions, report bugs, open feature requests, contribute code or docs, participate in discussions, write blogs or anything that can benefit the project.
Chainsaw is built and maintained under the Kyverno umbrella but decisions are
To attend our community meetings, join the Chainsaw group. You will then be sent a meeting invite and will have access to the agenda and meeting notes. Any member may suggest topics for discussion.
This is a public, weekly for Kyverno-Chainsaw maintainers to make announcements and provide project updates, and request input and feedback. This forum allows community members to raise agenda items of any sort, including but not limited to any PRs or issues on which they are working.
If you are using Chainsaw and want to share it publicly we always appreciate a bit of support. Pull requests to the ADOPTERS LIST will put a smile on our faces
\ No newline at end of file
+ Community - Chainsaw
Chainsaw has a growing community and we would definitely love to see you join and contribute.
Everyone is welcome to make suggestions, report bugs, open feature requests, contribute code or docs, participate in discussions, write blogs or anything that can benefit the project.
Chainsaw is built and maintained under the Kyverno umbrella but decisions are
To attend our community meetings, join the Chainsaw group. You will then be sent a meeting invite and will have access to the agenda and meeting notes. Any member may suggest topics for discussion.
This is a public, weekly for Kyverno-Chainsaw maintainers to make announcements and provide project updates, and request input and feedback. This forum allows community members to raise agenda items of any sort, including but not limited to any PRs or issues on which they are working.
If you are using Chainsaw and want to share it publicly we always appreciate a bit of support. Pull requests to the ADOPTERS LIST will put a smile on our faces
\ No newline at end of file
diff --git a/main/community/making-a-pull-request/index.html b/main/community/making-a-pull-request/index.html
index 6392f6c19..c7d188e77 100644
--- a/main/community/making-a-pull-request/index.html
+++ b/main/community/making-a-pull-request/index.html
@@ -1,4 +1,4 @@
- Making a pull request - Chainsaw
You can contribute to Chainsaw by making a pull request that will be reviewed by maintainers and integrated into the main repository when the changes made are approved. You can contribute bug fixes, documentation changes, or new functionalities.
Considering a pull request
Before deciding to spend effort on making changes and creating a pull request, please discuss what you intend to do. If you are responding to what you think might be a bug, please issue a bug report first. If you intend to work on documentation, create a documentation issue. If you want to work on a new feature, please create a change request.
Keep in mind the guidance given and let people advise you. It might be that there are easier solutions to the problem you perceive and want to address. It might be that what you want to achieve can already be done by configuration or [customization].
Pull requests are a concept layered on top of Git by services that provide Git hosting. Before you consider making a pull request, you should familiarize yourself with the documentation on GitHub, the service we are using. The following articles are of particular importance:
Note that they provide tailored documentation for different operating systems and different ways of interacting with GitHub. We do our best in the documentation here to describe the process as it applies to Chainsaw but cannot cover all possible combinations of tools and ways of doing things. It is also important that you understand the concept of a pull-request in general before continuing.
In the following, we describe the general process for making pull requests. The aim here is to provide the 30k ft overview before describing details later on.
The diagram below describes what typically happens to repositories in the process or preparing a pull request. We will be discussing the review-revise process below. It is important that you understand the overall process first before you worry about specific commands. This is why we cover this first before providing instructions below.
sequenceDiagram
+ Making a pull request - Chainsaw
You can contribute to Chainsaw by making a pull request that will be reviewed by maintainers and integrated into the main repository when the changes made are approved. You can contribute bug fixes, documentation changes, or new functionalities.
Considering a pull request
Before deciding to spend effort on making changes and creating a pull request, please discuss what you intend to do. If you are responding to what you think might be a bug, please issue a bug report first. If you intend to work on documentation, create a documentation issue. If you want to work on a new feature, please create a change request.
Keep in mind the guidance given and let people advise you. It might be that there are easier solutions to the problem you perceive and want to address. It might be that what you want to achieve can already be done by configuration or [customization].
Pull requests are a concept layered on top of Git by services that provide Git hosting. Before you consider making a pull request, you should familiarize yourself with the documentation on GitHub, the service we are using. The following articles are of particular importance:
Note that they provide tailored documentation for different operating systems and different ways of interacting with GitHub. We do our best in the documentation here to describe the process as it applies to Chainsaw but cannot cover all possible combinations of tools and ways of doing things. It is also important that you understand the concept of a pull-request in general before continuing.
In the following, we describe the general process for making pull requests. The aim here is to provide the 30k ft overview before describing details later on.
The diagram below describes what typically happens to repositories in the process or preparing a pull request. We will be discussing the review-revise process below. It is important that you understand the overall process first before you worry about specific commands. This is why we cover this first before providing instructions below.
sequenceDiagram
autonumber
participant chainsaw
@@ -41,4 +41,4 @@
local ->> local: delete branch
fork ->> local: pull
end
-
Finalize PR: Signal that your changes are ready for review.
Request Review: Ask the maintainer to review your changes.
Discuss and Revise: Engage in discussions, make necessary revisions, and iterate.
Merge and Squash: Once approved, the maintainer will merge and possibly squash your commits.
Clean Up: Delete the branch used for the PR from both your fork and local clone.
\ No newline at end of file
+
Finalize PR: Signal that your changes are ready for review.
Request Review: Ask the maintainer to review your changes.
Discuss and Revise: Engage in discussions, make necessary revisions, and iterate.
Merge and Squash: Once approved, the maintainer will merge and possibly squash your commits.
Clean Up: Delete the branch used for the PR from both your fork and local clone.
\ No newline at end of file
diff --git a/main/community/reporting-a-bug/index.html b/main/community/reporting-a-bug/index.html
index d14f9173a..c774190d5 100644
--- a/main/community/reporting-a-bug/index.html
+++ b/main/community/reporting-a-bug/index.html
@@ -1,2 +1,2 @@
- Reporting a bug - Chainsaw
Chainsaw, developed by Kyverno, is an actively maintained project that we constantly strive to improve. With a project of this size and complexity, bugs may occur. If you think you have discovered a bug, you can help us by submitting an issue in our public issue tracker, following this guide.
With numerous users, issues are created regularly. The maintainers of this project strive to address bugs promptly. By following this guide, you will know exactly what information we need to help you quickly.
Chances are that the bug you discovered was already fixed in a subsequent version. Before reporting an issue, ensure that you're running the [latest version] of Chainsaw. Consult our [upgrade guide] to learn how to upgrade to the latest version.
Bug fixes are not backported
Please understand that only bugs that occur in the latest version of Chainsaw will be addressed. Also, to reduce duplicate efforts, fixes cannot be backported to earlier versions.
If you're using customizations like additional configurations, remove them before reporting a bug. We can't offer official support for bugs that might hide in your overrides, so make sure to omit custom settings from your configuration files.
Don't be shy to ask on our discussion board for help if you run into problems.
At this stage, we know that the problem persists in the latest version and is not caused by any of your customizations. However, the problem might result from a small typo or a syntactical error in a configuration file.
Before creating a bug report, save time for us and yourself by doing some research:
Search our documentation for relevant sections related to your problem. Ensure everything is configured correctly.
[Search our issue tracker] as another user might have already reported the same problem.
[Search our discussion board] to see if other users are facing similar issues and find possible solutions.
Keep track of all search terms and relevant links; you'll need them in the bug report.
If you still haven't found a solution to your problem, create an issue. It's now likely that you've encountered something new. Read the following section to learn how to create a complete and helpful bug report.
We have created a new issue template to make the bug reporting process as simple as possible and more efficient for our community and us. It consists of the following parts:
A good title is short and descriptive. It should be a one-sentence executive summary of the issue, so the impact and severity of the bug can be inferred from the title.
Example
Clear
Chainsaw apply command fails with specific CRD
Wordy
The apply command in Chainsaw fails when used with a certain Custom Resource Definition
Before describing the bug, you can provide additional context to help us understand what you were trying to achieve. Explain the circumstances under which you're using Chainsaw, and what you think might be relevant. Don't describe the bug here.
Provide a clear, focused, specific, and concise summary of the bug you encountered. Explain why you think this is a bug that should be reported to Chainsaw, and not to one of its dependencies. Follow these principles:
Explain the what, not the how – don't explain how to reproduce the bug here, we're getting there. Focus on articulating the problem and its impact.
Keep it short and concise – if the bug can be precisely explained in one or two sentences, perfect. Don't inflate it.
One bug at a time – if you encounter several unrelated bugs, create separate issues for them.
Share links to relevant sections of our documentation and any related issues or discussions. This helps us improve our documentation and understand the problem better.
A minimal reproduction is essential for a well-written bug report, as it allows us to recreate the conditions necessary to inspect the bug. Follow the guide to create a reproduction:
After creating the reproduction, you should have a .zip file, ideally not larger than 1 MB. Drag and drop the .zip file into the issue field, which will automatically upload it to GitHub.
Don't share links to repositories
While linking to a repository is a common practice, we currently don't support this. The reproduction, created using the built-in info plugin, contains all necessary environment information.
List specific steps to follow when running your reproduction to observe the bug. Keep the steps concise and ensure nothing is left out. Use simple language and focus on continuity.
If the bug only occurs in specific browsers, let us know which ones are affected. This field is optional, as it is only relevant for bugs that do not involve a crash when previewing or building your site.
Incognito Mode
Verify that the bug is not caused by a browser extension by switching to incognito mode. If the bug disappears, it is likely caused by an extension.
Chainsaw, developed by Kyverno, is an actively maintained project that we constantly strive to improve. With a project of this size and complexity, bugs may occur. If you think you have discovered a bug, you can help us by submitting an issue in our public issue tracker, following this guide.
With numerous users, issues are created regularly. The maintainers of this project strive to address bugs promptly. By following this guide, you will know exactly what information we need to help you quickly.
Chances are that the bug you discovered was already fixed in a subsequent version. Before reporting an issue, ensure that you're running the [latest version] of Chainsaw. Consult our [upgrade guide] to learn how to upgrade to the latest version.
Bug fixes are not backported
Please understand that only bugs that occur in the latest version of Chainsaw will be addressed. Also, to reduce duplicate efforts, fixes cannot be backported to earlier versions.
If you're using customizations like additional configurations, remove them before reporting a bug. We can't offer official support for bugs that might hide in your overrides, so make sure to omit custom settings from your configuration files.
Don't be shy to ask on our discussion board for help if you run into problems.
At this stage, we know that the problem persists in the latest version and is not caused by any of your customizations. However, the problem might result from a small typo or a syntactical error in a configuration file.
Before creating a bug report, save time for us and yourself by doing some research:
Search our documentation for relevant sections related to your problem. Ensure everything is configured correctly.
[Search our issue tracker] as another user might have already reported the same problem.
[Search our discussion board] to see if other users are facing similar issues and find possible solutions.
Keep track of all search terms and relevant links; you'll need them in the bug report.
If you still haven't found a solution to your problem, create an issue. It's now likely that you've encountered something new. Read the following section to learn how to create a complete and helpful bug report.
We have created a new issue template to make the bug reporting process as simple as possible and more efficient for our community and us. It consists of the following parts:
A good title is short and descriptive. It should be a one-sentence executive summary of the issue, so the impact and severity of the bug can be inferred from the title.
Example
Clear
Chainsaw apply command fails with specific CRD
Wordy
The apply command in Chainsaw fails when used with a certain Custom Resource Definition
Before describing the bug, you can provide additional context to help us understand what you were trying to achieve. Explain the circumstances under which you're using Chainsaw, and what you think might be relevant. Don't describe the bug here.
Provide a clear, focused, specific, and concise summary of the bug you encountered. Explain why you think this is a bug that should be reported to Chainsaw, and not to one of its dependencies. Follow these principles:
Explain the what, not the how – don't explain how to reproduce the bug here, we're getting there. Focus on articulating the problem and its impact.
Keep it short and concise – if the bug can be precisely explained in one or two sentences, perfect. Don't inflate it.
One bug at a time – if you encounter several unrelated bugs, create separate issues for them.
Share links to relevant sections of our documentation and any related issues or discussions. This helps us improve our documentation and understand the problem better.
A minimal reproduction is essential for a well-written bug report, as it allows us to recreate the conditions necessary to inspect the bug. Follow the guide to create a reproduction:
After creating the reproduction, you should have a .zip file, ideally not larger than 1 MB. Drag and drop the .zip file into the issue field, which will automatically upload it to GitHub.
Don't share links to repositories
While linking to a repository is a common practice, we currently don't support this. The reproduction, created using the built-in info plugin, contains all necessary environment information.
List specific steps to follow when running your reproduction to observe the bug. Keep the steps concise and ensure nothing is left out. Use simple language and focus on continuity.
If the bug only occurs in specific browsers, let us know which ones are affected. This field is optional, as it is only relevant for bugs that do not involve a crash when previewing or building your site.
Incognito Mode
Verify that the bug is not caused by a browser extension by switching to incognito mode. If the bug disappears, it is likely caused by an extension.
Thanks for following the guide and creating a high-quality bug report. We will take it from here.
\ No newline at end of file
diff --git a/main/community/reporting-a-docs-issue/index.html b/main/community/reporting-a-docs-issue/index.html
index c59e6a8a0..187c5b322 100644
--- a/main/community/reporting-a-docs-issue/index.html
+++ b/main/community/reporting-a-docs-issue/index.html
@@ -1 +1 @@
- Reporting a docs issue - Chainsaw
The Chainsaw documentation includes extensive information on features, configurations, customizations, and more. If you have found an inconsistency or see room for improvement, please follow this guide to submit an issue on our issue tracker.
Reporting a documentation issue is usually less involved than reporting a bug, as we don't need a [reproduction]. Please thoroughly read this guide before creating a new documentation issue, and provide the following information as part of the issue:
A good title should be a short, one-sentence description of the issue, containing all relevant information and keywords to simplify the search in our issue tracker.
Provide a clear and concise summary of the inconsistency or issue you encountered in the documentation or the documentation section that needs improvement. Explain why you think the documentation should be adjusted and describe the severity of the issue:
Keep it short and concise – if the inconsistency or issue can be precisely explained in one or two sentences, perfect. Maintainers and future users will be grateful for having to read less.
One issue at a time – if you encounter several unrelated inconsistencies, please create separate issues for them.
Why we need this: describing the problem clearly and concisely is a prerequisite for improving our documentation – we need to understand what's wrong so we can fix it.
After you describe the documentation section that needs to be adjusted, share the link to this specific documentation section and other possibly related sections. Use anchor links (permanent links) where possible, as it simplifies discovery.
Why we need this: providing the links to the documentation helps us understand which sections of our documentation need to be adjusted, extended, or overhauled.
Now that you have provided us with the description and links to the documentation sections, you can help us, maintainers, and the community by proposing an improvement. You can sketch out rough ideas or write a concrete proposal. This field is optional but very helpful.
Why we need this: an improvement proposal can be beneficial for other users who encounter the same issue, as they offer solutions before we maintainers can update the documentation.
Thanks for following the guide and providing valuable feedback for our documentation – you are almost done. The checklist ensures that you have read this guide and have worked to your best knowledge to provide us with every piece of information we need to improve it.
We'll take it from here.
\ No newline at end of file
+ Reporting a docs issue - Chainsaw
The Chainsaw documentation includes extensive information on features, configurations, customizations, and more. If you have found an inconsistency or see room for improvement, please follow this guide to submit an issue on our issue tracker.
Reporting a documentation issue is usually less involved than reporting a bug, as we don't need a [reproduction]. Please thoroughly read this guide before creating a new documentation issue, and provide the following information as part of the issue:
A good title should be a short, one-sentence description of the issue, containing all relevant information and keywords to simplify the search in our issue tracker.
Provide a clear and concise summary of the inconsistency or issue you encountered in the documentation or the documentation section that needs improvement. Explain why you think the documentation should be adjusted and describe the severity of the issue:
Keep it short and concise – if the inconsistency or issue can be precisely explained in one or two sentences, perfect. Maintainers and future users will be grateful for having to read less.
One issue at a time – if you encounter several unrelated inconsistencies, please create separate issues for them.
Why we need this: describing the problem clearly and concisely is a prerequisite for improving our documentation – we need to understand what's wrong so we can fix it.
After you describe the documentation section that needs to be adjusted, share the link to this specific documentation section and other possibly related sections. Use anchor links (permanent links) where possible, as it simplifies discovery.
Why we need this: providing the links to the documentation helps us understand which sections of our documentation need to be adjusted, extended, or overhauled.
Now that you have provided us with the description and links to the documentation sections, you can help us, maintainers, and the community by proposing an improvement. You can sketch out rough ideas or write a concrete proposal. This field is optional but very helpful.
Why we need this: an improvement proposal can be beneficial for other users who encounter the same issue, as they offer solutions before we maintainers can update the documentation.
Thanks for following the guide and providing valuable feedback for our documentation – you are almost done. The checklist ensures that you have read this guide and have worked to your best knowledge to provide us with every piece of information we need to improve it.
We'll take it from here.
\ No newline at end of file
diff --git a/main/community/requesting-a-change/index.html b/main/community/requesting-a-change/index.html
index 32c8e0572..8e45d53bb 100644
--- a/main/community/requesting-a-change/index.html
+++ b/main/community/requesting-a-change/index.html
@@ -1 +1 @@
- Requesting a change - Chainsaw
Chainsaw by Kyverno is a powerful tool for end-to-end testing. Serving a wide range of use cases, we value every idea or contribution from our community. Please follow this guide before submitting your change request in our public issue tracker. This helps us better understand the proposed change and how it will benefit our community.
Before you invest time in submitting a change request, answer these questions to determine if your idea is a good fit for Chainsaw and matches the project's philosophy and tone.
Change requests suggest minor adjustments, new features, or influence the project's direction. They are not intended for reporting bugs. Refer to our bug reporting guide for that.
Our discussion board is the best place to connect with our community. Seeking input from other users helps implement features that benefit a larger number of users.
Provide additional context to help us understand what you are trying to achieve. Explain the circumstances and relevant settings without describing the change request itself.
Provide a detailed and clear description of your idea. Explain why your idea is relevant to Chainsaw and should be implemented here, not in one of its dependencies.
Explain the what, not the why – focus on describing the change request precisely.
Keep it short and concise – be brief and to the point.
One idea at a time – if you have multiple ideas, open separate change requests for each.
Explain how your change request would work from an author's and user's perspective. What is the expected impact, and why does it benefit other users? Would it potentially break existing functionality?
If you have any visuals, such as sketches, screenshots, mockups, or external assets, present them in this section. If you have seen this change used in other tools, showcase and describe its implementation.
Thanks for following the guide and creating a high-quality change request. The checklist ensures that you have read this guide and provided all necessary information for us to review your idea.
Your change request got rejected? We're sorry for that. We understand it can be frustrating, but we always need to consider the needs of our entire community. If you're unsure why your change request was rejected, please ask for clarification.
We consider the following principles when evaluating change requests:
Alignment with the project's vision and tone
Compatibility with existing features and plugins
Compatibility with all screen sizes and browsers
Effort of implementation and maintenance
Usefulness to the majority of users
Simplicity and ease of use
Accessibility
If your idea was rejected, you can always implement it via [customization]. If you're unsure how or want to know if someone has already done it, get in touch with our community on the discussion board.
\ No newline at end of file
+ Requesting a change - Chainsaw
Chainsaw by Kyverno is a powerful tool for end-to-end testing. Serving a wide range of use cases, we value every idea or contribution from our community. Please follow this guide before submitting your change request in our public issue tracker. This helps us better understand the proposed change and how it will benefit our community.
Before you invest time in submitting a change request, answer these questions to determine if your idea is a good fit for Chainsaw and matches the project's philosophy and tone.
Change requests suggest minor adjustments, new features, or influence the project's direction. They are not intended for reporting bugs. Refer to our bug reporting guide for that.
Our discussion board is the best place to connect with our community. Seeking input from other users helps implement features that benefit a larger number of users.
Provide additional context to help us understand what you are trying to achieve. Explain the circumstances and relevant settings without describing the change request itself.
Provide a detailed and clear description of your idea. Explain why your idea is relevant to Chainsaw and should be implemented here, not in one of its dependencies.
Explain the what, not the why – focus on describing the change request precisely.
Keep it short and concise – be brief and to the point.
One idea at a time – if you have multiple ideas, open separate change requests for each.
Explain how your change request would work from an author's and user's perspective. What is the expected impact, and why does it benefit other users? Would it potentially break existing functionality?
If you have any visuals, such as sketches, screenshots, mockups, or external assets, present them in this section. If you have seen this change used in other tools, showcase and describe its implementation.
Thanks for following the guide and creating a high-quality change request. The checklist ensures that you have read this guide and provided all necessary information for us to review your idea.
Your change request got rejected? We're sorry for that. We understand it can be frustrating, but we always need to consider the needs of our entire community. If you're unsure why your change request was rejected, please ask for clarification.
We consider the following principles when evaluating change requests:
Alignment with the project's vision and tone
Compatibility with existing features and plugins
Compatibility with all screen sizes and browsers
Effort of implementation and maintenance
Usefulness to the majority of users
Simplicity and ease of use
Accessibility
If your idea was rejected, you can always implement it via [customization]. If you're unsure how or want to know if someone has already done it, get in touch with our community on the discussion board.
\ No newline at end of file
diff --git a/main/configuration/file/index.html b/main/configuration/file/index.html
index 2567fea00..2ebdbdb47 100644
--- a/main/configuration/file/index.html
+++ b/main/configuration/file/index.html
@@ -1,4 +1,4 @@
- Configuration file - Chainsaw
\ No newline at end of file
diff --git a/main/configuration/flags/index.html b/main/configuration/flags/index.html
index 36f2a5422..5f19320d4 100644
--- a/main/configuration/flags/index.html
+++ b/main/configuration/flags/index.html
@@ -1,4 +1,4 @@
- Command line flags - Chainsaw
In this example, Chainsaw will load a configuration file but the timeout configuration and other settings will be overridden by the values set in the flags, regardless of the value in the loaded configuration file.
See chainsaw test command reference for the list of all available flags.
\ No newline at end of file
+
In this example, Chainsaw will load a configuration file but the timeout configuration and other settings will be overridden by the values set in the flags, regardless of the value in the loaded configuration file.
At the end of each test, Chainsaw will delete the resources it created during the test.
When testing operators, it can be useful to wait a little bit before starting the cleanup process to make sure the operator/controller has the necessary time to update its internal state.
At the end of each test, Chainsaw will delete the resources it created during the test.
When testing operators, it can be useful to wait a little bit before starting the cleanup process to make sure the operator/controller has the necessary time to update its internal state.
Setting Orphan is probably never a good idea because it would leak resources in the test cluster. Chainsaw uses Background as its default value which is a reasonable choice.
Note that Foreground can be useful to fail when the dependent resources fail to delete.
Setting Orphan is probably never a good idea because it would leak resources in the test cluster. Chainsaw uses Background as its default value which is a reasonable choice.
Note that Foreground can be useful to fail when the dependent resources fail to delete.
Some Kubernetes resources can take time before being terminated. For example, deleting a pod can take time if the underlying container doesn't quit quickly enough.
Chainsaw can override the grace period for the following resource kinds:
Some Kubernetes resources can take time before being terminated. For example, deleting a pod can take time if the underlying container doesn't quit quickly enough.
Chainsaw can override the grace period for the following resource kinds:
Name defines the namespace to use for tests. If not specified, every test will execute in a random ephemeral namespace unless the namespace is overridden in a the test spec.
template
Template defines a template to create the test namespace.
Name defines the namespace to use for tests. If not specified, every test will execute in a random ephemeral namespace unless the namespace is overridden in a the test spec.
template
Template defines a template to create the test namespace.
The template element can't be configured with flags.
chainsawtest--namespacefoo
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/main/configuration/options/no-cluster/index.html b/main/configuration/options/no-cluster/index.html
index 8c50bc2d2..41610e6a9 100644
--- a/main/configuration/options/no-cluster/index.html
+++ b/main/configuration/options/no-cluster/index.html
@@ -1,2 +1,2 @@
- No cluster options - Chainsaw
Chainsaw can be configured to pause and wait for user input when a failure happens. This is useful when Chainsaw is run locally to allow debugging and troubleshooting failures.
Chainsaw can be configured to pause and wait for user input when a failure happens. This is useful when Chainsaw is run locally to allow debugging and troubleshooting failures.
\ No newline at end of file
diff --git a/main/examples/concurrency/index.html b/main/examples/concurrency/index.html
index 7b2c12586..b82a72906 100644
--- a/main/examples/concurrency/index.html
+++ b/main/examples/concurrency/index.html
@@ -1,4 +1,4 @@
- Concurrency control - Chainsaw
The number of concurrent tests can be configured globally using a configuration file or with the --parallel flag.
Alternatively, the concurrent nature of a test can specified at the test level:
apiVersion:chainsaw.kyverno.io/v1alpha1kind:Testmetadata:name:example
@@ -7,4 +7,4 @@
# default value is `true`concurrent:false# ...
-
All non-concurrent tests are executed first, followed by the concurrent tests running in parallel.
\ No newline at end of file
+
All non-concurrent tests are executed first, followed by the concurrent tests running in parallel.
\ No newline at end of file
diff --git a/main/examples/crds/index.html b/main/examples/crds/index.html
index 352b32e67..7ff431610 100644
--- a/main/examples/crds/index.html
+++ b/main/examples/crds/index.html
@@ -1,4 +1,4 @@
- Work with CRDs - Chainsaw
\ No newline at end of file
diff --git a/main/examples/events/index.html b/main/examples/events/index.html
index e3c18a062..ff601d197 100644
--- a/main/examples/events/index.html
+++ b/main/examples/events/index.html
@@ -1,4 +1,4 @@
- Work with events - Chainsaw
\ No newline at end of file
diff --git a/main/examples/kube-version/index.html b/main/examples/kube-version/index.html
index a405b7c41..5f1d9e45b 100644
--- a/main/examples/kube-version/index.html
+++ b/main/examples/kube-version/index.html
@@ -1,4 +1,4 @@
- Check Kubernetes version - Chainsaw
The test below fetches the Kubernetes cluster version using the x_k8s_server_version function. It then uses the minor version retrieved to adapt an assertion based on the value in the $minorversion binding.
Tip
You can implement a ternary operator in JMESPath using an expression like this:
The test below fetches the Kubernetes cluster version using the x_k8s_server_version function. It then uses the minor version retrieved to adapt an assertion based on the value in the $minorversion binding.
Tip
You can implement a ternary operator in JMESPath using an expression like this:
\ No newline at end of file
diff --git a/main/examples/label-selectors/index.html b/main/examples/label-selectors/index.html
index f764184ce..699226d36 100644
--- a/main/examples/label-selectors/index.html
+++ b/main/examples/label-selectors/index.html
@@ -1,4 +1,4 @@
- Work with label selectors - Chainsaw
We can also register clusters dynamically and combine this with cluster selection to achieve scenarios where clusters are dynamically allocated in a test step, used in the following steps, and cleaned up at the end.
The following test demonstrates such a scenario by creating a local kind cluster in the first, using it in the second step, and configuring a cleanup script to delete the cluster when the test terminates:
We can also register clusters dynamically and combine this with cluster selection to achieve scenarios where clusters are dynamically allocated in a test step, used in the following steps, and cleaned up at the end.
The following test demonstrates such a scenario by creating a local kind cluster in the first, using it in the second step, and configuring a cleanup script to delete the cluster when the test terminates:
apiVersion:chainsaw.kyverno.io/v1alpha1kind:Testmetadata:name:example
@@ -101,4 +101,4 @@
| 10:45:10 | example | @cleanup | DELETE | RUN | v1/Namespace @ chainsaw-useful-seahorse
| 10:45:11 | example | @cleanup | DELETE | OK | v1/Namespace @ chainsaw-useful-seahorse
| 10:45:16 | example | @cleanup | DELETE | DONE | v1/Namespace @ chainsaw-useful-seahorse
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/main/examples/negative-testing/index.html b/main/examples/negative-testing/index.html
index e619adf8a..52d8f4054 100644
--- a/main/examples/negative-testing/index.html
+++ b/main/examples/negative-testing/index.html
@@ -1,4 +1,4 @@
- Negative testing - Chainsaw
Negative testing is the process of testing cases that are supposed to fail. That is, a test expects errors to happen and if the expected errors don't occur the test must fail.
Chainsaw supports negative testing by letting you decide what should be considered an error or not.
Tip
By default, Chainsaw will consider an operation failed if there was an error executing it (non-zero exit code in scripts and commands, error returned by the API server when calling into Kubernetes, etc...).
Negative testing is the process of testing cases that are supposed to fail. That is, a test expects errors to happen and if the expected errors don't occur the test must fail.
Chainsaw supports negative testing by letting you decide what should be considered an error or not.
Tip
By default, Chainsaw will consider an operation failed if there was an error executing it (non-zero exit code in scripts and commands, error returned by the API server when calling into Kubernetes, etc...).
Under certain circumstances, it makes sense to evaluate assertions that do not depend on resources. For example, when asserting the number of nodes in a cluster is equal to a known value.
The test below uses the x_k8s_list function to query the list of nodes in the cluster. It uses the results to compare the number of nodes found with a known number (1 in this case).
Under certain circumstances, it makes sense to evaluate assertions that do not depend on resources. For example, when asserting the number of nodes in a cluster is equal to a known value.
The test below uses the x_k8s_list function to query the list of nodes in the cluster. It uses the results to compare the number of nodes found with a known number (1 in this case).
\ No newline at end of file
diff --git a/main/examples/test-output/index.html b/main/examples/test-output/index.html
index 056834b8c..7c7bc2813 100644
--- a/main/examples/test-output/index.html
+++ b/main/examples/test-output/index.html
@@ -1,4 +1,4 @@
- Test command output - Chainsaw
Chainsaw can be used to easily check terminal output from CLIs and other commands. This is useful in that convoluted bash scripts involving chaining together tools like grep can be avoided or at least minimized to only complex use cases. Output to both stdout and stderr can be checked for a given string or precise contents.
One basic use case for content checking is that the output simply contains a given string or piece of content. For example, you might want to run automated tests on a CLI binary you build to ensure that a given command produces output that contains some content you specify somewhere in the output. Let's use the following output from the kubectl version command to show these examples.
Chainsaw can be used to easily check terminal output from CLIs and other commands. This is useful in that convoluted bash scripts involving chaining together tools like grep can be avoided or at least minimized to only complex use cases. Output to both stdout and stderr can be checked for a given string or precise contents.
One basic use case for content checking is that the output simply contains a given string or piece of content. For example, you might want to run automated tests on a CLI binary you build to ensure that a given command produces output that contains some content you specify somewhere in the output. Let's use the following output from the kubectl version command to show these examples.
kubectlversion
ClientVersion:v1.28.2
KustomizeVersion:v5.0.4-0.20230601165947-6ce0bf390ce3
@@ -76,4 +76,4 @@
($error != null):true# This checks that the output is exactly as intended.($stderr):"error:unknowncommand\"foo\"for\"kubectl\"\n\nDidyoumeanthis?\n\ttop"
-
\ No newline at end of file
+
\ No newline at end of file
diff --git a/main/examples/values/index.html b/main/examples/values/index.html
index d1d67836f..35c383f7f 100644
--- a/main/examples/values/index.html
+++ b/main/examples/values/index.html
@@ -1,4 +1,4 @@
- Pass data to tests - Chainsaw
You can think of bindings as a side context where you can store and retrieve data by name.
This is particularly useful when some data is only known at runtime. For example, to pass data from one operation to another, to implement resource templating, to fetch data from an external system, or anything that needs to be computed at runtime.
You can think of bindings as a side context where you can store and retrieve data by name.
This is particularly useful when some data is only known at runtime. For example, to pass data from one operation to another, to implement resource templating, to fetch data from an external system, or anything that needs to be computed at runtime.
While a simple check is enough to determine the result of a single operation, we needed a more advanced construct to cover apply, create, delete, patch and update operations. Those operations can operate on files containing multiple resources and every resource can lead to a different result and expectation.
While a simple check is enough to determine the result of a single operation, we needed a more advanced construct to cover apply, create, delete, patch and update operations. Those operations can operate on files containing multiple resources and every resource can lead to a different result and expectation.
The example below uses a simple check. The operation is expected to fail (($error != null): true):
apiVersion:chainsaw.kyverno.io/v1alpha1kind:Testmetadata:name:example
@@ -33,4 +33,4 @@
# - succeed if the operation failed# - fail if the operation succeeded($error != null):true
-
In the test above, only config maps are expected to fail. If the resources.yaml file contains other type of resources they are supposed to be created without error (if an error happens for a non config map resource, the operation will be considered a failure).
\ No newline at end of file
+
In the test above, only config maps are expected to fail. If the resources.yaml file contains other type of resources they are supposed to be created without error (if an error happens for a non config map resource, the operation will be considered a failure).
\ No newline at end of file
diff --git a/main/general/inheritance/index.html b/main/general/inheritance/index.html
index 2621d9193..3e3a00df7 100644
--- a/main/general/inheritance/index.html
+++ b/main/general/inheritance/index.html
@@ -1,4 +1,4 @@
- Inheritance - Chainsaw
Chainsaw has a concept of levels and most of the configuration elements and dynamic elements are inherited from one layer to the next in one way or another.
Chainsaw has a concept of levels and most of the configuration elements and dynamic elements are inherited from one layer to the next in one way or another.
flowchart TD
Configuration -. Configuration elements are inherited in tests .-> Test
Test -. Test elements are inherited in test steps .-> Step
- Step -. Step elements are inherited in step operations .-> Operation
The first layer comes from the Chainsaw configuration. You can think about this layer as the global scope and a way to configure how Chainsaw will behave globally.
Under certain circumstances, lower layers will be allowed to consume and/or override elements from upper layers.
The first layer comes from the Chainsaw configuration. You can think about this layer as the global scope and a way to configure how Chainsaw will behave globally.
Under certain circumstances, lower layers will be allowed to consume and/or override elements from upper layers.
Inheritance always flows from one level to the next and never propagates back to the upper levels.
There's no exception to this rule, but the only case where one operation can communicate with other ones is when using outputs.
\ No newline at end of file
diff --git a/main/general/namespace/index.html b/main/general/namespace/index.html
index 37998b728..7700244b6 100644
--- a/main/general/namespace/index.html
+++ b/main/general/namespace/index.html
@@ -1,4 +1,4 @@
- Test namespace - Chainsaw
By default, Chainsaw will create an ephemeral namespace with a random name for each test, unless a specific namespace name is provided at the global or test level.
One way to control the namespace used to run tests is to specify the name in the Chainsaw configuration Namespace options.
If a namespace name is specified at the configuration level Chainsaw will use it to run the tests (unless an individual test overrides the namespace name).
If the test name is specified in a test spec, Chainsaw will use it to run the test regardless of whether a namespace name was configured at the global level.
Because the name of the namespace is only known at runtime, depending on the resource being manipulated, Chainsaw will eventually inject the namespace name, except if:
By default, Chainsaw will create an ephemeral namespace with a random name for each test, unless a specific namespace name is provided at the global or test level.
One way to control the namespace used to run tests is to specify the name in the Chainsaw configuration Namespace options.
If a namespace name is specified at the configuration level Chainsaw will use it to run the tests (unless an individual test overrides the namespace name).
If the test name is specified in a test spec, Chainsaw will use it to run the test regardless of whether a namespace name was configured at the global level.
Because the name of the namespace is only known at runtime, depending on the resource being manipulated, Chainsaw will eventually inject the namespace name, except if:
Operation outputs can be useful for communicating and reusing computation results across operations.
Chainsaw evaluates outputs after an operation has finished executing. The results of output evaluations are registered in the bindings and are made available for the following operations.
Operation outputs can be useful for communicating and reusing computation results across operations.
Chainsaw evaluates outputs after an operation has finished executing. The results of output evaluations are registered in the bindings and are made available for the following operations.
One way to declare a resource is to do it directly inside the test definition:
apiVersion:chainsaw.kyverno.io/v1alpha1kind:Testmetadata:name:example
@@ -45,4 +45,4 @@
-apply:# use an URLfile:https://raw.githubusercontent.com/kyverno/chainsaw/main/testdata/step/configmap.yaml
-
When using file-based references, it is important to note that the referenced file(s) can declare multiple resources. Internally, Chainsaw will duplicate the operation once per resource.
This is important to keep this in mind, especially when working with bindings and outputs. Bindings and outputs will be evaluated for every operation instance.
When using file-based references, it is important to note that the referenced file(s) can declare multiple resources. Internally, Chainsaw will duplicate the operation once per resource.
This is important to keep this in mind, especially when working with bindings and outputs. Bindings and outputs will be evaluated for every operation instance.
\ No newline at end of file
diff --git a/main/general/templating/index.html b/main/general/templating/index.html
index 5e8e3c4d4..eb7a25fd6 100644
--- a/main/general/templating/index.html
+++ b/main/general/templating/index.html
@@ -1,4 +1,4 @@
- Templating - Chainsaw
Chainsaw simplifies dynamic configuration with native templating support.
In the past, users have created all sorts of hacks using tools like envsubst for dynamic substitution of env-variables. Those workarounds usually lack flexibility and introduce new problems like hiding the real resources from Chainsaw, preventing it from cleaning resources properly.
Templating in Chainsaw solves exactly this kind of problem.
In the template below, we are using the $namespace binding at two different places, effectively injecting the ephemeral namespace name in the name and the data.foo fields:
Chainsaw simplifies dynamic configuration with native templating support.
In the past, users have created all sorts of hacks using tools like envsubst for dynamic substitution of env-variables. Those workarounds usually lack flexibility and introduce new problems like hiding the real resources from Chainsaw, preventing it from cleaning resources properly.
Templating in Chainsaw solves exactly this kind of problem.
In the template below, we are using the $namespace binding at two different places, effectively injecting the ephemeral namespace name in the name and the data.foo fields:
\ No newline at end of file
diff --git a/main/guides/kuttl-migration/index.html b/main/guides/kuttl-migration/index.html
index cf4627ca5..7545009d4 100644
--- a/main/guides/kuttl-migration/index.html
+++ b/main/guides/kuttl-migration/index.html
@@ -1,3 +1,3 @@
- Migration from KUTTL - Chainsaw
\ No newline at end of file
diff --git a/main/guides/test-docs/index.html b/main/guides/test-docs/index.html
index 493bf8d07..8ca5de7d8 100644
--- a/main/guides/test-docs/index.html
+++ b/main/guides/test-docs/index.html
@@ -1,4 +1,4 @@
- Building test docs - Chainsaw
Install locally using a package manager like brew or nix, or simply download the binary from one of our releases. If you want to run using a Docker image, we have that too.
Easy to use
Write tests in minutes, not hours. All it takes is a YAML file to define the steps of a test. Chainsaw will do the rest, no need to learn a programing language or write a single line of code!
Comprehensive reporting
Understand and diagnose failures easily, thanks to a comprehensive output showing precisely what failed and why. Generate JUnit compatible reports to integrate with other test reporting tools.
Resource templating
Kubernetes is all about resouces and tests need to work with resources. Chainsaw has built-in support for bindings, operation outputs and resource templating to describe complex test scenarios.
Positive testing
Create, update, delete resources and assert your controller reconciles the desired and observed states in the expected way.
Negative testing
Try submitting invalid resources, invalid changes, or other disallowed actions and make sure they are rejected.
Stay focused
Focus on the software you are building, write test scenarios using YAML and let Chainsaw tell you what passes or not. Integrate in your CI pipeline to prevent regressions and release with better confidence.
Multi cluster
Native support for tests involving multiple clusters, either static or dynamically created ones, make Chainsaw an excellent tool for testing highly complex environments and architectures.
Install locally using a package manager like brew or nix, or simply download the binary from one of our releases. If you want to run using a Docker image, we have that too.
Easy to use
Write tests in minutes, not hours. All it takes is a YAML file to define the steps of a test. Chainsaw will do the rest, no need to learn a programing language or write a single line of code!
Comprehensive reporting
Understand and diagnose failures easily, thanks to a comprehensive output showing precisely what failed and why. Generate JUnit compatible reports to integrate with other test reporting tools.
Resource templating
Kubernetes is all about resouces and tests need to work with resources. Chainsaw has built-in support for bindings, operation outputs and resource templating to describe complex test scenarios.
Positive testing
Create, update, delete resources and assert your controller reconciles the desired and observed states in the expected way.
Negative testing
Try submitting invalid resources, invalid changes, or other disallowed actions and make sure they are rejected.
Stay focused
Focus on the software you are building, write test scenarios using YAML and let Chainsaw tell you what passes or not. Integrate in your CI pipeline to prevent regressions and release with better confidence.
Multi cluster
Native support for tests involving multiple clusters, either static or dynamically created ones, make Chainsaw an excellent tool for testing highly complex environments and architectures.
