Il y a pas loin d’un an, j’ai décrit sur l’une des nombreuses manière d’automatiser une release grace à Github et Travis CI.

Depuis, les nouvelles versions de Gitlag intègre des fonctionnalités d’intégration continue. Couplé avec des services comme Framagit qui permettent d’avoir des repos git privé, ça permet d’avoir gratuitement accès à une infrastructure d’intégration continue gratuite pour toutes sortes de projets personnels.

Je prends pour exemple une projet perso en latex SW-Redemption pour vous montrer ce qu’il est possible de faire avec gitlab-ci.

Configuration de gitlab-ci

Un peu comme pour travis qui lit un fichier .travis.yml, gitlab-ci utilise un fichier .gitlab-ci.yml (super original). Mais contrairement à celui de travis, il est vraiment plus simple, en tout cas à fonctionnalités égales. Toute la config est détaillée ici (en anglais).

Voilà ce que j’ai dans mon fichier

before_script:
  - apt-get update -qq && apt-get install -y -qq texlive-base texlive-xetex texlive-latex-recommended texlive-latex-extra texlive-extra-utils texlive-fonts-recommended texlive-font-utils texlive-lang-french texlive-math-extra texlive-pictures latex-xcolor texlive-bibtex-extra pgf lmodern biber latexmk ghostscript

swr-SNAPSHOT:
  stage: build
  script:
    - latexmk -f -r swr-class/latexmkrc || true
    - mv "build/swr-livre-joueur.pdf" "build/SW-Redemption, Livre du joueur.pdf"

  artifacts:
    expire_in: 1 day
    paths:
    - "build/SW-Redemption, Livre du joueur.pdf"
  allow_failure: true

• before_script C’est tout ce dont j’ai besoin pour construire mes pdf à partir de latex. Comme le addon.apt dans le fichier travis
• swr-SNAPSHOT C’est le nom du build
  • script les scripts à lancer pour le build
  • artefact Les fichiers du build à publier

Déjà à ce niveau, on voit que l’on crée l’artefact et que l’on a pas à se compliquer la vie avec les clé de connexion au repo. Rien que ça c’est appréciable. Après certes les fonctionnalités de release de Gitlab sont pas les mêmes que celles de Github mais ça fait bien le job.

Bref, la killer feature c’est ça :

image: marthym/latex:1.0.0

swr-SNAPSHOT:
  stage: build
  script:
    - latexmk -f -r swr-class/latexmkrc || true
    - mv "build/swr-livre-joueur.pdf" "build/SW-Redemption, Livre du joueur.pdf"

  artifacts:
    expire_in: 1 day
    paths:
    - "build/SW-Redemption, Livre du joueur.pdf"
  allow_failure: true

Il est possible d’utiliser des images Docker, présentent sur DockerHub. Et ça permet de ne plus avoir à faire les installations pre-build, particulièrement longue pour LaTeX. En plus ça permet aussi de tester le build depuis votre machine dans le container Docker. Pas besoin de committer dix fois pour trouver ce qui ne s’est pas bien installé sur l’image de Travis. Grace à cette fonctionnalité, on connaît exactement la version du système qui lance le build et si l’on utilise des packages en version récente, pas de soucis.

En bref c’est top.

Vous pouvez comparez le gitlab-ci et le travis-ci du projet en question.

Création de l’image Docker

Je fais un paragraphe rapide, c’est pas le but du post.

En gros, il faut se créer son Dockerfile et le pousser sur Github, vous trouverez le mien là. Ensuite vous créez un compte sur DockerHub. Puis vous allez dans “Create” » “Create Automated build” et vous choisissez Github. Le reste est assez clair et simple.

Ensuite chaque fois que vous poussez sur Github, ça builde le docker. Une fois builder, il est disponible pour Gitlab-ci.

GitLab-CI + Docker Hub écrit à l'origine par Marthym pour J'ai acheté un PC neuf cassé ... le April 21, 2017.

Original post of Marthym.Votez pour ce billet sur Planet Libre.

Dans un précédent article, j’ai décrit ce qu’était pour moi une bonne plateforme de traduction, voici mon retour d’expérience sur Pontoon. C’est déjà un bon outil alors qu’il est encore en pleine maturation, bien adapté pour les projets bien organisés, moins pour les plateformes génériques/multi-projets (ex: Fedora l10n ou Suse l10n).

La technique

