Avvio rapido: rendere visibile il primo repository ADO

Il percorso più breve da «il plugin è installato» a «un repository di Azure DevOps si può sfogliare nel wiki». Tre passi, circa quindici minuti. La versione estesa, con tutte le schermate della procedura guidata e tutti i casi particolari, sta nella guida in tedesco.

Prerequisiti

wkdoadogit, wkdocore, wkdostorage, wkdoado e wkcore sono installati e attivati. Senza wksourceview i file non si aprono nel cassetto.
L'estensione PHP curl è presente.
Esiste una connessione ADO provata — vedi l'avvio rapido di wkdoado. Un guasto di connessione indagato da qui si indaga due volte.
Per il mount servono diritti di amministratore: un mount scrive permessi per l'intero sito.

Prima del primo mount fate una copia di sicurezza di conf/acl.auth.php. Il mount scrive in un blocco gestito di quel file.

Passo 1: capire il patto che state accettando

Azure DevOps viene raggiunto tramite un solo account di servizio. Ne derivano due cose, valide subito:

È il wiki a decidere chi vede che cosa. Chi non ha un account in Azure DevOps può comunque sfogliare un repository montato, se il wiki lo consente.
Tutto ciò che l'account di servizio raggiunge è raggiungibile — da chiunque il wiki autorizzi.

Date perciò ora all'account di servizio i permessi più stretti che coprano i repository previsti. La sua portata è il soffitto; l'ACL del wiki è il cancello.

Passo 2: montare il repository

Amministrazione → Mount repo ADO-Git, direttamente /doku.php?do=admin&page=wkdoadogit_mounts. Aprire Registra mount; la procedura guidata attraversa quattro schermate:

Connessione — la connessione dei prerequisiti, nell'elenco come progetto / chiave.
Progetto ADO — il progetto in Azure DevOps.
Repository — spuntare uno o più repository, scegliere il livello di visibilità, poi Anteprima.
Anteprima — che cosa concede il livello, quale namespace nasce e ogni riga di permessi che verrà scritta. Poi Registra.

Sono disponibili quattro livelli:

Livello	Chi può leggere
`private`	Nessuno tranne il gruppo di esercizio.
`team`	I gruppi di ruolo proprio di questo progetto — lettori, collaboratori, manutentori.
`readonly`	Ogni account autenticato.
`public`	Tutti, anche senza autenticazione.

Finché quel mount non esiste, il repository nel wiki è invisibile. Che l'account di servizio lo veda non basta: l'esposizione è un atto esplicito.

Passo 3: collocare la vista su una pagina

Il mount e il markup sono due atti distinti. Il mount scrive soltanto permessi e non crea alcuna pagina. Il repository diventa visibile solo tramite il markup su una pagina. È il motivo più frequente dell'impressione che un mount non funzioni.

Modificare la pagina dei repository del progetto — it:projects:acme:repos — e inserirvi:

{{wk:adogit>connessione:progetto-ADO:repository region=toc}}

In questa installazione su de:projects:dwplugins:repos sta per esempio {{wk:adogit>wvds:DokuWiki-Plugins:wkdoadogit region=toc}}.

Verifica del risultato

Vedete i riferimenti, un albero di file e i file. Ognuna di quelle richieste passa per lo stesso cancello, valutato a ogni chiamata e mai messo in cache. Per questo una revoca ha effetto già alla chiamata successiva e non allo scadere di un termine.
Controprova con un secondo account — quei due minuti valgono una volta per installazione: un account senza permesso di lettura sul namespace del mount non vede nulla. Né un elenco parziale, né un messaggio d'errore che nomini il repository. Poi concedete la lettura e verificate che possa sfogliare.
Lettura e scrittura sono due livelli dello stesso namespace: il permesso di lettura significa sfogliare, quello di scrittura significa registrare commit e creare riferimenti. Per questo non si configura nient'altro.

Passo successivo

Guida (in tedesco) — la versione completa, con tutti i campi e le insidie.
Mostrare file di un repository su una pagina wiki (in tedesco)
Clonare un repository montato (in tedesco) — l'accesso dall'esterno, con token di accesso personale sotto ?do=wkdoadogit_tokens.
Diagnostica (in tedesco)