[SPIP Zone] SPIP git : tmp, local et gitignore

Archives Zone
1

Yop,

vu que la zone est down en svn, c'était l'occasion de m'y mettre, j'ai utilisé le script de checkout de Cédric (copié collé depuis le trac, puisque pas de svn).

Ça marche nickel, merci !

Une remarque : dans /local les deux fichiers CACHEDIR.TAG et remove.txt sont versionnés, du coup, dès qu'on vide le cache par exec=admin_vider (cache des images) ça les supprime et ça modifie la copie locale.
Idem dans /tmp si on supprime tout (même si là c'est une opération manuelle).
Il faut donc les revert pour se remettre au propre.

Est ce qu'on est vraiment obligés de les versionner ?

On pourrait y mettre juste un .gitignore avec ces règles :

* # ignore tous les fichiers
!.gitignore # sauf celui-ci

Il me semble que c'est une convention, ce serait plus safe...

Qu'en pensez vous ?

--
nicod_

2

Le 30/11/2019 à 23:04, nicod_ a écrit :

Une remarque : dans /local les deux fichiers CACHEDIR.TAG et remove.txt sont versionnés, du coup, dès qu'on vide le cache par exec=admin_vider (cache des images) ça les supprime et ça modifie la copie locale.
Idem dans /tmp si on supprime tout (même si là c'est une opération manuelle).
Il faut donc les revert pour se remettre au propre.

Est ce qu'on est vraiment obligés de les versionner ?

On pourrait y mettre juste un .gitignore avec ces règles :

* # ignore tous les fichiers
!.gitignore # sauf celui-ci

Il me semble que c'est une convention, ce serait plus safe...

Bon, ça inspire pas grand monde...

J'ai dit une connerie ou bien ?

--
nicod_

3

Hello,

Moi ça me parait idiot.
J’avais envoyé un mail il y a quelques mois sur le sujet du gitignore car je trouve qu’on mélange dans notre gitignore SPIP des restrictions propres à l’installation de SPIP mais aussi à des outils hors SPIP.
Je trouverais plus logique qu’on coupe le gitgnore actuel en deux avec un global pour les outils et un spécifique pour SPIP et son contenu de l’autre.

Donc oui il y a surement un truc à faire sur le sujet et une petite discussion à mener d’ici à ce qu’on utilise quotidiennement git…

4

Hello,

En fait la raison d’être du remove.txt c’est de bien avoir le dossier versionné et donc créé lorsque tu checkout.
C’est historique, car en SVN on pouvait bien avoir un dossier vide dans le repository, mais je crois que ça servait aussi pour être sur que dans le zip tu auras le dossier.

Avec GIT ça a tout son sens, car si on a aucun fichier dans le dossier, le dossier n’existe pas dans le repository, et donc il n’est pas créé si on checkout, ce qui est un peu pénible.
Donc ça me semble pas une bonne idée de les enlever

Le CACHEDIR.TAG permet d’exclure automatiquement les dossier quand tu tar (ou rsync ?) via une option —exclude-cache
Mais du moment qu’on garde le remove.txt il est pas gênant de l’avoir lui aussi, même si beaucoup moins indispensable

Par contre il faudrait qu’on gère ces fichiers pour ne pas les supprimer via le admin_vider, en effet.

--
Cédric
Le 30 nov. 2019 à 23:04 +0100, nicod_ <nicod@lerebooteux.fr>, a écrit :

Yop,

vu que la zone est down en svn, c'était l'occasion de m'y mettre, j'ai
utilisé le script de checkout de Cédric (copié collé depuis le trac,
puisque pas de svn).

Ça marche nickel, merci !

Une remarque : dans /local les deux fichiers CACHEDIR.TAG et remove.txt
sont versionnés, du coup, dès qu'on vide le cache par exec=admin_vider
(cache des images) ça les supprime et ça modifie la copie locale.
Idem dans /tmp si on supprime tout (même si là c'est une opération
manuelle).
Il faut donc les revert pour se remettre au propre.

Est ce qu'on est vraiment obligés de les versionner ?

On pourrait y mettre juste un .gitignore avec ces règles :

* # ignore tous les fichiers
!.gitignore # sauf celui-ci

Il me semble que c'est une convention, ce serait plus safe...

Qu'en pensez vous ?

--
nicod_
----
spip-zone@rezo.net - https://listes.rezo.net/mailman/listinfo/spip-zone

5

Hop,

Le 04/12/2019 à 08:57, Cerdic a écrit :

Hello,

En fait la raison d’être du remove.txt c’est de bien avoir le dossier versionné et donc créé lorsque tu checkout.
C’est historique, car en SVN on pouvait bien avoir un dossier vide dans le repository, mais je crois que ça servait aussi pour être sur que dans le zip tu auras le dossier.

Avec GIT ça a tout son sens, car si on a aucun fichier dans le dossier, le dossier n’existe pas dans le repository, et donc il n’est pas créé si on checkout, ce qui est un peu pénible.
Donc ça me semble pas une bonne idée de les enlever

Le CACHEDIR.TAG permet d’exclure automatiquement les dossier quand tu tar (ou rsync ?) via une option —exclude-cache
Mais du moment qu’on garde le remove.txt il est pas gênant de l’avoir lui aussi, même si beaucoup moins indispensable

J'étais justement en train de tester l'usage de ces fichiers avec tar et l'option --exclude-caches comme je l'indiquais dans le ticket à l'époque cf insérer des cache directory tag dans les dossiers temporaires (#2346) · Tickets · spip / spip · GitLab, mais je me suis complètement vautré dans l'introduction de ces fichiers dans SPIP ^^

En effet, d'après les specs, le fichier ne doit pas être vide, mais contenir une signature spécifique, j'envoie le correctif tout de suite.

D'ailleurs, ça vaudrait peut-être le coup de reporter ça en 3.1 aussi, non ?

Par contre il faudrait qu’on gère ces fichiers pour ne pas les supprimer via le admin_vider, en effet.

Je viens de faire le test, vider le cache laisser bien le CACHEDIR.TAG dans tmp, par contre vider le cache des images supprime tout le contenu de local, et donc le CACHEDIR.TAG, c'est ce point qu'il faut corriger.

++
b_b

6

Yop,

Le mer. 4 déc. 2019 à 10:35, Bruno Bergot <bruno@eliaz.fr> a écrit :

Hop,

Le 04/12/2019 à 08:57, Cerdic a écrit :

Hello,

En fait la raison d’être du remove.txt c’est de bien avoir le dossier versionné et donc créé lorsque tu checkout.
C’est historique, car en SVN on pouvait bien avoir un dossier vide dans le repository, mais je crois que ça servait aussi pour être sur que dans le zip tu auras le dossier.

Avec GIT ça a tout son sens, car si on a aucun fichier dans le dossier, le dossier n’existe pas dans le repository, et donc il n’est pas créé si on checkout, ce qui est un peu pénible.
Donc ça me semble pas une bonne idée de les enlever

Par contre il faudrait qu’on gère ces fichiers pour ne pas les supprimer via le admin_vider, en effet.

Je viens de faire le test, vider le cache laisser bien le CACHEDIR.TAG
dans tmp, par contre vider le cache des images supprime tout le contenu
de local, et donc le CACHEDIR.TAG, c’est ce point qu’il faut corriger.

y a pas le remove.txt aussi ?

++

Eric

7

Le 04/12/2019 à 08:57, Cerdic a écrit :

Hello,

En fait la raison d’être du remove.txt c’est de bien avoir le dossier versionné et donc créé lorsque tu checkout.
C’est historique, car en SVN on pouvait bien avoir un dossier vide dans le repository, mais je crois que ça servait aussi pour être sur que dans le zip tu auras le dossier.

Avec GIT ça a tout son sens, car si on a aucun fichier dans le dossier, le dossier n’existe pas dans le repository, et donc il n’est pas créé si on checkout, ce qui est un peu pénible.
Donc ça me semble pas une bonne idée de les enlever

Je le sais très bien, et je crois que tu n'as pas lu jusqu'au bout : je propose de coller un .gitignore dans /local et dans /tmp qui soit versionné (donc ils ne seront pas vides) qui contient juste ça :

* # ignore tous les fichiers
!.gitignore # sauf celui-ci

Ce serait beaucoup plus simple que de créer une exception dans le code et de faire attention à ne pas supprimer remove.txt et CACHEDIR_TAG quand on vide le cache.

--
nicod_

8

Le 04/12/2019 à 08:57, Cerdic a écrit :

Le CACHEDIR.TAG permet d’exclure automatiquement les dossier quand tu tar (ou rsync ?) via une option —exclude-cache

Je n'avais pas non plus lu jusqu'au bout :slight_smile:

Ok, je me suis toujours demandé à quoi ça servait, je comprends.
Mais c'est vraiment utile / utilisé ?

--
nicod_

9

Hop,

Le 04/12/2019 à 14:08, nicod_ a écrit :

Je le sais très bien, et je crois que tu n'as pas lu jusqu'au bout : je propose de coller un .gitignore dans /local et dans /tmp qui soit versionné (donc ils ne seront pas vides) qui contient juste ça :

* # ignore tous les fichiers
!.gitignore # sauf celui-ci

Ça me semble très bien.

Ce serait beaucoup plus simple que de créer une exception dans le code et de faire attention à ne pas supprimer remove.txt et CACHEDIR_TAG quand on vide le cache.

Attention, que le remove.txt soit absent, osef un peu, mais le CACHEDIR.TAG doit toujours être présent, sans quoi l'option --exclude-caches de tar sera inopérante.

++
b_b

10

Re,

Le 04/12/2019 à 10:35, Bruno Bergot a écrit :

En effet, d'après les specs, le fichier ne doit pas être vide, mais contenir une signature spécifique, j'envoie le correctif tout de suite.

Corrigé ce matin.

D'ailleurs, ça vaudrait peut-être le coup de reporter ça en 3.1 aussi, non ?

La question tiens toujours.

Par contre il faudrait qu’on gère ces fichiers pour ne pas les supprimer via le admin_vider, en effet.

Je viens de faire le test, vider le cache laisser bien le CACHEDIR.TAG dans tmp, par contre vider le cache des images supprime tout le contenu de local, et donc le CACHEDIR.TAG, c'est ce point qu'il faut corriger.

Sur ce point, comme je le disais sur IRC, deux options :

1) dans action_purger_dist(), on pourrait remplacer purger_repertoire(_DIR_VAR, array('subdir' => true)); par une liste des sous-répertoires ciblées cf ecrire/action/purger.php · master · spip / spip · GitLab

Ça serait bien plus fin d'ailleurs, car aujourd'hui, en cliquant sur un bouton qui annonce qu'on va vider le cache des images on vide :
les images, le cache css et js, et celui de plugins comme centre-image par exemple, donc bien plus que ce qui est annoncé.

2) autre piste, patcher la fonction purger_repertoire() à ce niveau :

