revuloj / voko-afido Goto Github PK

• Aldonu daton+tempon de trakto en la submetoj/rezultoj - tio faciligos la trovon de la koncerna protokolo en GH-agoj (momente ni havas nur ĉe sukceso la "hash"-on)
• Momente la submetoj restas en stato trakt, se antaŭ la forsendo de rezultoj okazas grava eraro, ekz. git push ne funkcias. Havante daton de lasta stato-ŝanĝo ni povus inkluzivi ekze. "trakt" post paso de 2h (alternative remeti al 'nov' aŭ regule kontroli postrestintajn artikolojn)
• La ligiloj en "viaj submetoj" eble montras la malnovan eldonon, se oni ne refreŝigis la paĝon, do se troviĝas novaj sukcese traktitaj submetoj altigu la version por la GET-parametro ?v=...
• Montru la submetitan XML. Tio aparte gravas se estas eraro au eble utilas ĝis la trakto.
• Ĉe okazinta eraro ofertu eblecon "reredaktu"

Se preni la liston de redaktantoj fiaskas, ĝi enhavas 404 anstataŭ redaktantojn. Poste redaktoj rifuziĝas. Ĝuste estas interrompi la procedon kun eraromesaĝo kaj trakti la retpoŝtojn post kiam la listo denove estas en ordo... Do kontrolu la enhavon antaŭ procedi aŭ uzu "exitcode" aŭ HTTP-respondo de curl... (opcio -f, --fail)

Ni havis konflikton en retpoŝta traktado (processmail.pl) fine de Aŭgusto.

En la protokoldosiero pli frue aperis "sintakseraro" (eble nerilata?)

------------------------------
sh: 1: Syntax error: end of file unexpected

En la koncerna tago:

TIME: Sa 21. Aug 16:10:02 CEST 2021

------------------------------
/usr/bin/git pull
git-out:
automatischer Merge von revo/konser.xml
KONFLIKT (Inhalt): Merge-Konflikt in revo/konser.xml
Automatischer Merge fehlgeschlagen; beheben Sie die Konflikte und committen Sie dann das Ergebnis.

git-err:
Von github.com:revuloj/revo-fonto
   b5d716241d..204ce706bd  master     -> origin/master

------------------------------
/usr/bin/rsync -rv /home/revo/dict/revo-fonto/revo/ /home/revo/dict/xml/
...
--------------------------------------------------
From    : "Revo redaktu.pl pok...." <[email protected]>
Reply-To: pok...
artikolo: $Id: cxeval.xml,v 1.156 2021/07/29 06:39:06 revo Exp $
shanghoj: +~isto, +~estro
------------------------------
/usr/bin/git add revo/cxeval.xml
------------------------------
------------------------------
/usr/bin/git commit -F /home/revo/tmp/shanghoj.msg
git-out:
U	revo/konser.xml

git-err:
error: Committen ist nicht möglich, weil Sie nicht zusammengeführte Dateien haben.
Hinweis: Korrigieren Sie dies im Arbeitsverzeichnis, und benutzen Sie
Hinweis: dann 'git add/rm <Datei>', um die Auflösung entsprechend zu markieren
Hinweis: und zu committen.
fatal: Wird wegen eines unaufgelösten Konfliktes beendet.

------------------------------
ERARO   : Eraro dum arkivado de la nova artikolversio:

U	revo/konser.xml

En postaj aperas:

/usr/bin/git pull
git-err:
error: Pullen ist nicht möglich, weil Sie nicht zusammengeführte Dateien haben.
Hinweis: Korrigieren Sie dies im Arbeitsverzeichnis, und benutzen Sie
Hinweis: dann 'git add/rm <Datei>', um die Auflösung entsprechend zu markieren
Hinweis: und zu committen.
fatal: Wird wegen eines unaufgelösten Konfliktes beendet.

Ni devos pli frue rimarki tian konfliktonkaj se eble evititi tute...

Kiel rimarki? Eble git diff --check / git status en la fino de traktado?

Ni ĝis nun sendis ĉiutage resumon kaj ĉiumonate ni purigis dosierojn en la redaktoservo. Ĉar nun ni ne plu uzas Ant por la retpoŝta akcepto, necesus ŝel-skriptoj aŭ simile por fari tion:

 target="srv-resumo"
 target="srv-purigu"

