fetch git nodes over https
validate / validate (pull_request) Successful in 59m10s

ssh:// cannot authenticate under dora-cli 1.0.1: it fetches through libgit2
with no credential callback, so the only transport that can work is anonymous
https. The documented URLs move accordingly, and the repository is now
dora-image-view rather than dora-plot.

The note about what a `git:` node needs is corrected while here. The cause is
not that a repository is private but that the fetch is anonymous: on Gitea a
repository inside a private organization is internal and answers an anonymous
clone with 401 even when the repository itself is marked public. The
organization has to be public too.
This commit is contained in:
2026-09-15 06:29:37 -03:00
parent 15e0b9155a
commit f7171de2af
3 changed files with 14 additions and 14 deletions
+7 -6
View File
@@ -14,7 +14,7 @@ Add to your dataflow:
```yaml
nodes:
- id: view
git: ssh://git@gitea.liria.cl:5001/liria/dora-image-view.git
git: https://gitea.liria.cl/liria/dora-image-view.git
tag: v0.1.0
build: uv pip install .
path: dora-image-view
@@ -85,11 +85,12 @@ else, and `dora validate --strict` warns about every *typed* input this node dec
that a dataflow leaves unwired. The strictness belongs to `dataflow.yml`, which drives
all of them.
**Known limitation (dora-cli 1.0.1).** A `git:` node pointing at a private repository
does not build: over `ssh://` on a non-standard port the connection fails, and over
`https://` libgit2 reports `remote authentication required but no callback set`. The
dataflow validates and the wiring is the form a consumer should use, but running it
needs that fixed or the repository made public.
**A `git:` node needs anonymous read access.** dora-cli 1.0.1 fetches through libgit2
with no credential callback, so a repository that asks for credentials fails with
`remote authentication required but no callback set`, and `ssh://` cannot authenticate
at all. Note that marking a repository public is not sufficient on Gitea: a repository
inside a **private organization** is treated as internal and still answers anonymous
clones with `401`. The organization has to be public too.
### Node manifest
+6 -7
View File
@@ -4,12 +4,11 @@
# Not run by CI: it needs a camera and it fetches dora-webcam over the network.
# dataflow.yml is the gate, and needs neither.
#
# Known limitation, dora-cli 1.0.1: a `git:` node pointing at a *private*
# repository does not build. Over ssh:// on a non-standard port the connection
# fails outright, and over https:// libgit2 reports "remote authentication
# required but no callback set" -- dora has no credential callback, so neither
# transport authenticates. This file validates, and the wiring below is the form
# a consumer should use; running it needs that fixed, or the repository public.
# This needs anonymous read access to the camera's repository. dora-cli 1.0.1
# fetches through libgit2 with no credential callback, so anything that asks for
# credentials fails with "remote authentication required but no callback set".
# On Gitea, marking the repository public is not enough: a repository inside a
# private organization is internal and still answers anonymous clones with 401.
#
# `strict_types` is deliberately absent. A camera publishes an image and nothing
# else, and `dora validate --strict` warns about every *typed* input this node
@@ -19,7 +18,7 @@
nodes:
- id: camera
git: ssh://git@gitea.liria.cl:5001/liria/dora-webcam.git
git: https://gitea.liria.cl/liria/dora-webcam.git
tag: v0.1.0
build: uv pip install .
path: dora-webcam
+1 -1
View File
@@ -86,7 +86,7 @@ env:
example: |
- id: view
git: ssh://git@gitea.liria.cl:5001/liria/dora-image-view.git
git: https://gitea.liria.cl/liria/dora-image-view.git
tag: v0.1.0
build: uv pip install .
path: dora-image-view