En y ajoutant CACHEDIR.TAG à la liste des fichiers à exclure de la purge, et hop.

Votre avis ?

++
b_b

11

Je vote 1) cibler le repertoire cache-xx qu’on vide plutot que tout vider bourrin

--
Cédric
Le 4 déc. 2019 à 14:44 +0100, Bruno Bergot <bruno@eliaz.fr>, a écrit :

Re,

Le 04/12/2019 à 10:35, Bruno Bergot a écrit :
>
> En effet, d'après les specs, le fichier ne doit pas être vide, mais
> contenir une signature spécifique, j'envoie le correctif tout de suite.
>

Corrigé ce matin.

> D'ailleurs, ça vaudrait peut-être le coup de reporter ça en 3.1 aussi,
> non ?
>

La question tiens toujours.

> > Par contre il faudrait qu’on gère ces fichiers pour ne pas les
> > supprimer via le admin_vider, en effet.
> >
>
> Je viens de faire le test, vider le cache laisser bien le CACHEDIR.TAG
> dans tmp, par contre vider le cache des images supprime tout le contenu
> de local, et donc le CACHEDIR.TAG, c'est ce point qu'il faut corriger.
>

Sur ce point, comme je le disais sur IRC, deux options :

1) dans action_purger_dist(), on pourrait remplacer
purger_repertoire(_DIR_VAR, array('subdir' => true)); par une liste des
sous-répertoires ciblées cf
ecrire/action/purger.php · master · spip / spip · GitLab