La resumo serĉis i.a. pri BUILD: FAILED en la Ant-raporto. Ni do bezonas alian manieron konstati malsukceson / problemon en la redaktoservo.

Noto 12/2019: Paralela konservado en Git (revo-fonto) jam estas realigita kaj teste ruliĝas. Necesos poste fari ankoraŭ:

• forigonte CVS-konservadon: kontroli version kompare kun la versio en Git anstataŭ tiu en CVS
• farita: renovigi revo-fonto kaj transiri de testo al normala paralela procedo
• permesi flegi rekte en Git kaj per repoŝto: tiam necesos aldoni "git pull" (merge)
• pliajn aferojn ankoraŭ pripensindajn, ekz. uzi "Github Actions" por afido k.s.
  ===

Ĝis nun artikol-historioj estas deponitaj per CVS, kio havas kelkajn malavantaĝojn:

• Necesas centra deponejo, el kiu nur estas du plej aktualaj kopioj. Kontraŭe Git ne bezonas centran deponejon kaj povas havi pli da distribuitaj kopioj
• CVS estas malnova, ne subtenas Unikodon (aparte necesas Askio en kmentoj), kaj atendeble iam baldaŭ ĝi ne plu estos flegata de la Linuks-eldonoj

Krome uzante Git mi esperas, ke ni povos iom post iom forigi la bezonon sendi redaktojn per retpoŝto. Anstataŭe la redaktilo povus ekz. rekte sekurigi al github.com. Tiel ni havus ankaŭ ĉiam publike alireblan historion de artikoloj tie.

farita: Unua paŝo estus aldoni konservadon al Git-deponejo en processmail.pl - CVS verŝajne plu necesas tiom longe, kiel la publika Revo-servo uzas precipe Perlo, kiel programlingvo.

Solvenda problemo: la komparo, ĉu redakto baziĝas sur la aktuala versio, momente funkcias per aŭtomate flegata versio en argumento $Id$ ŝovitan en ĉiun artikolon. Ankaŭ la ŝanĝoj malsupre kolektiĝas per $Log$. Ambaŭ traktiĝas aŭtomate de CVS. Git ne havas tiajn aŭtomatajn argumentojn. Do ni devas aparte realigi tian kontrolon per alia rimedo:

• kontrolo povus okazi per kontrolsumo - tamen tiun oni ne povas ŝovi en la artikolon mem, ĉar tio ŝanĝus la sumon. Do ni bezonas aŭ apartan lokon, kie memori la kontrolsumon aŭ pendigi ĝin kape aŭ voste de artikolo en parto, kiu ne estas kunkontrolata.
• farita: la versio de artikolo devas ankaŭ iel aŭtomate altiĝi aŭ ni transiros al tiuj haketoj (hases), kiujn uzas Git por versioj. Numero ŝajnas al mi pli homtaŭga.
• la lastajn ŝanĝojn oni ne nepre bezonas en la artikolo mem, se la historio en Github estas publike rigardebla.

Se tio estas realigita, sekva paŝo povos esti traktado de novaj redaktoj rekte el Git- anstataŭ CVS-deponejo. (vd. ĉe voko-formiko)

La eraro jam estas en la malnova adaptita skripto en SVN:

Normale post ĉiu kuro kun traktita poŝto devus aperi:

shovas /home/revo/revotmp/mail al /home/revo/revolog/oldmail/20210204_175828
shovas /home/revo/revotmp/mailsend al /home/revo/revolog/20210204_175828

sed foje aperas nur

shovas /home/revo/revotmp/mail al /home/revo/revolog/oldmail/20210204_190439

Se estas steleto en la ŝanĝpriskribo ni ricevas versikonflikton (gists...):
ekz-e: kamizo | ⚠ | 2021-10-26 05:20 | +trd*, etendis rim

La redakto tamen traktiĝas.

Momente la retpoŝta traktado estas plenfunkcia, sed riskas malsinkroniĝi kaj obstrukciĝi pro la fina "git push" - konkurence al la traktado ĉe Github.

Ebleco por simpligi estus ne puŝi la redaktojn rekte al Git, sed al gists.github.com - tiam ili traktiĝus kune kun la aliaj.

