Sync API Entreprise/API Particulier fiches to data.gouv.fr#264
Sync API Entreprise/API Particulier fiches to data.gouv.fr#264Samuelfaure wants to merge 9 commits into
Conversation
93ba634 to
beea280
Compare
|
Problème: il faut sync back le datagouv_uid depuis l'action github 🤔 mais on a des règles de protection de commits et de PR reviews, faut que je trouve comment bypass pour les actions github |
|
On ne peut pas passer par un moissonneur ? |
|
Ce |
|
Faire faire des commits à travers une API c'est une très mauvaise idée btw. Faut trouver une autre solution. Vu qu'il y a l'air d'avoir un search ( https://guides.data.gouv.fr/api-de-data.gouv.fr/reference/dataservices ) je pense qu'il faut explorer cette piste. Ça simplifiera. Par ailleurs, je vois qu'il y a des exclus du style DGFIP/URSSAF.. c'est voulu ? |
|
Imo destroy de deprecated bonne idée datagouv_uid ça simplifie la sync mais effectivement je suis pas fan de la solution actuelle, le search sera peut-être bien meilleur si ça marche (imo ça devrait passer, faut juste faire un search à chaque sync, un peu lourd mais plus simple) Je crois pas qu'on puisse être source de vérité sur datagouv_uid vu que c'est set par datagouv (à explorer si on peut pas le set nous-même, juste au cas où ça soit possible) - mais avec le search on peut peut-être juste jarter tout ça Le moissoneur j'ai reçu l'avis de @nicolaskempf57 qui m'a tldr dit "ne fait pas ça" (la team a l'air assez terrifiée du code relatif au moissonnage, la complexité semble +++) |
Pourquoi ? Je ne vois pas de use case en fait, vu qu'un bump de version on garde le même uid et on udpate la donnée.
C'est évident oui, mais ça ne change pas le fait qu'on devrait être le seul "pusher" de la donnée et qu'on ne devrait pas avoir besoin de faire des itérations techniques avec les ids dans notre codebase (c'est clairement une béquille actuellement), d'où ma proposition de faire des search (limite sur le champ de l'url qui est imo une clé valide). |
|
dans les cas comme DGFIP-TVA vaudrait mieux suppr la fiche non? J'ai du mal à voir pourquoi tu veux garder des fiches d'endpoints depreciés sur datagouv |
Ces cas se comptent sur les doigts d'une main (voir c'est le seul ..?) |
|
OKAY U GOT A POINT lol |
|
Cela étant dit c'est une balance code/logique métier à maintenir VS confort de supprimer les dépréciés sur datagouv. Vu qu'actuellement ce n'est de toute manière par réellement maintenu un j'aurais tendance à ne pas le gérer mais j'ai aucun strong belief la dessus |
|
je serais partisan de le garder si t'as pas d'opinion forte du coup, flemme de me rappeller de delete manuellement si le cas repop |
6d4fa9d to
a9503c7
Compare
…ip_attestation fiches from datagouv sync These uids share a single datagouv_uid across deprecated/current pairs or grouped entries. Without sync_with_datagouv: false, SyncFiche's deprecated-endpoint deletion path would delete the shared dataservice out from under the still-live sibling. Only the deprecated member of each pair needs the flag to block its delete path -- the live dgfip/urssaf/qualibat members keep syncing normally. The INSEE (8-way) and DJEPVA (2-way) groups have no deprecated member at all (every entry is independently live), so all members stay excluded there to avoid different live entries fighting over the same remote dataservice's title/description on every run.
a9503c7 to
c6fc014
Compare
datagouv:sync takes uids via the SYNC_UIDS env var (comma-separated) -- the mechanism the GitHub Actions workflow uses, since Rake's bracket-arg CLI syntax (`datagouv:sync[a,b,c]`) splits on commas into separate positional arguments before the task runs and silently drops all but the first uid. The bracket argument remains a fallback for a single uid passed manually from a shell. datagouv:sync_all syncs every endpoint.
Runs on push to main (the auto-generated force-push from develop after CI goes green) when commons/endpoints/** changed, and computes the touched fiche uids from the push's before/after SHAs to sync only what changed; workflow_dispatch runs a full sync instead. DATAGOUV_HOST is a plain vars entry (swappable to point at production later) and DATAGOUV_API_TOKEN a secret. Sync is search-based (Datagouv::DataserviceIndex lists data.gouv.fr's own records and matches them by an embedded marker) rather than relying on a locally-stored id, so the workflow never writes back to the repo -- no repo write permissions needed, no branch-protection bypass required.
|
C'est techniquement prêt mais je suis pas sûr d'être satisfait du résultat, + faut tester en sandbox sur demo. Je demande pas encore les reviews du coup, je me laisse un peu de temps pour voir si je trouve mieux |
2 participants
Summary
commons/endpoints/*.ymlto data.gouv.fr's dataservices API, triggered by a GitHub Actions workflow when fiche files change (push tomain, i.e. the develop→main CI force-push, filtered tocommons/endpoints/**).datagouv_uidvalues are written back into the yml automatically, committed todevelopvia the GitHub Contents API so the commit is GitHub-signed (required bydevelop's branch-protection ruleset).sync_with_datagouv: falseadded to all endpoint entries that share adatagouv_uidwith a sibling (deprecated/current pairs, grouped INSEE Sirene/DJEPVA entries), so the shared dataservice is never deleted out from under a still-live sibling.demo.data.gouv.frvia theDATAGOUV_HOSTGitHub variable — swapping it todata.gouv.frlater works identically, since the client has no hardcoded demo reference (also need to change DATAGOUV_API_TOKEN)Test plan
bundle exec rspec spec/services/datagouv/ spec/clients/datagouv_api_client_spec.rb spec/models/abstract_endpoint_spec.rb spec/lib/tasks/datagouv_spec.rb— 62 examples, 0 failuresbundle exec rubocopon all touched files — clean (one pre-existing, unrelated offense ininflections.rb)datagouv_uidwithoutsync_with_datagouv: falsedemo.data.gouv.fronce the bot identity is added to the "Secure contain protek" ruleset's bypass list ondevelop(required for the write-back commit'spull_requestrule, separate from the signing fix already in place)