Organisasjonsadministrasjon

Organisasjonsadministrasjonen i fremforge ligger på frem.sh/<din-org>/_admin. En sidemeny med fem grupper samler adminsidene, og topplinjen har en Cmd-K-palett (⌘K / Ctrl-K) som søker i alle sider etter etikett og nøkkelord. Ingen gjemte undermenyer, ingen overraskende modaler.

Organisasjon: Overview, Repos, Medlemmer, SSO, Fakturering, Public docs, Dataeksport, Settings. Sikkerhet: Overview, Findings, Components, Prioritise, Fix, Reports, Policies, Access. Se Security nedenfor. Bygg og utrulling: Miljøer, Utrullinger, Secrets, Avhengighetsoppdateringer (samme side som Sikkerhet › Utbedre), Avhengighetsproxy, frembench. Integrasjon: AI-integrasjoner, Programmatic access, Webhooks, Videresending til SIEM. Rapporter: DORA, Revisjonslogg (kryptografisk integritet i Revisjonskjede), Tilgangslogg for registeret, Legal hold, Oppbevaring av bevis, Legal notices.

Hvis siden du vil til, tilhører en kunde som for øyeblikket er suspendert eller er i perioden på 90 dager etter oppsigelse, er adminflaten skrivebeskyttet overalt unntatt i Billing og Data export. Banneret øverst på hver side sier dette tydelig.

Fanelinjen er den samme på alle adminsider, så du kan bytte mellom faner uten å miste oversikten over hvor du var.

Hvem som har tilgang til administrasjonen

Alle med rollen Eier i Forgejo-organisasjonen. Rollen settes på Forgejos side <org>/-/teams/owners. Kontrollen skjer på serveren ved hver adminforespørsel, så når du tilbakekaller eierrollen til en bruker, blir adminsesjonen deres ugyldig med en gang.

Medlemmer og eksterne samarbeidspartnere har ikke tilgang til /admin. Ruten svarer med 403 og meldingen «not an org owner».

Faner

Billing

frem.sh/<org>/_admin/billing dekker alt som har med penger å gjøre.

• Nåværende antall brukere og estimat for månedsregningen
• Status for betalingsmåten (med lenken «Set up payment» hvis det ennå ikke finnes noen fullmakt, eller «Replace payment method» hvis den eksisterende fullmakten ikke virker)
• Fakturahistorikk med kvitteringer du kan laste ned
• Flyt for å si opp abonnementet (sikret ved at du skriver inn organisasjonens slug for å bekrefte)

Oppsigelsesflyten setter cancellation_scheduled med en frist på 30 dager før oppsigelsen trer i kraft. I denne perioden kan kunden angre fra adminflaten eller fra lenken i e-posten som sendes ved oppsigelsen. Etter fristen går organisasjonen over til cancelled (skrivebeskyttet oppbevaring i 60 dager til), deretter deleted (sletting etter databehandleravtalen §9).

SSO

frem.sh/<org>/_admin/sso, føderasjon av identitet til din IdP.

• Bekreftede domener: bevis at du kontrollerer et e-postdomene med en DNS TXT-post eller en .well-known-fil over HTTP. Kreves før en autentiseringskilde som bruker domenet, aktiveres.
• Autentiseringskilder: registrer OIDC-leverandører.

Når domenet er bekreftet og kilden registrert, logger brukerne dine inn med sin IdP på frem.sh/<org>/login. PAT-er og SSH-nøkler er fortsatt gyldige i seg selv. Når Require SSO er slått på, validerer fremforge IdP-sesjonen på nytt hvert 15. minutt ved Git-operasjoner, så en bruker som deaktiveres i IdP-en, mister Git-tilgangen innenfor det tidsrommet selv om nøkkelen fortsatt ligger på kontoen. Se OIDC SSO for hele håndhevingsmodellen.

Se migrering → GitHub → Steg 7: Bekreft og avvikle for hvordan du bekrefter SSO-innlogging som del av en full migrering, eller følg stegene for å sette opp en autentiseringskilde direkte i SSO-fanen beskrevet over.

Security

frem.sh/<org>/_admin/security/overview. Security-gruppen i sidemenyen har åtte oppføringer, i den rekkefølgen du jobber deg gjennom et funn: oppdage, prioritere, rette, rapportere, pluss policyene som avgjør hva som er tillatt og hvem som slipper inn.

