Journal Github et la génération (pas terrible) de contenu

Posté par  (site web personnel) . Licence CC By‑SA.
Étiquettes :
14
24
mar.
2016

Attention, l'emploi moulistique que j'occupe veut que, demain pour moi c'est férié ! Alors pour moi, c'est un peu trolldi en avance.

Une rapide étude au doigt mouillé m'indique que Github « sailemal », mais que quand même par bien des aspects c'est pas si mal.
Je ne vous listerai pas les billets qui en parlent, ils sont pléthores sur ce site.

Suite à un bug que je rencontre sur la plate-forme Github, je me pose la question suivante :

Github est tellement populaire. Se peut-il qu'un Sourceforge bis en émerge ?
Qui peut se permettre de valider que le contenu des archives fournies par Github n'est pas modifié à dessin ?

Pour expliquer, ma dernière remarque, le bug que j'observe est que l'archive.zip de ma branche master est corrompu. Par corrompu, j'entends que le contenu des fichiers dans l'archive est altéré.

En effet en clonant le repository pas de soucis, tous les fichiers sont correctes. En cliquant, sur le lien Download ZIP et en extrayant les fichiers, un des fichiers s'est fait déposséder d'un dollar devant un nom de variable.
Alors certes dans mon cas ça provoque une erreur, seulement si l'utilisateur utilise le script avec un argument particulier. Mais comment prévoir qu'il ne s'agit pas d'une tentative de fonctionnalité ajoutée par Github ?

