Takk for raskt svar!

Antar at med GitHub sitt API så tenker du på å lese ut liste over mapper og filer som er i kodelageret (repository).

Ja, det var egentlig eneste måten jeg visste om å hente ut filer fra GitHub. Disse direktelenkene til råfilene løser jo egentlig alle problemene sånn sett. Det viktigste var å slippe og forholde oss til GitHub APIene som jeg tenkte ville bli litt unødvendig hodebry for å hente ut filer.

Når det gjelder punkt to så tenkte jeg som du sier å ha noe type "./latest". Men jeg har gravd litt mer i eksisterende løsning og ser at vi har noe logikk for å håndtere årstallene i URLene på noen av disse leveransedataene. Ikke så veldig elegant sånn sett, men vi sjekker bare på mulige årstall det kan være data for og henter ned dataen på den måten allerede. Så det kan vi fortsette å gjøre siden det fungerer i dag, så trenger vi ikke å lage mer arbeid enn vi trenger.

Med disse direktelenkene og forutsigbare serier så har vi det slik som i dag, så da er vi fornøyde

3. Releases i GitHub

Kan vere mogleg, men usikker på om det gir nok verdi til å forsvare ekstra kostnaden ved å måtte manuelt opprette releases i GitHub når > det kjem nye datasett. Om ein gjer seg avhengig av dette, kan det også blir ei ekstra feilkjelde. Fort gjort å legge ut dataene men gløyme å > opprette release.

Tenker det er betre framgangsmåte å oppdage at nye datasett (mapper) er dukka opp.

Skulle ein hatt opplegg med releases, kunne ein tenke seg å legge på tags for melk, egg, korn etc.

Utdjup gjerne vidare om du likevel trur det er verdt å sjå vidare på.

Jeg ser absolutt den, det er jo noe med å lage en prosess rundt å lage releases nok til at det blir en stabil og sikker måte å løse det på. For vår del så er ikke dette noe game changer sånn sett, vi beholder nok de tidsbaserte triggerne våre så er ikke avhengig av at man får synkronisert med releases etc. var noen umiddelbare tanker rundt på kontoret på noe som kunne vært kult og ha når dere potensielt går over til GitHub.

Heisann, vi i Innovasjon Norge henter ned data fra Landbruksdirektoratet programmatisk. På denne måten blir det mulig for oss å hente data via GitHubs API, men så vidt jeg vet er ikke dette helt frem å gjøre det på den måten og ikke helt ideelt på samme måten som et åpent API med mer direkte adresser etc. Jeg hadde et par spørsmål og innspill i den forbindelse, nå er det jo litt tidlig i testingen og sånt så ikke sikkert dere har alle svarene og tanker enda

1. Først og fremst lurte jeg på om dere vet om det er mulig å hente ned filene på en enklere måte enn ved å bruke GitHubs API

og så et par innspill

2. Dersom valget faller på GitHub er det mulig å ha det slik at den seneste dataen er på en fast "path" slik at det blir litt enklere å sette opp den automatiserte hentingen uten å måtte forholde seg til endringer i mappestruktur etc.

3. Siden dette er CSV filer, så kan man bruke versjoneringen til å lage "releases" av ny data, som også gjør det litt enklere for situasjoner som oss og lete seg tilbake i historikk osv. For å forklare litt nærmere så tenker jeg da at man kan ha en utgivelser for f.eks. «Melk» som da kan være 2024, 2025 osv.
   Henger litt sammen med punkt 1 at man har en fast "path" for dataen og, da kan man «tracke releases» etc.