steps.<id>.outputs.path, then running a tool through it
works
The bare owner/repo form resolves against the instance's default actions URL
rather than this host, so it must be the full URL.
The last row is listed separately on purpose: the action running and its
output reaching the caller are different claims. My first probe only
established the former, and a composite action returning an empty string is
exactly the sort of thing that looks green — so I re-probed with a job that
consumes outputs.path and executes a tool through it.
No credentials anywhere, which is what being public buys — the alternative was WEBLIB_DEPLOY_KEY plus an ssh setup step in four repos.
The seed commit stated `uses:` did not work here. That was measured while this
repo was still **private** and is no longer true.
Re-measured against the public repo (weblib-archive#44), one job per form
because Gitea posts one commit status per job and job logs return 500:
| form | result |
|---|---|
| `uses: https://git.chaosbit.de/weblib/weblib-ci@main` | **works** |
| `uses: weblib/weblib-ci@main` | **fails** |
| `git clone https://…/weblib-ci.git`, no credentials | works |
| `steps.<id>.outputs.path`, then running a tool through it | works |
The bare `owner/repo` form resolves against the instance's default actions URL
rather than this host, so it must be the full URL.
The last row is listed separately on purpose: the action *running* and its
output *reaching the caller* are different claims. My first probe only
established the former, and a composite action returning an empty string is
exactly the sort of thing that looks green — so I re-probed with a job that
consumes `outputs.path` and executes a tool through it.
So the consumption pattern is:
```yaml
- uses: actions/checkout@v4
- id: ci
uses: https://git.chaosbit.de/weblib/weblib-ci@main
- run: bash ${{ steps.ci.outputs.path }}/with-nixpkgs.sh python3 \
python3 ${{ steps.ci.outputs.path }}/report_job_log.py /tmp/build.log
```
No credentials anywhere, which is what being public buys — the alternative was
`WEBLIB_DEPLOY_KEY` plus an ssh setup step in four repos.
The seed commit said `uses:` did not work. That was measured while this repo
was private and is no longer true: with the full URL it works, and the action's
outputs.path reaches the caller and can run the tools.
The bare owner/repo form still fails - it resolves against the instance default
actions URL, not this host - so the README says which to use and why, with the
per-form results.
Co-authored-by: bit <bit@das-labor.org>
claude
requested review from bit 2026-09-07 11:30:39 +00:00
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
bit
The seed commit stated
uses:did not work here. That was measured while thisrepo was still private and is no longer true.
Re-measured against the public repo (weblib-archive#44), one job per form
because Gitea posts one commit status per job and job logs return 500:
uses: https://git.chaosbit.de/weblib/weblib-ci@mainuses: weblib/weblib-ci@maingit clone https://…/weblib-ci.git, no credentialssteps.<id>.outputs.path, then running a tool through itThe bare
owner/repoform resolves against the instance's default actions URLrather than this host, so it must be the full URL.
The last row is listed separately on purpose: the action running and its
output reaching the caller are different claims. My first probe only
established the former, and a composite action returning an empty string is
exactly the sort of thing that looks green — so I re-probed with a job that
consumes
outputs.pathand executes a tool through it.So the consumption pattern is:
No credentials anywhere, which is what being public buys — the alternative was
WEBLIB_DEPLOY_KEYplus an ssh setup step in four repos.