N.B. : Quelqu'un sait comment ouvrir un defect auprès de la plate-forme Github ? Parce que mis à part le formulaire de contact, je n'ai pas trouvé grand chose.

  • # oui github se sourceforgise :/

    Posté par  (site web personnel) . Évalué à 8.

    j'ai reçu un mail pour confirmer mon mail, ce qui m'a mis en visibilité de leur offre « Pro » (publicité incidente).

    oui, il y a le formulaire de contact sur https://github.com/contact et oui, je m'étais fait la même remarque que toi : « tiens, ils ne savent même pas proposer leur propre système de gestion des demandes que pour les projets libres », j'en ai conclu qu'ils craignent que les projets proprios (payant) passent par le même système, ce qui pourrait exposer leur business model d'exploiter ceux ne sachant pas faire du libre :-)

    Contrairement à ce que promeut Zenitram< sur https://linuxfr.org/users/bluebird/journaux/comment-github-a-ressuscite-mon-logiciel-libre dans les commentaires, il y a sans doute un réel problème latent avec github qui va enfin permettre de promouvoir de vraies alternatives, pérennes et existant depuis longtemps :

    • http://gitorious.org c'est mort, malencontreusement, ce qui montre l'avantage du libre à s'adapter et savoir migrer, bouger et toujours garder quelque chose de distribué à beaucoup d'endroits :/ (bienvenue sur Internet où de superbes initiatives naissent et meurent en moins de 5 ans, diaspora semble revivre, on verra bien…)
    • http://gitlab.org (même si le volet CE est amputé de fonctionnalités facilement ajoutables pour utilisation en entreprise comme la connexion au LDAP)
    • http://framasoft.net le dégooglisons est gaÿnial, continuez !
    • http://tuxfamily.org bon je suis partie prenante, vous pouvez auto-héberger votre VHFFS : faîtes-le !
    • https://gna.org oui, ça existe encore et yeupou fait un super boulot !
    • nos potes de http://toile-libre.org même s'ils aiment bien le NC, 'fin plus que des libristes…

    • [^] # Re: oui github se sourceforgise :/

      Posté par  . Évalué à 5.

      Gitlab CE comprend l'authentification par LDAP/AD. Dans l'édition entreprise, on trouve en plus la possibilité de synchroniser les groupes ldap avec les groupes internes, et la possibilité de connecter plusieurs serveurs LDAP.

      Voir la comparaison des 2 sur le site officiel.

    • [^] # Re: oui github se sourceforgise :/

      Posté par  . Évalué à 2.

      Je permet de citer Kallithea dans le cas d'un système auto-hébergé.
      J'ajouterais aussi que Github(gitlab,git*…) crée un autre biais qui est l'utilisation exclusive de git, pour ma part je trouve ça assez problématique.

      • [^] # phabricator

        Posté par  (site web personnel) . Évalué à 7.

        ils ont l'air de petits rigolos, extrait de

        http://phabricator.org/

        Written in PHP so literally anyone can contribute, even if they have no idea how to program.
        Even babies and dogs can contribute.
        You, too, can contribute!

        mais le produit est bien

        ウィズコロナ

    • [^] # Re: oui github se sourceforgise :/

      Posté par  . Évalué à -6.

      quand tu dis un problème latent je pense au fait que Github est très lent.

      C'est pour cette raison que je ne vais plus sur github et que je pense à me tourner vers un modèle de publication de type arborescence ( code only ) qui je trouve valorise plus le code sans se substituer aux rapport sociaux qui l'entourent.

    • [^] # Re: oui github se sourceforgise :/

      Posté par  . Évalué à 8.

      Contrairement à ce que promeut Zenitram< sur https://linuxfr.org/users/bluebird/journaux/comment-github-a-ressuscite-mon-logiciel-libre dans les commentaires

      J'ai cliqué sur le lien, j'ai fait un Ctrl-F, impossible de trouver la chaîne de caractères "Zenitram". Qu'on l'apprécie ou pas, c'est une chose, mais ne pas lui prêter des propos qu'il n'a pas tenus, c'est bien aussi ;).

      Ça, ce sont les sources. Le mouton que tu veux est dedans.

      • [^] # Re: oui github se sourceforgise :/

        Posté par  . Évalué à 4.

        BAud a du se tromper de journal sur github, je suppose qu'il pensait à la position que zenitram a exposé dans celui-ci : le danger github.

        Sapere aude ! Aie le courage de te servir de ton propre entendement. Voilà la devise des Lumières.

        • [^] # Re: oui github se sourceforgise :/

          Posté par  (site web personnel) . Évalué à 2. Dernière modification le 25 mars 2016 à 20:25.

          oui effectivement _o/ Merci, il n'était pas taggué github (ce que j'ai fait) ce qui a compliqué ma recherche :/

          mais ne pas lui prêter des propos qu'il n'a pas tenus, c'est bien aussi ;).

          eh oh je connais tout de même bien les positions, parfois à l'emporte-pièce, de notre Zenitram< préféré :-) Il a fait beaucoup d'efforts par rapport à il y a longtemps tout de même :D (même s'il lui reste quelques reliquats de surinterpréter parfois le propos de ses interlocuteurs).

  • # La réponse de Github

    Posté par  (site web personnel) . Évalué à 10.

    Ma foi, un retour plutôt rapide pour m'indiquer avec gentillesse que finalement, il n'y a pas d'erreur de leur part, avec la description de la raison.

    La page de contact permet donc bien d'ouvrir un defect sur Github.

    Pour la petite histoire, j'utilise $Format:%h$, le problème est que j'ai oublié le dernier $ et donc git en cherche un et le trouve sur la ligne suivante. Donc pas de Bug de la part de Github.

    Cependant, cela n'empêche pas la question : Comment vérifier toutes les archives générées et analyser si aucun ajout n'est fait ?

    • [^] # 6ème dimension

      Posté par  . Évalué à 2.

      donc git ajoute des caractères qui lui semblent manquer dans les sources lors de l'export ZIP,
      mais pourquoi fait-il cela ?

      est-ce que tu pourrais développer ou publier la réponse de github ?

      Envoyé depuis mon Archlinux

      • [^] # Re: 6ème dimension

        Posté par  . Évalué à 5. Dernière modification le 25 mars 2016 à 10:44.

        je viens de cloner ton dépôt,
        j'ai supprimé à nouveau le $
        après un commit/add (pas de push) j'ai lancé un
        git archive --format zip --output "output.zip" master
        et je n'obtiens pas exactement le comportement décrit :

        le $ devant le premier OPTARG de la ligne suivante est conservé,

        en revanche, le

        [$Format:%h]

        avec le $ manquant est transformé en [7a055ed]

        mes connaissance en git (et bash) sont quasiment nulles, mais j'essaye tout de même de comprendre (probablement au-delà de mes capacités :-)

        est-ce que quelqu'un peut expliquer cela ?
        est-ce que cela peut se produire avec des sources d'autres langages ?

        Envoyé depuis mon Archlinux

        • [^] # Re: 6ème dimension

          Posté par  (site web personnel) . Évalué à 5.

          Étrange je viens de faire le test, à l'instant :

          • Clonage
          • Modification pour supprimer le $
          • commit
          • Génération de l'archive

          J'ai exactement le même problème. C'est donc git (et non Github comme je le pensais), qui fait le remplacement.

          AMHA, cela peut se produire avec n'importe quel langage, git fait son remplacement pour tous les fichiers où ident export-subst est utilisé.

      • [^] # Re: 6ème dimension

        Posté par  (site web personnel) . Évalué à 1.

        Pas tout à fait, dans les deux lignes suivantes :

        v) echo -e "${0} v${VERSION} [$Format:%h]\nbaker © taylorchu(2013-2015) & Flyounet(2015-2016)\n" ; exit 0;;
