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:
@@ -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
@@ -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
@@ -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
|
||||
|
||||
Reference in New Issue
Block a user