added versioning to syllabus and added Release 1.0.1 to the versioned docs

Signed-off-by: René <snooz@posteo.de>

Author: Snooz82

.github/workflows/pr-preview-surge.yml

@@ -64,7 +64,7 @@ jobs:
         run: npm ci
 
       - name: Build
-        run: npm run build
+        run: npm run build:preview
 
       - name: Upload build artifact
         uses: actions/upload-artifact@v4

.github/workflows/release-pages.yml

@@ -31,7 +31,7 @@ jobs:
 
       - name: Build website
         working-directory: ./website
-        run: npm run build
+        run: npm run build:production
 
       - name: Deploy to gh-pages
         uses: peaceiris/actions-gh-pages@v3

website/README.md

@@ -30,6 +30,20 @@ $ npm run build
 
 This command generates static content into the `build` directory and can be served using any static contents hosting service.
 
+Build modes:
+
+```
+$ npm run build:preview
+```
+
+Builds docs with both released versions and `next` content.
+
+```
+$ npm run build:production
+```
+
+Builds docs with released versions only (hides `next`).
+
 ### Deployment
 
 Using SSH:

website/docusaurus.config.ts

@@ -7,6 +7,16 @@ import remarkDirective from "remark-directive";
 import remarkTermDirective from "./src/remark/remark-term-directive.js";
 import codeMaxLineLength from './src/remark/remark-code-max-line-length.js';
 