Ça commence bien, même si Pontoon est géré par mozilla (qui pousse le L20N), cet outil prend en charge divers formats bien connus : gettext, XLIFF, L20n, lang, properties, etc.

On voit ici que les développeurs ont compris comment faciliter la vie tant des développeurs que des traducteurs, puisque la synchronisation avec un dépôt est obligatoire, encore une fois les standards sont respectés : SVN, HG et Git. On limite ainsi les risques de désynchonisation, et via un mécanisme de robots, l’outillage est complet pour faire de l’automatisation.

On notera que sur la majorité de ses projets, Mozilla crée des dépôts dédiés pour les traductions, allant jusqu’à faire un dépôt par langue (pour une question de gestion des droits).

Le support au travail d’équipe

La plateforme utilise une structure générale simple et efficace : langue > projet > ressource > interface de traduction. On retrouve cette structure à l’identique dans l’adresse de navigation.

L’entête de la page affiche systématiquement les informations utiles. C’est tellement simple que je n’ai même pas besoin d’une impression d’écran pour l’expliquer :

French fr
    Plural forms* one, other
    Script Latin
    Writing direction Left-to-right
    Number of literate speakers* 231,632,000
    Translated strings 53,584
    Suggested strings 16
    Fuzzy strings 0
    Missing strings 64
    All strings 53,664

L’équipe française fonctionne par un mécanisme de validation. Seules quelques personnes peuvent valider le contenu tandis que toutes peuvent suggérer des améliorations. Encore du pragmatisme, bravo à ceux qui ont mis en place ce mécanisme simple et efficace, c’est un peu fermé car tout le monde n’est pas à égalité, mais extrêmement simple à comprendre.

Quand on descend dans un projet, on voit plein d’autres choses utiles, allant du point de contact à l’échéance de traduction, incluant le degré de priorité, les sites de production et de développement et le dépôt… Que demander de plus ?

EU Copyright campaign French :
    Priority
    Deadline Mar 10, 2017
    Repository github.com/mozilla/copyright
    Resources Production site · Development site
    Contact person Théo Chevalier

Si on est capable de voir les contributeurs les plus actifs (et les contacter), il n’est malheureusement pas possible de discuter dans l’outil, que ce soit sur une phrase, sur un projet ou avec le mainteneur. Les échanges doivent donc se reporter sur une liste de discussion, un canal IRC ou autre. Pontoon étant en développement, il est probable que cela vienne un jour.

L’aide à la traduction

L’interface d’édition est simple et efficace, focalisée sur le travail de traduction et ergonomique. On y retrouve les suggestions, la traduction automatique (via mémoire de traduction ou outils en ligne) et les traductions menées par d’autres équipes de traduction.

Les points évoqués dans le travail d’équipe confirme qu’il y a donc nombre d’étapes très limité pour trouver son projet et commencer à travailler, ainsi que pour comprendre le parcours de la traduction à la diffusion/publication de notre travail.

La mémoire de traduction n’est cependant pas interrogeable directement depuis Pontoon, il faut aller sur un autre outil maison de Mozilla.

Bilan

C’est donc globalement une plateforme très intéressante, à laquelle il ne manque pas grand-chose pour pouvoir être utilisé par n’importe quelle structure :

• une connexion avec autre chose qu’une adresse Mozilla (personna/Firefox sync),
• des notifications (mail) en fonction des évènements sur la plateforme (nouveau projet à traduire, modifications, etc.),
• la possibilité d’importer/exporter dans divers formats,
• l’utilisation de règles qualité lancées sur les traductions.

À ce stade, elle ne pourrait pas vraiment être utilisée par Fedora par exemple, mais on y est presque !

Original post of Jean-Baptiste Holcroft.Votez pour ce billet sur Planet Libre.

A ma grande stupeur il n’y a eu quasiment aucune info sur la sortie de la version 2.3 de Ansible le 12/04. En Français rien de rien et en Anglais un malheureux article dans ZDNet vide d’intérêt. Il se trouve que j’attendais avec impatience cette version, profitons-en pour faire le point.

Les grosses news

Ansible s’est fait racheter par Red Hat en octobre 2015. On aurait pu craindre que l’outil soit relégué au second plan mais 18 mois plus tard on constate que le rythme de développement est toujours soutenu et que l’outil continue de s’améliorer. Dans l’absolu le rachat est une excellente nouvelle car ça pérennise Ansible et augmente sa popularité/visibilité derrière le numéro 1 de l’Open Source Red Hat.