Ça serait bien plus fin d'ailleurs, car aujourd'hui, en cliquant sur un
bouton qui annonce qu'on va vider le cache des images on vide :
les images, le cache css et js, et celui de plugins comme centre-image
par exemple, donc bien plus que ce qui est annoncé.

2) autre piste, patcher la fonction purger_repertoire() à ce niveau :

ecrire/inc/invalideur.php · master · spip / spip · GitLab

En y ajoutant CACHEDIR.TAG à la liste des fichiers à exclure de la
purge, et hop.

Votre avis ?

++
b_b

12

Bon,

Le 04/12/2019 à 16:06, Cerdic a écrit :

Je vote 1) cibler le repertoire cache-xx qu’on vide plutot que tout vider bourrin

Fausse alerte, les fichiers CACHEDIR.TAG config.txt remove.txt sont bien là après avoir vidé le cache des images, tout va bien donc.

Maintenant que j'ai soulevé le problème, ça serait juste une amélioration de action_purger_dist() et non une correction de bug.

Si on le fait, je pense à cette liste de répertoires à cibler :

cache-gd2
cache-texte
cache-vignettes
cache-TeX

Ainsi, on ne touche plus au cache css et js avec cette action, ça vous va ? (ce qui veut dire qu'on ne peut plus vider ces dossiers, pas certain que ça soit bien)

++
b_b

13

Hello,

14

Attention !

local/ ne doit pas être utilisé pour sa persistence, qui n’est pas supposée meilleure ou différente de tmp/ mais uniquement pour le fait que le conteni de local/ est accessible en http.

Autrement dit, si c’est un fichier interne, non directement chargé par l’internaute, il doit aller dans tmp/, sinon dans local/

Et c’est aussi le problème de vider sauvagement local/ : on supprime plein de fichiers référencés dans les squelettes, les pages, et dont les internautes ont besoin (tous les caches CSS notamment) et on a un site complètement cassé après ça.

Perso je suis pas loin de penser que cette fonction devrait disparaitre, chaque fois que quelqu’un l’utilise en prod ça se passe mal…

--
Cédric
Le 4 déc. 2019 à 16:42 +0100, Eric Lupinacci <eric@smellup.net>, a écrit :

Hello,

> Le mer. 4 déc. 2019 à 16:15, Bruno Bergot <bruno@eliaz.fr> a écrit :
> >
> > Si on le fait, je pense à cette liste de répertoires à cibler :
> >
> > cache-gd2
> > cache-texte
> > cache-vignettes
> > cache-TeX
> >
> > Ainsi, on ne touche plus au cache css et js avec cette action, ça vous
> > va ? (ce qui veut dire qu'on ne peut plus vider ces dossiers, pas
> > certain que ça soit bien)
> >
>
> Je ne suis pas sur que ce soit la bonne solution.
> Dans pas mal de plugins j'utilise local/ pour avoir des caches plus "persistents" a priori que tmp/.
> J'ai souvent avec une gestion du vidage de ces caches (si j'utilise Cache Factory) mais je ne suis pas sur que ce soit toujours le cas ou que je soit le seul à faire ça.
> Donc, je pense qu'on s'attend en général à voir les répertoires cache-monboplugin disparaitre aussi.
>
> Je serais donc plus favorable à une liste d'exclusions (qui pourrait être mise à jour par pipeline éventuellement) plutôt qu'à un ciblage.
>
> ++
> Eric
>