Alle eldre adresser til disse sidene, for eksempel _admin/security/policies/edge, _admin/code-security/…, _admin/compliance-evidence eller _admin/attestations, videresendes til den nye fanen. «Edge policies» finnes ikke lenger: innstillingene ligger nå på Prioriter (Fix-by SLA, Pull request checks), Tilgang (IP allowlist, Support access, AI connectors og informasjonen om tofaktorautentisering på Authentication policy) og Rapporter › Varsler (sikkerhetsoppsummeringen).

Push-beskyttelse

frem.sh/<org>/_admin/security/policies/push-protection. Skanning etter secrets ved hver push er alltid på. Denne fanen inneholder listen over overstyringer og feilmodusen for skanneren.

• Siste avvisninger: hver push som ble blokkert fordi gitleaks fant et secret-mønster med høy tiltro. Klikk «Approve» for å gjøre den om til en engangsoverstyring eller en overstyring avgrenset til mønsteret.
• Aktive overstyringer: tillatelseslisten din. Hver overstyring har en begrunnelse (logget i revisjonsloggen) og kan avgrenses til regel, stimønster, commit eller repository. Du kan tilbakekalle en overstyring når som helst.

Hvis et funn er en ekte secret, roterer du den først hos tjenesten som utstedte den, fjerner den deretter fra historikken med git filter-repo, og pusher så. Hvis det er en falsk positiv (testdata, en bevisst offentlig legitimasjon), legger du til en overstyring avgrenset til stien. Se Push-beskyttelse.

Funn

frem.sh/<org>/_admin/security/findings/sast. Én fane per skanner: SAST, Dependencies, Licences, Container images, Skanning etter secrets, Malware (skanning av opplastinger etter skadevare), pluss Unntak. Hver fane viser funnene først, med én linje som sier om skanneren er på og ved hvilken alvorlighetsgrad pull request-sjekken feiler. Selve innstillingene ligger på Sikkerhet › Policyer › Skannere. Reglene et funn vurderes etter, for eksempel lisenslistene og sperren for image-pull, ligger under Sikkerhet › Policyer (se Sikkerhetspolicyer).

Avhengighetsoppdateringer

frem.sh/<org>/_admin/dependency-updates, under Sikkerhet › Utbedre (Build & deploy har en lenke til samme side). Én side med to spor: Sikkerhetsrettelser, én pull request per sårbar pakke drevet av funnene dine, og Versjonsoppdateringer fra hostet Renovate. Siden viser også hvilke repositoryer som er med, og den siste aktiviteten.

• Slå på: oppretter en bot-bruker per kunde og starter en nattlig kjøring for organisasjonens repositoryer.
• Siste kjøringer: de 10 siste Renovate-kjøringene med antall PR-er og eventuelle feil.
• Kjør nå: utløser en kjøring utenom tur (begrenset til én per time).
• Slå av: tilbakekaller botens token umiddelbart og fjerner den fra organisasjonen. PR-er som boten allerede har åpnet, forblir åpne.

Konfigurasjon per repository gjøres med renovate.json i roten av repositoryet. Se Avhengighetsoppdateringer for begge sporene, Versjonsoppdateringer for Renovate-referansen og Sikkerhetsrettelser for rettelses-pull requests drevet av funn.

Secrets

frem.sh/<org>/_admin/secrets, Actions-secrets på organisasjonsnivå som injiseres som miljøvariabler i hver CI-jobb i organisasjonen. Forgejo er lagringslaget (kryptert ved lagring). fremforge-administrasjonen videreformidler opprett-, les-, endre- og slett-operasjonene og sender revisjonshendelser med navnet på secreten, aktøren og tidsstempelet (verdien lagres aldri i fremforges database eller revisjonslogg).

• New / overwrite secret: navn (UPPER_SNAKE_CASE; kan ikke starte med FORGEJO_ eller GITHUB_) og verdi. Sender du inn et navn som allerede finnes, overskrives det; samme skjema er rotasjonsflyten.
• Active secrets: liste over navn med tidspunkt for opprettelse. Verdiene kan bare skrives; fremforge leser eller viser aldri en verdi igjen etter at den er opprettet.
• Slett: bekreftes i en JS-dialog confirm(). Workflower som refererer til secreten, feiler til den opprettes på nytt.