Le chantier pour passer Ansible sur Python 3 est en cours et une tech preview du support de Python 3 est disponible depuis Ansible 2.2.

Le dernier point concerne la direction que prend Ansible notamment en développant toute la partie réseau que ce soit au niveau des modules (networking modules) et du fonctionnement de Ansible. Je vous invite à lire deux articles sur ces sujets sur le blog de Ansible (1, 2).

Toujours plus de modules

Voici une short list des nouveautés qui ont attiré mon attention sur les deux dernières versions majeures. Je vous invite à consulter le changelog complet de chaque version pour voir les nombreux autres modules ajoutés.

Changelog Ansible 2.3 :

• Module iso_extract: Extraire des fichiers d’une image ISO
• Module ldap_entry : Ajouter/supprimer des entrées LDAP
• Module archive : Archiver (compresser) des fichiers/dossiers, c’est l’inverse du module unarchive
• Module proxmox_kvm : Gérer les machines virtuelles Qemu (KVM) sur un cluster Proxmox
• Module parted : Configurer les partitions

Changelog Ansible 2.2 :

• Module letsencrypt : Créer des certificats SSL avec Let’s Encrypt
• Module systemd : Gérer les services
• Module wakeonlan : Envoyer des paquets Wake-on-LAN (WoL)

Et Windows

J’attendais de voir l’évolution de l’automatisation des environnements Windows sur Ansible et c’est (enfin) mature :

• Depuis un moment les commandes ansible-vault encrypt et ansible-vault decrypt permettent de chiffrer/déchiffrer les informations confidentielles (mots de passe notamment). Ça donnera par exemple ansible windows -m win_ping --ask-vault-pass
• La liste des modules Windows s’étoffe de plus en plus et a passé un cap à mon sens
• On peut très bien se passer de Kerberos, personnellement j’ai décidé de gérer la connexion avec le compte administrateur local
• Abyss Project, Zwindler et IT-Connect ont fait de bons tutos de démarrage pour gérer Windows avec Ansible
• Il est devenu très simple de configurer un hôte Windows. En prérequis il faut PowerShell 3 installé puis taper quelques commandes

# On exécute PowerShell en tant qu'administrateur (Clic droit puis Exécuter en tant qu'administrateur)
# https://github.com/ansible/ansible/blob/devel/examples/scripts/ConfigureRemotingForAnsible.ps1
# ConfigureRemotingForAnsible.ps1 est placé à la racine du C:\\
Set-ExecutionPolicy Unrestricted -Force
cd C:\\; .\\ConfigureRemotingForAnsible.ps1
Set-ExecutionPolicy Restricted -Force
Remove-Item ConfigureRemotingForAnsible.ps1; exit

J’ai configuré tous mes serveurs Windows et je vais maintenant m’intéresser aux tâches que je peux automatiser.

Original post of blog-libre.Votez pour ce billet sur Planet Libre.

Si il y a une chose dont j’ai horreur c’est d’essuyer les plâtres d’outils mal finalisés. La dernière version d’Ubuntu 17.04 Zesty Zapus est sortie le 13/04 et j’ai eu la chance malchance d’avoir un peu de temps pour mettre à jour mes postes. Mais bon restons positif ça me donne l’occasion d’aider les pauvres malheureux qui vont se retrouver avec des ennuis DNS comme moi.

Un des changements importants apportés par cette nouvelle version est que systemd-resolved est maintenant utilisé comme résolveur DNS par défaut. Afin de jeter un œil vous pouvez faire un petit systemd-resolve status dans votre terminal. Vous pourrez également constater les changements dans le fichier /etc/resolv.conf.

# Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8)
#     DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN
# 127.0.0.53 is the systemd-resolved stub resolver.
# run "systemd-resolve --status" to see details about the actual nameservers.

nameserver 127.0.0.53

nameserver 127.0.0.53 pointe donc en réalité vers le daemon systemd-resolved comme c’est marqué ci-dessus. Chez moi ça se traduit tout de suite par une extrême lenteur pour aller sur le web, parfois des DNS Probe Finished, parfois des timeouts. Joie.

