all Slack wisdom

Image versioning in CD

By Tomas Pousette on 2025-11-25

Tomas Pousette:

Does someone understand how the image version numbers work in the CD in opendatastack? It seems to build images with the same version number as the previous image sometimes

See these two runs for example:

First: https://github.com/knowit-solutions-cocreate/datadrivet-infra-opendatastack/actions/runs/19664554028/job/56318270850

Second: https://github.com/knowit-solutions-cocreate/datadrivet-infra-opendatastack/actions/runs/19670675098/job/56338521922

Kristian:

commitizen ska göra det automatiskt genom en github action som uppdaterar versionen i pyproject.toml

det finns några tags i commit meddelandet som inte bumpar versionen så det får man se upp med

till exempel är en PATCH bump som ändrar bara tredje siffran i versionen (0.0.X):

  • fix: - Bug fixes
  • perf: - Performance improvements
  • refactor: - Code refactoring
  • build: - Build system changes
  • ci: - CI/CD changes
  • docs: - Documentation only changes
  • style: - Code style changes
  • test: - Adding/updating tests
  • chore: - Other changes that don’t modify src

sen ett till krav är att åtminstone en fil måste finnas i /dbt eller /processing mappen eller vara datadriven.Dockerfile

så om man ändrat någon annan typ av fil så fångas det inte upp av versionsändringen

Linking PR to issue in github

By Fredrik Möllerstrand on 2025-10-22

Thorvaldur:

vet inte hur man länkar pr till issue :laughing:

Fredrik:

En kan skriva “fixes knowit-solutions-cocreate/datadrivet-infra-opendatastack#492”

Mallen för att referera till en issue iett annat repo är “keyword org/repo#number”

Här finns det hela dokumenterat: https://docs.github.com/en/issues/tracking-your-work-with-issues/using-issues/linking-a-pull-request-to-an-issue#linking-a-pull-request-to-an-issue-using-a-keyword

openwebui and cofinder-mcp troubleshooting

By Tomas Pousette on 2025-10-16

Angående openwebui och cofinder-mcp:

När vi först fick det att funka så slutade fungera efter ca. ett dygn. Svagt minne av att det var problem med något “session id” i antingen mcp eller mcpo loggen i kubernetes. Dokumenterade dock inte detta. Fick igång det igen genom att starta om mcpo podden (och kanske mcp podden också, starta om mcp podden först isf)

Om det strular, prova att gå in i k9s och

  • Starta om mcpo-podden (ctrl + k på den) Funkar det inte så kan hjälpsam debugging vara:
  • Kolla mcp poddens log vid omstart av mcpo-podden (då den försöker köra pat-auth). Borde komma loggning om att det försöker köra PAT-auth och om det lyckas eller ej
  • Kolla cofinder-api poddens log också, och kolla vad som händer i /authenticate_token requestet

Dök upp ett problem idag som var att /authenticate_token tog för lång tid (ca. 11 sek), och att requestet från pat_middleware.py i mcp’n då timeade ut. Ökade timeout från 10 till 20 sek, och då kunde openwebui connecta till mcp’n igen. Borde det verkligen ta så lång tid att authenticatea en pat?

Inspecting database

By Edvard Lindelöf on 2025-10-14

postar hur man kan inspektera databasen här då detta är användbart för fler. Ståendes i fluxcd-dataplattform/ kör man kubectl port-forward service/postgres-service 5432:5432 -n cofinder-api . Också konfar man sin DBeaver (trevligt program) såhär:

Screenshot of DBeaver setup

Standup board

By Edvard Lindelöf on 2025-10-14