La tradicia akceptilo de la redaktoservo (processmail.pl) akceptas redaktojn kiel MIME-koditaj retpoŝtoj. Se ni ŝanĝos la procedon uzante Github-giston, necesos reverki la akceptilon. Ĝi devas plenumi pli malpli la sekvajn taskojn:

• kontroli ĉu la redakto venas de registrita redaktanto
• ĉe aldono de nova artikolo, ĉu la dosiernomo (el la priskribo "aldono: ") estas ankoraŭ libera
• ĉe nova artikolo, enŝovi $Log$ kiel fina komento
• ĉe redaktita artikolo, ĉu ŝanĝo estas priskribita kaj aldoni la faritan ŝanĝon supre de $Log kaj forigi liniojn superantajn 20 malsupre
• kontroli la sintakson kontraŭ la DTD (per rxp, aŭ alternative kontraŭ la pli strikta Relax per jing)
• kontroli ĉu la redaktita versio identas kun la arĥivita (aliokaze verŝajne iu alia intertempe sendi redakton de la sama artikolo)
• aldoni la redakton en la arĥivo (aŭ per git commit+push aŭ per Github API)

La tradicia akceptilo estas verkita en Perlo. Ni povus konsideri uzi pli aktualan programlingvon kiel Javoskripto aŭ eĉ simplan bash-skripton, se ni celas tre malgrandan procesumon.

Ni ankoraŭ devas konsideri, kiel sendi la rezultojn al la redaktantoj. Ni plu bezonas retpoŝtilon por tio, sed sufiĉus sendi per SMTP - do ne necesas loka sendmail-proceso. Alternativoj estus ie afisi la rezultojn, ekz. ankaŭ kiel Gisto aŭ en revuloj.groups.io...? Sed ĉi lasta eble estas nesufiĉe privata, speciale ĉe eraroj.

La sendado de rezultoj povas esti apartigita de la akceptado, se ni unue skribas ĉiujn rezultojn de la traktado en protokolon.

La tradicia vojo, sendi redaktojn per retpoŝto estas pripensinda, precipe ĉar:

• SPAM-filtrilo foje (malofte, sed tamen) blokas alvenon de redakto sen ke la redaktanto rimarkas facile, ke lia redakto ne traktiĝis. Eĉ la alsendo de kopio en tiuj okazoj ne funkcias, kio malfaciligas resendadon
• retpoŝtoj ne estas la plej taŭga maniero transporti XML-dosieron
• ni devas regule kontroli pri novaj retpoŝtoj, do ĝis redakto aperas, daŭras ĝis nunu horo
• se retpoŝto ne bone traktiĝis foje estas iom malfacile ripari tion en la servilo
• ni volas rezigni pri daŭra servilo por la redaktoservo, sed uzi kompletan retpoŝtilon en efemera Github-ago ne ŝajnas la plej bona ideo

Post iom da pripensado kaj esploro la uzo de Github-gisto ŝajnas avantaĝa:

• oni povas simple lasi tie unu aŭ plurajn kod-dosierojn kun priskribo kaj tempo
• oni povas sendi, preni kaj forigi per REST-API de Github, kio estas facile uzebla de diversaj programlingvoju inkluzive per komandoj curl+jq
• administranto havas ŝancon okaze enrigardi alvenantajn dosierojn kaj eble eĉ korekti problemetojn
• gistojn oni povas trakti ankaŭ kiel normala Git-arĥivo -> do ili eĉ post forigo ne perdiĝas, oni havas komplketan historion kaju oni povas preni la tuton al loka dosiero, se necesas pli grandaj riparoj

Krom la XML-dosiero ni bezonas:

1. la priskribon de la ŝanĝo kun prefikso "aldono:" aŭ "redakto:" - same kiel ni uzis ĝis nun en retpoŝta transsendo
2. la nomon kaj retpoŝtadreson de la redaktanto por kontroli, ĉu tiu estas registrita

Gisto havas priskribon por la unua, sed la duan prefere ni aldonu en aparta dosiereto, en formato JSON kune kun sigelo. La sigelon ni kalkulu laŭ algoritmo HMAC kun SHA256 el la XML+registrita retpoŝtadreso. Por tio ni krome bezonas sekretan ŝlosilon (sigelilon), kiun devas koni kaj la redaktilo por sigeli kaj la programo akceptanta redaktojn por kontroli la sigelon.

