Projet

Général

Profil

Development #66488

tox : refactoring des cibles pour coller davantage aux dépendances dans leur version d’une release debian donnée

Ajouté par Paul Marillonnet il y a presque 2 ans. Mis à jour il y a presque 2 ans.

Statut:
Fermé
Priorité:
Normal
Assigné à:
Catégorie:
-
Version cible:
-
Début:
22 juin 2022
Echéance:
% réalisé:

0%

Temps estimé:
Patch proposed:
Oui
Planning:
Non

Description

problème relevé dans #66438, où on a des croisements étranges entre versions de dépendances dans les cibles tox.


Fichiers


Demandes liées

Lié à Authentic 2 - Development #66438: auth_oidc: JWK.get n'existe pas dans la version 0.8.0 de jwcrypto disponible en bullseye (remplacer par les accesseurs correspondant dans ce cas)Fermé21 juin 2022

Actions
Lié à Authentic 2 - Development #66595: tox: régorganiser les cibles autour des versions de debianRejeté24 juin 2022

Actions

Révisions associées

Révision cd12cdc0 (diff)
Ajouté par Paul Marillonnet il y a presque 2 ans

tox: remove deprecated dependency rules (#66488)

Révision 474b5691 (diff)
Ajouté par Paul Marillonnet il y a presque 2 ans

tox: explicitly match envs dependencies with debian releases (#66488)

Révision e89d757e (diff)
Ajouté par Paul Marillonnet il y a presque 2 ans

jenkins: adapt jenkinsfile scripts to env changes in tox.ini (#66488)

Historique

#1

Mis à jour par Paul Marillonnet il y a presque 2 ans

  • Lié à Development #66438: auth_oidc: JWK.get n'existe pas dans la version 0.8.0 de jwcrypto disponible en bullseye (remplacer par les accesseurs correspondant dans ce cas) ajouté
#3

Mis à jour par Paul Marillonnet il y a presque 2 ans

  • Lié à Development #66595: tox: régorganiser les cibles autour des versions de debian ajouté
#4

Mis à jour par Benjamin Dauvergne il y a presque 2 ans

À quoi sert la cible stable-backports ?

#5

Mis à jour par Paul Marillonnet il y a presque 2 ans

Benjamin Dauvergne a écrit :

À quoi sert la cible stable-backports ?

À tester le backports de django dans bullseye (version 3.2 au lieu de 2.2) et celui de django-tables qu’on imaginait faire nous-mêmes (#64568, la v2.4.1 au lieu de 2.2.1).

#6

Mis à jour par Paul Marillonnet il y a presque 2 ans

  • Assigné à mis à Paul Marillonnet
#7

Mis à jour par Benjamin Dauvergne il y a presque 2 ans

Bon je n'arrive pas à faire un truc qui fonctionne de mon coté, les contraintes de dépendances ne sont plus respectées quand je réorganise et je ne trouve pas la différence entre ton patch et le mien, mais j'aurai aimé encore simplifier les cibles pour enlever authentic du nom des cibles et avoir :
  • py3
  • py3-buster
  • py3-bullseye
  • py3-stable-backports
  • py3-rbac (et utiliser les règles rbac: et !rbac pour lancer les tests rbac ou authentic)

J'ai poussé une branche avec ces modifications pour voir si ça passe avec tes patchs.

#8

Mis à jour par Benjamin Dauvergne il y a presque 2 ans

Benjamin Dauvergne a écrit :

J'ai poussé une branche avec ces modifications pour voir si ça passe avec tes patchs.

Et ça marche ! \o/ Je vais quand même rebasé et testé localement parce que c'est [tox:jenkins] qui s'est exécuté ici.

#9

Mis à jour par Paul Marillonnet il y a presque 2 ans

Benjamin Dauvergne a écrit :

Et ça marche ! \o/ Je vais quand même rebasé et testé localement parce que c'est [tox:jenkins] qui s'est exécuté ici.

L’idée de l’environnement py3 c’est de tester sans chercher à attraper les dépendances dans leurs versions empaquetées dans debian, c’est ça ?

#10

Mis à jour par Benjamin Dauvergne il y a presque 2 ans

Paul Marillonnet a écrit :

Benjamin Dauvergne a écrit :

Et ça marche ! \o/ Je vais quand même rebasé et testé localement parce que c'est [tox:jenkins] qui s'est exécuté ici.

L’idée de l’environnement py3 c’est de tester sans chercher à attraper les dépendances dans leurs versions empaquetées dans debian, c’est ça ?

Oui, c'est de testé le paquet sur les dernières versions dispo sur pypi quand on a pas mis de limite de versions, ça nous permet de voir les soucis en avance (PS: et de maintenir le setup.py correctement).

#11

Mis à jour par Paul Marillonnet il y a presque 2 ans

Ok. Je squashe les modifications de ton commit wip respectivement dans 0002 pour les modifs du fichier tox.ini et dans 0003 pour les modifs du Jenkinsfile, c’est bon pour toi ?

#12

Mis à jour par Benjamin Dauvergne il y a presque 2 ans

Tout à fait.

#13

Mis à jour par Benjamin Dauvergne il y a presque 2 ans

L'histoire du kid a été corrigé après la 0.6, on n'y peut rien je crois, par défaut avant la 0.8 jwcrypto impose qu'un kid soit déclaré dans le header du jwt et dans le jwkset pour identifier la clé, dans les versions suivantes si pas de kid, il essaie toutes les clés du jwkset, je dois pouvoir retrouver le ticket github sur le sujet.

#14

Mis à jour par Paul Marillonnet il y a presque 2 ans

Benjamin Dauvergne a écrit :

L'histoire du kid a été corrigé après la 0.6, on n'y peut rien je crois, par défaut avant la 0.8 jwcrypto impose qu'un kid soit déclaré dans le header du jwt et dans le jwkset pour identifier la clé, dans les versions suivantes si pas de kid, il essaie toutes les clés du jwkset, je dois pouvoir retrouver le ticket github sur le sujet.

Avec le rebasage sur les modifications du tox.ini pour tester ces contraintes sur jwcrypto, ça donne ça.
Aussi, dans tox:jenkins on teste maintenant deux jeux de tests complets (buster et bullseye), ça éclate le temps de build des branches wip, je pense qu’il faut ne laisser que buster pour l’instant, et reléguer bullseye au job de la branche main.

#15

Mis à jour par Frédéric Péters il y a presque 2 ans

il faut ne laisser que buster pour l’instant, et reléguer bullseye au job de la branche main.

L'inverse plutôt. (on devrait refaire un point mais il y avait objectif bullseye partout pour ce premier semestre).

#16

Mis à jour par Benjamin Dauvergne il y a presque 2 ans

Frédéric Péters a écrit :

L'inverse plutôt. (on devrait refaire un point mais il y avait objectif bullseye partout pour ce premier semestre).

Oui allons y pour bullseye à parte django-tables2 et django-rest-framework il n'y a pas de différence dans les dépendances. Par contre je ne vois pas la contrainte sur jwcrypto pour buster et bullseye, pour bullseye ça devrait être au moins jwcrypto<0.9 (et pour buster on sait que ça marche <0.7 avec des limitations, on peut mettre pareil).

#17

Mis à jour par Benjamin Dauvergne il y a presque 2 ans

  • Statut changé de Solution proposée à Solution validée
#18

Mis à jour par Paul Marillonnet il y a presque 2 ans

  • Statut changé de Solution validée à Résolu (à déployer)
commit e89d757e352f0c6e7f7db16a49ed24f549f044e4
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Wed Jun 22 18:45:15 2022 +0200

    jenkins: adapt jenkinsfile scripts to env changes in tox.ini (#66488)

commit 474b56913a9c5c5e0346361e9530942f1f1a345d
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Wed Jun 22 18:43:15 2022 +0200

    tox: explicitly match envs dependencies with debian releases (#66488)

commit cd12cdc0ebffbc817e834a804f48cb3d142f5282
Author: Paul Marillonnet <pmarillonnet@entrouvert.com>
Date:   Wed Jun 22 18:36:22 2022 +0200

    tox: remove deprecated dependency rules (#66488)
#19

Mis à jour par Transition automatique il y a presque 2 ans

  • Statut changé de Résolu (à déployer) à Solution déployée
#20

Mis à jour par Transition automatique il y a plus d'un an

Automatic expiration

Formats disponibles : Atom PDF