Maj des fichiers
This commit is contained in:
parent
0adfa413ae
commit
e41bac359e
682
dkrun
682
dkrun
|
|
@ -16,7 +16,11 @@ USAGE
|
|||
|
||||
OPTIONS
|
||||
-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
|
||||
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
|
||||
|
||||
|
|
|
|||
Loading…
Reference in New Issue