15

Re,

Le 04/12/2019 à 16:42, Eric Lupinacci a écrit :

Je ne suis pas sur que ce soit la bonne solution.

Je rappelle que l'idée était de rendre cohérent l'action avec ce qu'elle annonce faire, donc vider le cache de qui est décrit comme "Les images calculées automatiquement par SPIP (vignettes des documents, titres présentés sous forme graphique, fonctions mathématiques au format TeX...) occupent dans le répertoire local/"

Dans pas mal de plugins j'utilise local/ pour avoir des caches plus
"persistents" a priori que tmp/.

Tu fais donc un usage détourné du répertoire local/ car tu supposes que les gens le vide moins souvent que tmp, c'est bien ça ?

Donc, je pense qu'on s'attend en général à voir les répertoires
cache-monboplugin disparaitre aussi.

Oui peut-être, d'où ma question/remarque à propos des répertoires cache-css et cache-js.

Je serais donc plus favorable à une liste d'exclusions (qui pourrait être
mise à jour par pipeline éventuellement) plutôt qu'à un ciblage.

Oui pourquoi pas plus tard, là je pensais juste à un fix "rapide" :slight_smile:

++
b_b

16

Yop,

Attention !

local/ ne doit pas être utilisé pour sa persistence, qui n’est pas supposée meilleure ou différente de tmp/ mais uniquement pour le fait que le conteni de local/ est accessible en http.

