added actions doc
This commit is contained in:
parent
3fceb4a5de
commit
9bc6f6e795
1 changed files with 82 additions and 59 deletions
|
|
@ -21,96 +21,119 @@ description: GitHub Actions-compatible CI/CD automation
|
|||
|
||||
## Overview
|
||||
|
||||
[Detailed description of the component - what it is, what it does, and why it exists]
|
||||
Forgejo Actions is a built-in CI/CD automation system that enables developers to define and execute workflows directly within their Forgejo repositories. As a continuous integration and continuous deployment platform, Forgejo Actions automates software development tasks such as building, testing, packaging, and deploying applications whenever specific events occur in your repository.
|
||||
|
||||
Forgejo Actions provides [GitHub Actions similarity](https://forgejo.org/docs/latest/user/actions/github-actions/), allowing teams to easily adapt existing GitHub Actions workflows and marketplace actions with minimal or no modifications. This compatibility significantly reduces migration effort for teams transitioning from GitHub to Forgejo, while maintaining familiar syntax and workflow patterns.
|
||||
|
||||
Workflows are defined using YAML files stored in the `.forgejo/workflows/` directory of your repository. Each workflow consists of one or more jobs that execute on action runners when triggered by repository events such as pushes, pull requests, tags, or manual dispatch. This enables automation of repetitive development tasks, ensuring consistent build and deployment processes across your software delivery pipeline.
|
||||
|
||||
By integrating CI/CD directly into the repository management platform, Forgejo Actions eliminates the need for external CI/CD systems, reducing infrastructure complexity and providing a unified development experience.
|
||||
|
||||
## Key Features
|
||||
|
||||
* [Feature 1]
|
||||
* [Feature 2]
|
||||
* [Feature 3]
|
||||
* **Automated Workflow Execution** - Execute automated workflows triggered by repository events such as code pushes, pull requests, tag creation, or manual dispatch, enabling continuous integration and deployment without manual intervention
|
||||
* **GitHub Actions Similarity** - Maintains similarity with GitHub Actions syntax and workflows, allowing reuse of existing actions from the GitHub marketplace and simplifying migration from GitHub-based CI/CD pipelines
|
||||
|
||||
## Purpose in EDP
|
||||
|
||||
[Explain the role this component plays in the Edge Developer Platform and how it contributes to the overall platform capabilities]
|
||||
Forgejo Actions enables EDP customers to execute complete CI/CD pipelines directly on the platform for building, testing, packaging, and deploying software. This integrated automation capability is fundamental to the EDP value proposition.
|
||||
|
||||
## Repository
|
||||
Without native CI/CD automation, customers would face significant integration overhead connecting external CI/CD systems to their EDP workflows. This fragmentation would complicate pipeline management, increase operational complexity, and reduce the platform's effectiveness as a unified development solution.
|
||||
|
||||
**Code**: [Link to source code repository]
|
||||
|
||||
**Documentation**: [Link to component-specific documentation]
|
||||
Since Forgejo Actions is natively integrated into Forgejo, EDP provides this critical CI/CD capability with minimal additional infrastructure. Customers benefit from seamless automation without requiring separate tool provisioning, authentication configuration, or cross-system integration maintenance.
|
||||
|
||||
## Getting Started
|
||||
|
||||
### Prerequisites
|
||||
|
||||
* [Prerequisite 1]
|
||||
* [Prerequisite 2]
|
||||
* Installed Forgejo
|
||||
* Installed Forgejo runner (see [Runner Installation Quick Start](/docs/components/forgejo/actions/runner/#quick-start))
|
||||
|
||||
### Quick Start
|
||||
|
||||
[Step-by-step guide to get started with this component]
|
||||
1. Create a repository
|
||||
2. Create file `/.forgejo/workflows/example.yaml`
|
||||
|
||||
1. [Step 1]
|
||||
2. [Step 2]
|
||||
3. [Step 3]
|
||||
```yaml
|
||||
# example.yaml
|
||||
name: example
|
||||
|
||||
on:
|
||||
workflow_dispatch:
|
||||
|
||||
jobs:
|
||||
build:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Hello World
|
||||
run: |
|
||||
echo "Hello World!"
|
||||
```
|
||||
|
||||
3. Navigate to Actions > example.yaml > Run workflow
|
||||
|
||||
### Verification
|
||||
|
||||
[How to verify the component is working correctly]
|
||||
See the logs, there should appear a "Hello World!" in "Hello World" Step
|
||||
|
||||
## Usage Examples
|
||||
|
||||
### [Use Case 1]
|
||||
### Use actions to deploy infrastructure
|
||||
|
||||
[Example with code/commands showing common use case]
|
||||
See [infra-deploy](https://edp.buildth.ing/DevFW/infra-deploy/src/branch/main/.github/workflows/deploy.yaml) repository as a example
|
||||
|
||||
```bash
|
||||
# Example commands
|
||||
### Use goreleaser to build, test, package and release a project
|
||||
|
||||
This pipeline is triggered when a tag with the prefix `v` is pushed to the repository.
|
||||
Then, it fetches the current repository with all tags and checks out the version for the current run.
|
||||
|
||||
After that the application is being built.
|
||||
|
||||
```yaml
|
||||
# .github/workflows/release.yaml
|
||||
name: ci
|
||||
|
||||
on:
|
||||
push:
|
||||
tags:
|
||||
- v*
|
||||
|
||||
jobs:
|
||||
goreleaser:
|
||||
runs-on: ubuntu-latest
|
||||
steps:
|
||||
- name: Checkout
|
||||
uses: actions/checkout@v4
|
||||
with:
|
||||
fetch-depth: 0
|
||||
- name: Set up Go
|
||||
uses: actions/setup-go@v6
|
||||
with:
|
||||
go-version: ">=1.25.1"
|
||||
- name: Test code
|
||||
run: make test
|
||||
- name: Import GPG key
|
||||
id: import_gpg
|
||||
uses: https://github.com/crazy-max/ghaction-import-gpg@v6
|
||||
with:
|
||||
gpg_private_key: ${{ secrets.GPG_PRIVATE_KEY }}
|
||||
passphrase: ${{ secrets.GPG_PASSPHRASE }}
|
||||
- name: Run GoReleaser
|
||||
uses: https://github.com/goreleaser/goreleaser-action@v6
|
||||
env:
|
||||
GITEA_TOKEN: ${{ secrets.PACKAGES_TOKEN }}
|
||||
GPG_FINGERPRINT: ${{ steps.import_gpg.outputs.fingerprint }}
|
||||
with:
|
||||
args: release --clean
|
||||
```
|
||||
|
||||
### [Use Case 2]
|
||||
|
||||
[Another common scenario]
|
||||
|
||||
## Integration Points
|
||||
|
||||
* **[Component A]**: [How it integrates]
|
||||
* **[Component B]**: [How it integrates]
|
||||
* **[Component C]**: [How it integrates]
|
||||
|
||||
## Architecture
|
||||
|
||||
[Optional: Add architectural diagrams and descriptions]
|
||||
|
||||
### Component Architecture (C4)
|
||||
|
||||
[Add C4 Container or Component diagrams showing the internal structure]
|
||||
|
||||
### Sequence Diagrams
|
||||
|
||||
[Add sequence diagrams showing key interaction flows with other components]
|
||||
|
||||
### Deployment Architecture
|
||||
|
||||
[Add infrastructure and deployment diagrams showing how the component is deployed]
|
||||
|
||||
## Configuration
|
||||
|
||||
[Key configuration options and how to set them]
|
||||
|
||||
## Troubleshooting
|
||||
|
||||
### [Common Issue 1]
|
||||
### The job is not being executed by a runner
|
||||
|
||||
**Problem**: [Description]
|
||||
**Problem**: The job is not being picked up by a runner
|
||||
|
||||
**Solution**: [How to fix]
|
||||
|
||||
### [Common Issue 2]
|
||||
|
||||
**Problem**: [Description]
|
||||
|
||||
**Solution**: [How to fix]
|
||||
**Solution**: Probably, there is currently no runner available with the label defined in your job `runs-on` attribute. Check the available runner for your repository by navigating to the repository settings > Actions > Runners. Now you can see all available runners and their Labels. Choose on of them as your `runs-on` attribute.
|
||||
|
||||
## Status
|
||||
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue