Open-source automation that isn't tied to one forge.
Our GitHub Actions are built to run on GitHub Actions, Gitea Actions, and locally under act. They read what they can from git and the workflow environment, and where an action genuinely needs a forge API — creating a release, say — it detects the platform and talks to the right one instead of assuming GitHub.
If you self-host Gitea, mirror between forges, or want to reproduce a failing job locally with act, these are built for you.
| Action | What it does |
|---|---|
| tag-info | Read tag information from a local or remote repository |
| tag-create-update | Create or update a tag, local or remote |
| tag-floating-version | Maintain floating aliases like v1 and v1.2 |
| tag-validate-version | Detect, validate and parse a version tag into its components |
| commit-info | Get commit details at HEAD or a given offset |
| Action | What it does |
|---|---|
| release | Create releases on GitHub, Gitea or self-hosted Gitea |
| release-changelog-builder | Build changelogs across multiple providers |
| changelog-parser | Extract entries from a local or remote CHANGELOG.md |
| Action | What it does |
|---|---|
| docker-metadata | Extract tags and OCI labels from git refs — a fork of docker/metadata-action with no GitHub API dependency |
| docker-cleanup | Clean up images and tags in a container registry |
| docker-test | Run basic smoke tests against a built image |
| docker-act-compatibility | Resolve build context and Dockerfile paths when they differ from the repo root |
| Action | What it does |
|---|---|
| ca-certificate-import | Install custom CA certificates into the runner, for private registries and internal services |
| install-gitea-tea | Install the Gitea tea CLI for use in a workflow |
| trigger-workflow | Trigger workflows in other repositories, on GitHub or Gitea |
| rclone | Install and run rclone to publish files anywhere it supports |
Using one:
- uses: LiquidLogicLabs/git-action-tag-validate-version@v2
with:
tag: ${{ github.ref_name }}Every action is versioned independently and maintains floating vX and vX.Y tags, so pinning to a major line gets you fixes without breaking changes.
| Image | What it does |
|---|---|
| markdown-mermaidjs-to-pdf | Render Markdown with embedded Mermaid diagrams to PDF |
| dnn-docker | Docker setup for running DotNetNuke |
| docker-baseimage-arch | Arch Linux base image |
| Plugin | What it does |
|---|---|
| traefik-plugin-cors-regex | Traefik middleware adding regex and wildcard support for CORS origins |
| Package | What it does |
|---|---|
| git-platform-detector | Detects the hosting platform (GitHub, Gitea, Bitbucket) from a repository URL or CI environment and returns a matching API client. Used by several of the actions above. |
npm install @liquidlogiclabs/git-platform-detectorMost CI actions assume GitHub, which is fine until you self-host or mirror elsewhere. Ours split the difference deliberately:
- Actions that need no API at all derive everything from git and the workflow environment, so they behave identically on GitHub, Gitea and
act. docker-metadata is the clearest example — it is a fork ofdocker/metadata-actionwith the GitHub API dependency removed entirely. - Actions that genuinely need an API — creating a release, triggering a workflow, pushing a tag to a remote — detect the platform via
git-platform-detectorand use the matching client.
Either way, the same workflow file runs in all three places.