Ğecko talks / user support

Clients Ğecko
#84

En fait je ne créer plus de release sur le gitlab car j’ai automatisé le déploiement.
En fait je créer des tags à chaque fois: Tags · clients / Ğecko · GitLab

Mais le liens de l’APK n’y est pas, est-ce que ça t’irais si les prochaines fois je rajoute le lien vers l’APK dans ces messages de tags ?

Les liens seront toujours au format https://gecko-apk.p2p.legal/dl/gecko-VERSION.apk
Donc même si on a pas le lien on peut le deviner si a la lien de la version précédente.

Je ne sais pas comment créer des release en ligne de commande, c’est une mécanique propre à gitlab donc je suppose qu’il faut passer par l’api gitlab, alors que là je fait juste:

TAG_MESSAGE="$(git log --pretty='format:- %s ([%C(auto)%h](https://git.duniter.org/clients/gecko/-/commit/%C(auto)%h)) ' $LAST_VERSION...HEAD --no-merges)"
git tag -a v$VERSION -m"$TAG_MESSAGE" || exit 1
git push --tags || exit 1

Et j’ai un hook qui lance automatiquement le build côté CodeMagic et publie sur le playstore, lorsqu’un tag commençant par v est push sur master.
@llaq est en train de mettre un hook sur ces tags aussi pour fDroid, comme il connait le pattern des liens de téléchargement il n’en a pas besoin dans les messages de tags.

1 « J'aime »
#85

Non pas dans le message de commit c’est sale.

Le mieux c’est de créer la release gitlab automatiquement quand le git tag est push, c’est assez simple à faire avec gitlab: Releases | GitLab

Quelque chose dans ce style devrait fonctionner:

release_job:
  stage: release
  image: registry.gitlab.com/gitlab-org/release-cli:latest
  rules:
    - if: $CI_COMMIT_TAG                 # Run this job when a tag is created
  script:
    - echo "running release_job"
  release:
    tag_name: '$CI_COMMIT_TAG'
    description: '$CI_COMMIT_TAG'
    assets:
      links:
        - name: 'android-apk'
          url: 'https://gecko-apk.p2p.legal/dl/gecko-$CI_COMMIT_TAG.apk'
2 « J'aime »
#86

Ca m’a l’aire super ça!

Par contre il faut que la CI gitlab fonctionne pour ça, hors j’ai encore des soucis, je comptais l’abandonner pour rester exclusivement sur la CI de codemagic, qui me fait déjà le déploiement sur le PlayStore oklm et tout…

Même si en vrai là j’ai quasiement finit de debuguer la CI gitlab de gecko…

#87

Est-ce que codemagic te permet de jouer les tests sur chaque push d’une MR ouverte ?

Parce que l’intérêt principal de la CI de gitlab c’est ça: tester une MR à chaque push d’un nouveau commit pour vérifier qu’elle n’induit pas de regression :slight_smile:

L’idéal étant de configurer gitab de manière à ne pas pouvoir merger une MR si la CI ne passe pas, et ne pas pouvoir push sur master, ça donne de bonnes garantie que master ne sera pas cassé facilement, et ça apporte un cadre sécurisant pour les nouveaux contributeurs.

Ça n’empêche pas de garder le webhook codemagic pour la partie packaging et publication, qui correspond plus à la partie « CD » que « CI » :wink:

#88

Oui bien sûr, et plus encore, il fait vraiment le café:

image
image1318×842 61.5 KB

Alors là j’avoue que je ne fonctionne plus du tout en MR avec Ğecko étant donnée que je suis solo à dev dessus, et que je me sert justement plus de la CI gitlab, je merge en local…

Je sais que ce n’est pas l’idéal, mais franchement redshift pour la CI gitlab est super lente, bien plus lente que la VM la plus lente de codemagic…

Oui je pense que je vais garder codemagic pour les tests (pas encore activés), les builds et publications playstore/appstore.
Je peux changer la CI gitlab de gecko pour juste créer une nouvelle release à chaque tag v*, comme ton template le suggère, mais je ne mettrait que ça dedans du coup.

1 « J'aime »
#89

