This repository has been archived by the owner on Mar 22, 2024. It is now read-only.
Add maintainer's handbook. #265
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
The maintainer's handbook is a guide to remind the maintainers of the values and approaches that most maintainers already hold. Specifics of code quality will come later, but putting them into this document would make it too long, and thus unread. Closes spiffe#263 Signed-off-by: Edwin Buck <edwbuck@gmail.com>
edwbuck
requested review from
marcofranssen,
kfox1111,
developer-guy,
dfeldman,
faisal-memon and
mrsabath
as code owners
mrsabath
reviewed
May 9, 2023
kfox1111
reviewed
May 9, 2023
Co-authored-by: Marco Franssen <marco.franssen@gmail.com> Signed-off-by: Edwin Buck <edwbuck@gmail.com>
Co-authored-by: Marco Franssen <marco.franssen@gmail.com> Signed-off-by: Edwin Buck <edwbuck@gmail.com>
Co-authored-by: Marco Franssen <marco.franssen@gmail.com> Signed-off-by: Edwin Buck <edwbuck@gmail.com>
Co-authored-by: Mariusz Sabath <mrsabath@gmail.com> Signed-off-by: Edwin Buck <edwbuck@gmail.com>
Signed-off-by: Edwin Buck <edwbuck@gmail.com>
Co-authored-by: Faisal Memon <fymemon@yahoo.com> Signed-off-by: Edwin Buck <edwbuck@gmail.com>
Co-authored-by: Faisal Memon <fymemon@yahoo.com> Signed-off-by: Edwin Buck <edwbuck@gmail.com>
Co-authored-by: Faisal Memon <fymemon@yahoo.com> Signed-off-by: Edwin Buck <edwbuck@gmail.com>
faisal-memon
approved these changes
May 15, 2023
|
The ci pipeline doesn't seem to be working.... |
|
What's going on with this commit? It seems to be stuck. |
This commit intends to have the checks rerun, as they seem to have been stuck due to the return values not being captured by the sign-off process. Signed-off-by: Edwin Buck <edwbuck@gmail.com>
|
This is a really well written document. Thank you @edwbuck ! |
Comment on lines
+11
to
+18
| Pull requests are submitted through GitHub. They are contributions to change | ||
| the project. There is no difference between code and non-code submissions, in | ||
| procedure or policy. | ||
|
|
||
| All maintainers should consider that pull requests are gifts. The project | ||
| survives due to the effort of frequent contributors and their generosity. As | ||
| such, to encourage future submissions, the default approach to handling a merge | ||
| request should be gratitude, even if the request cannot be merged. |
There was a problem hiding this comment.
Suggested change
| Pull requests are submitted through GitHub. They are contributions to change | |
| the project. There is no difference between code and non-code submissions, in | |
| procedure or policy. | |
| All maintainers should consider that pull requests are gifts. The project | |
| survives due to the effort of frequent contributors and their generosity. As | |
| such, to encourage future submissions, the default approach to handling a merge | |
| request should be gratitude, even if the request cannot be merged. | |
| Pull requests are submitted through GitHub. They are contributions to change | |
| the project. There is no difference between code and non-code submissions, in | |
| procedure or policy. | |
| All maintainers should consider that pull requests are gifts. The project | |
| survives due to the effort of frequent contributors and their generosity. As | |
| such, to encourage future submissions, the default approach to handling a merge | |
| request should be gratitude, even if the request cannot be merged. |
Comment on lines
+37
to
+40
| Committers are people contributing changes to the repository. The first | ||
| committer is typically the one that opens the pull request. Additional people | ||
| can become committers in the same merge request if they change the pull request | ||
| directly. |
There was a problem hiding this comment.
Suggested change
| Committers are people contributing changes to the repository. The first | |
| committer is typically the one that opens the pull request. Additional people | |
| can become committers in the same merge request if they change the pull request | |
| directly. | |
| Committers are people contributing changes to the repository. The first | |
| committer is typically the one that opens the pull request. Additional people | |
| can become committers in the same merge request if they change the pull request | |
| directly. |
Comment on lines
+48
to
+56
| Maintainers hold a dual role in the project. They are ambassadors of the | ||
| effort as well as the gatekeepers permitting changes to the repository. As | ||
| ambassadors, maintainers must present a fair and impartial demeanor when | ||
| dealing with contributors. | ||
|
|
||
| Failure to be fair or impartial reflects poorly on the released product, as | ||
| guilt by association taints the product. The process of reviewing a merge | ||
| request often includes conflict. Contributors can become defensive about work | ||
| they've done while maintainers can become adamant in the changes they request. |
There was a problem hiding this comment.
Suggested change
| Maintainers hold a dual role in the project. They are ambassadors of the | |
| effort as well as the gatekeepers permitting changes to the repository. As | |
| ambassadors, maintainers must present a fair and impartial demeanor when | |
| dealing with contributors. | |
| Failure to be fair or impartial reflects poorly on the released product, as | |
| guilt by association taints the product. The process of reviewing a merge | |
| request often includes conflict. Contributors can become defensive about work | |
| they've done while maintainers can become adamant in the changes they request. | |
| Maintainers hold a dual role in the project. They are ambassadors of the | |
| effort as well as the gatekeepers permitting changes to the repository. As | |
| ambassadors, maintainers must present a fair and impartial demeanor when | |
| dealing with contributors. | |
| Failure to be fair or impartial reflects poorly on the released product, as | |
| guilt by association taints the product. The process of reviewing a merge | |
| request often includes conflict. Contributors can become defensive about work | |
| they've done while maintainers can become adamant in the changes they request. |
Comment on lines
+58
to
+61
| To prevent a breakdown in the review process, the project encourages all | ||
| reviewers to adhere to a standard set of review best practices. Reviewers | ||
| should familiarize themselves with these practices and suggest updates to keep | ||
| the practices relevant over time. |
There was a problem hiding this comment.
Suggested change
| To prevent a breakdown in the review process, the project encourages all | |
| reviewers to adhere to a standard set of review best practices. Reviewers | |
| should familiarize themselves with these practices and suggest updates to keep | |
| the practices relevant over time. | |
| To prevent a breakdown in the review process, the project encourages all | |
| reviewers to adhere to a standard set of review best practices. Reviewers | |
| should familiarize themselves with these practices and suggest updates to keep | |
| the practices relevant over time. |
Comment on lines
+65
to
+73
| These standards serve to prevent problems from cropping up during a review. The | ||
| intent is that consistent application of these standards permits a consistent | ||
| review process, leading to repeatable, suprise free, outcomes during a review. | ||
|
|
||
| The intent of maintaining standards is to enhance productivity and improve team | ||
| morale. In the event the standards have a negative impact on productivity or | ||
| morale, the standard itself should be questioned. To clarify the kinds of | ||
| productivity to be improved, the intent is to reduce the time between initial | ||
| submission of a merge request and its resolution. |
There was a problem hiding this comment.
Suggested change
| These standards serve to prevent problems from cropping up during a review. The | |
| intent is that consistent application of these standards permits a consistent | |
| review process, leading to repeatable, suprise free, outcomes during a review. | |
| The intent of maintaining standards is to enhance productivity and improve team | |
| morale. In the event the standards have a negative impact on productivity or | |
| morale, the standard itself should be questioned. To clarify the kinds of | |
| productivity to be improved, the intent is to reduce the time between initial | |
| submission of a merge request and its resolution. | |
| These standards serve to prevent problems from cropping up during a review. The | |
| intent is that consistent application of these standards permits a consistent | |
| review process, leading to repeatable, suprise free, outcomes during a review. | |
| The intent of maintaining standards is to enhance productivity and improve team | |
| morale. In the event the standards have a negative impact on productivity or | |
| morale, the standard itself should be questioned. To clarify the kinds of | |
| productivity to be improved, the intent is to reduce the time between initial | |
| submission of a merge request and its resolution. |
Comment on lines
+77
to
+86
| Whenever possible, a maintainer should not argue a point about the review | ||
| standards with a contributor. Instead they should provide this document to the | ||
| contributor, indicating that changes to the review process are to be initiated | ||
| with a standard-altering Issue. | ||
|
|
||
| In the exceedingly rare situation that a reviewer opts to ignore a review | ||
| standard during a merge request, the reviewer must indicate they are purposefully | ||
| ignoring the standard and the reason why. There are valid reasons to ignore | ||
| standards, but whenever possible a maintainer should uphold the standard or | ||
| change it. |
There was a problem hiding this comment.
Suggested change
| Whenever possible, a maintainer should not argue a point about the review | |
| standards with a contributor. Instead they should provide this document to the | |
| contributor, indicating that changes to the review process are to be initiated | |
| with a standard-altering Issue. | |
| In the exceedingly rare situation that a reviewer opts to ignore a review | |
| standard during a merge request, the reviewer must indicate they are purposefully | |
| ignoring the standard and the reason why. There are valid reasons to ignore | |
| standards, but whenever possible a maintainer should uphold the standard or | |
| change it. | |
| Whenever possible, a maintainer should not argue a point about the review | |
| standards with a contributor. Instead they should provide this document to the | |
| contributor, indicating that changes to the review process are to be initiated | |
| with a standard-altering Issue. | |
| In the exceedingly rare situation that a reviewer opts to ignore a review | |
| standard during a merge request, the reviewer must indicate they are purposefully | |
| ignoring the standard and the reason why. There are valid reasons to ignore | |
| standards, but whenever possible a maintainer should uphold the standard or | |
| change it. |
Comment on lines
+105
to
+112
| Maintainers should set aside and appropriate amount of time when reviewing. The | ||
| initial suggestion is one hour. Most reviews will complete well under this time, | ||
| but a few will take longer. Longer reviews should include review breaks, so the | ||
| reviewer remains fresh and attentive. Attempting a three hour long review often | ||
| yields worse results than two or three shorter efforts with breaks. | ||
|
|
||
| The concept of going slow to complete items quickly is not a new one. With a | ||
| little extra time, comments can be thoughtful instead of reactive. |
There was a problem hiding this comment.
Suggested change
| Maintainers should set aside and appropriate amount of time when reviewing. The | |
| initial suggestion is one hour. Most reviews will complete well under this time, | |
| but a few will take longer. Longer reviews should include review breaks, so the | |
| reviewer remains fresh and attentive. Attempting a three hour long review often | |
| yields worse results than two or three shorter efforts with breaks. | |
| The concept of going slow to complete items quickly is not a new one. With a | |
| little extra time, comments can be thoughtful instead of reactive. | |
| Maintainers should set aside and appropriate amount of time when reviewing. The | |
| initial suggestion is one hour. Most reviews will complete well under this time, | |
| but a few will take longer. Longer reviews should include review breaks, so the | |
| reviewer remains fresh and attentive. Attempting a three hour long review often | |
| yields worse results than two or three shorter efforts with breaks. | |
| The concept of going slow to complete items quickly is not a new one. With a | |
| little extra time, comments can be thoughtful instead of reactive. |
Comment on lines
+116
to
+119
| Each review should have a defined set of goals established prior to the main | ||
| work of the review. The review process often challenges the committer, in the | ||
| hopes of improving the merge request. Keeping the review scoped to goals avoids | ||
| scenarios where the reviewer's requests seem capricious or autocratic. |
There was a problem hiding this comment.
Suggested change
| Each review should have a defined set of goals established prior to the main | |
| work of the review. The review process often challenges the committer, in the | |
| hopes of improving the merge request. Keeping the review scoped to goals avoids | |
| scenarios where the reviewer's requests seem capricious or autocratic. | |
| Each review should have a defined set of goals established prior to the main | |
| work of the review. The review process often challenges the committer, in the | |
| hopes of improving the merge request. Keeping the review scoped to goals avoids | |
| scenarios where the reviewer's requests seem capricious or autocratic. |
Comment on lines
+142
to
+153
| Each submission should assume that the committer ran the unit tests and | ||
| small-scale (not requiring an environment) integration tests prior to submission. | ||
| The merge request CI pipeline also runs these tests automatically. Failure to | ||
| pass them leads to an automatic call for merge request modification. | ||
|
|
||
| Attempts to pass this requirement by disabling tests or modifying them such that | ||
| they are effectively disabled are strongly discouraged. They violate the review | ||
| goals by reducing maintainability (no new failures will be detected) and | ||
| possibly functionality (for scenarios outside of the current mindset). | ||
|
|
||
| At their leisure, maintainers may suggest code changes make the test suite pass. | ||
| Doing so is never required, nor part of the minimum duties of a maintainer. |
There was a problem hiding this comment.
Suggested change
| Each submission should assume that the committer ran the unit tests and | |
| small-scale (not requiring an environment) integration tests prior to submission. | |
| The merge request CI pipeline also runs these tests automatically. Failure to | |
| pass them leads to an automatic call for merge request modification. | |
| Attempts to pass this requirement by disabling tests or modifying them such that | |
| they are effectively disabled are strongly discouraged. They violate the review | |
| goals by reducing maintainability (no new failures will be detected) and | |
| possibly functionality (for scenarios outside of the current mindset). | |
| At their leisure, maintainers may suggest code changes make the test suite pass. | |
| Doing so is never required, nor part of the minimum duties of a maintainer. | |
| Each submission should assume that the committer ran the unit tests and | |
| small-scale (not requiring an environment) integration tests prior to submission. | |
| The merge request CI pipeline also runs these tests automatically. Failure to | |
| pass them leads to an automatic call for merge request modification. | |
| Attempts to pass this requirement by disabling tests or modifying them such that | |
| they are effectively disabled are strongly discouraged. They violate the review | |
| goals by reducing maintainability (no new failures will be detected) and | |
| possibly functionality (for scenarios outside of the current mindset). | |
| At their leisure, maintainers may suggest code changes make the test suite pass. | |
| Doing so is never required, nor part of the minimum duties of a maintainer. |
|
|
||
| The amount of possible communication grows such that | ||
| `commChannels(reviewers) = reviewers + reviewers(reviewers-1)/2` leads to an | ||
| `O(n^2)` number of channels. Thus, keeping reviewer count low is critical to |
There was a problem hiding this comment.
Suggested change
| `O(n^2)` number of channels. Thus, keeping reviewer count low is critical to | |
| `O(n^2)` number of channels. Thus, keeping reviewer count low is critical to |
Comment on lines
+178
to
+197
| Reviewers should coordinate among themselves when differences of opinion arise | ||
| in a review. The first reviewer is likely to make a statement before being | ||
| aware of the difference of opinion; but, once a difference of opinion is known, | ||
| the reviewers should coordinate privately to find a unified presentation of the | ||
| desired features to communicate back to the committer. | ||
|
|
||
| The committer has no role in the evaluation of options to determine the proper | ||
| path forward, including them only diminishes the efficiency of the process and | ||
| increases the stress they endure while they observe the discussion. Once a path | ||
| is agreed upon: | ||
|
|
||
| - If the request to the committer was reversed, the reviewer making that stance | ||
| should present the new path. | ||
| - If the request to the committer was refined, the second reviewer should | ||
| present the refined path. | ||
|
|
||
| If no path forward can be agreed upon, the proposed path that is closest to the | ||
| committer submission is the accepted path. This guideline exists to promote | ||
| cooperation among reviewers. Ideas of merit which don't become part of the | ||
| merge request should be submitted as new issues and reviewed independently. |
There was a problem hiding this comment.
Suggested change
| Reviewers should coordinate among themselves when differences of opinion arise | |
| in a review. The first reviewer is likely to make a statement before being | |
| aware of the difference of opinion; but, once a difference of opinion is known, | |
| the reviewers should coordinate privately to find a unified presentation of the | |
| desired features to communicate back to the committer. | |
| The committer has no role in the evaluation of options to determine the proper | |
| path forward, including them only diminishes the efficiency of the process and | |
| increases the stress they endure while they observe the discussion. Once a path | |
| is agreed upon: | |
| - If the request to the committer was reversed, the reviewer making that stance | |
| should present the new path. | |
| - If the request to the committer was refined, the second reviewer should | |
| present the refined path. | |
| If no path forward can be agreed upon, the proposed path that is closest to the | |
| committer submission is the accepted path. This guideline exists to promote | |
| cooperation among reviewers. Ideas of merit which don't become part of the | |
| merge request should be submitted as new issues and reviewed independently. | |
| Reviewers should coordinate among themselves when differences of opinion arise | |
| in a review. The first reviewer is likely to make a statement before being | |
| aware of the difference of opinion; but, once a difference of opinion is known, | |
| the reviewers should coordinate privately to find a unified presentation of the | |
| desired features to communicate back to the committer. | |
| The committer has no role in the evaluation of options to determine the proper | |
| path forward, including them only diminishes the efficiency of the process and | |
| increases the stress they endure while they observe the discussion. Once a path | |
| is agreed upon: | |
| - If the request to the committer was reversed, the reviewer making that stance | |
| should present the new path. | |
| - If the request to the committer was refined, the second reviewer should | |
| present the refined path. | |
| If no path forward can be agreed upon, the proposed path that is closest to the | |
| committer submission is the accepted path. This guideline exists to promote | |
| cooperation among reviewers. Ideas of merit which don't become part of the | |
| merge request should be submitted as new issues and reviewed independently. |
azdagron
reviewed
May 16, 2023
|
|
||
| Suggestions to a committer by a maintainer, such as commentary that with a | ||
| change the merge request might be accepted, does not make a maintainer a | ||
| committer, as the committer will choose include the change at their discretion. |
There was a problem hiding this comment.
Suggested change
| committer, as the committer will choose include the change at their discretion. | |
| committer, as the committer will choose to include the change at their discretion. |
| goals by reducing maintainability (no new failures will be detected) and | ||
| possibly functionality (for scenarios outside of the current mindset). | ||
|
|
||
| At their leisure, maintainers may suggest code changes make the test suite pass. |
There was a problem hiding this comment.
Suggested change
| At their leisure, maintainers may suggest code changes make the test suite pass. | |
| At their leisure, maintainers may suggest code changes to make the test suite pass. |
faisal-memon
added a commit
that referenced
this pull request
May 16, 2023
This reverts commit 2669d8b.
|
🤦 Merged with comments outstanding. |
marcofranssen
added a commit
that referenced
this pull request
May 25, 2023
* c1c5b11 Merge pull request #306 from spiffe/remove-1.21 * 0df45e3 Fix up docs * ed038fe Upgrade to spire 1.6.4 (#308) * dc5d9cf Fix root README.md * e4447fd Upgrade Tornjak to new image v1.2.1 (#299) * 69f402e Update docs * 38d51d5 Apply suggestions from code review * a1ba235 Update docs * 1922085 Fix hooks for K3s (#305) * 4fb549e Remove 1.21.x testing * 88efc77 Allow to use spire-server as an upstream authority (#304) * 0ba0388 Add support for spire-server ingress (#68) * 4777a30 Bump test chart dependencies (#301) * 00c2c1a Fix the generated pr so that it runs jobs too (#303) * dd1ad49 Update images for cve's found by the cronjob (#290) * 1c69470 Updated Tornjak documenation with Not-for-production labels (#297) * 7809637 Merge pull request #296 from spiffe/dependabot/github_actions/helm/kind-action-1.7.0 * e61ed17 Merge pull request #295 from spiffe/dependabot/github_actions/sigstore/cosign-installer-3.0.5 * 9975e58 Merge pull request #245 from spiffe/tags * 7bb7ece Bump helm/kind-action from 1.6.0 to 1.7.0 * f1623a5 Bump sigstore/cosign-installer from 3.0.4 to 3.0.5 * f8db5a3 Fix Tornjak persistence issue (#294) * b30b412 Tornjak reuse spire-lib.cluster-domain macro (#292) * 90c9eb5 Fix kubectl-image macro to handle version deprecation * 300d1cc Apply deprecation of image.version to Tornjak * d850486 Instead of removing version, first deprecate version * 59e422b Add documentation for all image.tag values * d1f3cdb Switch image.version to image.tag * 31ce704 Cleanup maintainer handbook (#287) * a2da943 Remove manual dispatch from dummy workflow (#288) * 807558b Bump helm/kind-action from 1.5.0 to 1.6.0 (#285) * 3df67db Bump sigstore/cosign-installer from 3.0.3 to 3.0.4 (#286) * 5505d41 Merge pull request #283 from spiffe/additional-k8s-native-feature-tornjak-frontend * 391f093 Allow to configure topologySpreadConstraints for tornjak-frontend * 5cc26d3 Allow to configure tolerations for tornjak-frontend * 3537161 Allow to configure affinity for tornjak-frontend * aed6fdf Use the correct kubectl for the cluster (#248) * ee43c5e Add nodeSelector for tornjak * fc13cbd Merge pull request #234 from spiffe/tornjak * ed472aa Update documentation * a11cfc9 Allow to define the resources for tornjak backend * 382e0d4 Upgrade Tornjak image to version v1.2.0 (#259) * 657c460 Update charts/spire/charts/tornjak-frontend/templates/service.yaml * 7521caf Update charts/spire/charts/spire-server/templates/tornjak-config.yaml * b64c352 Update charts/spire/charts/spire-server/templates/tests/test-tornjak-connection.yaml * 6ddf6ab Improve tornjak docs (#276) * 80d34f0 Use common post-install scripts for testing * f5efa0c Remove dead macros * bd86518 Fixing shellcheck * 91bdea2 Provide minimal resources to prevent accidental crashes due to resource exhaustion * 1675997 Tornjak global image fix (#228) * 5e827ee Add Tornjak Tests (#220) * bdba97b Add empty directory to Tornjak to support npm cache (#224) * da186c5 Split Tornjak Frontend into separate subchart (#179) * 6d22126 Add Tornjak * 2669d8b Add maintainer's handbook. (#265) * 72596ae Skip tests for docs folders (#281) * 7c71738 Bump test chart dependencies (#279) * 05addae Add json to test path (#280) * 8d9b734 Switch the spire tests to always run (#250) Signed-off-by: Marco Franssen <marco.franssen@gmail.com>
marcofranssen
added a commit
that referenced
this pull request
May 25, 2023
* c1c5b11 Merge pull request #306 from spiffe/remove-1.21 * 0df45e3 Fix up docs * ed038fe Upgrade to spire 1.6.4 (#308) * dc5d9cf Fix root README.md * e4447fd Upgrade Tornjak to new image v1.2.1 (#299) * 69f402e Update docs * 38d51d5 Apply suggestions from code review * a1ba235 Update docs * 1922085 Fix hooks for K3s (#305) * 4fb549e Remove 1.21.x testing * 88efc77 Allow to use spire-server as an upstream authority (#304) * 0ba0388 Add support for spire-server ingress (#68) * 4777a30 Bump test chart dependencies (#301) * 00c2c1a Fix the generated pr so that it runs jobs too (#303) * dd1ad49 Update images for cve's found by the cronjob (#290) * 1c69470 Updated Tornjak documenation with Not-for-production labels (#297) * 7809637 Merge pull request #296 from spiffe/dependabot/github_actions/helm/kind-action-1.7.0 * e61ed17 Merge pull request #295 from spiffe/dependabot/github_actions/sigstore/cosign-installer-3.0.5 * 9975e58 Merge pull request #245 from spiffe/tags * 7bb7ece Bump helm/kind-action from 1.6.0 to 1.7.0 * f1623a5 Bump sigstore/cosign-installer from 3.0.4 to 3.0.5 * f8db5a3 Fix Tornjak persistence issue (#294) * b30b412 Tornjak reuse spire-lib.cluster-domain macro (#292) * 90c9eb5 Fix kubectl-image macro to handle version deprecation * 300d1cc Apply deprecation of image.version to Tornjak * d850486 Instead of removing version, first deprecate version * 59e422b Add documentation for all image.tag values * d1f3cdb Switch image.version to image.tag * 31ce704 Cleanup maintainer handbook (#287) * a2da943 Remove manual dispatch from dummy workflow (#288) * 807558b Bump helm/kind-action from 1.5.0 to 1.6.0 (#285) * 3df67db Bump sigstore/cosign-installer from 3.0.3 to 3.0.4 (#286) * 5505d41 Merge pull request #283 from spiffe/additional-k8s-native-feature-tornjak-frontend * 391f093 Allow to configure topologySpreadConstraints for tornjak-frontend * 5cc26d3 Allow to configure tolerations for tornjak-frontend * 3537161 Allow to configure affinity for tornjak-frontend * aed6fdf Use the correct kubectl for the cluster (#248) * ee43c5e Add nodeSelector for tornjak * fc13cbd Merge pull request #234 from spiffe/tornjak * ed472aa Update documentation * a11cfc9 Allow to define the resources for tornjak backend * 382e0d4 Upgrade Tornjak image to version v1.2.0 (#259) * 657c460 Update charts/spire/charts/tornjak-frontend/templates/service.yaml * 7521caf Update charts/spire/charts/spire-server/templates/tornjak-config.yaml * b64c352 Update charts/spire/charts/spire-server/templates/tests/test-tornjak-connection.yaml * 6ddf6ab Improve tornjak docs (#276) * 80d34f0 Use common post-install scripts for testing * f5efa0c Remove dead macros * bd86518 Fixing shellcheck * 91bdea2 Provide minimal resources to prevent accidental crashes due to resource exhaustion * 1675997 Tornjak global image fix (#228) * 5e827ee Add Tornjak Tests (#220) * bdba97b Add empty directory to Tornjak to support npm cache (#224) * da186c5 Split Tornjak Frontend into separate subchart (#179) * 6d22126 Add Tornjak * 2669d8b Add maintainer's handbook. (#265) * 72596ae Skip tests for docs folders (#281) * 7c71738 Bump test chart dependencies (#279) * 05addae Add json to test path (#280) * 8d9b734 Switch the spire tests to always run (#250) Signed-off-by: Marco Franssen <marco.franssen@gmail.com>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The maintainer's handbook is a guide to remind the maintainers of the values and approaches that most maintainers already hold.
Specifics of code quality will come later, but putting them into this document would make it too long, and thus unread.
Closes #263