docs(index): update 'front door consistency' and remove drafts
This commit is contained in:
parent
eeb623517b
commit
145705edf7
4 changed files with 53 additions and 72 deletions
|
|
@ -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 %}}
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
|
|
|||
|
|
@ -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
|
||||
|
||||
|
|
|
|||
|
|
@ -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.
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue