build: automatic update of astrololo

updates image gitea/astrololo-data tag '320a0ab2' to '10ade555' updates image gitea/astrololo-logic tag '320a0ab2' to '10ade555' updates image gitea/astrololo-presentation tag '320a0ab2' to '10ade555'
2026-08-26 14:25:52 +00:00 · 2026-08-26 09:31:26 +00:00 · 2026-08-26 09:07:21 +00:00 · 2026-08-26 09:05:28 +00:00 · 2026-08-24 15:45:25 +00:00 · 2026-08-24 15:43:21 +00:00
4 changed files with 31 additions and 5 deletions
@@ -11,10 +11,10 @@ resources:
  - ingress.yaml # wejście po https + przekierowanie z http
 images:
  - name: gitea.czernobog.pl/gitea/astrololo-data
-    newTag: f0d07ee8
+    newTag: 10ade555
  - name: gitea.czernobog.pl/gitea/astrololo-logic
-    newTag: f0d07ee8
+    newTag: 10ade555
  - name: gitea.czernobog.pl/gitea/astrololo-render
    newTag: latest
  - name: gitea.czernobog.pl/gitea/astrololo-presentation
-    newTag: f0d07ee8
+    newTag: 10ade555
@@ -31,6 +31,19 @@ spec:
            # Where the librarian sends THIS bot's results/pongs back to (its own
            # NodePort). Lets one librarian serve both bots - see deploy-bot.yaml.
            - { name: CONJURER_SELF_CALLBACK,     value: "http://192.168.1.73:32442" }
+            # Self-hosted models (Ollama). No API key - the endpoint IS the
+            # configuration, and the backend stays unselectable while unset.
+            # Pick a model at runtime with: $gadaj_teraz ollama <model>
+            # ($modele_ai lists what the server actually has pulled).
+            - { name: CONJURER_OLLAMA_URL,        value: "http://192.168.1.72:11434" }
+            # The server currently has exactly one model pulled (verified via
+            # /v1/models): gemma4:e2b. Without this the built-in default
+            # (llama3.1:8b) would be requested and every reply would fail.
+            - { name: CONJURER_OLLAMA_MODEL,      value: "gemma4:e2b" }
+            # Self-hosted generation is far slower than a hosted API, especially
+            # the first request after the model is evicted from VRAM. Applies to
+            # every backend, so keep it only as high as you actually need.
+            - { name: CONJURER_AI_TIMEOUT_SECONDS, value: "240" }
          volumeMounts:
            - { name: data,  mountPath: /data }
            - { name: netrc, mountPath: /secrets, readOnly: true }
@@ -51,6 +51,19 @@ spec:
            # query and answers results/pongs HERE - so it serves this bot AND the
            # test bot from one instance, no CONJURER_MAIN_BOT repointing needed.
            - { name: CONJURER_SELF_CALLBACK,     value: "http://192.168.1.73:32443" }
+            # Self-hosted models (Ollama). No API key - the endpoint IS the
+            # configuration, and the backend stays unselectable while unset.
+            # Pick a model at runtime with: $gadaj_teraz ollama <model>
+            # ($modele_ai lists what the server actually has pulled).
+            - { name: CONJURER_OLLAMA_URL,        value: "http://192.168.1.72:11434" }
+            # The server currently has exactly one model pulled (verified via
+            # /v1/models): gemma4:e2b. Without this the built-in default
+            # (llama3.1:8b) would be requested and every reply would fail.
+            - { name: CONJURER_OLLAMA_MODEL,      value: "gemma4:e2b" }
+            # Self-hosted generation is far slower than a hosted API, especially
+            # the first request after the model is evicted from VRAM. Applies to
+            # every backend, so keep it only as high as you actually need.
+            - { name: CONJURER_AI_TIMEOUT_SECONDS, value: "240" }
          volumeMounts:
            - { name: data,  mountPath: /data }
            - { name: netrc, mountPath: /secrets, readOnly: true }
@@ -8,9 +8,9 @@ resources:
  - deploy-bot-backup.yaml
 images:
  - name: gitea.czernobog.pl/gitea/conjurer-librarian
-    newTag: d0c7ab61
+    newTag: fdc1fa18
  - name: gitea.czernobog.pl/gitea/conjurer-bot
-    newTag: d0c7ab61
+    newTag: fdc1fa18
  # Production bot channel - only bumped when a [deploy]-tagged build appears.
  # Bootstrapped to fbd1ec9f: that's the image the first [deploy] build (merge
  # of conjurer#20) promoted to conjurer-bot-deploy. From here the image-updater