Organisasjons-secrets arves av hvert repository i organisasjonen. For omfang per repository setter du secreten under Repository → Innstillinger → Actions → Secrets i Forgejos eget grensesnitt. For omfang per miljø setter du den under Organisasjonsadministrasjon → Miljøer → <env> → Miljø-secrets (frem.sh/<org>/_admin/environments). Det mest spesifikke omfanget vinner: en miljø-secret med samme navn som en organisasjons-secret skygger for organisasjons-secreten i jobber i det miljøet.

Se Secrets for den fullstendige referansen, inkludert API-stien og rotasjonsprosedyren.

Standarder for repositoryer

frem.sh/<org>/_admin/repo-defaults videresender til Sikkerhet › Policyer › Regler for repositoryer (_admin/security/policies/repository-rules#org-baseline): standardene for branchbeskyttelse i organisasjonens repositoryer, for eksempel påkrevde godkjenninger, gjennomgang fra CODEOWNERS og signerte commits. Se Branchbeskyttelse.

Webhooks

frem.sh/<org>/_admin/webhooks, leveringshistorikk og ny levering for webhooks for hendelser som spres i hele organisasjonen. Oppretting av webhooks (hvilke hendelser du abonnerer på, mål-URL, signerings-secret) konfigureres i Forgejos eget grensesnitt på /<org>/-/settings/hooks (organisasjonsnivå) eller /<org>/<repo>/settings/hooks (repositorynivå). fremforge eier dashbordet for leveringshistorikk under administrasjon → Webhooks; Forgejo eier registreringen.

• Nylige leveringer: se på enkeltforsøk på levering, svarkoder og nyttelast.
• Redeliver: send en hvilken som helst hendelse på nytt fra historikkvisningen. Nyttig for å feilsøke feil hos mottakeren etter en rettelse.

Organisasjonswebhooks utløses for hendelser med samme form som webhooks per repository. Se webhooks for den fullstendige referansen over hendelsestyper og nyttelastskjemaet.

Miljøer

frem.sh/<org>/_admin/environments, utrullingsmiljøer i GitHub-stil for CI/CD-jobber. Hvert miljø har et navn (som workflow-YAML refererer til med jobs.<id>.environment: <name>), beskyttelsesmønstre for brancher og tagger, avgrensede secrets og avgrensede variabler.

• Brancher og tagger for utrulling: glob-mønstre (main, release/*, v[0-9]*) som begrenser hvilke refs som kan rulles ut til miljøet. Refs som ikke passer, avvises før runneren i det hele tatt henter workflowen.
• Miljø-secrets: krypterte secrets som injiseres i jobber som kjører med environment: <name>. De skygger for organisasjons-secrets med samme nøkkel. Nyttig for legitimasjon som bare skal brukes i produksjon.
• Miljøvariabler: miljøvariabler som ikke er hemmelige (region, utrullings-URL og lignende), knyttet til miljøet.
• OIDC federation: hver workflow-kjøring har et OIDC-token der sub-claimen inneholder navnet på miljøet (repo:owner/repo:environment:prod). Stol på dette i skyens IdP for å gi kortlivet utrullingslegitimasjon uten langlivede secrets.

Se utrullings-secrets for en fullstendig gjennomgang av OIDC-føderasjon, inkludert tillitspolicyer for AWS, Azure, GCP og T Cloud Public.

Oppbevaring av byggeartefakter

frem.sh/<org>/_admin/artifact-retention, organisasjonens innstilling for hvor lenge artefakter fra Forgejo Actions (byggeresultater, testrapporter, feilsøkingspakker) oppbevares, i dager fra 1 til 90. Standard er 30 dager for nye organisasjoner, og organisasjoner som aldri hadde endret verdien, gikk fra 90 til 30 dager 2026-10-21. En verdi du har satt selv, beholdes.

Hva som faktisk sletter en artefakt i dag. Forgejo lar en artefakt utløpe etter retention-days som ble oppgitt ved opplasting, eller etter plattformens tak på 90 dager (Forgejo-instansens [actions].ARTIFACT_RETENTION_DAYS), det som kommer først. Organisasjonsinnstillingen over sletter ennå ingenting: den nattlige jobben som skal bruke en kortere verdi, trenger et artefakt-API som denne Forgejo-versjonen ikke har. For å oppbevare artefakter i mindre enn 90 dager setter du retention-days ved opplastingen:

- uses: actions/upload-artifact@v3
  with:
    name: test-report
    path: report/
    retention-days: 7

Utløpte artefakter teller ikke lenger mot organisasjonens artefaktkvote.

SIEM-videresending

frem.sh/<org>/_admin/siem, strømmer kundens revisjonslogg til din SIEM nesten i sanntid. Støtter Splunk HEC, Sentinel HTTP Data Collector, Elastic Cloud og generisk webhook med HMAC-SHA256-signering. Splunk og Sentinel krever en tynn proxy som oversetter HMAC (se SIEM-videresending); Elastic Filebeat og generisk webhook kobles direkte. Hvert endepunkt kan testes med en syntetisk hendelse før det tas i bruk; endepunkter som feiler, får gradvis lengre ventetid mellom forsøkene, og feilene vises i operatørportalen.

Leverandørattestering og kontrollbevis

Begge ligger under Sikkerhet › Rapporter: Leverandørattestering (_admin/security/reports/vendor-attestation) er et dokument om fremforge som din leverandør, og Kontrollbevis (_admin/security/reports/control-evidence) knytter organisasjonens revisjonshendelser til kontroller i SOC 2 og ISO 27001. SLSA-byggeproveniens ligger under Sikkerhet › Komponenter › Byggeattesteringer; se SLSA-proveniens.

Livssyklus for organisasjoner og repositoryer

Noen operasjoner står utenfor fanene fordi de gjøres én gang, ikke er løpende konfigurasjon. De ligger der de naturlig hører hjemme (innstillingene for repositoryet eller siden for å gi organisasjonen nytt navn), men de nevnes her så de ikke blir usynlige.

Gi en organisasjon nytt navn

frem.sh/<org>/_admin/settings, endre organisasjonens slug. Eksisterende repository-URL-er, klone-URL-er, API-kall og referanser i webhook-nyttelast som bruker den gamle slugen, videresendes fortsatt i 90 dager etter navnebyttet. Etter 90 dager kan den gamle slugen registreres av andre igjen, så planlegg overgangen, oppdater integrasjonene mens videresendingen virker, og ikke vent med det.

Navnebyttet utføres av en eier av organisasjonen, logges i revisjonsloggen og bekreftes ved at du skriver inn den gamle slugen.

Overføre et repository til en annen organisasjon

frem.sh/<org>/<repo>/settings → Transfer ownership. Et repository kan overføres til en annen organisasjon du eier (eller til en annen brukers konto; brukeren må godta). Ved overføring:

• Alle brancher, tagger, historikk, issues, PR-er, utgivelser, pakker, webhooks og CI-workflow-kjøringer følger med repositoryet.
• Forker av repositoryet på fremforge blir der de var; de oppdaterer automatisk upstream-pekeren til den nye adressen.
• git clone, git fetch og HTTP API-URL-er mot den gamle stien <org>/<repo> videresendes i 90 dager, samme periode som ved et navnebytte for organisasjonen. Oppdater remotes når det passer; videresendingen er en driftsbuffer, ikke en permanent garanti.

Overføringen styres av policyen i målorganisasjonen: hvis målorganisasjonen krever SSO, signerte commits og lignende, arver det overførte repositoryet den policyen når det kommer fram. Eksisterende regler for branchbeskyttelse i repositoryet beholdes, med mindre standardene i målorganisasjonen er strengere.

Si opp et abonnement

Utføres av en eier, sikret ved at organisasjonens slug skrives inn. Se fanen Fakturering over for oppsigelsesflyten og siden Fakturering for tilstandene i livssyklusen (oppsigelse planlagt → oppsagt → slettet).

Slette en personlig konto

Hører ikke hjemme i organisasjonsadministrasjonen. Sletting av personlige kontoer (retten til sletting etter GDPR) ligger under Brukerinnstillinger → Konto. Se Din fremforge-konto for hele flyten, inkludert hva som bevares som historisk attribusjon.

Branchbeskyttelse, begrepsreferanse

Branchbeskyttelse følger et hierarki i tre nivåer: plattformens minimum (satt av fremforge, kan ikke konfigureres) → organisasjonens standard (satt av eieren av organisasjonen, gjelder alle repositoryer) → regler per repository (kan stramme inn organisasjonens standarder, men ikke løsne under organisasjonens minimum).

Organisasjonens standardbeskyttelse: Sikkerhet › Policyer › Regler for repositoryer, standarder for branchbeskyttelse. Sett regler som gjelder alle nyopprettede repositoryer og alle eksisterende repositoryer som ikke har en strengere overstyring på repositorynivå.

Beskyttelse per repository: Repository → Innstillinger → Brancher → Legg til ny regel. Skriv inn et mønster for branchnavnet (for eksempel main, release/*). Tilgjengelige beskyttelser:

Plattformens minimum: Plattformen håndhever følgende: signerte commits er tillatt (ikke påkrevd) på plattformnivå; skanning etter secrets kjører uansett innstillinger for branchbeskyttelse; revisjonsloggen registrerer alle force-push-hendelser selv om force push ikke er blokkert.

Arv av policy: Hvis organisasjonens standard krever 1 PR-gjennomgang og en regel i repositoryet krever 2, vinner den strengeste regelen (2). Regler i repositoryet kan bare stramme inn, ikke løsne.

Dataeksport

frem.sh/<org>/_admin/data-export, fullstendig eksport med selvbetjening.

• Start en ny eksport: setter sammen én signert .tar.gz med en git bundle per repository, hvert repositorys issues, pull requests, kommentarer, etiketter, milepæler og utgivelser, pakkeoversikten og et utsnitt av revisjonsloggen for 90 dager. Se Dataeksport for nøyaktig hva den inneholder.
• Nylige jobber: de 20 siste eksportjobbene med nedlastingslenker (gyldige i 7 dager etter at de er klare) og status.

Begrenset til én eksport per organisasjon per 24 timer. Pakker over 50 GB bruker en annen prosedyre. Kontakt support.

Se dataeksport for oppbygningen av pakken, oppskrifter for å bekrefte den og API-endepunktene.

Innstillinger

frem.sh/<org>/_admin/settings, grunnleggende metadata for organisasjonen: synlighet (public / limited / private), visningsnavn, beskrivelse, nettsted og sted. Endringer her videreformidles til Forgejo med PATCH /api/v1/orgs/{org} og sender revisjonshendelsen tenant.org.settings.updated.

Innstillinger som håndteres andre steder:

• Organisasjonsnavn (slug): å gi slugen nytt navn er en Forgejo-handling med 90 dagers videresending; håndteres i Forgejos eget grensesnitt under /<org>/-/settings.
• Avatar / profilbilde: Forgejos eget grensesnitt under /<org>/-/settings.
• Fakturering, SSO, sikkerhetspolicy, push-beskyttelse: se de egne fanene over.

Grensen: fremforge-administrasjonen eier organisasjonsnavn (visning), synlighet, nettsted, beskrivelse og sted i tillegg til de egne fanene for abonnement, policy, sikkerhet og revisjon. Forgejos eget grensesnitt på /<org>/-/settings eier avatar / profilbilde, nytt navn på slugen, Forgejos interne standarder for nye repositoryer og dypere konfigurasjon som bare finnes i Forgejo. Begge kan nås fra eierkontoer; velg flaten som passer endringen du gjør.

Revisjonslogg

frem.sh/<org>/_admin/audit-log, hver adminhandling som endrer tilstand i organisasjonen din, til å bla i i sanntid.

• Actor filter: avgrens til én bestemt Forgejo-bruker, til operatørhandlinger (med prefikset operator:<email>) eller til en agent. Filteret matcher aktøren, personen en agent handlet for og selve agenten, så et filter på en bruker tar med det agenter har gjort på brukerens vegne.
• Via agent chip: en handling en agent har utført på vegne av en person, oppgir personen som aktør og merkes via agent; agentens id står i hendelsens felt agent.
• Action filter: avgrens til et navnerom (for eksempel push-protection eller billing.cancel).
• Since filter: avgrenset i tid.
• Operator badge: handlinger som ansatte i fremverk utfører på organisasjonens vegne, utheves i oransje og skjer aldri i det stille. De samme dataene havner i revisjonsutsnittet i dataeksportpakken din.

Eldre hendelser kuttes etter 200 rader på skjermen. For fullstendige historiske uttrekk bruker du Dataeksport. Revisjonsutsnittet i pakken har ingen slik grense.

Oppbevaring. Etter databehandleravtalen, vedlegg A.7 ligger sikkerhetsrelevante hendelser (autentisering, autorisasjon, adminhandlinger) i et søkbart varmt lag med en oppbevaringstid per kunde som du setter under Sikkerhet → Autentiseringspolicy → Oppbevaring av revisjonsloggen: forhåndsvalgene er 90 / 180 / 365 / 730 dager, med 90 (standardplan) eller 365 (enterprise-planer) som standard. Driftslogger (HTTP, runner, infrastruktur) holdes i det varme laget i 30 dager (kan ikke konfigureres). Begge lagene skrives til et uforanderlig WORM-arkiv på T Cloud Public OBS i 3 år, forankret i en hashkjede hvert 2. minutt slik at manipulering kan avsløres. Etter grensen for det varme laget sladdes innholdet (aktør, fields_json), men SHA-256-hashene i kjeden oppbevares i alle de 3 årene. Visningen på skjermen og revisjonsutsnittet i dataeksportpakken dekker begge den konfigurerte perioden i det varme laget. For å hente eldre hendelser fra WORM-arkivet kontakter du support@frem.sh.

API-ekvivalens

Hver adminhandling er også et dokumentert REST-endepunkt. Admingrensesnittet er selv en klient av det samme API-et en AI-agent ville brukt. Se offentlig REST API for OpenAPI-spesifikasjonen.

To navnerom, én vert. Ruter under /api/v1/... er Forgejos egne (samme form som upstream-Forgejos API, uten fremforge-prefiks, brukt til opprett-, les-, endre- og slett-operasjoner på organisasjoner, repositoryer, brukere, issues og PR-er som Forgejo allerede dekker). Ruter under /_app/api/v1/... er fremforge-utvidelser (tilleggene i kontrollplanet som vi legger oppå: fakturering, push-beskyttelse, dataeksport, hostet Renovate, SSO-policy, attesteringer). Kallet PATCH /api/v1/orgs/{org} som det vises til under §Innstillinger over, er Forgejos egen form; den samme verten betjener begge prefiksene gjennom ruting i plattformen. Velg prefikset som passer det dokumenterte endepunktet, og ikke bland dem.

Det betyr at alt du gjør i admingrensesnittet, også kan gjøres programmatisk:

• POST /_app/api/v1/orgs/<org>/dependency-updates/enrol, det samme som å klikke «Enable hosted Renovate» (fremforge-utvidelse)
• POST /_app/api/v1/orgs/<org>/exports, det samme som å klikke «Start a new export» (fremforge-utvidelse)
• GET /_app/api/v1/orgs/<org>/push-protection/overrides, lister aktive overstyringer av push-beskyttelsen (fremforge-utvidelse)
• PATCH /api/v1/orgs/<org>, oppdaterer visningsnavn / nettsted / sted / synlighet (Forgejos egen)
• …og så videre.

Autentisering med token: PAT utstedt fra brukerinnstillingene dine i Forgejo. OAuth 2.0 client credentials er planlagt sammen med flyten for agentidentitet.

Revisjonsspor

Hver adminhandling sender en strukturert logglinje til fremforges revisjonsstrøm med feltene actor, action, tenant_id og felt som er spesifikke for handlingen. Revisjonsloggen er med i dataeksportpakken, avgrenset til organisasjonen din.

Dette ser du i revisjonsutsnittet ditt:

• Alle POST- og DELETE-handlinger i admingrensesnittet (alt som endrer tilstand)
• Alle API-kall autentisert som et medlem av organisasjonen din
• Alle operatørhandlinger som ansatte i fremverk utfører på organisasjonens vegne (merket med actor=operator:<email>, aldri i det stille)

Dette ser du ikke (av personvernhensyn og juridiske hensyn):

• Interne infrastrukturhendelser hos fremverk (de går til en egen revisjonsstrøm)
• Identifikatorer som kobler hendelser på tvers av kunder (sladdet før eksport)

Se også

• Priser, hva som er inkludert i planen til 30 € per bruker
• Trust, underdatabehandlere, sertifiseringer og holdning til suverenitet
• Offentlig REST API, programmatiske ekvivalenter til hver adminhandling
• Migreringsguider, steg for steg-oppsett fra GitHub / GitLab / Azure DevOps