Lors d’un git fetch, si vous rentrez cette erreur :
server certificate verification failed. CAfile: /etc/ssl/certs/ca-certificates.crt CRLfile: none
Si vous utilisez un serveur Git sur un réseau privé et que ce serveur utilise un certificat autosigné, il faut désactiver la vérification ssl sur votre poste avec la commande suivante.
git config http.sslverify "false"
Si l’on veut squasher un grand nombre de commits rapidement, et surtout si l’on veut conserver les messages de commit, voici comment faire ci-dessous :
Par exemple, pour les 20 derniers commits
git reset --soft HEAD~20
git commit --edit -m"$(git log --format=%B --reverse HEAD..HEAD@{1})"
Au moment du commit, on va retrouver les 20 messages de commits, et on pourra les éditer.
Pour exécuter un script bash à intervalle régulié sur un CoreOS, on peut utiliser les systemd timers.
L’exemple ci-dessous copie un fichier vers un répertoire toutes les 2 minutes. Mais vous pouvez exécuter le script que vous voulez.
Créer le fichier service. Il doit être créé dans ce répertoire, et son nom doit se terminer par « .service »
sudo vi /etc/systemd/system/copy.service
Contenu du fichier de service
[Unit]
Description=Copy files from a folder to another
[Service]
Type=oneshot
ExecStart=/usr/bin/sh -c '/home/core/script/copy'
Le script appelé copy qui s’exécute dans le service
#!/bin/bash
# Copy the hello.png file to home folder
cp /tmp/hello.png /home/core/
Créez le timer. Il faut le mettre dans le même répertoire, et son nom doit se terminer par « .timer »
sudo vi /etc/systemd/system/copy.timer
Contenu du fichier
[Unit]
Description=Run service every 2 minutes
[Timer]
OnCalendar=*:0/2
# Pour lister tous les timers
sudo systemctl list-timers --all
Cela permet de savoir quand le timer va s’exécuter à nouveau, et quand il s’est exécuté la dernière fois.
# Pour démarrer le timer
sudo systemctl start copy.timer
# Pour l'arrêter
sudo systemctl stop copy.timer
Voir la documentation :
https://coreos.com/os/docs/latest/scheduling-tasks-with-systemd-timers.html
Lors d’un build Maven, celui-ci doit récupérer des dépendances. Il a le choix entre utiliser :
– une dépendance locale, elles sont dans le répertoire .m2 sur votre poste
Lorsque l’on builde du code en local (mvn install), les jars sont copiés dans ce .m2
– une dépendance distante sur Nexus
Elle sont créées par le server de build
Comment Maven choisit entre une dépendance locale ou Nexus ?
– Pour une dépendance en SNAPSHOT, il se base sur la date de build, si une version plus récente existe sur le server, c’est celle-ci qui est utilisée.
– Pour une dépendance en release, si elle existe en local, il ne va pas la récupérer sur le server.
Paramétrer ce comportement dans le settings.xml
Il y a un paramétrage pour les dépendances, et un pour les dépendances pour les plugins maven. Et pour chacun, il y a une partie pour les snapshots et une partie pour les versions releases.
<repository> <id>public</id> <name>Public Repositories</name> <url>http://ournexus.com:8081/nexus/content/groups/public</url> <releases> <enabled>true</enabled> <updatePolicy>XXX</updatePolicy> </releases> <snapshots> <enabled>true</enabled> <updatePolicy>XXX</updatePolicy> </snapshots> </repository>
where XXX can be:
always: Maven will check for a newer version on every build;
daily, the default value;
interval:XXX: an interval in minutes (XXX)
never: Maven will never try to retrieve another version. It will do that only if it doesn’t exist locally. With the configuration, SNAPSHOT version will be handled as the stable libraries.
https://maven.apache.org/settings.html
Problème si vous ne compilez pas tous les modules régulièrement, ou si l’on a un problème d’ordre de build dans notre projet :
il est possible d’utiliser un vieux SNAPSHOT d’un de nos modules provenant de Nexus, alors que l’on pense utiliser un SNAPSHOT local.
Pour pouvoir modifier à chaud la configuration de logback,
il faut modifier la balise « configuration » du fichier logback.xml et rajouter scanPeriod.
par exemple
<configuration scan="true" scanPeriod="5 seconds">
Par défaut, la période de scan des modifs est d’une minute. Il est possible de la modifier comme ici à 5 secondes.
Vous pouvez maintenant modifier ce que vous voulez, le niveau de log, les appenders, etc …
documentation :
https://logback.qos.ch/manual/configuration.html#autoScan
Lorsque l’on travaille sur une application versionnée sur Git, il est normal de créer régulièrement des branches. Le problème, c’est que les branches inutiles ne sont pas toujours supprimées au fur et à mesure.
for branch in `git branch -r | grep -v HEAD`; \ do echo -e `git show --format="%ci" \ $branch | head -n 1` \\t$branch; done | sort -r
2018-03-28 12:13:23 +0200 origin/master
2018-03-26 12:13:23 +0200 origin/develop
2018-03-26 11:14:05 +0200 origin/feature-new-button
2018-03-23 18:35:41 +0100 origin/feature-fix-css
2017-03-23 17:36:50 +0100 origin/feature-new-page
2016-02-09 12:11:53 +0100 origin/feature-process
…
En principe, ceux sont des branches qui ne doivent pas être supprimées, car elles n’ont pas été mergées sur la branche develop (choisir master dans la commande si vous n’utilisez pas de branche develop).
De plus, si vous avez squashé certaines branches après merge, elles peuvent se retrouver dans cette liste, même si vous l’avez mergée sur develop. Car lors d’un squash, le hash du commit change.
git branch --no-merged develop
Pour voir la liste
git remote prune origin --dry-run
Pour supprimer les références
git remote prune origin
Par exemple, la branche locale « feature/mybranch »
git branch -D feature/mybranch
Par exemple, la branche distante « feature/mybranch », (il faut avoir les droits)
git push origin --delete feature/mybranch
Dans Intellij, il est possible de générer les setters d’une classe. Il peut être intéressant dans certains cas de renvoyer « this » dans ces setters.
– Faire Alt Insert, « getter and setter »
– Choisir « Setter template : Builder »
Voir l’impression écran ci-dessous.
Si vous n’avez pas de jdk dans vos containers Docker, vous ne pourrez pas directement faire de heap dump de la JVM. Par exemple, si vos containers sont basés sur Alpine, avec un jre OpenJdk. Il n’y a pas les outils nécessaires.
Exemple pour faire un heap dump. Les commandes sont à effectuer depuis la machine hôte.
# Installer un OpenJdk pour pouvoir lancer le dump docker exec -ti container-name apk add \ --no-cache openjdk8 # Lister les process java du container, # et mémoriser celui de l'application, ici c'est le 22 docker exec -ti container-name jps # Créer un heap dump # à la fin de la commande, remplacer 22 par le bon pid # le dump se fait ici à la racine / docker exec -ti container-name jmap \ -dump:live,format=b,file=/heapDump.hprof 22 # Copier le dump, # du container vers la machine hôte docker cp container-name:/heapDump.hprof ./