New version and updated docs

README.md

@@ -71,8 +71,27 @@ Documentation is available on [docs.stepci.com](https://docs.stepci.com)
 
 You can find example workflows under [`examples/`](examples/)
 
+## Community
+
+Join our community on [GitHub Discussions](https://github.com/stepci/stepci/discussions)
+
+## Contributing
+
+As an open-source project, we welcome contributions from the community. If you are experiencing any bugs or want to add some improvements, please feel free to open an issue or pull request
+
 ## License
 
 The source code is distributed under Mozilla Public License terms
 
-## [Privacy](https://docs.stepci.com/legal/privacy)
+## Privacy
+
+By default, the CLI collects anonymous usage data, which includes:
+
+- Unique user ID
+- OS Name
+- Node Version
+- CLI Version
+- Command (`stepci run`, `stepci generate`)
+- Environment (Local, Docker, CI/CD)
+
+> **Note**: The usage analytics can be disabled by setting `STEPCI_DISABLE_ANALYTICS` environment variable

docs/.vitepress/config.js

@@ -21,9 +21,14 @@ export default {
       pattern: 'https://github.com/stepci/stepci/edit/main/docs/:path',
       text: 'Edit this page on GitHub'
     },
+    algolia: {
+      appId: 'BGFVFFQ7D3',
+      apiKey: '3edb499a6cb1b332569b42cd4e44da82',
+      indexName: 'stepci'
+    },
     sidebar: [
       {
-        text: 'Guides',
+        text: 'Learn',
         items: [
           { text: 'Introduction', link: '/' },
           { text: 'Getting Started', link: '/guides/getting-started' },
@@ -37,7 +42,7 @@ export default {
           { text: 'Load Testing <span class="badge-new">New</span>', link: '/guides/load-testing' },
           { text: 'Fuzz Testing', link: '/guides/fuzz-testing' },
           { text: 'CO<sub>2</sub> Testing', link: '/guides/co2-testing' },
-          { text: 'Organising Tests', link: '/guides/organising-tests' },
+          { text: 'Organising Workflows', link: '/guides/organising-workflows' },
           { text: 'Using as a Library', link: '/guides/using-library' },
         ]
       },
@@ -52,8 +57,9 @@ export default {
         items: [
           { text: 'Using the CLI', link: '/reference/cli' },
           { text: 'Workflow Syntax', link: '/reference/workflow-syntax' },
-          { text: 'Using Matchers', link: '/reference/matchers' },
           { text: 'Templating', link: '/reference/templating' },
+          { text: 'Matchers', link: '/reference/matchers' },
+          { text: 'Reusables', link: '/reference/reusables' },
           { text: 'Examples', link: '/reference/examples' },
         ]
       },

docs/.vitepress/theme/custom.css

@@ -10,6 +10,7 @@
   --vp-c-bg-alt: #141414;
   --vp-c-bg: #181818;
   --vp-code-block-bg: #141414;
+  --docsearch-hit-active-color: black;
 }
 
 .dark .VPImage.logo {
@@ -46,6 +47,6 @@
 
 @media (min-width: 960px) {
   .dark .VPNavBar.has-sidebar .content {
-    background-color: rgba(24, 24, 24, 0.95) !important;
+    background-color: rgba(24, 24, 24, 0.7) !important;
   }
 }

docs/guides/concepts.md

@@ -2,28 +2,28 @@
 
 ### Workflows
 
-Workflows contain meta information, tests and configuration
+Workflows contain meta information, tests and default configuration
 
 ### Tests
 
-Tests describe different test suites. Tests can have multiple steps. Tests are executed concurrently. Each test has a separate context, shared accross steps
+Tests describe different test suites. Tests can have multiple steps. Tests are executed concurrently. Each test has a separate context, shared across steps
 
 ### Steps
 
-Steps are the instructions to be executed by the runner. Steps contain the request parameters and assertions. Steps are executed in a sequence. If one step fails, all the following steps are skipped. Steps have access to shared context
-
-### Checks
-
-Steps can have many different checks to validate responses
+Steps are the instructions to be executed by the runner. Steps contain the request parameters, captures and checks. Steps are executed in a sequence. If one step fails, all the following steps are skipped. Steps have access to shared context
 
 ### Captures
 
-Steps can capture data from responses into named variables
+Steps can specify captures to capture data from responses into named variables that can later be used in consequent requests. Also known as "request chaining"
 
-### Conditions
+### Checks
 
-Steps can be skipped if a condition is not met
+Steps can include checks to validate responses
 
 ### Matchers
 
-Matchers can match values against a pre-defined set of rules
+Matchers can be used to match values against a pre-defined set of rules
+
+### Reusables
+
+Reusables allow you to reuse content such as schemas and credentials without repetition

docs/guides/fuzz-testing.md

@@ -1,5 +1,9 @@
 # Fuzz Testing
 
+Fuzz Testing is a type of testing, that involves providing unexpected or invalid input to an API in order to test its robustness and identify any potential vulnerabilities
+
+The goal of API fuzz testing is to simulate attacks on the API in order to uncover any security weaknesses that may exist
+
 You can utilise the [templating](/reference/templating) functionality combined with `naughtystring` filter to replace a placeholder value with a "naughty" string
 
 ::: info

docs/guides/load-testing.md

@@ -1,6 +1,8 @@
 # Load Testing
 
-Load Testing is a process of ensuring your API performs as expected during a typical and peak load
+Load Testing is a process of ensuring your API performs as expected during a typical and peak load without breaking or becoming unresponsive
+
+The goal of API load testing is typically to identify potential bottlenecks or issues that may arise when the API is used at scale, and to provide information that can be used to optimize the API for better performance
 
 ::: warning
 This feature is currently in preview. Some things may break or change in the future
@@ -51,6 +53,10 @@ This feature is currently in preview. Some things may break or change in the fut
 
     Your load test can have multiple phases. Each phase has a `duration`, which defines how long a phase lasts and an `arrivalRate`, which sets how many virtual visitors (or requests) arrive per second during the duration of a phase
 
+    :::warning
+    By default, the test runner will skip subsequent steps after the previous ones have failed. Add `continueOnFail` configuration option to your test or your workflow if you want to continue test execution after a failed step
+    :::
+
 3. Add (optional) checks
 
     **loadtest.yml**

docs/guides/organising-tests.md → docs/guides/organising-workflows.md

@@ -1,4 +1,4 @@
-# Organising Tests
+# Organising Workflows
 
 ## Splitting tests into multiple files
 

docs/guides/testing-graphql.md

@@ -1,8 +1,10 @@
 # Testing GraphQL APIs
 
-[GraphQL](https://graphql.org) is a query language for APIs and a runtime for fulfilling those queries with your existing data
+[GraphQL](https://graphql.org) is a query language used to access and manipulate data in APIs
 
-We have added useful helpers to reduce the burden for testing GraphQL-powered APIs with our tool
+Testing such APIs would involve ensuring that they function properly and that they can effectively retrieve and manipulate data using GraphQL queries
+
+This typically involves sending requests to the API and examining the responses to ensure that they are correct and meet the expectations of the developer
 
 **Example: GraphQL Query**
 
@@ -28,6 +30,6 @@ tests:
               $.data.method: POST
 ```
 
-:::info
-See [Workflow Syntax Reference](/reference/workflow-syntax#tests-test-steps-step-http-graphql) for more request options
+:::tip
+See [Testing HTTP APIs](/guides/testing-http) for the full guide on testing HTTP-based APIs
 :::