+const rawDocsBuildMode = process.env.DOCS_BUILD_MODE ?? 'preview';
+
+if (!['preview', 'production'].includes(rawDocsBuildMode)) {
+  throw new Error(
+    `Invalid DOCS_BUILD_MODE: "${rawDocsBuildMode}". Expected "preview" or "production".`,
+  );
+}
+
+const includeCurrentVersion = rawDocsBuildMode === 'preview';
+
 
 /** @type {import('@docusaurus/types').Config} */
 const config = {
@@ -34,6 +44,7 @@ const config = {
       /** @type {import('@docusaurus/preset-classic').Options} */
       ({
         docs: {
+          includeCurrentVersion,
           admonitions: {
             keywords: ['lo', 'K1', 'K2', 'K3', 'note', 'tip', 'info', 'warning', 'danger'],
             extendDefaults: true,
@@ -107,6 +118,12 @@ const config = {
             to: '/docs/learning_objectives',
             position: 'left',
           },
+          {
+            type: 'docsVersionDropdown',
+            position: 'right',
+            docsPluginId: 'default',
+            dropdownActiveClassDisabled: true,
+          },
         ],
       },
       footer: {

website/package.json

@@ -8,6 +8,8 @@
     "start": "docusaurus start",
     "start-public": "docusaurus start --host 0.0.0.0",
     "build": "docusaurus build",
+    "build:preview": "DOCS_BUILD_MODE=preview npm run build",
+    "build:production": "DOCS_BUILD_MODE=production npm run build",
     "swizzle": "docusaurus swizzle",
     "deploy": "docusaurus deploy",
     "clear": "docusaurus clear",

website/src/remark/remark-code-max-line-length.js

@@ -8,6 +8,13 @@ export default function codeMaxLineLength(options = {}) {
   const max = options.max ?? 100;
 
   return (tree, file) => {
+    const sourcePath = file.path ?? file.history?.[0] ?? '';
+
+    // Versioned docs are snapshots and should not fail on current lint rules.
+    if (/(^|[\\/])versioned_docs([\\/]|$)/.test(sourcePath)) {
+      return;
+    }
+
     visit(tree, 'code', (node) => {
       // Optional: allow opt-out with "nolint" in code block meta:
       // ```js nolint

website/static/img/Run_Process_Docs.png

@@ -0,0 +1,3 @@
+# 1 Introduction to Robot Framework
+
+The upcoming chapters provide a concise overview of Robot Framework, including its core structure, use cases in test automation and Robotic Process Automation (RPA), and key specification styles like keyword-driven and behavior-driven testing. You'll learn about its architecture, syntax, and how test cases and tasks are organized. Additionally, the chapters explain the open-source licensing under Apache 2.0, the role of the Robot Framework Foundation in maintaining the ecosystem, and the foundational web resources available for further exploration and contributions.

website/versioned_docs/version-1.0.1/chapter-01/00_overview.md

@@ -0,0 +1,65 @@
+# 1.1 Purpose / Use Cases
+
+::::lo[Learning Objectives]
+
+:::K1[LO-1.1]
+
+Recall the two main use cases of Robot Framework
+
+:::
+
+::::
+
+Robot Framework is a versatile, open-source automation framework that supports both **test automation** and **robotic process automation (RPA)**.
+Initially designed for acceptance testing, it has since evolved to cover other types of testing and various automation tasks in both IT and business environments.
+Its keyword-driven approach allows users to create reusable components, making it accessible even to those with minimal programming skills.
+Robot Framework can be extended through a vast array of third-party or custom made keyword libraries, allowing it to automate interactions with APIs, user interfaces, databases, and many more technologies.
+
+
+
+## 1.1.1 Test Automation
+
+::::lo[Learning Objectives]
+
+:::K1[LO-1.1.1]
+
+Recall the test levels Robot Framework is mostly used for
+
+:::
+
+::::
+
+Robot Framework is widely used at various levels of testing, primarily focusing on:
+
+- **System Testing**: Involves verifying the complete system’s behavior and capabilities. It often includes both functional and non-functional aspects (e.g., accessibility, security) and may use simulated components.
+
+- **System Integration Testing**: Focuses on the interaction between the system under test and external services, as well as on the integration of multiple systems into a larger system, ensuring that all integrated components communicate and function together as expected.
+
+- **Acceptance Testing**: Aims to validate that the system meets business requirements and is ready for deployment or release. This often includes different forms of acceptance testing (e.g., user acceptance, operational acceptance, regulatory acceptance) and is frequently written or conducted by end-users or stakeholders to confirm the system’s readiness for use. Acceptance tests, often defined by business stakeholders in approaches like Acceptance Test-Driven Development (ATDD), can be automated and executed earlier in the development process. This ensures that the solution aligns with business requirements from the start and provides immediate feedback, reducing costly changes later.
+
+- **End-to-End Testing**: Verifies that a complete workflow or process within the system operates as intended, covering all interconnected subsystems, interfaces, and external components. End-to-end tests ensure the correct functioning of the application in real-world scenarios by simulating user interactions from start to finish.
+
+Robot Framework's flexibility and support for external libraries make it an excellent tool for automating these comprehensive test cases, ensuring seamless interaction between components and validating the system's behavior also in production or production-like conditions.
+
+Robot Framework is typically not used for **component testing** nor **integration testing** because its primary strength lies in higher-level testing, such as system, acceptance, and end-to-end testing, where behavior-driven and keyword-based approaches excel. Component testing requires low-level, granular tests focusing on individual units of code, often necessitating direct interaction with the codebase, mocking, or stubbing, which are better handled by unit testing frameworks like JUnit, pytest, or NUnit. Similarly, integration testing at a low level often requires precise control over service interactions, such as API stubs or protocol-level testing, which may not align with Robot Framework's abstraction-oriented design. While Robot Framework can technically handle these cases through custom libraries, its overhead and design philosophy make it less efficient compared to tools specifically tailored for low-level and tightly scoped testing tasks.
+
+
+### 1.1.1.1 Synthetic Monitoring
+
+Beyond traditional test levels, **Synthetic Monitoring**, also referred to as **Active Monitoring** or **Proactive Monitoring**, is a proactive approach that simulates user interactions with live systems at regular intervals. It detects performance issues or downtime early with the goal of detecting such failure before they affect actual users.
+
+
+
+## 1.1.2 Robotic Process Automation (RPA)
+
+Robotic Process Automation (RPA) uses software bots to perform tasks and interactions normally performed by humans, without requiring changes to the underlying applications.
+
+Robot Framework, with its keyword-driven approach, vast ecosystem of libraries, simplicity, and scalability, is widely adopted for RPA tasks.
+Robot Framework allows users to automate most workflows using ready-made keyword libraries that provide a wide range of functionalities. These libraries can be combined and reused in user-defined keywords, making automation simple and efficient. For custom functionalities or more complex tasks, Robot Framework also offers the flexibility to create custom keyword libraries using Python, enabling advanced use cases and seamless integration with unique systems.
+
+Common use cases of RPA with Robot Framework include:
+
+- **Data extraction and manipulation**: Automating data transfers and processing between systems.
+- **Task / Process automation**: Automating tasks such as form submissions, clicks, and file operations across web or desktop applications.
+
+

website/versioned_docs/version-1.0.1/chapter-01/01_purpose.md

@@ -0,0 +1,104 @@
+# 1.2 Architecture of Robot Framework
+
+Robot Framework is an open-source automation framework that allows you to build automation scripts for testing and RPA (Robotic Process Automation).
+It focuses on providing a keyword-driven or behavior-driven approach, making the automation easy to understand and maintain.
+However, it is not a full-stack solution that encompasses all layers of automation.
+Instead, it provides a flexible platform where different tools, libraries, and integrations handle specific tasks to implement a flexible automation solution.
+
+
+
+## 1.2.1 Robot Framework and the gTAA (Generic Test Automation Architecture)
+
+::::lo[Learning Objectives]
+
+:::K1[LO-1.2.1]
+
+Recall the layers of the Generic Test Automation Architecture (gTAA) and their corresponding components in Robot Framework
+
+:::
+
+::::
+
+The **Generic Test Automation Architecture (gTAA)** described in the ISTQB "Certified Tester Advanced Level Test Automation Engineering" offers a structured approach to test automation, dividing it into different layers for a clear separation of concerns:
+
+- **Definition Layer**: This layer contains the "Test Data" (test cases, tasks, resource files which include user keywords and variables).
+In Robot Framework, the test data is written using the defined syntax and contains keyword calls and argument values that make the test case or task definitions structured in suites.
+
+- **Execution Layer**: In Robot Framework, the execution layer consists of the framework itself, including its core components and APIs.
+It parses and interprets the test data syntax to build an execution model.
+The execution layer is responsible for processing this execution model to execute the library keywords with their argument values, logging results, and generating reports.
+
+- **Adaptation Layer**: This layer provides the connection between Robot Framework and the system under test (SUT).
+In Robot Framework, this is where the keyword libraries, which contain code responsible for interacting with different technologies and interfaces,
+such as those for UI, API, database interactions, or others, are located.
+These keyword libraries enable interaction with different technologies and interfaces, ensuring the automation is flexible and adaptable to various environments.
+
+Editors/IDEs that offer support for Robot Framework's syntax are tools that support or integrate in these layers.
+When writing tests|tasks or keywords, the editor supports the definition layer.
+When executing or debugging tests|tasks, the editor supports the execution layer.
+When writing keywords in e.g. Python for keyword libraries, the editor supports the adaptation layer.
+Therefore also other additional extensions of Robot Framework can be categorized into these layers.
+
+{/* TODO: add a graphic here */}
+
+## 1.2.2 What is Robot Framework & What It Is Not
+
+::::lo[Learning Objectives]
+
+:::K1[LO-1.2.2]
+
+Recall what is part of Robot Framework and what is not
+
+:::
+
+::::
+
+
+Robot Framework itself focuses primarily on **test|task execution**.
+It includes:
+
+- A parser to read test|task data and build an execution model.
+- An execution engine to process model and execute the keywords.
+- A result generation mechanism to provide logs and reports.
+- A collection of generic standard libraries to process and handle data or interact with files and processes.
+- Defined APIs for extensions and customizations.
+
+However, Robot Framework **does not** include:
+
+- Keyword libraries to control systems under test/RPA.
+
+  Such as:
+  - Web front-end automation libraries.
+  - API interaction libraries.
+  - Mobile automation libraries.
+  - Database interaction libraries.
+  - RPA libraries.
+  - etc.
+
+- Code editors or IDEs.
+- CI/CD Integration.
+
+Robot Framework defines the syntax for test|task data, but it is the role of external libraries and tools to extend its functionality for specific automation needs.
+
+
+
+## 1.2.3 Technology & Prerequisites
+
+::::lo[Learning Objectives]
+
+:::K1[LO-1.2.3]
+
+Recall the technology Robot Framework is built on and the prerequisites for running it
+
+:::
+
+::::
+
+
+Robot Framework is built on **Python** but is adaptable to other languages and technologies through external libraries.
+To run Robot Framework, an [officially supported version](https://devguide.python.org/versions/) of the **Python interpreter** is required on the machine executing the tests|tasks.
+Typically, Robot Framework and its libraries are installed via the "package installer for Python" (`pip`) from [PyPi.org](https://pypi.org/project/robotframework/), allowing for straightforward installation and setup.
+Robot Framework itself does not have any external dependencies, but additional third party tools or keyword libraries may require additional installations.
+
+
+