Déploiement de summary

[simkim]

Summary dépend de 5 services : issues, packages, repos, timeline, commits

repos nous l'avons packages est stateless donc on peut utiliser l'officiel commits est statefull donc à déployer si besoin issues semble statefull mais pas sur qu'on en ai besoin ? timeline ne supporte que github à confirmer si statefull ou stateless

Dans ce contexte statefull veut dire qu'on doit déployer une db est lancer des jobs dessus stateless que l'app prend un repo en paramètre fait son action et renvoit les infos sans accéder à une db

[simkim]

La liste des services est de plus codé en dur, il faudra les passer en variable d'env

[bzg]

Dans https://data.code.gouv.fr/api/v1/hosts/github/repositories/micmacIGN/micmac j'ai l'impression que le pushed_at correspond bien à l'heure à laquelle est poussé le dernier commit.

(L'exemple donne la date/heure du 23 août 15h26, ce qui est la date/heure du dernier push au moment où les données sont collectées, le 26 août).

Est-ce que tu confirmes que le pushed_at correspond à cette information et qu'on n'a pas besoin du service commits pour cette info ?

[bzg]

Autre question pour mesurer l'intérêt d'ajouter d'autres services : https://data.code.gouv.fr/api/v1/hosts/github/repositories/micmacIGN/micmac propose un champ dependencies_parsed_at mais cette API ne donne pas la liste des dépendances, alors que l'API de summary la donne avec un champ dependencies (à tester sur https://summary.ecosyste.ms/docs/index.html).

Puisqu'on peut utiliser le service packages déjà déployé sur ecosyste.ms pour avoir la liste des dépendances?

Si oui, cela signifierait qu'on installerait un service summary juste pour avoir cette liste de dépendances, c'est bien ça ?

[simkim]

Dans https://data.code.gouv.fr/api/v1/hosts/github/repositories/micmacIGN/micmac j'ai l'impression que le pushed_at correspond bien à l'heure à laquelle est poussé le dernier commit.

(L'exemple donne la date/heure du 23 août 15h26, ce qui est la date/heure du dernier push au moment où les données sont collectées, le 26 août).

Est-ce que tu confirmes que le pushed_at correspond à cette information et qu'on n'a pas besoin du service commits pour cette info ?

Oui pour github, pour gitlab ca semble plutot être ma date de premiere synchro. Pushed_at n'est pas utilisé dans le connecteur gitlab. On a que le last_activity_at qui ne correspond pas au dernier commit mais au dernier n'importe quel modif

[simkim]

Autre question pour mesurer l'intérêt d'ajouter d'autres services : https://data.code.gouv.fr/api/v1/hosts/github/repositories/micmacIGN/micmac propose un champ dependencies_parsed_at mais cette API ne donne pas la liste des dépendances, alors que l'API de summary la donne avec un champ dependencies (à tester sur https://summary.ecosyste.ms/docs/index.html).

Puisqu'on peut utiliser le service packages déjà déployé sur ecosyste.ms pour avoir la liste des dépendances?

Si oui, cela signifierait qu'on installerait un service summary juste pour avoir cette liste de dépendances, c'est bien ça ?

On peut avoir les dependencies dans repo, si le champs dependencies_parsed_at est rempli c'est qu'on les as sur repo. Maintenant pour les avoir c'est potentiellement lourd / lent. Il fait appel à PARSER qui va lui donner un numéro de job et il faut relancer régulièrement pour avoir le résultat du job. Ca vaudrait le coup d'avoir un PARSER à nous pour que les jobs tournent plus vite.

Ensuite il faudrait soit ajouter un point d'api à REPO sous l'url /hosts/{hostName}/repositories/{repositoryName}/manifests soit directement dans le json du repository

[bzg]

OK, laissons tomber les dépendances pour l'instant.

Et pour le pushed_at laissons aussi tomber pour l'instant: j'utiliserai (peut-être) last_activity_at pour affiner le score.