diff --git a/content/en/_index.md b/content/en/_index.md index 65102fa..cfe30c8 100644 --- a/content/en/_index.md +++ b/content/en/_index.md @@ -16,22 +16,22 @@ Built on open standards and battle-tested technologies. {{% blocks/section color="dark" type="row" %}} -{{% blocks/feature icon="fa-solid fa-diagram-project" title="Architecture Documentation" url="/docs/architecture/" %}} -Explore the platform's architecture with interactive C4 diagrams. Understand the system design, components, and deployment topology. +{{% blocks/feature icon="fa-solid fa-diagram-project" title="Edge Developer Platform (EDP)" url="/docs/edp/" %}} +Understand EDP as the developer platform hub (Forgejo, CI/CD, deployment, operations) and how it connects inner loop and outer loop workflows. -**Dive into the architecture →** +**Dive into EDP docs →** {{% /blocks/feature %}} -{{% blocks/feature icon="fa-solid fa-book-open" title="Technical Writer Guide" url="/docs/documentation/" %}} -Learn how to contribute to this documentation. Write content, test locally, and understand the CI/CD pipeline. +{{% blocks/feature icon="fa-solid fa-cloud" title="EdgeConnect Cloud" url="/docs/edgeconnect/" %}} +Learn what EdgeConnect is, how it is consumed via stable entry points (CLI, SDK, Terraform), and how EDP integrates with it as a deployment target. -**Start documenting →** +**Explore EdgeConnect →** {{% /blocks/feature %}} -{{% blocks/feature icon="fa-solid fa-archive" title="Legacy Documentation (v1)" url="/docs/v1/" %}} -Access the previous version of our documentation including historical project information and early architecture decisions. +{{% blocks/feature icon="fa-solid fa-scale-balanced" title="Governance" url="/docs/governance/" %}} +Read the project history, decision context, and audit-oriented traceability to primary sources and repository artifacts. -**Browse v1 docs →** +**Go to Governance →** {{% /blocks/feature %}} {{% /blocks/section %}} @@ -76,11 +76,11 @@ Access the previous version of our documentation including historical project in ## Get Started -Whether you're a **platform engineer**, **application developer**, or **technicalWriter**, we have resources for you: +Whether you're a **platform engineer**, **application developer**, or **auditor**, we have resources for you: -* 📖 Read the [Documentation](/docs/) to understand the platform -* 🏗️ Explore [Platform Components](/docs/components/) and their usage -* ✍️ Learn [How to Document](/docs/DOCUMENTATION-GUIDE/) and contribute -* 🔍 Browse [Legacy Documentation](/docs-old/) for historical context +* 📖 Start at [Documentation](/docs/) +* 🧭 Read [Edge Developer Platform (EDP)](/docs/edp/) +* ☁️ Read [EdgeConnect Cloud](/docs/edgeconnect/) +* 🧾 Read [Governance](/docs/governance/) {{% /blocks/section %}} diff --git a/content/en/docs/_index.md b/content/en/docs/_index.md index 4602768..72f5932 100644 --- a/content/en/docs/_index.md +++ b/content/en/docs/_index.md @@ -22,6 +22,6 @@ It describes the outcomes and products of the edgeDeveloperFramework (eDF) sub-p The documentation is organized into three core areas: -* **Edge Developer Platform (EDP)**: The central platform to support developers working in the Edge, based around Forgejo -* **Edge Connect Cloud**: The IPCEI-CIS channel of EDP deployments per secure connectivity solutions for edge devices and environments -* **Governance**: Project history, decisions, and compliance +* **[Edge Developer Platform (EDP)](/docs/edp/)**: The central platform to support developers working at the edge, based around Forgejo +* **[EdgeConnect Cloud](/docs/edgeconnect/)**: The sovereign edge cloud context and key deployment target for EDP integrations +* **[Governance](/docs/governance/)**: Project history, decision context, and audit-oriented traceability diff --git a/content/en/docs/edp/forgejo/actions/_index.md b/content/en/docs/edp/forgejo/actions/_index.md index 723c6ad..6faf101 100644 --- a/content/en/docs/edp/forgejo/actions/_index.md +++ b/content/en/docs/edp/forgejo/actions/_index.md @@ -5,19 +5,7 @@ weight: 10 description: GitHub Actions-compatible CI/CD automation --- -{{% alert title="Draft" color="warning" %}} -**Editorial Status**: This page is currently being developed. -* **Jira Ticket**: [TICKET-XXX](https://your-jira/browse/TICKET-XXX) -* **Assignee**: [Name or Team] -* **Status**: Draft -* **Last Updated**: YYYY-MM-DD -* **TODO**: - * [ ] Add detailed component description - * [ ] Include usage examples and code samples - * [ ] Add architecture diagrams - * [ ] Review and finalize content -{{% /alert %}} ## Overview @@ -70,7 +58,7 @@ jobs: echo "Hello World!" ``` -3. Navigate to Actions > example.yaml > Run workflow +1. Navigate to Actions > example.yaml > Run workflow ### Verification diff --git a/content/en/docs/edp/forgejo/actions/runners/_index.md b/content/en/docs/edp/forgejo/actions/runners/_index.md index bcc4ac0..c66f4c2 100644 --- a/content/en/docs/edp/forgejo/actions/runners/_index.md +++ b/content/en/docs/edp/forgejo/actions/runners/_index.md @@ -6,20 +6,6 @@ description: > Self-hosted runner infrastructure with orchestration capabilities --- -{{% alert title="Draft" color="warning" %}} -**Editorial Status**: This page is currently being developed. - -* **Jira Ticket**: [TICKET-XXX](https://your-jira/browse/TICKET-XXX) -* **Assignee**: [Name or Team] -* **Status**: Draft -* **Last Updated**: YYYY-MM-DD -* **TODO**: - * [ ] Add detailed component description - * [ ] Include usage examples and code samples - * [ ] Add architecture diagrams - * [ ] Review and finalize content -{{% /alert %}} - ## Overview Action runners are the execution environment for Forgejo Actions workflows. By design, runners execute remote code submitted through CI/CD pipelines, making their architecture highly dependent on the underlying infrastructure and security requirements. @@ -43,8 +29,9 @@ A actions runner are executing Forgejo actions, which can be used to build, test ## Repository **Code**: -- [Runner on edge connect using GARM](https://edp.buildth.ing/DevFW-CICD/garm-provider-edge-connect/src/branch/main/runner) -- [Static runner](https://edp.buildth.ing/DevFW-CICD/stacks/src/branch/main/template/stacks/forgejo/forgejo-runner/dind-docker.yaml) + +* [Runner on edge connect using GARM](https://edp.buildth.ing/DevFW-CICD/garm-provider-edge-connect/src/branch/main/runner) +* [Static runner](https://edp.buildth.ing/DevFW-CICD/stacks/src/branch/main/template/stacks/forgejo/forgejo-runner/dind-docker.yaml) **Documentation**: [Forgejo Runner installation guide](https://forgejo.org/docs/latest/admin/actions/runner-installation/) @@ -57,16 +44,18 @@ Different runner deployment architectures offer varying levels of isolation, sec Bare metal runners execute directly on physical hardware without virtualization layers. **Advantages:** -- Maximum performance with direct hardware access -- Complete hardware isolation between different physical machines -- No hypervisor overhead or virtualization complexity + +* Maximum performance with direct hardware access +* Complete hardware isolation between different physical machines +* No hypervisor overhead or virtualization complexity **Disadvantages:** -- Difficult to clean after each run, requiring manual intervention or full OS reinstallation -- Long provisioning time for individual runners -- Complex provisioning processes requiring physical access or remote management tools -- Limited scalability due to physical hardware constraints -- Higher risk of persistent contamination between runs + +* Difficult to clean after each run, requiring manual intervention or full OS reinstallation +* Long provisioning time for individual runners +* Complex provisioning processes requiring physical access or remote management tools +* Limited scalability due to physical hardware constraints +* Higher risk of persistent contamination between runs **Use case:** Best suited for specialized workloads requiring specific hardware, performance-critical builds, or environments where virtualization is not available. @@ -75,17 +64,19 @@ Bare metal runners execute directly on physical hardware without virtualization VM-based runners operate within virtualized environments managed by a hypervisor. **Advantages:** -- Strong isolation through hypervisor and hardware memory mapping -- Virtual machine images enable faster provisioning compared to bare metal -- Easy to snapshot, clone, and restore to clean states -- Better resource utilization through multiple VMs per physical host -- Automated cleanup by destroying and recreating VMs after each run + +* Strong isolation through hypervisor and hardware memory mapping +* Virtual machine images enable faster provisioning compared to bare metal +* Easy to snapshot, clone, and restore to clean states +* Better resource utilization through multiple VMs per physical host +* Automated cleanup by destroying and recreating VMs after each run **Disadvantages:** -- Requires hypervisor infrastructure and management -- Slower provisioning than containers -- Higher resource overhead compared to containerized solutions -- More complex orchestration for scaling runner fleets + +* Requires hypervisor infrastructure and management +* Slower provisioning than containers +* Higher resource overhead compared to containerized solutions +* More complex orchestration for scaling runner fleets **Use case:** Ideal for environments requiring strong isolation guarantees, multi-tenant scenarios, or when running untrusted code from external contributors. @@ -94,17 +85,19 @@ VM-based runners operate within virtualized environments managed by a hypervisor Container-based runners execute within isolated containers using OCI-compliant runtimes. **Advantages:** -- Kernel-level isolation using Linux namespaces and cgroups -- Fast provisioning and startup times -- Easy deployment through standardized OCI container images -- Lightweight resource usage enabling high-density runner deployments -- Simple orchestration with Kubernetes or Docker Compose + +* Kernel-level isolation using Linux namespaces and cgroups +* Fast provisioning and startup times +* Easy deployment through standardized OCI container images +* Lightweight resource usage enabling high-density runner deployments +* Simple orchestration with Kubernetes or Docker Compose **Disadvantages:** -- Weaker isolation than VMs since containers share the host kernel -- Requires elevated permissions or privileged access for certain workflows (e.g., Docker-in-Docker) -- Potential kernel-level vulnerabilities affect all containers on the host -- Container escape vulnerabilities pose security risks in multi-tenant environments + +* Weaker isolation than VMs since containers share the host kernel +* Requires elevated permissions or privileged access for certain workflows (e.g., Docker-in-Docker) +* Potential kernel-level vulnerabilities affect all containers on the host +* Container escape vulnerabilities pose security risks in multi-tenant environments **Use case:** Best for high-volume CI/CD workloads, trusted code repositories, and environments prioritizing speed and efficiency over maximum isolation.