RevoTale CI

Run your project’s checks in Woodpecker and publish its artifacts when you tag a release. Choose a workflow below and keep its YAML in your repository.

Migrate a repository · Dependency updates · Release flow · Releases

Choose a workflow

Project output	Starting point
Checks only	Minimal start
Docker images	Docker workflow
Binaries, archives or other files	Task workflow

Each starting point includes lint and unit tests. For both images and files, share validation.

Minimal start

Enable the repository in Woodpecker. From the repository root, run task lint and task test:unit to confirm both tasks exist and pass. If Go and Task provide all the tools they need, save this as .woodpecker.yaml:

when:
  - event: [pull_request, manual]
  - event: push
    branch: ${CI_REPO_DEFAULT_BRANCH}
  - event: tag
    ref: refs/tags/v*

steps:
  - name: lint
    image: ghcr.io/revotale/ci/base:v0.1.5@sha256:6e63627e23192f3e6258776bc9eeca0cc42829b1c447bc252ece997541e73f09
    depends_on: []
    commands: [task lint]

  - name: unit
    image: ghcr.io/revotale/ci/base:v0.1.5@sha256:6e63627e23192f3e6258776bc9eeca0cc42829b1c447bc252ece997541e73f09
    depends_on: []
    commands: [task test:unit]

Open a pull request. In Woodpecker, look for two parallel steps, lint and unit. Open a failed step to see the output of its Task command.

If your tasks need extra tools or services, choose a check environment. Add optional steps for capabilities the project uses.

How the Docker workflow runs

flowchart TD
    A["PR · main push · manual · v* tag"] --> L["task lint"]
    A --> U["task test:unit"]
    L --> T["artifact-test target · native platform"]
    U --> T
    T --> E{"Event"}
    E -->|"PR / push / manual"| B["Build release target · native platform"]
    E -->|"v* tag"| P["Build and publish · ARM64 + AMD64"]

Loading

Checks use the builder's native platform. Only release publication builds ARM64 and AMD64. Additional check platforms are an explicit project choice. See optional steps for integration tests and the Task workflow.

Working-branch pushes do not duplicate PR checks. Each release tag runs its own checks before publishing. Other tags are ignored.

Artifact checks run during the Dockerfile build. Both targets share the runtime stage; matching layers are reused through Buildx cache.

Cache is shared between steps in one workflow. Persistent and cross-project caching require separate configuration.

Real Dockerfile · Why tests live in Dockerfile targets · Multiple images with a matrix

Shared components

Component	When to use it
ghcr.io/revotale/ci/base	Run Go and Task commands on Debian Trixie.
ghcr.io/revotale/ci/buildx	Build a Docker image and publish it with the project’s name, purpose, authors and license.
ghcr.io/revotale/ci/updatecli	Run Updatecli in a scheduled or manual Woodpecker step.
ghcr.io/revotale/ci/policies/dependencies:0.2.0	Reference these rules in updatecli-compose.yaml to collect image, Go and policy updates in one GitHub PR.

The three images support ARM64 and AMD64. The policy has its own version.

Agent and credentials

Use a dedicated CI machine and require approval for untrusted PRs. Allow the exact Buildx image used by the workflow: our wrapper needs the same builder privileges as the official plugin.

Secret	Used for	Allowed events
registry_username, registry_password	Publishing images and policies	tag
forge_token	Release PRs and forge releases	Default-branch push
forge_token	Dependency PRs, when enabled	cron, manual

Registry credentials need push access. Forge credentials need repository contents and pull-request write access. Do not expose them to PR checks.

In RevoTale/ci itself, merging a release PR triggers the tag and forge release after main checks pass. The tag pipeline publishes artifacts and verifies them for consumers. See release flow.

Dependency updates

flowchart LR
    A["Daily cron / manual"] --> B["Updatecli runner + shared policy"]
    B --> C["Dependency PR"]
    C --> D["Project CI + review"]

Loading

Connect with two files: an Updatecli compose file and a Woodpecker workflow. There is no automerge.

Follow the integration guide for files, registry access, secrets and cron setup. The current policy uses GitHub; do not assign the same dependencies to both Updatecli and another updater.

What is enforced

Our Buildx wrapper requires title, description, authors and licenses. It checks that values are present, not that they are correct. A workflow that bypasses the wrapper also bypasses these checks.

Keep image versions explicit in every step so dependency updates show exactly which steps change.

For contributors and AI agents

Read AGENTS.md and DECISIONS.md before proposing changes. For existing projects, follow the migration guide.

Build shared functionality here. Propose extraction into woodpecker-toolkit only when it provides clear value outside RevoTale.