Standup board (länk)) Vi har tre nivåer av items:

  • Här skapar vi, ibland, kategorier av arbete som skall vara på en nivå som alla har möjlighet att tolka, alltså antingen är kopplad till någon konkret produktfunktion e.g. “få cofinder-ads-kanalen att fungera i teams” eller utgör en utvecklarslaskkategori som “förbättra kodkvalitet”. Deras syfte är att låta oss hålla koll på vad vi prioriterar. De behöver i allmänhet inte stängas.
  • På standup board är det fritt fram att som utvecklare skapa items under respektive kategori i kolumnen Planned. Sätt Issue Type till Bug eller Feature så syns den. Syftet med dessa är att vid varje standup låta oss gå igenom vad var och en jobbar (eller försöker jobba) med för att möjliggöra att man ber om hjälp, delar med sig av snabba tips eller på annat sätt stödjer varandra. Efter att du skapat en item här får du berätta på nästa standup vad tanken med den är. Beroende på prio så drar vi den då till backlog eller låter den ligga kvar på standup. Dessa dras till höger i takt med att dom blir klara och försvinnre så småningom från boarden.
  • Knappen “Create sub-issue” bestämmer man själv om/hur mycket man vill använda (att skapa guidande sub-issues är ett mycket bra sätt att coacha en kollega!). Vi tittar vanligen inte på dessa vid standup.

I backlog lägger vi features ämnade att genomföras senare. Vid planeringsmöten flyttar vi features, som vi anser prioriterade, härifrån till planned.

Det är fritt fram att spamma tråden härunder med uppdateringar kring olika items.

Admin issue in cloning dagster

By Edvard Lindelöf & Minh Tran on 2025-10-12

Minh:

Jag fick detta felet när jag kör ett dagster materialize ett asset

The above exception was caused by the following exception:
dlt.pipeline.exceptions.PipelineStepFailed: Pipeline execution failed at `step=load` when processing package with `load_id=1760105365.4028292` with exception:

<class 'dlt.destinations.exceptions.DatabaseTransientException'>
100132 (P0000): JavaScript execution error: Uncaught Execution of multiple statements failed on statement "ALTER TABLE "RAW_TEAMTAILOR"."..." (at line 1, position 0).
SQL access control error:
Insufficient privileges to operate on table 'CANDIDATES'. in SYSTEM$MULTISTMT at '    throw `Execution of multiple statements failed on statement {0} (at line {1}, position {2}).`.replace('{1}', LINES[i])' position 4
stackstrace: 
SYSTEM$MULTISTMT line: 10

Detta gäller att min development role har inte ownership permission att skriva och skapa något i detta databas.

Det finns bara SELECT i DEVELOPMENT role.

Screenshot of Snowflake webUI

Edvard:

Nu har vi löst saken för Minh. Problemet är att behörighetsredigeringsraderna i klonskriptet failar tyst om man ej är admin. Tillsvidare så gäller det att man får klona från DATADRIVEN_ACCEPTANCE, som redan har rätt behörighetsstyrning:

set this_db = 'DATADRIVEN_<ditt namn>';
CREATE DATABASE identifier($this_db) CLONE DATADRIVEN_ACCEPTANCE;

om statet i acceptance är utdaterat m a p vad man meckar med, be en admin att köra prod -> acc synk skriptet

Och adminskriptet (som du alltså INTE skall köra om du ej är admin) ser i sin tur ut såhär:

set this_db = 'DATADRIVEN_ACCEPTANCE';
set this_role = 'DEVELOPMENT';
CREATE DATABASE identifier($this_db) CLONE DATADRIVEN;
GRANT OWNERSHIP ON DATABASE identifier($this_db) TO ROLE identifier($this_role) REVOKE CURRENT GRANTS;
GRANT OWNERSHIP ON ALL SCHEMAS IN DATABASE identifier($this_db) TO ROLE identifier($this_role) REVOKE CURRENT GRANTS;
GRANT OWNERSHIP ON ALL TABLES IN DATABASE identifier($this_db) TO ROLE identifier($this_role) REVOKE CURRENT GRANTS;
GRANT OWNERSHIP ON ALL VIEWS IN DATABASE identifier($this_db) TO ROLE identifier($this_role) REVOKE CURRENT GRANTS;