Skip to content

linkml-sidecar workflow

Servicegithub actionsforgejo actionscodebergworkflowgh-pagesLINKML_DOCS_ENABLEDservices/linkml-sidecar-workflow

Checked by automation only

still a draft

Written 2026-10-22 by ktl-librarian (automation). Last checked 2026-10-22 by ktl-librarian (automation).

The full record
Checks
  • 2026-10-22 by ktl-librarian (automation)
Sources
Is part of
References
Pointed to by
Graph
Open this concept in the knowledge graph
IRI
https://w3id.org/ktl/linkml-sidecar/knowledge/services/linkml-sidecar-workflow
Licence
CC BY 4.0
Files
MarkdownJSON-LDSource on GitHubHistory on GitHub

On GitHub, templates/github/linkml-sidecar.yaml is installed in Step 5 at .github/workflows/linkml-sidecar.yaml. On Forgejo and Codeberg, templates/forgejo/linkml-sidecar.yaml takes its place. Neither template has placeholders, so every host carries the same bytes. The template’s own workflows under .linkml/.github/ stay as inert copies, because GitHub reads .github/workflows/ at the root only.

  • lint-and-test runs on a pull request or a push to any branch that touches .linkml/**, .lokf/lokf.yaml or the workflow, and on dispatch. In .linkml/ it runs uv sync --locked --group dev, just lint and just test on Python 3.12.
  • docs runs on the same events, on the default branch only, after the gate. It runs just gen-doc and mkdocs build, and keeps the site as the linkml-docs artifact.
  • publish-docs runs after docs, only while the repository variable LINKML_DOCS_ENABLED is true. It publishes the artifact under the linkml/ subpath of the host’s gh-pages branch and replaces that subpath and nothing else.

--locked means the lock the host committed is what runs, so a sidecar whose uv.lock is not in git fails at the install step.

With --adopt, the schema sits outside .linkml/, so Step 5 adds its folder ("<dir>/**") to both paths: lists, and an edit to the schema runs the gate too.

Every uses: names a commit, with the version in a trailing comment. Dependabot reaches this repository’s own workflows only, so the contract fails until a bump is copied into both templates too.

templates/forgejo/linkml-sidecar.yaml runs the same gate on Forgejo Actions, as Codeberg runs them. Step 5 puts it in the folder the preflight’s workflows line names. Forgejo reads only the first of .forgejo/workflows/, .gitea/workflows/ and .github/workflows/ that exists, so a new .forgejo/workflows/ beside an existing .github/workflows/ would hide every workflow there from it.

It differs from the GitHub template only where Forgejo does:

  • Both jobs run on Codeberg’s codeberg-small runner. On a self-hosted Forgejo, the two runs-on lines name one of its runners’ labels, and the host owns that copy from then on.
  • It has no harden-runner and no permissions block.
  • Each action is named by its full address, so the file does not depend on the instance’s default action mirror.
  • The docs job builds the site and publishes it in one job, because the stock upload-artifact and download-artifact actions fail on Forgejo.
  • It publishes with Codeberg’s git-pages action under the linkml/ subpath of https://<owner>.codeberg.page/<repo>/, once LINKML_DOCS_ENABLED is true. A self-hosted Forgejo has no Pages, so the variable stays unset there, and the job builds the site and stops.

On Codeberg, Actions are off by default. They are turned on in the repository’s settings, under Units, Overview.

On GitLab, Gitea or a forge with no CI of its own, the install, lint, test and mkdocs build steps are plain shell in .linkml/ and port unchanged. They run as a job of the host’s existing CI, with .linkml as its working directory. GitLab Pages serves a public/ folder from the pipeline, so the host’s own Pages job copies .linkml/site to public/linkml/. Gitea runs the GitHub Actions syntax, so the Forgejo template is the nearer start there, but it has not been run on Gitea.