Autrement dit, si c’est un fichier interne, non directement chargé par l’internaute, il doit aller dans tmp/, sinon dans local/

Ah ben la bonne légende urbaine que je me suis fabriquée tout seul :stuck_out_tongue: !
Mais j’avoue que je ne comprends pas bien ce que ça veut dire que l’internaute peut charger le fichier directement ?

Et c’est aussi le problème de vider sauvagement local/ : on supprime plein de fichiers référencés dans les squelettes, les pages, et dont les internautes ont besoin (tous les caches CSS notamment) et on a un site complètement cassé après ça.

Perso je suis pas loin de penser que cette fonction devrait disparaitre, chaque fois que quelqu’un l’utilise en prod ça se passe mal…

Maintenant, même si je n’ai rien compris à l’utilité de local/ j’avoue quand même que le besoin d’un cache piloté par la durée de péremption et pas simplement vidable via la page vider le cache est réel.
Aujourd’hui j’utilise toujours Cache Factory pour gérer les caches des plugins que je maintiens et la plupart (REST Factory, Rainette, SPIPer Ipsum…), sauf N-Core, possèdent une durée de conservation et je les mets dans local/.
Et donc Cache Factory fournit par défaut une page de vidage de ses caches où il est possible de choisir unitairement les caches à supprimer.

C’est dommage de ne pas avoir un endroit dans SPIP pour assurer ce genre de mécanisme.
Donc je plussoie à ta proposition de supprimer la fonction de vidage du répertoire local/ ce qui permettrait d’avoir aussi un cache plus « persistent ». Mais je ne sais pas si c’est une bonne pratique vu l’accès par HTTP.

Et contrairement à ce que j’ai dit à b_b il a raison, il faut vider les caches identifiés de SPIP uniquement voire à appeler un pipeline pour ajouter des caches à vider.

17

Re,

Le mer. 4 déc. 2019 à 16:50, Bruno Bergot <bruno@eliaz.fr> a écrit :

Re,

Le 04/12/2019 à 16:42, Eric Lupinacci a écrit :

