Maj des fichiers

This commit is contained in:
Jephté Clain 2023-01-14 17:48:30 +04:00
parent 0adfa413ae
commit e41bac359e
1 changed files with 5 additions and 677 deletions

682
dkrun
View File

@ -16,7 +16,11 @@ USAGE
OPTIONS OPTIONS
-m, --machine MACHINE -m, --machine MACHINE
Sélectionner la machine spécifiée avant de dérouler le script Sélectionner la machine spécifiée pour les opérations docker. Cette
option est incompatible avec --context
-M, --context CONTEXT
Sélectionner le contexte spécifié pour les opérations docker et
kubernetes. Cette option est incompatible avec --machine
-n, --no-build -n, --no-build
Ne pas reconstruire l'image avant de déployer/exécuter l'application Ne pas reconstruire l'image avant de déployer/exécuter l'application
@ -57,682 +61,6 @@ OPTIONS
" "
} }
function display_help_dkbuild() {
uecho "\
OPTIONS
--help Aide générale
* --hdk Aide sur le format du fichier dkbuild
--href Référence sur les commandes utilisables dans un fichier dkbuild
DKBUILD
=======
Un fichier dkbuild est un script shell utilisé pour construire une ou plusieurs
images docker.
A cause de l'implémentation utilisée pour les directives, le fichier doit être
parcouru (i.e exécuté) à de multiples reprises pour analyser les paramètres et
variables définis. il faut donc \"protéger\" les appels de scripts externes ou
de fonctions gourmandes avec les commandes 'run' et 'call' pour éviter que ces
commandes ne soient exécutées à plusieurs reprises.
Quand un fichier dkbuild est exécuté, le répertoire courant est toujours le
répertoire qui contient le fichier
## Distributions ###############################################################
Une distribution s'entend au sens de la distribution linux utilisée comme base
pour l'image construite. L'idée est de pouvoir construire des images similaires
qui ne diffèrent que par la version de base du système d'exploitation
Pour une même distribution, plusieurs versions d'une image peuvent être
construites. Une version est définie en ajoutant un préfixe à la distribution.
La commande 'setdists' permet de lister explicitement les distributions valides
(et les versions associées le cas échéant). Si la distribution sélectionnée par
l'utilisateur n'est pas dans la liste fournie, le script s'arrête sans erreur.
La première distribution listée est spéciale: c'est la distribution la plus
récente, celle qui reçoit le tag :latest
La commande 'dist' permet de tester si la distribution spécifiée en argument a
été sélectionnée par l'utilisateur. L'argument 'LATEST' permet de tester la
dernière distribution.
La commande 'version' permet de tester si la version spécifiée en argument a été
sélectionnée par l'utilisateur. On part du principe qu'une distribution a déjà
été testée au préalable avec 'dist'
Exemple:
setdists 3.0-d11 3.1-d11 d10 d9
if dist d11; then
if version 3.0; then
...
elif version 3.1; then
...
fi
elif dist d10; then
...
elif dist d9; then
...
fi
Dans une même distribution, les versions doivent être ordonnées de la plus
ancienne à la plus récente. ici, la version 3.1 est listée après la version 3.0
pour que l'image construite aie le tag :latest
Note: 'setdists' ne doit être utilisé qu'une seule fois. Les invocations
suivantes sont ignorées.
## Profils #####################################################################
Un profil correspond à l'environnement de destination de l'image: production,
test, développement.
La commande 'setprofiles' permet de lister explicitement les profils valides.
Si le profil sélectionné par l'utilisateur n'est pas dans la liste fournie, le
script s'arrête avec une erreur. Le premier profil listé est spécial: c'est le
profil par défaut.
La commande 'profile' permet de tester si le profil spécifié en argument a été
sélectionné par l'utilisateur. L'argument 'DEFAULT' permet de tester le profil
par défaut.
Exemple:
setprofiles prod devel
if profile prod; then
...
elif profile devel; then
...
fi
Si le build est indépendant de la distribution, ou si la distribution est
utilisée sans version, alors il est possible de préfixer le profil d'une
version. Exemple:
setprofiles v1-prod v2-prod
if profile prod; then
if version v1; then
...
elif version v2; then
...
fi
fi
Dans un même profil, les versions doivent être ordonnées de la plus ancienne à
la plus récente.
Si les distributions sont utilisées avec des versions, alors c'est une erreur de
spécifier une version dans le profil
Note: 'setprofiles' ne doit être utilisé qu'une seule fois. Les invocations
suivantes sont ignorées.
## Versions ####################################################################
Si la version de l'image à construire n'est liée ni à la distribution, ni au
profil, il est possible de la spécifier avec la commande 'setversion'. La
version spécifiée avec 'setversion' est utilisée par défaut pour toutes les
images dont la version n'est pas spécifiée dans la distribution ou le profil.
La commande 'setversion' est évaluée en même temps que les commandes 'setenv',
ainsi il est possible d'utiliser la valeur d'une variable définie au préalable.
## Environnement ###############################################################
La commande 'machine' permet de tester si le build est fait sur la machine
spécifiée. Ce peut être la machine courante, ou la machine spécifiée avec
l'option --machine de la commande build
Exemple:
if machine host{1,2,3}-prod; then
setprofiles prod
elif machine host{1,2,3}-test; then
setprofiles test
else
setprofiles devel test prod
fi
Les variables sont de deux types: argument de build ou variable d'environnement
La commande 'setenv' permet de définir une variable d'environnement. La commande
'setarg' permet de définir un argument de build. Ces valeurs sont alors
automatiquement utilisées à l'endroit approprié.
Ces commandes acceptent une liste d'argument de la forme VAR[=VALUE]
Si la valeur n'est pas spécifiée (e.g 'setarg DESTDIR'), alors la variable doit
être définie dans l'environnement courant. Si la variable n'est pas définie dans
l'environnement, alors le script s'arrête avec une erreur.
Une fois qu'une variable est définie, il n'est plus possible de la modifier. Les
commandes alternatives 'resetenv' et 'resetarg' permettent de pallier cette
limitation.
## Valeurs par défaut ##########################################################
Toutes les commandes ont des arguments requis, mais aussi des arguments
facultatifs qui sont fournis sous la forme d'une liste d'éléments VAR=VALUE
La commande 'default' permet de spécifier les valeurs par défaut de ces
arguments. Exemple:
if profile prod; then
default composer mode=production
elif profile devel; then
default composer mode=development
fi
composer install path/to/project
Une fois qu'une valeur par défaut est définie, il n'est plus possible de la
modifier. La commande alternative 'resetdefault' permet de pallier cette
limitation.
Définir des valeurs par défaut pour la commande 'docker' impacte la commande
'build' et toutes les commandes qui utilisent docker, comme 'composer' ou 'mvn'
## Synchronisation de fichiers #################################################
On peut vouloir s'assurer de la présence de certains fichiers à certains
endroits.
La commande 'checkout URL DESTDIR' permet de s'assurer qu'un checkout du dépôt
spécifié existe dans le répertoire DESTDIR. La branche ou le commit à utiliser,
la source en mode développement, etc. peuvent être spécifiés par des arguments
facultatifs.
La commande 'copy SRC DEST' permet de s'assurer que SRC et DEST sont
synchronisés. Si possible, des liens physiques sont créés pour conserver
l'espace disque. Par défaut, les fichiers ne sont créés que s'ils n'existent
pas.
## Support Composer, Maven, commandes génériques ###############################
La commande 'composer install' permet d'installer les dépendances Composer d'un
projet
La commande 'mvn package' permet de construire un projet Java.
La commande 'run' permet de lancer une commande quelconque. La commande est
cherchée dans le PATH et exécutée avec son chemin complet. celà permet de lancer
des commandes comme 'mvn' ou 'composer' ou dont le nom correspond à une fonction
déjà définie.
La commande 'call' permet de lancer une commande quelconque. La différence avec
'run' est que la commande est lancée telle quelle, sans modifications. Si une
fonction est définie, elle sera utilisée en priorité.
Si elles sont utilisées sans argument, les commandes 'composer', 'mvn', 'run' et
'call' retournent vrai si la commande doit être exécutée dans le contexte
courant. Celà permet d'implémenter des traitements complexes. Ainsi le script
suivant:
run cmd1
run cmd2
est équivalent à:
if run; then
cmd1
cmd2
fi
En phase d'analyse, ces commandes retournent faux, donc cmd1 et cmd2 ne seront
lancés qu'une seule fois lors de l'invocation de dkbuild. Cela signifie qu'il ne
faut pas utiliser des directives de définition de variables à l'intérieur. Par
exemple, le script suivant ne produit pas forcément l'effet escompté:
if run; then
setenv var=value
default
cmd args...
fi
Bien entendu, si on veut être sûr que des commandes externes soient lancées, on
peut toujours utiliser 'run' à l'intérieur, e.g
if composer; then
run extcmd
func
composer args...
fi
## Support Dockerfile et docker build ##########################################
La commande 'dockerfile OUTPUT' permet de construire de façon incrémentale et
dynamique un fichier Dockerfile. Toutes les commandes d'un fichier dockerfile
traditionnelles sont reconnues et elles doivent être spécifiées après la
commande 'dockerfile'.
La commande 'build' termine la construction du fichier Docker puis lance la
construction de l'image.
* arguments de build: les arguments de build définis dans le script sont passés
à docker pour la construction de l'image
* nom de l'image et tag: par défaut, la variable d'environnement IMAGE est
combinée le cas échéant avec DIST et VERSION pour déterminer les tags que
reçoit l'image construite.
La commande 'cbuild' lance le build de toutes les images mentionnées dans les
fichiers 'docker-compose.yml' et 'docker-compose.PROFILE.yml' le cas échéant
* variables d'environnement: les arguments de build définis sont inscrits dans
un fichier .env qui est utilisé ensuite par docker compose
Si aucune commande 'build' ou 'cbuild' ne figure dans le fichier, 'build' est
lancé automatiquement à la fin
## Autres commandes ############################################################
Il est possible d'organiser le script dans plusieurs fichiers qui sont inclus
avec la commande 'include'. Fonctionnellement, cela se passe comme si le contenu
du fichier inclus était inséré dans le script principal, à ceci près que le
répertoire courant devient temporairement celui du fichier inclus.
Exemple:
setdists d11 d10 d9
if dist d9; then
include d9/dkbuild
elif dist d10; then
include d10/dkbuild
elif dist d11; then
include d11/dkbuild
fi
La commande 'dkbuild' lance le build d'un répertoire destination. La différence
avec 'include' est que cela est fait dans un processus complètement différent,
comme si le build avait été lancé depuis la ligne de commande.
Les commandes 'section', 'note', 'info', 'debug' permettent d'afficher des
messages de différents niveaux
## Variables globales ##########################################################
PROJDIR est le chemin absolu du projet, dans lequel se trouve le fichier dkbuild
initial
La distribution actuellement sélectionnée se trouve dans la variable DIST. La
version actuellement sélectionnée se trouve dans la variable VERSION. Si la
commande 'setdists' n'est pas utilisée, alors ni DIST ni VERSION ne sont définis
Le profil actuellement sélectionné se trouve dans la variable PROFILE. La
version actuellement sélectionnée se trouve dans la variable VERSION (si les
distributions sont utilisées sans le support de la version). Si la commande
'setprofiles' n'est pas utilisée, alors ni PROFILE ni VERSION ne sont définis
IMAGE est le nom de l'image à construire. Si le nom de l'image contient le tag
(e.g IMAGE:TAG) alors le nom est utilisé tel quel. Sinon, DIST et VERSION sont
utilisés comme tags (i.e IMAGE:DIST et IMAGE:VERSION-DIST)"
}
function display_help_reference() {
uecho "\
OPTIONS
--help Aide générale
--hdk Aide sur le format du fichier dkbuild
* --href Référence sur les commandes utilisables dans un fichier dkbuild
REFERENCE
=========
## fonctions d'affichage
USAGE:
section TITLE
note MESSAGE
info MESSAGE
debug MESSAGE
## machine -- vérifier la machine courante
## setdists -- spécifier les distributions valides
## dist -- vérifier la distribution courante
## setprofiles -- spécifier les profils valides
## profile -- vérifier le profil courant
## setversion -- spécifier la version par défaut
USAGE: setversion VERSION
Les paramètres optionnels sont
* from-file=FILE
prendre la version depuis le fichier spécifié. les formats pom.xml et
VERSION.txt sont supportés
* from-repo=REPO
calculer la version depuis le dépôt git spécifié
* from-glob=GLOB
calculer la version depuis le chemin spécifié
* extract=REGEXP
à partir de la valeur calculée par l'un des paramètres from-*, matcher
l'expression régulière au format AWK, et prendre comme version la valeur de
l'expression \$1
Si from-glob est spécifié, la valeur par défaut de extract est calculée en
remplaçant '*' par '(.*)'
* add-prefix=PREFIX
Ajouter le préfixe spécifié à la version extraite
* add-suffix=SUFFIX
Ajouter le suffixe spécifié à la version extraite
## version -- vérifier la version courante
## setenv -- spécifier une variable d'environnement
## resetenv -- spécifier une variable d'environnement
## setarg -- spécifier une variable de build
## resetarg -- spécifier une variable de build
## default -- spécifier des arguments par défaut
## resetdefault -- spécifier des arguments par défaut
## checkout -- faire et vérifier checkout d'un dépôt git
USAGE: checkout URL [DESTDIR] [PARAMS]
Les paramètres optionnels sont
* checkout
mettre à jour dépôt. c'est la valeur par défaut. utiliser checkout= pour
désactiver la mise à jour du dépôt. utiliser checkout=devel pour synchroniser
depuis le répertoire de développement.
* origin=ORIGIN
spécifier l'origine. Par défaut, prendre 'origin'
* branch=BRANCH
spécifier la branche à utiliser dans l'origine spécifiée. La valeur par défaut
est 'master' si les profils ne sont pas utilisé. Si les profils sont utilisés,
la valeur par défaut est 'develop' pour les profils 'test' et 'devel', sinon
c'est 'master'.
Utiliser la syntaxe ^COMMIT pour ignorer l'origine et sélectionner un commit
en particulier.
* develdir=DIR
spécifier l'emplacement du répertoire de développement, utilisé avec
checkout=devel
* develtype=TYPE
spécifier le type de projet pour la synchronisation depuis le répertoire de
développement. certains projets, notamment les projets composer avec des
dépendances de type 'path', nécessitent une méthode de synchronisation
particulière. Si ce paramètre n'est pas spécifié, il est auto-détecté. Les
valeurs supportées sont:
* composer -- détecté de par la présence d'un fichier composer.json
* maven -- détecté de par la présence d'un fichier pom.xml
* none -- valeur par défaut: pas de type particulier
## copy -- synchroniser des fichiers
USAGE: copy SRC DEST [PARAMS]
Si SRC est un fichier, alors DEST doit être un chemin vers le fichier
destination. Si SRC est un répertoire, alors DEST doit être un chemin vers le
répertoire destination. On peut forcer à considérer SRC et/ou DEST comme un
répertoire en les suffixant de '/'
Par exemple:
* copy SRCDIR/ DESTDIR/
échoue si SRCDIR et/ou DESTDIR sont des fichiers
* les commandes suivantes sont équivalentes:
copy SRC DESTDIR/
copy SRC DESTDIR/SRCNAME
Les paramètres optionnels sont
* copy
synchroniser les fichiers. c'est la valeur par défaut. utiliser copy= pour
désactiver la synchronisation des fichiers.
* overwrite
autoriser l'écrasement des fichiers destination, ce qui permet de rendre la
destination identique à la source. par défaut, un fichier destination est
laissé en place, ce qui permet d'avoir le cas échéant des fichiers locaux
différents de la source.
* gitignore=BASEDIR
maintenir le fichier .gitignore de BASEDIR, qui doit être un répertoire parent
de DESTDIR. Les fichiers synchronisés sont rajouté le cas échéant dans
.gitignore, sauf si le répertoire qui les contient est déjà exclu.
NB: Un fichier n'est considéré pour l'ajout dans .gitignore que s'il a été
copié au préalable. Ainsi, un fichier déjà existant dans la destination ne
sera pas ajouté dans le fichier .gitignore si overwrite=
## genfile -- créer un fichier générique
USAGE: genfile OUTPUT [INPUT] [PARAMS]
Si le fichier INPUT est spécifié, il est utilisé pour créer le contenu initial
du fichier. Sinon, l'entrée standard *doit* être redirigée depuis un fichier, et
elle est lue pour générer le contenu initial du fichier à générer.
Les paramètres optionnels sont
* context=DIR
générer le fichier dans le répertoire spécifié
* sed=SCRIPT
script sed à appliquer au fichier
## dockerfile -- créer un fichier Dockerfile
USAGE: dockerfile [OUTPUT [INPUT]] [PARAMS]
Si le fichier INPUT est spécifié, il est utilisé pour créer le contenu initial
du fichier. Sinon, *si* l'entrée standard est redirigée depuis un fichier, elle
est lue pour générer le contenu initial du fichier.
Les paramètres optionnels sont
* context=DIR
générer le fichier dans le répertoire spécifié
* sed=SCRIPT
script sed à appliquer au fichier initial, construit à partir de l'entrée
standard. Le fichier n'est plus modifié par la suite.
## build -- construire une image avec docker
USAGE: build [PARAMS]
Les paramètres optionnels sont
* build
construire les images, c'est la valeur par défaut. utiliser build= pour
désactiver la construction.
* context=DIR
répertoire de contexte. cette valeur est en principe générée automatiquement
par la commande 'dockerfile'
* dockerfile=FILE
fichier de build à utiliser. cette valeur est en principe générée automatiquement
par la commande 'dockerfile'
* no-cache
ne pas utiliser le cache
* pull
forcer la mise à jour des images dépendantes
* host-mappings=MAPPINGS
définir des mappings d'hôte. si ce paramètre n'est pas spécifié, consulter
aussi la valeur par défaut 'docker host-mappings='
* set-tag=TAGS... ou set-tags=TAGS...
spécifier des tags à rajouter au nom de l'image, séparés par un espace. cette
liste remplace celle calculée automatiquement. ce paramètre est ignoré pour
les noms d'images comportant un tag
* add-tag=TAGS... ou add-tags=TAGS...
spécifier des tags à rajouter à la liste calculée automatiquement, séparés par
un espace. ce paramètre est ignoré pour les noms d'images comportant un tag
* image=IMAGES... ou images=IMAGES...
liste de nom d'images, séparés par un espace. si les noms n'ont pas de tag, le
tag est construit à partir de DIST et VERSION sous la forme [VERSION-]DIST
* push
pousser les images vers le registry après les avoir construites
## cbuild -- construire une image avec docker compose
USAGE: cbuild [SERVICE] [PARAMS]
Les paramètres optionnels sont
* files=FILES...
spécifier les fichiers docker-compose à utiliser. Par défaut, prendre
docker-compose.yml et docker-compose.PROFILE.yml
* project-name=PROJECT_NAME
spécifier le nom du projet
* no-cache
ne pas utiliser le cache
* pull
forcer la mise à jour des images dépendantes
## include -- inclure un autre fichier dkbuild
## dkbuild -- lancer un builder externe
La commande dkbuild qui traite le script de build courant est lancée telle
quelle, avec la même syntaxe qu'en ligne de commande. L'intérêt de cette
commande est qu'on est assuré d'utiliser le même dkbuild que celui qui traite le
script de build courant.
## composer -- gérer projet composer
USAGE: composer DESTDIR [ACTION [PARAMS] [ARGS]]
La destination est obligatoire. Sans arguments, cette commande retourne
simplement vrai
Les actions valides sont
* install -- installer les dépendances. c'est l'action par défaut
* update -- mettre à jour les dépendances
* rshell -- lancer un shell root dans le répertoire du projet
* shell -- lancer un shell utilisateur dans le répertoire du projet
* none -- ne rien faire
L'action est exécutée sur DESTDIR. Juste avant de lancer l'action, le répertoire
courant est modifié pour être DESTDIR, ce qui permet d'utiliser des chemins
relatifs le cas échéant.
La commande 'rshell' lance un shell bash avec l'utilisateur root au lieu de
lancer la commande composer, ce qui permet de faire des opérations plus
complexes si le besoin s'en fait sentir. La commande alternative 'shell' lance
le shell avec le compte utilisateur. Ces commandes sont particulièrement utiles
si composer est paramétré pour être lancé dans un container
Les paramètres optionnels sont
* args=ARGS...
arguments à rajouter à la commande composer. La valeur par défaut dépend du
profil:
* prod: --no-dev -o
* test: --no-dev -o
* autres profils: (pas d'arguments)
* php=VERSION
version de PHP en dessous de laquelle image= est utilisé. En d'autres termes,
c'est la version minimum de PHP nécessaire pour faire tourner composer. L'idée
est que si la version de PHP installée est suffisante, il n'est pas nécessaire
de passer par une image docker.
Cette valeur doit être spécifiée avec le format de PHP_VERSION_ID i.e 70300
pour PHP 7.3
* Spécifier 'any' ou 'force' pour forcer l'utilisation de l'image docker.
* Spécifier 'none' ou 'system' pour lancer directement composer sans passer
par une image docker.
* php-max=VERSION
version de PHP à partir de laquelle image= est utilisé. En d'autres termes,
c'est la version maximum de PHP, à partir de laquelle il faut passer par une
image docker. L'idée est que si la version de PHP installée est trop récente,
ça peut poser problème avec le calcul des dépendances.
Cette valeur doit être spécifiée avec le format de PHP_VERSION_ID i.e 70300
pour PHP 7.3
Si la valeur n'est pas spécifiée ou vaut 'none', elle est ignorée.
* image=COMPOSER_IMAGE
image docker utilisée pour lancer composer. La valeur par défaut est la valeur
de la variable d'environnement \$COMPOSER_IMAGE
Spécifier 'none' pour lancer directement composer sans passer par une image
docker.
L'image spécifiée doit disposer de la commande 'su-exec' afin de pouvoir
lancer la commande avec l'utilisateur courant. Le répertoire \$HOME est monté
à l'intérieur du container et le script composer.phar du projet est utilisé le
cas échéant.
* machine=MACHINE
nom de la docker machine sur laquelle se connecter pour lancer l'image docker.
La valeur par défaut est -u, ce qui force l'utilisation de l'instance docker
locale. Spécifier 'current' pour ne pas modifier la valeur courante le cas
échéant
* host-mappings=MAPPINGS
définir des mappings d'hôte. si ce paramètre n'est pas spécifié, consulter
aussi la valeur par défaut 'docker host-mappings='
* composer=PATH/TO/COMPOSER
chemin vers l'exécutable composer. Par défaut, utiliser composer.phar s'il
existe dans le répertoire du projet. Sinon utiliser /usr/bin/composer
* setup=CMDS...
liste de commandes à lancer pour configurer le container. Un container ayant
pour base COMPOSER_IMAGE et nommé d'après le nom du projet est préparé et les
commandes spécifiées y sont lancées. Ce container est réutilisé à chaque fois.
Ce paramétrage est utilisé par exemple pour installer certains packages
nécessaire au projet.
* project-name=PROJECT_NAME
si setup= est défini, nommer l'image sur la base de ce nom. par défaut, le nom
est calculé automatiquement
Si un fichier .composer.conf existe dans le répertoire du projet, il est sourcé
pour obtenir les valeurs par défaut des paramètres:
* COMPOSER_PHP -- valeur par défaut de php=
* COMPOSER_PHP_MAX -- valeur par défaut de php-max=
* COMPOSER_IMAGE -- valeur par défaut de image=
* COMPOSER_MACHINE -- valeur par défaut de machine=
* COMPOSER_CMD -- valeur par défaut de composer=
* COMPOSER_SETUP -- valeur par défaut de setup=
## mvn -- construire projet maven
USAGE: mvn DESTDIR [ACTION [PARAMS] [ARGS]]
Le répertoire de destination est obligatoire. Sans arguments, cette commande
retourne simplement vrai. L'action par défaut est 'package'
Les actions valides sont
* install -- lance mvn avec les commandes 'clean package install'
* package -- lance mvn avec les commandes 'clean package'
* package_only -- lance mvn avec uniquement la commande 'package'
* rshell -- lancer un shell root dans le répertoire du projet
* shell -- lancer un shell utilisateur dans le répertoire du projet
* java -- lancer java au lieu de lancer mvn. il est possible de spécifier la
version de java directement, e.g java7, java8, java11
L'action est exécutée sur DESTDIR. Juste avant de lancer l'action, le répertoire
courant est modifié pour être DESTDIR, ce qui permet d'utiliser des chemins
relatifs le cas échéant.
La commande 'rshell' lance un shell bash avec l'utilisateur root au lieu de
lancer la commande mvn, ce qui permet de faire des opérations plus complexes si
le besoin s'en fait sentir. La commande alternative 'shell' lance le shell avec
le compte utilisateur. Ces commandes sont particulièrement utiles si mvn est
paramétré pour être lancé dans un container
Les paramètres optionnels sont
* args=ARGS...
arguments à rajouter à la commande mvn
* java=VERSION
version de Java à sélectionner à l'intérieur de l'image docker
* Spécifier 'any' ou 'force' pour prendre la valeur par défaut
* Spécifier 'none' ou 'system' pour ne pas utiliser l'image docker
* image=MAVEN_IMAGE
image docker utilisée pour lancer mvn. La valeur par défaut est la valeur
de la variable d'environnement \$MAVEN_IMAGE
Spécifier 'none' pour lancer directement mvn sans passer par une image
docker, même si java= est renseigné
L'image spécifiée doit disposer de la commande 'su-exec' afin de pouvoir
lancer la commande avec l'utilisateur courant. Le répertoire \$HOME est monté
à l'intérieur du container.
* machine=MACHINE
nom de la docker machine sur laquelle se connecter pour lancer l'image docker.
La valeur par défaut est -u, ce qui force l'utilisation de l'instance docker
locale. Spécifier 'current' pour ne pas modifier la valeur courante le cas
échéant
* host-mappings=MAPPINGS
définir des mappings d'hôte. si ce paramètre n'est pas spécifié, consulter
aussi la valeur par défaut 'docker host-mappings='
* mvn=PATH/TO/MVN
chemin vers l'exécutable mvn. Par défaut, utiliser la commande trouvée dans le
PATH
* setup=CMDS...
liste de commandes à lancer pour configurer le container. Un container ayant
pour base MAVEN_IMAGE et nommé d'après le nom du projet est préparé et les
commandes spécifiées y sont lancées. Ce container est réutilisé à chaque fois.
Ce paramétrage est utilisé par exemple pour installer certains packages
nécessaire au projet.
* project-name=PROJECT_NAME
si setup= est défini, nommer l'image sur la base de ce nom. par défaut, le nom
est calculé automatiquement
Si un fichier .maven.conf existe dans le répertoire du projet, il est sourcé
pour obtenir les valeurs par défaut des paramètres:
* MAVEN_JAVA -- valeur par défaut de java=
* MAVEN_IMAGE -- valeur par défaut de image=
* MAVEN_MACHINE -- valeur par défaut de machine=
* MAVEN_CMD -- valeur par défaut de mvn=
* MAVEN_SETUP -- valeur par défaut de setup=
## run -- lancer des commandes
## call -- lancer des commandes ou des fonctions
"
}
##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ##~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
## shared ## shared