From ca15a09df5b74144feed90c3b1ce9f79334aa429 Mon Sep 17 00:00:00 2001 From: Andrew Roth Date: Fri, 8 Oct 2021 10:31:02 -0700 Subject: [PATCH 1/8] wip --- CONTRIBUTING.md | 7 +++++++ 1 file changed, 7 insertions(+) create mode 100644 CONTRIBUTING.md diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md new file mode 100644 index 0000000000..ebcc1765a8 --- /dev/null +++ b/CONTRIBUTING.md @@ -0,0 +1,7 @@ +# Contributing to Zarf + +First off, thanks so much for wanting to help out! :tada: + +The following is a set of guidelines for contributing to Zarf. These are mostly guidelines, not rules. Use your best judgement, and feel free to propose changes to this document in a pull request. + +## Testing \ No newline at end of file From ad9064420eac8bcd365262b9ab9fd7a48baf4178 Mon Sep 17 00:00:00 2001 From: Andrew Roth Date: Fri, 8 Oct 2021 11:35:23 -0700 Subject: [PATCH 2/8] wip --- CONTRIBUTING.md | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index ebcc1765a8..388b90bad5 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,4 +4,12 @@ First off, thanks so much for wanting to help out! :tada: The following is a set of guidelines for contributing to Zarf. These are mostly guidelines, not rules. Use your best judgement, and feel free to propose changes to this document in a pull request. -## Testing \ No newline at end of file +## Developer Workflow + +Continuous Delivery is core to our development philosophy. Check out [https://minimumcd.org](https://minimumcd.org/) for a good baseline agreement on what that means. + +Specifically: + +- We do trunk-based development with short-lived feature branches that originate from the trunk, get merged to the trunk, and are deleted after the merge +- We perform automated testing on all changes before they get merged to the trunk +- \ No newline at end of file From b738d5e09bfa1ae17bd94a76df37a537111550f4 Mon Sep 17 00:00:00 2001 From: Andrew Roth Date: Fri, 8 Oct 2021 15:24:45 -0700 Subject: [PATCH 3/8] wip --- CONTRIBUTING.md | 21 +++++++++++++++++++-- 1 file changed, 19 insertions(+), 2 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 388b90bad5..7e300bff57 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -4,12 +4,29 @@ First off, thanks so much for wanting to help out! :tada: The following is a set of guidelines for contributing to Zarf. These are mostly guidelines, not rules. Use your best judgement, and feel free to propose changes to this document in a pull request. -## Developer Workflow +## Developer Experience Continuous Delivery is core to our development philosophy. Check out [https://minimumcd.org](https://minimumcd.org/) for a good baseline agreement on what that means. Specifically: - We do trunk-based development with short-lived feature branches that originate from the trunk, get merged to the trunk, and are deleted after the merge +- We don't merge code into the trunk that isn't releasable - We perform automated testing on all changes before they get merged to the trunk -- \ No newline at end of file +- We create immutable release artifacts + +### Developer Workflow + +Here's what a typical "day in the life" of a Zarf developer might look like. Keep in mind that other than things that are required through automation these aren't hard-and-fast rules. When in doubt, the process outlined here works for us. + +1. Pick an outstanding issue to work on, set yourself as the assignee, and move it to "Now" in the [Roadmap](https://github.com/defenseunicorns/zarf/projects/1). The "Next" and "Later" columns are mostly prioritized according to feedback from our users and other inputs, but don't feel like you have to pick from the top of the pile if something else is jumping out at you. +1. Write up a rough outline of what you plan to do in the issue so you can get early feedback. Clearly announce any breaking changes you think need to be made. +1. Required: Set up your Git config to GPG sign all commits. [Here's some documentation on how to set it up](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). You won't be able to merge your PR if you have any unverified commits. +1. Required: Create a branch off the trunk, or a fork if you don't have the right permissions to push a branch. +1. Create a Draft Pull Request as soon as you are able to, even if it is just 5 minutes after you started working on it. Around here we aren't afraid to show unfinished work. It helps us get feedback more quickly. +1. Required: Create a Pull Request (or mark it Ready for Review if you've been working in a Draft PR). +1. Required: Run all automated tests by adding `/test all` as a comment in the PR. If you want to re-run certain tests you can also run them individually. Example: `/test e2e` just runs the end-to-end tests. You can chain different tests together like `/test foo bar baz` +1. Clearly announce any breaking changes that have been made. +1. Required: Get at least 1 peer-review approval. +1. Required: Merge the PR into the trunk. We tend to prefer "Squash and Merge" but if your commits are on-point and you want to preserve them in the Git history of the trunk that's fine too. +1. Delete the branch \ No newline at end of file From c85f260c56d558b83097509579bf8cf12a0929de Mon Sep 17 00:00:00 2001 From: Andrew Roth Date: Fri, 8 Oct 2021 15:30:42 -0700 Subject: [PATCH 4/8] wip --- CONTRIBUTING.md | 12 ++++++------ 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 7e300bff57..1c0c31617d 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -21,12 +21,12 @@ Here's what a typical "day in the life" of a Zarf developer might look like. Kee 1. Pick an outstanding issue to work on, set yourself as the assignee, and move it to "Now" in the [Roadmap](https://github.com/defenseunicorns/zarf/projects/1). The "Next" and "Later" columns are mostly prioritized according to feedback from our users and other inputs, but don't feel like you have to pick from the top of the pile if something else is jumping out at you. 1. Write up a rough outline of what you plan to do in the issue so you can get early feedback. Clearly announce any breaking changes you think need to be made. -1. Required: Set up your Git config to GPG sign all commits. [Here's some documentation on how to set it up](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). You won't be able to merge your PR if you have any unverified commits. -1. Required: Create a branch off the trunk, or a fork if you don't have the right permissions to push a branch. +1. :key: Set up your Git config to GPG sign all commits. [Here's some documentation on how to set it up](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). You won't be able to merge your PR if you have any unverified commits. +1. :key: Create a branch off the trunk, or a fork if you don't have the right permissions to push a branch. 1. Create a Draft Pull Request as soon as you are able to, even if it is just 5 minutes after you started working on it. Around here we aren't afraid to show unfinished work. It helps us get feedback more quickly. -1. Required: Create a Pull Request (or mark it Ready for Review if you've been working in a Draft PR). -1. Required: Run all automated tests by adding `/test all` as a comment in the PR. If you want to re-run certain tests you can also run them individually. Example: `/test e2e` just runs the end-to-end tests. You can chain different tests together like `/test foo bar baz` +1. :key: Create a Pull Request (or mark it Ready for Review if you've been working in a Draft PR). +1. :key: Run all automated tests by adding `/test all` as a comment in the PR. If you want to re-run certain tests you can also run them individually. Example: `/test e2e` just runs the end-to-end tests. You can chain different tests together like `/test foo bar baz` 1. Clearly announce any breaking changes that have been made. -1. Required: Get at least 1 peer-review approval. -1. Required: Merge the PR into the trunk. We tend to prefer "Squash and Merge" but if your commits are on-point and you want to preserve them in the Git history of the trunk that's fine too. +1. :key: Get at least 1 peer-review approval. +1. :key: Merge the PR into the trunk. We tend to prefer "Squash and Merge" but if your commits are on-point and you want to preserve them in the Git history of the trunk that's fine too. 1. Delete the branch \ No newline at end of file From 6002f7d145428af1dd296f2eacaf7bc5170959f8 Mon Sep 17 00:00:00 2001 From: Andrew Roth Date: Fri, 8 Oct 2021 15:31:34 -0700 Subject: [PATCH 5/8] wip --- CONTRIBUTING.md | 2 ++ 1 file changed, 2 insertions(+) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1c0c31617d..0da3569374 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -19,6 +19,8 @@ Specifically: Here's what a typical "day in the life" of a Zarf developer might look like. Keep in mind that other than things that are required through automation these aren't hard-and-fast rules. When in doubt, the process outlined here works for us. +:key: == Required by automation + 1. Pick an outstanding issue to work on, set yourself as the assignee, and move it to "Now" in the [Roadmap](https://github.com/defenseunicorns/zarf/projects/1). The "Next" and "Later" columns are mostly prioritized according to feedback from our users and other inputs, but don't feel like you have to pick from the top of the pile if something else is jumping out at you. 1. Write up a rough outline of what you plan to do in the issue so you can get early feedback. Clearly announce any breaking changes you think need to be made. 1. :key: Set up your Git config to GPG sign all commits. [Here's some documentation on how to set it up](https://docs.github.com/en/authentication/managing-commit-signature-verification/signing-commits). You won't be able to merge your PR if you have any unverified commits. From 9f1756dbc3efd03e8fcb32dab9bec702f366eb2c Mon Sep 17 00:00:00 2001 From: Andrew Roth Date: Fri, 8 Oct 2021 15:42:25 -0700 Subject: [PATCH 6/8] wip --- CONTRIBUTING.md | 21 ++++++++++++++++++++- 1 file changed, 20 insertions(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 0da3569374..e5bdb554e8 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -31,4 +31,23 @@ Here's what a typical "day in the life" of a Zarf developer might look like. Kee 1. Clearly announce any breaking changes that have been made. 1. :key: Get at least 1 peer-review approval. 1. :key: Merge the PR into the trunk. We tend to prefer "Squash and Merge" but if your commits are on-point and you want to preserve them in the Git history of the trunk that's fine too. -1. Delete the branch \ No newline at end of file +1. Delete the branch +1. Close the issue if it got fully resolved by your PR. *Hint: You can add "Fixes #XX" to the PR description to automatically close an issue when the PR is merged.* + +## Testing + +This section dives deeper into how we test Zarf + +### End2End Testing + +Our E2E tests utilize [Terratest](https://terratest.gruntwork.io/). They create real infrastructure in AWS that the tests get run on. By doing this we are able to make the test environments ephemeral and allow them to be run in parallel so that we can do more testing more quickly. + +The Terratest E2E tests can be found in the `/test` folder. + +We're still working on building out the test suite. If you want to help check out these issues: + +- #97: Make our own test harness container +- #99: Writing additional tests +- #100: Each test should be runnable locally +- #101: Run E2E tests on multiple distros +- #102: Make the E2E tests more efficient \ No newline at end of file From 40943c084ff0ea33cbff02df8fa4de453c5c8052 Mon Sep 17 00:00:00 2001 From: Andrew Roth Date: Fri, 8 Oct 2021 15:48:40 -0700 Subject: [PATCH 7/8] wip --- CONTRIBUTING.md | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index e5bdb554e8..1be3136dfc 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -27,7 +27,7 @@ Here's what a typical "day in the life" of a Zarf developer might look like. Kee 1. :key: Create a branch off the trunk, or a fork if you don't have the right permissions to push a branch. 1. Create a Draft Pull Request as soon as you are able to, even if it is just 5 minutes after you started working on it. Around here we aren't afraid to show unfinished work. It helps us get feedback more quickly. 1. :key: Create a Pull Request (or mark it Ready for Review if you've been working in a Draft PR). -1. :key: Run all automated tests by adding `/test all` as a comment in the PR. If you want to re-run certain tests you can also run them individually. Example: `/test e2e` just runs the end-to-end tests. You can chain different tests together like `/test foo bar baz` +1. :key: Run all automated tests by adding `/test all` as a comment in the PR. If you want to re-run certain tests you can also run them individually. Example: `/test e2e` just runs the end-to-end tests. You can chain different tests together like `/test foo bar baz`. You need `write` permission to the repo to trigger the tests. 1. Clearly announce any breaking changes that have been made. 1. :key: Get at least 1 peer-review approval. 1. :key: Merge the PR into the trunk. We tend to prefer "Squash and Merge" but if your commits are on-point and you want to preserve them in the Git history of the trunk that's fine too. From 37f20841c164461cc55854d184200097ee5a62b6 Mon Sep 17 00:00:00 2001 From: Andrew Roth Date: Fri, 8 Oct 2021 15:51:23 -0700 Subject: [PATCH 8/8] wip --- CONTRIBUTING.md | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/CONTRIBUTING.md b/CONTRIBUTING.md index 1be3136dfc..771ccf0b02 100644 --- a/CONTRIBUTING.md +++ b/CONTRIBUTING.md @@ -46,8 +46,8 @@ The Terratest E2E tests can be found in the `/test` folder. We're still working on building out the test suite. If you want to help check out these issues: -- #97: Make our own test harness container -- #99: Writing additional tests -- #100: Each test should be runnable locally -- #101: Run E2E tests on multiple distros -- #102: Make the E2E tests more efficient \ No newline at end of file +- [#97](https://github.com/defenseunicorns/zarf/issues/97): Make our own test harness container +- [#99](https://github.com/defenseunicorns/zarf/issues/99): Writing additional tests +- [#100](https://github.com/defenseunicorns/zarf/issues/100): Each test should be runnable locally +- [#101](https://github.com/defenseunicorns/zarf/issues/101): Run E2E tests on multiple distros +- [#102](https://github.com/defenseunicorns/zarf/issues/102): Make the E2E tests more efficient \ No newline at end of file