PapillonApp
EcoleDirecte - Menu étendu + 2FA
Checklist d'avant pull request
- [x] Vous avez testé de build le projet avec vos modifications et ce build a réussi
- [x] Vous respectez les conventions de codage et de nommage du projet
- [x] Vous utilisez la tabulation pour l'indentation afin de maintenir un code lisible
- [x] Cette pull request n'est pas un duplicata d'une autre
- [x] Cette pull request est prête à être revue (review) et fusionnée (merge)
- [x] Cette pull request doit être fusionnée dans la branche
development(le cas contraire préciser laquelle) - [x] Il n'y a pas de
TODO(aka des annotations pour du code manquant) dans vos modifications - [x] Il n'y a pas d'erreurs de langue dans votre code (grammaire, vocabulaire, conjugaison, orthographe)
- [x] Les détails des changements ont été décrits ci-dessous
- [x] Cette pull-request n'est pas une "breaking-change" (par exemple des modifications qui vont entraîner la modification du fonctionnement de certaines fonctionnalités déjà existantes)
Explications des changements
- Ajout d'un menu étendu pour certaines fonctions d'EcoleDirecte (Cloud, Documents)
- Prise en charge de la double authentification
Changelogs proposés
- Ajout d'un menu étendu pour certaines fonctions d'EcoleDirecte (Cloud, Documents)
- Prise en charge de la double authentification
Note
Pour que votre pull-request soit fusionnée, vous devez obtenir l'approbation de au moins deux membres de l'équipe dont un coordinateur. Soyez donc patient :)
À part erreur de ma part, il y avait déjà eu une issue sur cet aspect mais que le forfait gratuit de eas est trop limité (30 builds par mois)
Yes et aussi on a pas voulu mon idée pour faire un gh action qui dure indéfiniment
À part erreur de ma part, il y avait déjà eu une issue sur cet aspect mais que le forfait gratuit de eas est trop limité (30 builds par mois)
Non c'est pas une erreur, mais juste la docs d'expo qui est pas très bien fournie sur ce contexte ! Donc je vais résumer en gros ce que j'ai lu :
Le principe de faires des previews sur expo n'est pas reconnu comme un build. D'ailleurs ce n'est pas expo en lui même mais EAS (un de leurs services). EAS propose de multiples fonctions, dont le build en ipa / apk etc. C'est le service EAS build. Le service qui nous intéresse c'est le service EAS updates qui a des contraintes différentes qui sont les suivantes :
- Les builds ne doivent pas durer plus de 45min (mais je ne crois meme pas que les GitHub Actions puissent durer si longtemps)
- Les bundles sont limités à 30mo
- Les liens expirent au bout de 30j
Si une de ces conditions ne fonctionne pas au moment du build, le terminal informe l'utilisateur que le build a échouer et s'arrête automatiquement si aucun abonnement n'est lancer.
On va faire quelque test en interne, mais selon la doc, tout est ok ! 👌
En revanche toi, Louis, tu as du te tromper de doc (elle est foireuse je te l'accorde). Ton GH action publier la mises à jour sur les stores à chaque PR, ce qui n'est pas vraiment ce qu'on voulait !
Concernant les actions GitHub, voici les limites (tirées de la doc):
-
Durée d'exécution des tâches : chaque tâche d'un workflow peut s'exécuter pendant une durée maximale de 6 heures. Si une tâche atteint cette limite, elle est interrompue et ne parvient pas à se terminer.
-
Durée d'exécution du workflow - Chaque exécution du workflow est limitée à 35 jours. Si une exécution de workflow atteint cette limite, elle est annulée. Cette période comprend la durée d'exécution et le temps passé à attendre et à approuver.
Concernant les actions GitHub, voici les limites (tirées de la doc):
Durée d'exécution des tâches : chaque tâche d'un workflow peut s'exécuter pendant une durée maximale de 6 heures. Si une tâche atteint cette limite, elle est interrompue et ne parvient pas à se terminer.
Durée d'exécution du workflow - Chaque exécution du workflow est limitée à 35 jours. Si une exécution de workflow atteint cette limite, elle est annulée. Cette période comprend la durée d'exécution et le temps passé à attendre et à approuver.
Un workflow sur une pr dure 4h max
À part erreur de ma part, il y avait déjà eu une issue sur cet aspect mais que le forfait gratuit de eas est trop limité (30 builds par mois)
Non c'est pas une erreur, mais juste la docs d'expo qui est pas très bien fournie sur ce contexte ! Donc je vais résumer en gros ce que j'ai lu :
Le principe de faires des previews sur expo n'est pas reconnu comme un build. D'ailleurs ce n'est pas expo en lui même mais EAS (un de leurs services). EAS propose de multiples fonctions, dont le build en ipa / apk etc. C'est le service EAS build. Le service qui nous intéresse c'est le service EAS updates qui a des contraintes différentes qui sont les suivantes :
- Les builds ne doivent pas durer plus de 45min (mais je ne crois meme pas que les GitHub Actions puissent durer si longtemps)
- Les bundles sont limités à 30mo
- Les liens expirent au bout de 30j
Si une de ces conditions ne fonctionne pas au moment du build, le terminal informe l'utilisateur que le build a échouer et s'arrête automatiquement si aucun abonnement n'est lancer.
On va faire quelque test en interne, mais selon la doc, tout est ok ! 👌
En revanche toi, Louis, tu as du te tromper de doc (elle est foireuse je te l'accorde). Ton GH action publier la mises à jour sur les stores à chaque PR, ce qui n'est pas vraiment ce qu'on voulait !
Non, je n'ai pas fait de pr pour mon truc, pour avoir un workflow qui dure indéfiniment, il y avait 2 workflow qui se lançaient mutuellement
À part erreur de ma part, il y avait déjà eu une issue sur cet aspect mais que le forfait gratuit de eas est trop limité (30 builds par mois)
Non c'est pas une erreur, mais juste la docs d'expo qui est pas très bien fournie sur ce contexte ! Donc je vais résumer en gros ce que j'ai lu :
Le principe de faires des previews sur expo n'est pas reconnu comme un build. D'ailleurs ce n'est pas expo en lui même mais EAS (un de leurs services). EAS propose de multiples fonctions, dont le build en ipa / apk etc. C'est le service EAS build. Le service qui nous intéresse c'est le service EAS updates qui a des contraintes différentes qui sont les suivantes :
- Les builds ne doivent pas durer plus de 45min (mais je ne crois meme pas que les GitHub Actions puissent durer si longtemps)
- Les bundles sont limités à 30mo
- Les liens expirent au bout de 30j
Si une de ces conditions ne fonctionne pas au moment du build, le terminal informe l'utilisateur que le build a échouer et s'arrête automatiquement si aucun abonnement n'est lancer.
On va faire quelque test en interne, mais selon la doc, tout est ok ! 👌
En revanche toi, Louis, tu as du te tromper de doc (elle est foireuse je te l'accorde). Ton GH action publier la mises à jour sur les stores à chaque PR, ce qui n'est pas vraiment ce qu'on voulait !
Et si tu parles de cette pr : https://github.com/PapillonApp/Papillon/pull/183 savais juste pas lire, il ne publiait jamais sur les stores quand on le lançaient via pr