datagouv / tableschema-template

Template de départ pour les dépôts contenant un schéma Table Schema
Other
7 stars 9 forks source link

feat: add workflow to check version consistency #8

Closed Pierlou closed 5 months ago

Pierlou commented 6 months ago

Merci pour cette review Pierre ! Pour les numéros de versions, nous cherchons à standardiser l'utilisation de vX.Y.Z pour les schémas de schema.data.gouv, dans un souci de cohérence, d'où ce choix. Nous pouvons aussi changer le pattern pour que le v soit facultatif, qu'en penses-tu ? De même dans les schémas que nous supervisons, les champs homepage et version sont attendus, nous y serons vigilants.

Pierlou commented 6 months ago

Merci pour ce retour Thibaut ! :pray: Point par point :

Pierlou commented 6 months ago

Update : j'ai modifié le code pour prendre en compte les datapackages et j'ai initié une PR sur le repo template : https://github.com/etalab/datapackage-template/pull/1 (qui montre d'ailleurs une incohérence due à l'absence d'un v comme tu le faisais remarquer Pierre). Tu pourras tester de ton côté Thibaut ?

thbar commented 6 months ago

Tu pourras tester de ton côté Thibaut ?

@Pierlou merci ! J'ai bien noté, je testerai et je te ferai un retour global aussi.

pierrecamilleri commented 6 months ago

... Nous pouvons aussi changer le pattern pour que le v soit facultatif, qu'en penses-tu ? ...

Comme nous sommes à l'origine du pattern et que nous avons l'opportunité de participer au groupe de travail pour la v2 de la spec, je dirais qu'on a tout intérêt à essayer de pousser un format unique avec le "v" ! (et donc garder le comportement actuel de ton script)

Pierlou commented 6 months ago

je dirais qu'on a tout intérêt à essayer de pousser un format unique avec le "v"

En réalité ici il s'agit uniquement de la détection des versions dans le schéma, pas de l'intention du choix du format. Dans la dernière version du script, le pattern cherche avec et sans le "v", pour détecter les cas où un schéma aurait des dissonances du type v1.0.0 VS 1.0.0. En parallèle, je suis effectivement d'accord pour qu'on pousse pour un formalisme unique 🤝

pierrecamilleri commented 6 months ago

En réalité ici il s'agit uniquement de la détection des versions dans le schéma, pas de l'intention du choix du format. Dans la dernière version du script, le pattern cherche avec et sans le "v", pour détecter les cas où un schéma aurait des dissonances du type v1.0.0 VS 1.0.0. En parallèle, je suis effectivement d'accord pour qu'on pousse pour un formalisme unique 🤝

Entendu, c'est parfait !

Pierlou commented 5 months ago

Poke @thbar est-ce que tu as pu te pencher sur le sujet ? 🙏 J'aimerais le passer sur d'autres schémas (on a beaucoup de cas où ce serait bénéfique) La version pour datapackage est ici : https://github.com/datagouv/datapackage-template/pull/1

thbar commented 5 months ago

@Pierlou je viens de faire un test, voilà l'output !

Versions are mismatched within the schema 'schema-irve-statique', expected version '2.3.0' but:
- path has version 'v2.3.0'
- resources[0].path has version 'v2.3.0'

Versions are mismatched within the schema 'schema-irve-dynamique', expected version '2.3.0' but:
- path has version 'v2.3.0'
- resources[0].path has version 'v2.3.0'

Voir:

C'est déjà chouette, je vais amender dans ce sens !

Il serait utile, à terme, d'avoir un check "pre-release" qui vérifie quand on pose un tag/crée une release que le tag ex: 'v2.3.1` est raccord avec ce qui est dans le schéma, et d'empêcher la création du tag/release si cela est possible ! (là ce n'est pas raccord chez nous, par exemple).

Chouette boulot, ça me paraît bien, je vais conserver de notre côté.

Pierlou commented 5 months ago

Merci pour ce retour ! En effet dans l'idéal ce serait bien d'avoir un process qui gère un peu tout (checks de cohérence, montée de version...). On pourrait imaginer un script qui passe lors d'une nouvelle release, mais je ne suis pas sûr de voir comment ça s'articulerait : l'action ici est sur un push, donc on a encore le temps d'amender avant de merge, mais lors de la création d'une release on n'a pas cette étape intermédiaire, donc on serait sur un test a posteriori ? Preneur d'idées sur le sujet

Pierlou commented 5 months ago

On a l'air d'avoir atterri sur un bon premier jet, merci à tous pour vos retours ! Je vous propose de continuer nos échanges sur le sujet dans cette issue