Shared Forgejo Actions for agent-skills org
Find a file
2026-05-08 11:16:38 +08:00
register-skill Install bun for skill package builds 2026-05-08 10:39:12 +08:00
.gitignore feat: add register-skill composite action 2026-03-12 21:52:42 +08:00
README.md Document skill release deployment flow 2026-05-08 11:16:38 +08:00

shared-actions

This directory is a working clone of the Forgejo repo agent-skills/shared-actions. Skill workflows pin actions here by URL:

uses: https://code.yuanwei-lnc.com/agent-skills/shared-actions/register-skill@main

Edit → git commitgit push from inside this dir. There is no separate "publish" step — pushing to origin/main is what makes the change live for every skill repo's CI on the next run.

Actions

  • register-skill/action.yaml — builds a skill package, uploads the zip to the current tag's Forgejo release, and registers the public release asset URL as artifact_url. SkillHub returns that same value to clients as download_url.
  • Auth uses SKILL_REGISTRY_TOKEN_TEST / SKILL_REGISTRY_TOKEN_PRD (skreg_*) for /ecom/skills/register-by-slug, and FORGEJO_TOKEN for creating releases and uploading release assets on https://code.yuanwei-lnc.com.

Release flow

  • Test tags such as v1.2.3-rc.1 or v1.2.3-test.1 register to the test registry. The test gateway defaults to https://api-gw-test.yuanwei-lnc.com.
  • Stable tags such as v1.2.3 register to the prd registry using the SKILL_API_BASE_PRD secret.
  • The skill zip is environment-neutral. The environment only controls which registry API receives the download_url.

Skill repo workflow

Each real skill repo keeps only a thin Forgejo workflow:

- name: Checkout
  shell: bash
  env:
    FORGEJO_TOKEN: ${{ secrets.FORGEJO_TOKEN }}
  run: |
    set -euo pipefail
    git init "$GITHUB_WORKSPACE"
    git -C "$GITHUB_WORKSPACE" remote add origin "${GITHUB_SERVER_URL}/${GITHUB_REPOSITORY}.git"
    git -C "$GITHUB_WORKSPACE" -c "http.extraHeader=Authorization: token ${FORGEJO_TOKEN}" fetch --depth 1 origin "${GITHUB_REF}"
    git -C "$GITHUB_WORKSPACE" checkout --force FETCH_HEAD

- uses: https://code.yuanwei-lnc.com/agent-skills/shared-actions/register-skill@main
  with:
    registry_token_test: ${{ secrets.SKILL_REGISTRY_TOKEN_TEST }}
    registry_token_prd: ${{ secrets.SKILL_REGISTRY_TOKEN_PRD }}
    test_api_base: https://api-gw-test.yuanwei-lnc.com
    prd_api_base: ${{ secrets.SKILL_API_BASE_PRD }}
    forgejo_token: ${{ secrets.FORGEJO_TOKEN }}

Do not use actions/checkout@v4 here. The Forgejo runner should fetch from https://code.yuanwei-lnc.com directly instead of trying to clone GitHub actions.

Deployment checklist

  1. Configure organization secrets on agent-skills:
    • FORGEJO_TOKEN
    • SKILL_REGISTRY_TOKEN_TEST
    • SKILL_REGISTRY_TOKEN_PRD
    • SKILL_API_BASE_PRD
  2. Push skill repo code to main.
  3. Push a test tag such as v1.2.3-test.1.
  4. Confirm the action logs contain Registered successfully and Download URL: https://code.yuanwei-lnc.com/...zip.
  5. Confirm the skill management UI shows the new test version.
  6. After testing the self-contained zip, push the stable tag v1.2.3 to register the same release shape to prd.

If runner capacity is low, trigger skills in small batches. Skip template-skill during normal verification because it is only a template repo.

Why nested in the monorepo

The action is a critical CI dependency for all 7+ skill repos. Keeping it visible in the monorepo source tree (instead of a flying repo on Forgejo) means it shows up in grep, in code search, and in this project's review habits. The nested .git is the deploy clone — the monorepo root isn't a git repo so there's nothing to conflict with.