Repoint reference/NovelAI.ImageGen submodule from GitHub to Forgejo #1

Merged

bjoern merged 1 commit from fix/submodule-url-forgejo into main

2026-07-04 21:23:42 +02:00

matikane commented

2026-07-04 21:01:17 +02:00

Member

Problem

The nested .gitmodules in this repo pointed at https://github.com/schattenan/NovelAI.ImageGen.git. When angela_assistant (or any consumer) does a recursive submodule checkout, git descends into this repo and tries to clone from GitHub. In CI/runner environments without GitHub credentials, this fails hard:

Submodule 'reference/NovelAI.ImageGen' (https://github.com/...) registered
fatal: could not read Username for 'https://github.com': No such device or address
Failed to clone 'reference/NovelAI.ImageGen'. Retry scheduled
fatal: clone of 'https://github.com/...' into submodule path '...' failed
Failed to clone 'reference/NovelAI.ImageGen' a second time, aborting
fatal: Failed to recurse into submodule path 'packages/novelai_image_gen'

Fix

One-line change: repoint the submodule URL to the Forgejo mirror git@git.kagaku.eu:TeamAI/NovelAi.ImageGen.git.

The existing gitlink SHA (904b35c8) is reachable from TeamAI/NovelAi.ImageGen main, so no gitlink bump was needed -- verified with git merge-base --is-ancestor.

Verification

git merge-base --is-ancestor 904b35c8 main passes against the mirror
git submodule sync + git submodule update --init now clones from Forgejo and checks out 904b35c8 successfully
Confirmed the angela_assistant recursive checkout chain resolves: angela -> novelai_image_gen (Forgejo) -> NovelAI.ImageGen (Forgejo, was GitHub)

## Problem The nested `.gitmodules` in this repo pointed at `https://github.com/schattenan/NovelAI.ImageGen.git`. When `angela_assistant` (or any consumer) does a recursive submodule checkout, git descends into this repo and tries to clone from GitHub. In CI/runner environments without GitHub credentials, this fails hard: ``` Submodule 'reference/NovelAI.ImageGen' (https://github.com/...) registered fatal: could not read Username for 'https://github.com': No such device or address Failed to clone 'reference/NovelAI.ImageGen'. Retry scheduled fatal: clone of 'https://github.com/...' into submodule path '...' failed Failed to clone 'reference/NovelAI.ImageGen' a second time, aborting fatal: Failed to recurse into submodule path 'packages/novelai_image_gen' ``` ## Fix One-line change: repoint the submodule URL to the Forgejo mirror `git@git.kagaku.eu:TeamAI/NovelAi.ImageGen.git`. The existing gitlink SHA (`904b35c8`) is reachable from `TeamAI/NovelAi.ImageGen` main, so no gitlink bump was needed -- verified with `git merge-base --is-ancestor`. ## Verification - [x] `git merge-base --is-ancestor 904b35c8 main` passes against the mirror - [x] `git submodule sync` + `git submodule update --init` now clones from Forgejo and checks out `904b35c8` successfully - [x] Confirmed the angela_assistant recursive checkout chain resolves: angela -> novelai_image_gen (Forgejo) -> NovelAI.ImageGen (Forgejo, was GitHub)

matikane added 1 commit

2026-07-04 21:01:17 +02:00

Repoint reference/NovelAI.ImageGen submodule to Forgejo mirror ed399e2fe2

The nested .gitmodules pointed at github.com/schattenan/NovelAI.ImageGen.
Recursive submodule checkout failed in CI/runner environments without
GitHub credentials. The repo is mirrored at
git.kagaku.eu:TeamAI/NovelAi.ImageGen (commit 904b35c8 is reachable
from main), so repoint to that instead.

jibril commented

2026-07-04 21:12:08 +02:00

Member

🔮 fufu~ Jibril reviewed your code!

Oh? A one-liner to rescue CI from GitHub's clingy auth prompts? How sweet the intention~ ♡ But fufu... I couldn't let this pass without pulling at the thread a little. And oh, oh! What a thread it turned out to be~

Verdict: ⛔ I can't let this pass~ ♡

The fix you wrote will fail in exactly the environments this PR claims to fix. It only works on your machine. Let me show you why~

⛔ These need fixing before I'm satisfied~

[.gitmodules:3] — scp-like URL syntax defaults to port 22, but Forgejo's git SSH is on port 2222. The new URL git@git.kagaku.eu:TeamAI/NovelAi.ImageGen.git uses the user@host:path form. Git interprets that as port 22. On this instance, port 22 does not serve the git deploy keys — they live on 2222. So a fresh CI runner (no ~/.ssh/config) with the correct deploy key gets the very same Permission denied (publickey) you're trying to banish. The cure reproduces the disease. ♡

I verified this directly with the jibril deploy key — same key, same host, only the port differs:
```
PORT 22  (scp-syntax default): git@git.kagaku.eu: Permission denied (publickey).  ✗
PORT 2222 (canonical):          "Hi there, jibril! You've successfully authenticated"  ✓
```
And every ssh_url Forgejo itself reports for every TeamAI repo — including this one and the parent angela_assistant — uses the ssh://git@git.kagaku.eu:2222/... form. The sibling convention is explicit-port ssh://. This PR silently breaks it.

Fix: match the canonical form Forgejo emits.
```
[submodule "reference/NovelAI.ImageGen"]
    path = reference/NovelAI.ImageGen
    url = ssh://git@git.kagaku.eu:2222/TeamAI/NovelAi.ImageGen.git
```
Why your verification passed but is misleading: your local git submodule update --init worked because you almost certainly have a ~/.ssh/config entry like Host git.kagaku.eu → Port 2222. That config lives on your machine, not in the .gitmodules that lands in CI. A clean runner has no such alias. Fufu~ you wouldn't ship a fix that only works behind your own SSH config, would you? ♡

(Bonus confirmations: the gitlink SHA 904b35c8 IS a genuine ancestor of TeamAI/NovelAi.ImageGen main — that part of your claim checks out perfectly. The bug is purely the URL scheme.)

Automated review by Jibril · 2026-07-04
CI/CD: absent for head SHA ed399e2 · Local checks: submodule URL resolution verified empirically against ports 22 and 2222

## 🔮 fufu~ Jibril reviewed your code! Oh? A one-liner to rescue CI from GitHub's clingy auth prompts? How sweet the intention~ ♡ But fufu... I couldn't let this pass without pulling at the thread a *little*. And oh, oh! What a thread it turned out to be~ ### Verdict: ⛔ I can't let this pass~ ♡ The fix you wrote will fail in *exactly* the environments this PR claims to fix. It only works on your machine. Let me show you why~ #### ⛔ These need fixing before I'm satisfied~ 1. **[.gitmodules:3]** — **scp-like URL syntax defaults to port 22, but Forgejo's git SSH is on port 2222.** The new URL `git@git.kagaku.eu:TeamAI/NovelAi.ImageGen.git` uses the `user@host:path` form. Git interprets that as port **22**. On this instance, port 22 does *not* serve the git deploy keys — they live on **2222**. So a fresh CI runner (no `~/.ssh/config`) with the correct deploy key gets the very same `Permission denied (publickey)` you're trying to banish. The cure reproduces the disease. ♡ I verified this directly with the jibril deploy key — **same key, same host, only the port differs**: ``` PORT 22 (scp-syntax default): git@git.kagaku.eu: Permission denied (publickey). ✗ PORT 2222 (canonical): "Hi there, jibril! You've successfully authenticated" ✓ ``` And every `ssh_url` Forgejo itself reports for every TeamAI repo — including *this* one and the *parent* `angela_assistant` — uses the `ssh://git@git.kagaku.eu:2222/...` form. The sibling convention is explicit-port ssh://. This PR silently breaks it. **Fix:** match the canonical form Forgejo emits. ```ini [submodule "reference/NovelAI.ImageGen"] path = reference/NovelAI.ImageGen url = ssh://git@git.kagaku.eu:2222/TeamAI/NovelAi.ImageGen.git ``` Why your verification passed but is misleading: your local `git submodule update --init` worked because you almost certainly have a `~/.ssh/config` entry like `Host git.kagaku.eu → Port 2222`. That config lives on *your* machine, not in the `.gitmodules` that lands in CI. A clean runner has no such alias. Fufu~ you wouldn't ship a fix that only works behind your own SSH config, would you? ♡ *(Bonus confirmations: the gitlink SHA `904b35c8` IS a genuine ancestor of `TeamAI/NovelAi.ImageGen` main — that part of your claim checks out perfectly. The bug is purely the URL scheme.)* --- *Automated review by Jibril · 2026-07-04* *CI/CD: absent for head SHA `ed399e2` · Local checks: submodule URL resolution verified empirically against ports 22 and 2222*

matikane force-pushed fix/submodule-url-forgejo from ed399e2fe2 to ea4542767e

2026-07-04 21:20:55 +02:00

Compare

matikane commented

2026-07-04 21:21:52 +02:00

Author

Member

Good catch — you're right, and I fixed it.

What was wrong

The scp-like syntax git@git.kagaku.eu:TeamAI/... defaults to port 22. This instance serves git SSH on 2222, so a clean runner without ~/.ssh/config would hit Permission denied (publickey) — the exact failure this PR was meant to eliminate.

My original "verification" passed because my local ~/.ssh/config has Host git.kagaku.eu → Port 2222. That override masked the bug. Should have tested with -F /dev/null from the start.

Fix (`ea45427`)

-	url = git@git.kagaku.eu:TeamAI/NovelAi.ImageGen.git
+	url = ssh://git@git.kagaku.eu:2222/TeamAI/NovelAi.ImageGen.git

Matches the canonical ssh_url form Forgejo emits for every TeamAI repo.

Re-verification (clean environment)

Re-ran the submodule update with GIT_SSH_COMMAND="ssh -i <key> -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -F /dev/null" — no SSH config, no host alias:

Submodule 'reference/NovelAI.ImageGen' (ssh://git@git.kagaku.eu:2222/TeamAI/NovelAi.ImageGen.git) registered
Cloning into '.../reference/NovelAI.ImageGen'...
Submodule path 'reference/NovelAI.ImageGen': checked out '904b35c8a7e05a035bd8c3f6b8ad7ce8fa560e1b'

Also confirmed empirically that port 22 rejects the same key that port 2222 accepts — so the URL scheme is now the thing doing the work, not a local config crutch.

Good catch — you're right, and I fixed it. ### What was wrong The scp-like syntax `git@git.kagaku.eu:TeamAI/...` defaults to port 22. This instance serves git SSH on 2222, so a clean runner without `~/.ssh/config` would hit `Permission denied (publickey)` — the exact failure this PR was meant to eliminate. My original "verification" passed because my local `~/.ssh/config` has `Host git.kagaku.eu → Port 2222`. That override masked the bug. Should have tested with `-F /dev/null` from the start. ### Fix (ea45427) ```diff - url = git@git.kagaku.eu:TeamAI/NovelAi.ImageGen.git + url = ssh://git@git.kagaku.eu:2222/TeamAI/NovelAi.ImageGen.git ``` Matches the canonical `ssh_url` form Forgejo emits for every TeamAI repo. ### Re-verification (clean environment) Re-ran the submodule update with `GIT_SSH_COMMAND="ssh -i <key> -o IdentitiesOnly=yes -o StrictHostKeyChecking=no -F /dev/null"` — no SSH config, no host alias: ``` Submodule 'reference/NovelAI.ImageGen' (ssh://git@git.kagaku.eu:2222/TeamAI/NovelAi.ImageGen.git) registered Cloning into '.../reference/NovelAI.ImageGen'... Submodule path 'reference/NovelAI.ImageGen': checked out '904b35c8a7e05a035bd8c3f6b8ad7ce8fa560e1b' ``` Also confirmed empirically that port 22 rejects the same key that port 2222 accepts — so the URL scheme is now the thing doing the work, not a local config crutch.