404 :’(

1 « J'aime »
#90

arf… fix !
C’est mon cron de cleanup des vieux APK qui faisait les choses à l’envers, il gardait uniquement les 5 plus vieux APK au lieux de garder les 5 plus récent … c’est réparé.

1 « J'aime »
#91

C’est mieux, mais :

L’application n’a pas été installée, car le package semble ne pas être valide.

:cry:

#92

Oui alors j’ai eu ce problème il faut désinstaller l’app pour installer cette nouvelle version, mais j’ai compris pourquoi. C’est le numéro de build après + qui en fait ne doit pas être utilisé comme je le fait depuis le début, car il doit toujours être supérieur ou égal au précédent, exemple: v0.0.9+2 est une version inférieur à v0.0.8+9 pour Android car 2<9 …

Donc je vais devoir arrêter mes +truc entre chaque version… Ou plutôt l’incrémenter constamment, et toujours incrémenter le numéro de version lorsque c’est une version officielle.

1 « J'aime »
#93

Tiens pour vérifier que ce que je dit est vrai, normalement avec ce build tu ne devrait plus avoir de problème d’install, alors que c’est le même que +2 mais avec un numéro de build +10: https://gecko-apk.p2p.legal/dl/gecko-0.0.9+10.apk

Dites moi si c’est bien le cas, je changerai le lien dans mon message précédent et le topic.

2 « J'aime »
#94

C’est bon, application installée avec ce dernier lien. :+1:

1 « J'aime »
#95

Bon par contre j’ai dû supprimer les données sinon l’application affichait indéfiniment le logo Ğecko au démarrage.

#96

Ah merde, le logo Ğecko ?
Ya pas de logo Gecko au démarrage, c’est bizarre j’ai jamais eu ce soucis.

Peut être dû à l’échec d’install de l’apk précédent, mais j’en doute :thinking:

bon normalement il a du retrouver automatiquement tes portefeuilles actifs, faut juste remettre les image si présentes, et les nom pour les portefeuilles sans identités si ils ont été changés…
J’aimerai reproduire ton bug.

#97

Je confirme que le numéro de version m’a posé problème aussi, j’ai désinstallé / réinstallé. N’hésite pas à sortir une version 0.1.0 pour pouvoir incrémenter dessus. C’est pas grave si on arrive à 0.1.223, 0.1.224, 0.1.225 avant de passer à la 0.2.0 :wink:
Et on gardera la v1.0.0 pour le passage de la ĞDev à la Ğ1 !

1 « J'aime »
#98

Je pense plutôt continuer comme avant sauf que je ne vais jamais reset la numéro de build après chaque monté de version comme je faisais.

Ca donnera des versions genre 0.0.11+329 ect … Le numéro de build étant toujours représentatif d’un build unique.

Mais c’est vrai qu’il va être temps de passer en v0.1.0+x bientôt oui :slight_smile:

1 « J'aime »
#99

J’ai peur que tu fonces seul trop vite, une app mobile c’est un très gros projet il va grossir et grossir encore, et tot ou tard tu ne pourras plus le maintenir seul.

Il me semble important de ralentir et mettre en place dès maintenant le nécessaire pour pouvoir accueillir d’autres contributeurs: identifier des issues faciles, mettre en place un workflow qui fonctionne à plusieurs et qui soit sécurisant (qu’on ait pas peur de tout casser en contribuant).

Tu as beaucoup appris en Flutter depuis 2 ans, il va être temps de transmettre et de créer une équipe :slight_smile:

Oui ça demande de ralentir, oui tout seul on va plus vite, mais ensemble on va plus loin, ça ne sert à rien de rusher une app complète que tu ne pourras pas maintenir seul dans la durée.

2 « J'aime »
#100

En premières contribution, moi ce dont j’ai le plus besoin, c’est de quelqu’un qui s’occupe de la CI de Ğecko sur le gitlab, ainsi qu’un serveur de CI plus puissant que redshift.

Ensuite, je n’ai jamais fait d’atelier ou formation de ce genre, ce serait une première pour moi.

Il faudrait déjà que je sonde sur ce forum qui serait intéressé par un workshop sur Ğecko, ou sur Flutter de manière plus général.

Je disais à Hugo tout à l’heure, que j’ai bien envie de transformer le gdev_annuaire en Ğecko explorer, uniquement pour web, lecture seul sur l’indexer, avec une recherche avancée, vue en tuile des profiles comme Ğecko, activités des profiles, ect …

Ca me semble beaucoup plus abordable pour commencer à mettre les mains dans Flutter pour plusieurs raisons:

  • Pas besoin de la stack android studio et compagnie, ni d’émulateur, chrome et vscode suffisent
  • Projet naissant que je n’ai pas encore architecturé mais je compte reprendre globalement la même archi que Ğecko
  • Beaucoup plus simple comme app, pas de gestion de coffre/portefeuille, pas de paiement ni certifs, que de l’exploration

Même si ça me démange de bosser sur cet annuaire, parceque ça me parait très simple et que ça me change un peu de Ğecko et sa complexité, je sais que ce serait bien de plutôt organiser des workshop en visio/peerprograming pour accompagner des contributeurs à le faire.

Je vais lancer un sondage pour voir si ça intéresse du monde.

2 « J'aime »
#101

Pour Ğecko c’est vrai que la stack est un peu trop galère à installer…

Pour simplifier ça, je pense qu’il faudrait que tu définisse un devcontainer, ça permettrais à n’importe-quel dev qui à vscode et docker de pouvoir contribuer à Ğecko sans rien avoir à installer :slight_smile:

J’ai trouvé un type qui à déjà fait ça pour flutter android:

En plus il map l’usb, donc normalement ça permet même de tester sur son phone en debug usb :wink:

2 « J'aime »
#102

Je pense qu’on est dans une phase où il faut se permettre d’aller vite. Un app comme Ğecko est un projet qu’on peut être amené à réécrire en grande partie plusieurs fois avant de stabiliser ce qu’on veut, tout simplement parce que les spécifications changent avec le temps. Évidemment avant de sortir la Ğ1 il faudra consolider et restructurer, mais pour l’instant ça me semble trop tôt et handicapant.

Il ne faut pas oublier que Ǧecko a commencé sur GVA avec tes bindings Rust et que maintenant c’est sur Substrate RPC avec un binding Javascript Polkadotjs et Apollo GraphQL pour l’indexeur. De plus l’écosystème Dart/Flutter évolue encore assez rapidement, Poka est obligé de maintenir des forks pour corriger des problèmes de null safety qui ne seront peut-être pas corrigés upstram. Il n’est pas impossible que dans un an ou deux, on préfère écrire une nouvelle lib en pur Dart pour remplacer des bouts entiers.

Je pense que ce serait une erreur de gérer la codebase de Ǧecko comme celle de Duniter-v2s, surtout à ce stade du projet où on a besoin de beaucoup de flexibilité.

Donc mon avis personnel est qu’il n’est pas encore temps de ralentir, c’est trop tôt pour ça.

1 « J'aime »
#103

Ma priorité est d’automatiser les builds aux ptits oignons pour me faciliter le boulo, et en même temps de traiter tous les bugs connus au fil de l’eau.

En fait je pense que Ğecko a plus besoin vite de tests d’intégrations complets et à jour, que d’autre chose.

Couvrir ces tests peut être fait par n’importe qui, même sans aucune connaissance de la codebase, car il s’agit de faire cliquer un robot à différents endroits de l’écran grâce à des keys déclarés partout dans le code, et vérifier si l’écran affiche bien ce qui est attendu.

Le plus important est d’éliminer les bugs, le reste, comme dit hugo, ça peut attendre la v1 le temps que la codebase se transforme encore pas mal, et se stabilise au fur et à mesure.

Il faut approfondir le fork de polkawallet-sdk que j’ai fait, pour le spécialiser sur les besoins de Ğecko, puis push ce fork dans un package sur pub.dev, compatible exclusivement mobile.

En parallèle, en extrayant tout ce qu’il faut pour gdev_annuaire, on pourra ensuite faire un autre package avec des widget customisable de Query vers l’indexer avec les bonnes requêtes, check de node up, ect … Ce dernier pouvant être inclu dans tous projets flutter Web/Desktop/Mobile.

On a la chance de pas espérer sortir gecko en prod avant la sortie de la Ğ1 v2s, donc ça laisse encore beaucoup de temps pour tout stabiliser, mais bien scinder les packages en briques, ainsi que refaire tous les tests d’intégrations, ça oui le plus tôt sera le mieux.

On est pas à l’abri d’un contributeur qui un jour se décide à binder une lib polkadot rust en dart, et qu’on préfère remplacer polkawallet-sdk par ça pour tous ce qui est:

  • Génération et chiffrement des seeds
  • Dérivations, signatures, ect …
  • Requêtes RPC
  • smoldot?

dans un package Dart comprenant ce binding dart/rust, + en full dart tout ce qui est stockage et gestion de la seed chiffré, et requêtes indexer.

Cette archi me semble la meilleurs sur tous les plans pour le long terme, mais nécessite du taf en Rust que je ne ferais pas.

1 « J'aime »