Read service containers as CI facts and judge database engine versions as a platform axis (SQL)

Offen
  • Stimmt etwas nicht?
#148 0 Kommentare 0 Reaktionen 0 zugewiesene Personen Auf GitHub ansehen

Maintainer antworten meist innerhalb von 1 Tag

Dieses Issue hat noch niemand übernommen.

Bewertung

Schwierigkeit
5/5
Geschätzter Aufwand
Über eine Woche
Anfängerfreundlichkeit
35/100
Issue-Typ
Feature
Klarheit
Größtenteils klar
Aktivitätsstatus
Aktiv
Tech-Stack
github-actions, gitlab, python, sql
Bereich
ci-cd, databases, devtools

Rechercherichtung

Start with docs/ecosystems/sql.md and the CI profile and check logic it describes. Trace how GitHub Actions and GitLab CI jobs are read, then identify where service image versions and platform axes are represented. Done means service containers are collected as per-job facts and SQL engine versions can be evaluated as a platform axis without requiring an OS grid.

Vom Indexierungsmodell aus dem Issue-Text verfasst.

Beschreibung

docs/ecosystems/sql.md (#139) explains why platform-matrix does not apply to SQL: the toolchains of a database project are database engine versions (the postgres:16, mysql:8 service containers CI runs), and the platform policy also asks for several operating systems, which SQL has no use for. A policy of engine versions alone would be a change to the check, not to the profile.

Two parts:

  • read service containers (services: in GitHub Actions jobs, services: in GitLab CI) as facts: image and version per job; nothing reads them today, although they are what a dbt or migration project is tested against;
  • a platform policy for ecosystems whose axis is not an OS × toolchain grid: several engine versions, any OS. The SQL profile would then declare a ToolchainAxis of engine versions and stop being skipped.

🤖 Generated with Claude Code

https://claude.ai/code/session_01ByTXNqDWdM7HzezrFtEvQt

Vorherrschende Sprache
Python
Sterne
4
Forks
1
Ø Merge
10 Std. 41 Min.
Gemergte PRs (30 T.)
79

Entwicklungsumgebung

Dieses Projekt bietet weder Dev-Container noch Dockerfile noch Beitragsleitfaden – die Einrichtung liegt bei Ihnen. Beginnen Sie mit der README; die allgemeinen Schritte stehen in unserem Leitfaden für den ersten Beitrag.

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 cpp-best-practices/project_validator

Alle Issues in cpp-best-practices/project_validator

Ähnliche Issues

Weitere Issues zu Python

Neue Issues direkt in Ihr Postfach

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