Reprise du message précédent :
 
up

c'est prévu mais j'ai pas le temps (c'est dans une todo list que j'ai du perdre )

je me suis inscrit à un cours en ligne ! faudrait quand même que je retrouve l'url aussi

 
L'idée est super cool!
Si il y a besoin d'aide pour dev, je peux filer un coup de main. Plutôt en Python qu'en php par contre

Il reste des trucs à faire à part le markdown to   HFRbbcode ? J'ai parcouru ton bitbucket, et j'ai pas trouvé de todo list

Déjà tu peux faire ça, après on pourra spawn une interface WYSUWYG/rawbbcode comme HFR

Bonsoir    
 
J'ai bien envie de convertir le script en Python et d'automatiser avec un workflow GitHub Actions, tout ça devrait être assez simple !
 
Mais la fonctionnalité (nouvelle) qui m’intéresse toujours c'est bien un éditeur WYSIWYG pour noobs, histoire de pouvoir faire collaborer n'importe qui facilement et éviter de sortir vim, git, gh cli et de faire une PR
Des idées/pistes pour arriver à ça ?

Le gus écrit son post sur la fenêtre d'HFR, il regarde le preview.
Une fois qu'il est content il copie/colle le texte dans github.
Tu définis un format d'entête au fichier ou sinon faut une nomenclature de fichier défini (avec le n° cat, n° topic n° post)
 
Genre

 
Et lors du push dans main la GH va maj les topics des fichiers modifiés

Le dépôt devrait déjà gérer le topic/FP. Sinon entretemps je pensais à une extension Greasemonkey-like

Celle celle qui fait le preview depuis la réponse rapide

Oh?

https://raw.githubusercontent.com/r [...] 21.user.js this

Ok ça c'est cool. Maintenant comment on pourrait éditer un post qui serait tagué collabo ?

le problème c'est l'auteur, soit tous les posts colabo sont du même auteur soit il faut un compte modal pour l'éditer
 
je vois bien marc lâcher un compte modal à xat pour le filer à un bot

Les credentials seront stockés dans GitHub Secrets et à priori une paire dans chaque dépôt qui s'occupera de tel FP (ou multi post) donc je vois pas le soucis
Si tu parles de l'édit via HFR/GM ça serait plutôt pour envoyer une PR/MR sur le dépôt référencé pour le post en question. Reste à définir comment faire cette référence mais ça devrait pas être compliqué.

hmff ok
 
bah y'a quoi qui bloque alors ?

L'écriture/adaptation du script GM qui reprendrait un post taggé colab et pousser la différence sur le Git. Doit-on avoir un compte GH ou alors un Webhook/que sais-je avec un compte générique/bot récupère le diff et fait un PR ?

Bon j'ai récupéré un bout de code python de notre cher forumeur garath_ qui avait déjà fait un truc pour envoyer un MP : https://github.com/XaaT/hfr-git2hfr [...] git2hfr.py

Est-ce qu'avoir un compte GH est un pb ?
Parce que suffit de cliquer sur Edit sur le fichier et ça ouvre l'éditeur (ou même dans vscode en ligne en appuyant su "." ) , fait un fork, crée une branche lors du commit et fait une PR automatique
Et tu fous le script de aperçu rapide sur la page github qui pointe sur le formulaire ?

Un chouilla, on perd la majorité des gens avec ça. Non ?

 
   
A+,  

Ca avance et en même temps j'apprends un peu mieux Python
 
https://github.com/XaaT/hfr-git2hfr [...] git2hfr.py
 
J'ai rajouté une class Config pour la gestion des variables d'env https://github.com/XaaT/hfr-git2hfr [...] .py#L6-L27
Et j'ai complètement refait la func connect en func login https://github.com/XaaT/hfr-git2hfr [...] py#L39-L78
 
P'tet un peu trop de lignes mais osef c'est sympa à faire

https://github.com/XaaT/hfr-git2hfr [...] git2hfr.py

Ca commence à avoir de la gueule