w) [[ -d "${OPTARG}" ]] && __w="$( cd ${OPTARG}; pwd)/";;

        J'ai oublié un $ après $Format:%h. Et donc git, recherche le prochain $ qui se situe à la ligne suivante.

        • [^] # Re: 6ème dimension

          Posté par  . Évalué à 3.

          j'ai lu la description du bug sur ta page web et essayé de reproduire le pb sur un dépôt local,
          je n'arrive pas au même résultat ($ devant le premier OPTARG de la ligne suivante est conservé, mais instruction Format transformée)

          mon git est en version 2.7.4
          c'est peut-être la raison de la différence de comportement

          c'est tout de même inquiétant/gênant si on ne peut pas faire confiance à la commande/script git archive pour donner du contenu fidèle…

          Envoyé depuis mon Archlinux

          • [^] # Re: 6ème dimension

            Posté par  (site web personnel) . Évalué à 1.

            Possiblement, car si tu utilises la master branche, j'ai updaté ce matin le repository.

            Pour maintenant repoduire mon soucis, tu dois utiliser le commit 3a06d0b9f1ce977267ccf59674393d383a6cabf3, et donc l'archive suivante :
            https://github.com/Flyounet/baker/archive/3a06d0b9f1ce977267ccf59674393d383a6cabf3.zip

            • [^] # Re: 6ème dimension

              Posté par  . Évalué à 3.

              ok, j'ai du me louper dans mon premier test, j'arrive bien au même pb

              et je ne savais pas que git pouvait faire des substitution lors des création d'archives ou de checkout,
              c'est intéressant, mais à utiliser avec précaution (comme un couteau bien tranchant…)

              merci pour les explications, je peux arrêter ma veille et me remettre au travail

              Envoyé depuis mon Archlinux

        • [^] # Re: 6ème dimension

          Posté par  (site web personnel) . Évalué à 5.

          Il faut utiliser printf au lieu de echo -e – tu cherches à te faire du mal! :)

          • [^] # Re: 6ème dimension

            Posté par  (site web personnel) . Évalué à 3.

            J'aurais pu te croire si tu avais écrits printf %b, mais là, tu bluffes.

            Disons que je m'attends avec un shebang appelant bash, à ce que les printf et echo soit des builtins.

            Du coup, remplacer echo -e par printf dans le cas présent, ne fonctionnera tout simplement pas avec la version clonée. Et devrait fonctionner avec la version archive.

            Étant en congé, mon stock de mauvaise foi est à bloc.

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.