Je ne suis pas sur que ce soit la bonne solution.

Je rappelle que l’idée était de rendre cohérent l’action avec ce qu’elle
annonce faire, donc vider le cache de qui est décrit comme « Les images
calculées automatiquement par SPIP (vignettes des documents, titres
présentés sous forme graphique, fonctions mathématiques au format
TeX…) occupent dans le répertoire local/ »

Oui tu as raison.

Dans pas mal de plugins j’utilise local/ pour avoir des caches plus
« persistents » a priori que tmp/.

Tu fais donc un usage détourné du répertoire local/ car tu supposes que
les gens le vide moins souvent que tmp, c’est bien ça ?

Et ouais, je viens de m’en rendre compte. J’ai répondu à Cédric sur le sujet.

Donc, je pense qu’on s’attend en général à voir les répertoires
cache-monboplugin disparaitre aussi.

Oui peut-être, d’où ma question/remarque à propos des répertoires
cache-css et cache-js.

Je serais donc plus favorable à une liste d’exclusions (qui pourrait être
mise à jour par pipeline éventuellement) plutôt qu’à un ciblage.

Oui pourquoi pas plus tard, là je pensais juste à un fix « rapide » :slight_smile:

Ben non en fait au vu de la réponse de Cédric mon idée est mauvaise.
Il faut bien faire ce que tu dis quitte à appeler plus tard un pipeline pour ajouter des nouveaux répertoires à vider.

++

Eric

18

Le 4 déc. 2019 à 18:53 +0100, Eric Lupinacci <eric@smellup.net>, a écrit :

Yop,

> Le mer. 4 déc. 2019 à 16:48, Cerdic <cedric@yterium.com> a écrit :
> > Attention !
> >
> > local/ ne doit pas être utilisé pour sa persistence, qui n’est pas supposée meilleure ou différente de tmp/ mais uniquement pour le fait que le conteni de local/ est accessible en http.
> >
> > Autrement dit, si c’est un fichier interne, non directement chargé par l’internaute, il doit aller dans tmp/, sinon dans local/
>
> Ah ben la bonne légende urbaine que je me suis fabriquée tout seul :stuck_out_tongue: !
> Mais j'avoue que je ne comprends pas bien ce que ça veut dire que l'internaute peut charger le fichier directement ?

Que le fichier (image ou CSS, ou je ne sais quoi) est directement référencé dans les pages html et envoyé à l’internaute.
Ou a tout le moins que tu peux afficher le fichier dans ton navigateur comme par exemple
https://contrib.spip.net/local/config.txt
alors que les fichiers de tmp/ sont non accessible (le dossier tmp/ est marqué en deny)

19

Mais j'avoue que je ne comprends pas bien ce que ça veut dire que l'internaute peut charger le fichier directement ?

Structure générale de SPIP - SPIP dit que c'est surtout de
cache d'images ...et ces images sont affichées par sur le sites public
:wink: Je pense qu'il faudrait peut-être expliciter plus l'article ?

Que le fichier (image ou CSS, ou je ne sais quoi) est directement référencé dans les pages html et envoyé à l’internaute.
Ou a tout le moins que tu peux afficher le fichier dans ton navigateur comme par exemple
https://contrib.spip.net/local/config.txt
alors que les fichiers de tmp/ sont non accessible (le dossier tmp/ est marqué en deny)

20

Le 04/12/2019 à 16:15, Bruno Bergot a écrit :

Bon,

Le 04/12/2019 à 16:06, Cerdic a écrit :

Je vote 1) cibler le repertoire cache-xx qu’on vide plutot que tout vider bourrin

Fausse alerte, les fichiers CACHEDIR.TAG config.txt remove.txt sont bien là après avoir vidé le cache des images, tout va bien donc.

Fausse fausse alerte, chez moi ils sont bien supprimés :slight_smile:

Y compris config.txt, qui est recréé aussitôt.

--
nicod_