Marchent:
* Génerer un post_data
* Toper le hash du hfrien
* Se loguer
* Envoyer un nouveau MP
* Editer un post
* Récuperer de la data d'un github
* Une partie des arguments à passer

Manquent:
* le CI (githubactions)
* scénarios en fonction des arguments
* doc
* jsais plus trop quoi

Je lorgne sur les bots Google pour GitHub et je pense à auto-approve, ça pourrait être sympa pour définir des règles pour auto merged les PR selon des critères (typiquement une liste de pseudo GitHub autorisés). En fonction de la confiance associé ça pourrait être sympa pour améliorer le workflow d'édition collaborative.
 
En gros :
* Un HFRien est owner du dépôt par défaut qui héberge le content pour l'édition d'un post collaboratif
* Un workflow GitHub Actions qui à chaque merge sur main va pousser le contenu sur les pots référencés (gestion des metadonnées à définir)
  * Script git2hfr.py qui va être exécuté par GHA avec gestion de l'auth HFR via variable d'environnement (dont GitHub Secrets pour le passwd) (en vrai il y'a le choix soit login dans l'appel du script soi via env)
   * Content récupéré de plusieurs façons possibles
* Bot qui va merger les PR de gens de confiance automatiquement
 
On pourra aussi sinon simplement autoriser un mec qui pousse à merger Mais le merge auto on peut rajouter du CI qui check (bon on a pas de lint HFR) et surtout détecte si y'a pas une grosse merde (mais bon si personne de confiance on devrait pas avoir à checker).
 
Enfin voilà c'est une réflexion ouverte, rien n'est fixé et vous pouvez faire des suggestions.
 
J'ai fini la gestion CLI/arguments du script : on peut se loguer (auto ou manuel), envoyer un MP, éditer un post et régler le content en fonction d'où on veut le prendre.
 
L'aide actuel

Oui bah ça reprend le nom du script tout seul, c'est une itération de test

C'est quand tu te plonges à faire des trucs sur le forum que tu vois qu'il a été codé avec le cul, trop relou

pas mieux

On devrait avoir de la doc pour pour savoir comment faire les trucs mais toutes les merdes qui traînent à éviter

edit:

Bon ~300 lignes ça commence à être long ce truc https://github.com/XaaT/hfr-git2hfr [...] git2hfr.py
Mais assez prêt pour faire des tests via un repo GH et un workflow GHA !

edit:
https://github.com/XaaT/hfr-topic-g [...] 7298278343
ah niksamere faut ajouter la sous-cat

edit:

lol le titre, petit loupé (edit: mon psuedo était poussé comme nom du topic )

edit: bon j'ai ajouté un truc qui récup le numéo de subcat quand on édite un FP (premier post), j'ai ça comme post_data mais je vois pas ce qui chie :

C'est pour le fp de ce topic (ici) https://forum.hardware.fr/forum2.ph [...] 0#t2318726

edit: si vous regarder le fp ça n'a pas été édité

edi2: ok ça marche je tentais de poster via message.php au lieu de bdd.php

Bon bah c'est fonctionnel, je pense qu'on arrive à maturation.  
Voila la version au dernier commit : https://github.com/XaaT/hfr-git2hfr [...] git2hfr.py
 
L'aide

 
Fonctionnalités :

• Login via variables en entrée du script ou via variable d'environnement (auto-login)
• Envoi de MP : création d'un MP avec un destinataire (marche mais pourrait être amélioré, certains cas mal addressés)  
• Edit de post/FP : édite un poste (FP ou normal)
• Tout ça prend du content en entrée, 3 façons : un fichier local, une entrée directement dans le script (content-string) ou un fichier sur un GitHub

Pas finito/à améliorer :