La communauté commence à s’activer et on voit fleurir quelques pistes pour résoudre le problème. J’ai personnellement apprécié cet article en Anglais qui propose dans un premier temps de désactiver DNSSEC source de la majorité des soucis apparemment. Comme il le souligne ce n’est pas propre, ce n’est pas une solution définitive car DNSSEC est utile d’un point de vue sécurité. Dans un second temps il propose de remplacer systemd-resolved par Unbound. C’est radical comme solution mais beaucoup de lecteurs souligneront que c’est LA bonne solution. Je vous fournis le lien pour des tutos en Français (moteur de recherche du Jdh powaaaa !).

Pour ma part j’ai choisi une autre solution moins radicale croisée ici. On peut constater que /etc/resolv.conf est en réalité un lien symbolique pointant vers /run/resolvconf/resolv.conf. On va supprimer ce lien symbolique puis en tirer un autre vers /run/systemd/resolve/resolv.conf qui est un fichier maintenu à jour par systemd-resolved pour compatibilité avec les programmes traditionnels Linux.

ls -la /etc/resolv.conf
sudo rm -f /etc/resolv.conf
sudo ln -s /run/systemd/resolve/resolv.conf /etc/resolv.conf

Je vous invite à présent à afficher /etc/resolv.conf pour constater le changement. Lorsque les plâtres sur systemd-resolved seront corrigés par les développeurs il vous suffira de faire un rollback en supprimant le lien symbolique et en tirant un lien symbolique vers /run/resolvconf/resolv.conf pour revenir à la configuration initiale.

ls -la /etc/resolv.conf
sudo rm -f /etc/resolv.conf
sudo ln -s /run/resolvconf/resolv.conf /etc/resolv.conf

Tcho !

Original post of blog-libre.Votez pour ce billet sur Planet Libre.

Aujourd'hui, ce jeudi 20 avril, est une journée dédiée à un test précis : sur la création de média installable pour Fedora. En effet, durant le cycle de développement, l'équipe d'assurance qualité dédie quelques journées autours de certains composants ou nouveautés afin de remonter un maximum de problèmes sur le sujet.

Elle fournit en plus une liste de tests précis à effectuer. Il vous suffit de les suivre, comparer votre résultat au résultat attendu et le notifier.

Qu'est-ce que la création de média installable ?

Son fonctionnement consiste en la sélection l'image voulue comme Workstation, spin KDE, Server ou autre, procède automatiquement au téléchargement et à l'installation sur un média amovible comme une clé USB disponible et compatible.

L'objectif étant de simplifier la procédure d'installation pour les néophytes, car beaucoup d'utilisateurs se perdent après le téléchargement du fichier ISO traditionnel pour procéder à l'installation. Là, tout sera automatisé et fonctionnel sans intervention particulière. De part cet objectif, ce sera le mode de téléchargement de l'image officielle de Fedora qui sera mis en avant à l'avenir.

La nouveauté par rapport à Fedora 25 est la disponibilité de l'utilitaire pour les images ARM avec installation sur d'autres médias que l'USB (comme une carte SD).

Les tests du jour couvrent :

• Le téléchargement ou la sélection de l'image souhaitée ;
• L'installation sur la clé USB ;
• La conformité de l'image d'installation (c'est-à-dire fonctionnelle) ;
• Compatible UEFI et BIOS ;
• Fonctionnel sous Fedora, Windows et Mac OS.

Le test est un peu inhabituel car il porte sur le fonctionnement de l'application sur d'autres systèmes que Fedora que sont Windows et Mac OS. Si vous avez de tels systèmes disponibles, il ne faut pas hésiter à remonter les soucis rencontrés avec eux. Car ce seront évidemment les systèmes préférentiels pour un tel outil.

Comment y participer ?

Vous pouvez vous rendre sur la page des tests pour lister les tests disponibles et rapporter vos résultats. La page wiki récapitule les modalités de la journée.

Si vous avez besoin d'aide lors du déroulement des tests, n'hésitez pas de faire un tour sur IRC pour recevoir un coup de main sur les canaux #fedora-test-days et #fedora-fr (respectivement en anglais et en français) sur le serveur Freenode.

En cas de bogue, il est nécessaire de le rapporter sur le BugZilla. Si vous ne savez pas faire, n'hésitez pas à consulter la documentation correspondante.

De plus, si une journée est dédiée à ces tests, il reste possible de les effectuer quelques jours plus tard sans problème ! Les résultats seront globalement d'actualité.

Original post of Renault.Votez pour ce billet sur Planet Libre.