Por simplaj riparoj ni akceptu ankaŭ nesigelitajn gistojn de administranto, kiuj ricevas indikon de redaktanto "revo" - kiel jam okazis ĝis nun ĉe riparigaj redaktoj rekte sur la servilo.

Plu la malnova redaktilo funkcias per retpoŝto. Oni povus aŭ same adapti ĝin al afiŝado aŭ akcepti retpoŝtojn kaj afiŝi ĉe gist.github.com kaj poste trakti laŭ la nova metodo, aŭ komplete paralele trakti retpoŝtojn kaj afiŝojn.

Aktuale la paralela traktado de retpoŝtoj ŝajnas preferinda:

• tio funkcias jam 20 jaroj relative stabila, dum la Api por gist.github.com foje ne estas alirebla. Do per retpoŝto ni ĉiam havas alternativon
• Ĉe eraro-arporto oni povas sendi korekton per ordinara retpoŝtilo, kio foje estas plej rekta procedo.

Sed ni devos certigi, ke ĉe erara raktado retpoŝto ne perdiĝu. Estas du eblecoj:

• unue legi ciujn retpoŝtojn, trakti kaj nur fine forigi - se tamen duoble ili traktiĝas ni havos kelkajn erarmesaĝojn pri versikonflikto al redaktantoj
• ie savi la retpoŝtojn, tiel ke ĉe problemo ni ie havas savkopion
• trakti ilin unu post alia. Tiam ni havos nur unu probleman kazon, se la procedo rompiĝas.

Cetere anstataŭ fetchmail, kiu postulas lokan SMTP-servilon(?) kaj poŝtfakon, oni povas legi kaj forigi mesaĝojn, eĉ forsendi ankaŭ per curl (https://everything.curl.dev/usingcurl/uploads) - ni elprovu tion por simpligi la necesan isntalaĵon en Afido.

Nova artikolo ankoraŭ ekhavas eraron en processmail.pl:

• post $Id... mankas dosiernomo, versio, tempo ktp.
• mankas $Log fine de la artikolo

Ambaŭ devus bone enmetiĝi per process::init_ver
Necesas analizi kial tio ne funkcias.

Aktualigante al Ubunto 20.04 ni ricevas eraron kiam ni skribas la traktrezulgon al gists.github.com per la Api:

 DATA:
  {
    "files": {
        "eraro.json": {
          "content": "{\"senddato\":\"2023-05-30T19:53:25Z\",\"dosiero\":\"/home/afido/dict/xml/313328a41723037825ba3f05e71c2047.xml\",\"rezulto\":\"eraro\",\"artikolo\":\"$Id: konven.xml,v 1.100 2022/11/13 23:33:38 revo Exp $\",\"mesagho\":\"La de vi sendita artikolo||ne baziĝas sur la aktuala arkiva versio||($Id: konven.xml,v 1.101 2023/05/30 20:24:03 revo Exp $)||Bonvolu preni aktualan version el la TTT-ejo. (http://www.reta-vortaro.de/cgi-bin/vokomail.pl?art=konven)\",\"shangho\":\"+~igi\"}"
        }
    }
  }

parse error: Invalid numeric literal at line 1, column 51

Eble estas pro la dolar-signoj aŭ io alia, sed kial la ŝanĝo de Ubunto aperaigas tiun problemon? Io en la klienta parto verŝajne ŝanĝiĝis,

Vd. https://github.blog/2021-04-05-behind-githubs-new-authentication-token-formats/

Ni uzas ilin ekz-e en voko-afido por legi redaktoj el "gists". ("provizi revo-fonton el mia gisto") difinita en revuloj(?) kaj uzata en GH-agoj de voko-formiko kiel REVO_TOKEN

duobla streko en ŝanĝpriskribo enirante la protokolon sube de XML kaŭzas eraron. Ni malpermesu aŭ anstataŭigu ĝin.

devus sufiĉi forigi la linion en .fetchmailrc...

Ĉar daŭre retpoŝto aperas nefidinda akceptilo por redaktoj ni povus anstataŭe uzi la datumbazon:

• redaktojn sekurigi al aparta akcepta tabelo
• dum traktado elpreni la artikolojn unu post alia kaj arĥivi kiel kutime
• forigi poste aŭ marki traktitajn