Author	SHA1	Message	Date
argocd-image-updater	5b8740cb93	build: automatic update of astrololo updates image gitea/astrololo-data tag '320a0ab2' to '10ade555' updates image gitea/astrololo-logic tag '320a0ab2' to '10ade555' updates image gitea/astrololo-presentation tag '320a0ab2' to '10ade555'	2026-08-26 14:25:52 +00:00
argocd-image-updater	4e3166e1c4	build: automatic update of astrololo updates image gitea/astrololo-data tag '1d0ff2f7' to '320a0ab2' updates image gitea/astrololo-logic tag '1d0ff2f7' to '320a0ab2' updates image gitea/astrololo-presentation tag '1d0ff2f7' to '320a0ab2'	2026-08-26 09:31:26 +00:00
argocd-image-updater	9425c6bd1a	build: automatic update of astrololo updates image gitea/astrololo-data tag 'f0d07ee8' to '1d0ff2f7' updates image gitea/astrololo-logic tag 'f0d07ee8' to '1d0ff2f7' updates image gitea/astrololo-presentation tag 'f0d07ee8' to '1d0ff2f7'	2026-08-26 09:07:21 +00:00
gitea	47544d1769	docs(sekrety): dołożenie klucza do ISTNIEJĄCEGO sekretu, nie tylko tworzenie Po zmergowaniu LOG-34 pody prezentacji nie wstały: Error: couldn't find key SESSION_SECRET in Secret astrololo/astrololo-auth Runbook opisywał wyłącznie ścieżkę instalacji OD ZERA — SESSION_SECRET pojawiał się tylko w komendzie `create secret`. Na działającym wdrożeniu sekret już istnieje, a merge manifestu kluczy do niego nie dokłada; każe ich tylko szukać. Gorzej: opisana rotacja też by tam nie zadziałała. Używała JSON Patch z `op: replace` na /data/SESSION_SECRET, a `replace` wymaga, żeby ścieżka już istniała — czyli jedyna komenda, po którą sięgnąłby ktoś w tej sytuacji, też odmawia. Teraz obie potrzeby obsługuje JEDNA komenda: `--type=merge` ze `stringData` dokłada albo nadpisuje i nie wymaga wcześniejszego istnienia klucza. Dopisane sprawdzenie kompletu kluczy bez pokazywania wartości oraz to samo ostrzeżenie w runbooku demo, gdzie czeka dokładnie ta sama pułapka. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>	2026-08-26 09:05:28 +00:00
argocd-image-updater	b0aa55a8b7	build: automatic update of conjurer updates image gitea/conjurer-librarian tag '13d2a040' to 'fdc1fa18' updates image gitea/conjurer-bot tag 'd0c7ab61' to 'fdc1fa18'	2026-08-24 15:45:25 +00:00
argocd-image-updater	3543c4a4be	build: automatic update of conjurer updates image gitea/conjurer-librarian tag 'd0c7ab61' to '13d2a040'	2026-08-24 15:43:21 +00:00
gitea	a802b90617	conjurer: pin the model Ollama actually has, and raise the AI timeout Probing the real server (192.168.1.72:11434) after it was opened to the LAN: /v1/models returns exactly one model, gemma4:e2b. Without pinning it the bot would request the built-in default llama3.1:8b and every reply would fail with "model not found", so set it explicitly on both bots. Also raise CONJURER_AI_TIMEOUT_SECONDS to 240. Self-hosted generation is far slower than a hosted API, particularly the first request after the model is evicted from VRAM. It applies to every backend, so it is deliberately not set higher than needed. Caveat recorded honestly: at the time of writing, generation on that server does not complete. /v1/models answers instantly, but both /v1/chat/ completions (180s) and native /api/generate with num_predict=5 (60s) return nothing, and /api/ps shows no model ever becomes resident - so the model never finishes loading. Ollama is 0.32.14 and gemma4:e2b is 5.1B Q4_K_M (~3.5GB) despite the "e2b" name. That is a server-side problem, not a configuration one; these values are correct and take effect once it loads. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-24 14:54:32 +02:00
gitea	aeb9bb5940	conjurer: point both bots at the Ollama server (192.168.1.72:11434) Wires CONJURER_OLLAMA_URL into the test bot and the deploy bot so the self-hosted backend from conjurer#25 is selectable. No API key exists for Ollama - the endpoint is the whole configuration - and until it is set the backend refuses to be selected, so this is what turns it on. NOTE, verified from the LAN before committing: 192.168.1.72 answers ping (0.4ms) but only port 22 is open - 11434 refuses. Ollama binds to 127.0.0.1:11434 by default, so it is not reachable off-host yet. This env var is correct but inert until the server listens on the network: sudo systemctl edit ollama.service [Service] Environment="OLLAMA_HOST=0.0.0.0:11434" sudo systemctl daemon-reload && sudo systemctl restart ollama Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>	2026-08-24 14:43:01 +02:00