Hacktoberfest 2026: die Issues, die Maintainer für den Oktober markiert haben – offen und einsteigerfreundlich. Hacktoberfest-Issues durchsuchen

[Feature][Grafana][config-ui] Gaps when running DevLake with a managed PostgreSQL and an external Grafana

Offen
#9,219 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 3 Tagen

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
3/5
Geschätzter Aufwand
1-2 Tage
Anfängerfreundlichkeit
42/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
docker-compose, nginx, postgresql, shell, typescript, vite

Rechercherichtung

This is a tracking issue for several separate gaps, so pick one item and work only on it. For the Grafana side, start in grafana/scripts/entrypoint.sh, where DATABASE_SSL_MODE and the hard-coded admin user are read, and check docker-compose-dev-postgresql.yml and env.example for the missing pass-through. For the config-ui side, start in nginx.conf for the external-Grafana redirect and in config-ui/routes/onboard/step-4.tsx and components/card.tsx for the Check Dashboard button. Done means the chosen item works as described with defaults unchanged.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

Search before asking
  • I had searched in the issues and found no similar feature requirement.
Use case

We run DevLake in Kubernetes with a managed PostgreSQL (TLS with a
corporate CA, sslmode=verify-full) and want to use a managed / external
Grafana
. Data sources are GitHub, GitLab, Jira and SonarQube.

The backend handles this setup fine (DB_URL is passed unchanged to pgx, so
sslmode=verify-full&sslrootcert=… works). The gaps are in the dashboard image
(grafana/scripts/entrypoint.sh) and in the config-ui. This issue collects
them in one place, so that the small PRs below can refer to it.

Description

Verified on main @ 4ad2f66df, PostgreSQL mode only. We do not run MySQL,
so MySQL paths are left unchanged and untested.

A. Dashboard image ↔ managed PostgreSQL over TLS (one small, additive PR planned)

  • DATABASE_SSL_MODE is read by entrypoint.sh (default disable), but
    docker-compose-dev-postgresql.yml / env.example do not pass it
    through (follow-up to #9207). Proposal: GRAFANA_DATABASE_SSL_MODE
    → DATABASE_SSL_MODE, default disable.
  • The PostgreSQL datasource payload has no sslRootCertFile /
    sslCertFile / sslKeyFile, so verify-ca / verify-full against a
    private CA fails. Proposal: optional DATABASE_SSL_ROOT_CERT
    (+ _CERT / _KEY) → jsonData.tlsConfigurationMethod: "file-path".
  • The API calls use a hard-coded admin: user. Renaming the admin via
    GF_SECURITY_ADMIN_USER silently breaks datasource creation, because
    the POST status is not checked. Proposal: ${GF_SECURITY_ADMIN_USER:-admin}
    plus a status check with a log message.
  • The entrypoint deletes all datasources on every start ("clean
    slate"). This is destructive when the Grafana state is shared (GF_DATABASE_*,
    several replicas, manually added datasources). Proposal for the PR: an
    opt-out DATASOURCE_CLEAN_SLATE=false. The default stays true, so
    the current behaviour is unchanged.

B. config-ui ↔ Grafana links (one small bug-fix PR planned)

  • With USE_EXTERNAL_GRAFANA=true, nginx.conf returns
    302 "${GRAFANA_ENDPOINT}" and drops the path and query, so every
    /grafana/d/<uid>/… deep link lands on the Grafana home page. Proposal:
    append the remaining path + $is_args$args.
  • Onboarding "Check Dashboard" (GitHub / GitLab,
    routes/onboard/step-4.tsx, components/card.tsx) calls
    window.open(import.meta.env.DEVLAKE_DASHBOARD_URL_*). The released
    image is built without a .env and the code has no fallback, so the
    button opens an empty tab. The example values in config-ui/env.example
    point to the MySQL UIDs (KXWvOFQnz, msSjEq97z), while the PostgreSQL
    dashboards use …-pg. Proposal: a DB-independent fallback (e.g.
    /grafana/dashboards?query=GitHub), or hide the button when the
    variable is empty. Also document the PostgreSQL UIDs.

C. Open points, no PR planned for now (feedback welcome)

  • Clean slate, alternatives to the opt-out: (i) delete only the DevLake
    datasource (UID devlake-postgres-api / devlake-mysql-api), or
    (iii) switch to file provisioning with env interpolation instead of the
    API.
  • Root-level dashboards ClaudeCodeAdoption*.json, Incidentio.json,
    Linear.json and Rootly.json reference the MySQL datasource
    devlake-mysql-api, but are also shipped in PostgreSQL mode, where they
    show datasource errors. Moving them to dashboards/mysql/ (plus
    PostgreSQL variants), and adding a dashboard-check rule against files
    directly under dashboards/, would fix this.
  • DEVLAKE_GRAFANA_PATH / DEVLAKE_DASHBOARD_URL_* are build-time only
    (Vite envPrefix). With relative /grafana/… links and the redirect
    fix from B this is fine for us. Runtime configuration (e.g. an
    env-config.js generated by nginx.sh) would only matter for setups
    with different dashboard UIDs or a non-default Grafana org. Noted here
    for completeness.
Related issues
  • #5009 — config-ui image support for optional/external Grafana (introduced USE_EXTERNAL_GRAFANA)
  • #9207 — Grafana against an external database via Compose (GRAFANA_DATABASE_*)
  • #4286 — deploying DevLake in a production setting
Are you willing to submit a PR?
  • Yes I am willing to submit a PR!

I will open the PRs for A and B one after another and link them here. They
are small and additive, and the defaults are unchanged.

Code of Conduct
  • I agree to follow this project's Code of Conduct
Vorherrschende Sprache
Go
Sterne
3.2k
Forks
819
Ø Merge
2 T. 21 Std.
Gemergte PRs (30 T.)
46

Entwicklungsumgebung

In Codespaces öffnen

Startet den Dev-Container des Projekts im Browser, mit Ihrem eigenen GitHub-Konto.

  • Kein Dockerfile und keine Docker-Compose-Datei
  • Hat eine Pull-Request-Vorlage
  • Kein Beitragsleitfaden

Erste Schritte

  1. Lesen Sie das ganze Issue und danach den Beitragsleitfaden des Projekts.
  2. Schreiben Sie ins Issue, dass Sie es übernehmen — das erspart doppelte Arbeit.
  3. Forken Sie das Repository und arbeiten Sie in einem Branch.
  4. Öffnen Sie einen Pull Request, der die Issue-Nummer nennt.

Mehr aus apache/devlake

Alle Issues in apache/devlake

Ähnliche Issues

Weitere Issues zu Go

Neue Issues direkt in Ihr Postfach

Eine kurze Übersicht über anfängerfreundliche GitHub-Issues.