• Poster un nouveau topic, poster SUR un topic
• FP: gestion sondage, changement de titre, changement de sous-cat, rajouter des topics à lire
• Nouveau MP: adresser tous les cas d'usage (notamment MP déjà existant ou limite de 60mn)
• Notifications : envoyer une notif sur un MP (ou créer ce MP) ou un sur topic (reprise de fonctionnalités, certes)
• Tests de toutes les possibilités (doit bien y'avoir des enchaînements d'arguments mal supportés) en CLI
• Gestion FP multi-post (toujours possible en lançant plusieurs fois le script sinon)

Manque pour pousser sur main :

• Doc
• Workflow GHA

 
 
Dites moi ce que vous pensez du code

Un dépôt GitHub et son workflow fonctionnel créé pour l'occasion : il met à jour automatiquement les posts (4) de la première page de ce topic.
 
Le dépôt : https://github.com/XaaT/hfr-topic-git2hfr

• Un fichier (.txt) par post à mettre à jour
• Un fichier de worfklow qui référence les fichiers et posts à mettre à jour
• `HFR_LOGIN` et `HFR_PASSWD` passés via variable puis secrets GitHub. Images :

           
 
Le Workflow GitHub Action : https://github.com/XaaT/hfr-topic-g [...] te-hfr.yml

• Plutôt simple : il lance un run sur une VM GitHub (ou CT), checkout (copie dans l'instance du code du repo Git), une action met à disposition python 3.11, j'affiche la version de python pour le fun, je copie en local le script git2hfr, j'installe les dépendances python puis ...
• Lancement d'une instance du script par post à mettre à jour, il suffit de renseigner la catégorie, le topic puis le numéro de post à mettre à jour! Je pourrais linker un repo GitHub mais j'ai déjà les fichiers en local donc je les utilise.
• Améliorations possible : ajouter les variables en entrée de workflow pour être facilement lisible et modifiable. Peut-être une boucle pour mettre à jour un certain nombre de posts (voir topics).
• Le script (workflow) se lance à chaque mise à jour du dépôt, tout seul! Dès une modification est poussé dans la branch main, ça met à jour HFR.
• Menu Actions de GH : référence les runs et les workflows. Exemple de run réussi https://github.com/XaaT/hfr-topic-g [...] 7446028986

tin juste comme ça t'as une ubuntu et t'y fais tourner ce que tu veux

ça change ma conception du monde

dommage que y'ai pas debian quand même

Welcome dans le monde réel
Tu as aussi du Mac ou du Windows mais le décompte des minutes n'est pas le même. En public c'est gratuit ou suffisamment en tout cas.
Je vois pas ce qu'une debian apporterai de plus, tu dois pouvoir faire du docker sinon.

Tu as pas besoin de faire le " name: Fetch git2hfr.py " parce que tu as déjà checkout le repo en première étape et idéalement tu lances le workflow lors d'un commit et tu récupères la liste des fichiers mis à jour et tu boucles sur cette liste

- Fetch obligatoire parce que c'est pas le même dépôt, c'est même sympa de referencer le script pour suivre les maj d'ailleurs (mais faut pas péter la compatibilité non plus.
- C'est déjà run à chaque commit (règle très large d'ailleurs)
- La boucle oui j'en parlais dans les améliorations possibles Reste à savoir où stocker les métadonnées (soit dans le .txt, soit à côté, soit en variable dans le workflow soit dans le repo)

J'allais proposer l'idée de pouvoir gérer la liste des intervenants d'un DT via le script/github aussi mais bon c'est pas très privé de lister les gens sur un DT

Le script pourra aussi servir de push de flux rss/news en utilisant le cron de github actions

en fait je transformerais ton repo en action github elle même https://docs.github.com/en/actions/creating-actions + tu fournis un repo template https://docs.github.com/en/reposito [...] repository avec un exemple et un workflow qui appelle ton action.
 
Les gens créent leur repo à partir du template, le workflow est déjà préconfiguré il faut juste ajouter les 2 secrets.
Puis les gens créent/updatent les posts dans le repo.
Je ferais en entête (ou à la fin) du txt du post les métadatas du post à maj (cat/sub/num réponse) comme ça c'est l'édition du post qui lance le workflow pour maj le post en question