3.5. Binaire (local) source

Le contenu en streaming d’un système de fichiers local vers le constructeur est appelé une construction de type binaire. La valeur correspondante de BuildConfig.spec.source.type est binaire pour ces builds.

Ce type de source est unique en ce qu’il est exploité uniquement en fonction de votre utilisation de la construction de démarrage oc.

Afin d’utiliser des builds binaires, invoquez oc start-build avec l’une de ces options:

Dans chacun des cas énumérés précédemment:

Au lieu d’un nom de fichier, vous pouvez passer une URL avec un schéma HTTP ou HTTPS à --from-file et --from-archive. Lorsque vous utilisez --from-file avec une URL, le nom du fichier dans l’image du constructeur est déterminé par l’en-tête Content-Disposition envoyé par le serveur Web, ou le dernier composant du chemin d’URL si l’en-tête n’est pas présent. Aucune forme d’authentification n’est prise en charge et il n’est pas possible d’utiliser un certificat TLS personnalisé ou de désactiver la validation du certificat.

Lorsque vous utilisez oc new-build --binary=true, la commande veille à ce que les restrictions associées aux builds binaires soient appliquées. Le BuildConfig résultant a un type source de binaire, ce qui signifie que la seule façon valide d’exécuter une build pour ce BuildConfig est d’utiliser oc start-build avec l’une des options pour fournir les données binaires requises.

Les options source Dockerfile et contextDir ont une signification particulière avec les builds binaires.

Dockerfile peut être utilisé avec n’importe quelle source de construction binaire. Lorsque Dockerfile est utilisé et que le flux binaire est une archive, son contenu sert de Dockerfile de remplacement à n’importe quel Dockerfile dans l’archive. Lorsque Dockerfile est utilisé avec l’argument --from-file, et que l’argument de fichier est nommé Dockerfile, la valeur de Dockerfile remplace la valeur du flux binaire.

Dans le cas du flux binaire encapsulant le contenu d’archive extrait, la valeur du champ contextDir est interprétée comme un sous-répertoire dans l’archive, et, si elle est valide, le constructeur change dans ce sous-répertoire avant d’exécuter la build.