Aller au contenu
Table des matières

another-install-script : Un menu d’installation pour le homelab

another-install-script propose un menu shell pour choisir des opérations système et installer des conteneurs. Les menus et les définitions de services sont séparés, ce qui évite de placer toutes les commandes dans setup.sh.

Configuration et automatisation Docker
  • Mis à jour
  • 3
  • Shell · 93.8%
  • GPL-3.0
Composants documentés
2Explorer les modules
Documents source
2Lire les instructions
Langages du dépôtShell 93.8%3

Parts calculées à partir des octets GitHub Linguist.

Shell93.8%
93.8%129 426 octets
Dockerfile3.12%
3.12%4 311 octets
Python3.07%
3.07%4 242 octets
Langage%Octets
Shell93.8%129 426
Dockerfile3.12%4 311
Python3.07%4 242

1. Aperçu

1.1. Pourquoi il existe

Installateur shell interactif (TUI) automatisant le déploiement de conteneurs Docker et de configurations serveur.

1.2. Cas d’usage

Déploiement rapide de serveurs et d'environnements homelab en une commande.

2. Cas d’utilisation

Menu whiptail en Bash qui installe des outils de base et des services Docker Compose sur un serveur Ubuntu personnel.

Diagramme de cas d’utilisation de another-install-script : Installer les outils de base; Déployer des conteneurs; Ouvrir les ports au pare-feu; Retirer des conteneurs; Tout désinstalleranother-install-scriptInstaller les outils de baseDéployer des conteneursOuvrir les ports au pare-feuRetirer des conteneursTout désinstallerAdmin du serveur«système»Moteur Docker«système»Pare-feu UFW
Acteurs à gauche (personnes) et à droite (systèmes externes) ; chaque ovale est un cas d’utilisation appuyé par les fichiers cités ci-dessous.
Installer les outils de base
Admin du serveur

L’entrée Installation de main_setup_menu (src/menu.sh) affiche une liste à cocher : paquets de base, Docker, Cockpit, LXDE, Ansible, Dokku, Vagrant, etc. ; src/install.sh exécute les choix.

Déployer des conteneurs
Admin du serveurMoteur Docker

Add Container liste les dossiers de containers/ ; chaque <nom>.sh lance docker-compose up -d sur le docker-compose.yml voisin (par exemple containers/gogs/).

Ouvrir les ports au pare-feu
Admin du serveurPare-feu UFW

Après l’ajout de conteneurs, manage_firewall_ports_allow_list (src/firewall.sh) lit leurs ports dans config.yml et les autorise ; si system.firewall vaut yes, ufw refuse le reste du trafic entrant sauf SSH, 2222, HTTP et HTTPS.

Retirer des conteneurs
Admin du serveurMoteur Docker

remove_container_menu affiche les conteneurs installés ; chaque fonction remove_docker_<nom> lance docker-compose down sur ce service.

Tout désinstaller
Admin du serveurMoteur DockerPare-feu UFW

L’entrée Uninstall lance uninstall.sh, qui charge les modules de src/ pour défaire l’installation. L’entrée Backup appelle pour l’instant le même script ; les fonctions de src/backup.sh ne sont pas reliées au menu.

2.1. Scénario : Préparer un VPS avec quelques services auto-hébergés

  1. Cloner le dépôt et lancer sudo bash setup.sh ; main_setup_menu s’ouvre car bashmenu vaut yes dans config.yml.
  2. Choisir Installation et garder basic et docker cochés ; le choix de docker ouvre ensuite la liste des conteneurs.
  3. Cocher des services comme gogs et bookstack ; chaque script lance docker-compose up -d.
  4. Laisser l’étape pare-feu autoriser les ports listés dans config.yml et activer ufw.
  5. Plus tard, utiliser Remove Container pour arrêter un service avec docker-compose down.

Fichiers consultésREADME.mdsetup.shconfig.ymlsrc/menu.shsrc/install.shsrc/containers.shsrc/firewall.shsrc/backup.shuninstall.shcontainers/gogs/gogs.sh

3. Démarrage

Ces commandes viennent de la documentation du dépôt. Elles n’ont pas été exécutées pendant cette revue.

README.md · How to install
git clone https://github.com/antoinebou13/another-install-script.git
cd another-install-script
sudo bash setup.sh
README.md · How to run coverage and tests
cd tests
bash test.sh
README.md · How to run coverage and tests
cd tests
bash coverage.sh
README.md · How to generate the documentation
git submodule update --init --recursive
git pull --recurse-submodules
git submodule update --remote
cd docs/generator
chmod +x generate_docs.sh
bash generate_docs.sh ../docs.md
README.md · Project Structure
+-- docs
|   +-- vendor
|       +-- ...
|   +-- docs.md
|   +-- generate_docs.md
|   +-- ...
+-- containers
|   +-- $container_name
|   |   |   +-- docker-compose.yml
|   |   |   +-- $container_name.sh
|   |   |   +-- ...
+-- src

4. Références du dépôt

Extraits des guides du dépôt, dans leur langue d’origine. Les liens ouvrent la version du code consultée.

Prérequis et premier essai

4.1. How to install

README.md

Currently, the script has been tested only on Ubuntu 18.04. You can install it by:
Lire les instructions complètes ↗

4.2. List of other installed program that you can chose to install

README.md

This script also offers optional installation of several other programs including git, python3, docker, docker-compose, snapd, curl, vim, and more.

  • build-essential
  • git
  • python3
  • python3-pip
  • wireless-tools
  • wpasupplicant
  • default-jre
  • jq
  • net-tools
  • firefox
  • lxde
  • vim
  • snapd
  • nmap
  • wget
  • curl
  • mlocate
  • cmake
  • docker
  • docker-compose
  • dry
  • ctop
  • emojify
  • dokku
  • lynk
Lire les instructions complètes ↗
Développement et contributions

4.3. How to run coverage and tests

README.md

Manuel Testing For running the bats tests For running and generate with kcov
Lire les instructions complètes ↗

4.4. Contributing

README.md

All pull request and suggestion is highly appreciated and encourage Go to Contributing
Lire les instructions complètes ↗

4.5. Contributing (CONTRIBUTING.md)

.github/CONTRIBUTING.md

When contributing to this repository, please first discuss the change you wish to make via issue, email, or any other method with the owners of this repository before making a change. Please note we have a code of conduct, please follow it in all your interactions with the project.
Lire les instructions complètes ↗
Documentation source

2 documents lus parmi 2 candidats.

5. Fonctions et composants 2

Point d’entrée et menus
setup.sh charge src/menu.sh et appelle main_setup_menu. Le script racine traite les arguments, tandis que le module chargé pilote la navigation. config.yml constitue le fichier de configuration placé à côté du lanceur.
Définitions des services
Le dossier containers contient les éléments d’installation propres aux services. Cette séparation facilite l’ajout de services, mais chaque installation modifie tout de même l’hôte ou son environnement Docker.

6. Architecture

Ouvrez un composant pour suivre ses connexions, ou explorez le diagramme complet.

Composants du système Contexte
Mermaid Diagramme interactif

Vue générale des composants et des échanges vérifiés dans le dépôt.

Vue statique de l’architecture de another-install-script
Aperçu statique. Le diagramme interactif le remplace après le chargement de Mermaid.
flowchart LR

subgraph group_cli["CLI management"]
  node_menu["CLI menu<br/>[menu.sh]"]
  node_router["Command router<br/>[router.sh]"]
  node_utilities["Shell utilities<br/>[utils.sh]"]
end

subgraph group_services["Service deployment"]
  node_service_catalog["Service catalog"]
  node_service_scripts["Service installers"]
  node_compose_definitions["Compose definitions"]
  node_container_manager["Container manager<br/>[containers.sh]"]
  node_docker_manager["Docker operations<br/>[docker.sh]"]
end

subgraph group_system["Server management"]
  node_program_installer["Program installer<br/>[install.sh]"]
  node_other_tools["Other programs<br/>[other.sh]"]
  node_firewall["Firewall management<br/>[firewall.sh]"]
  node_backup["Backup management<br/>[backup.sh]"]
end

subgraph group_config["Configuration utilities"]
  node_config_loader["Config management<br/>[config.sh]"]
  node_list_generator["Service list generator<br/>[containers_list.py]"]
  node_proxy_generator["Proxy config generator"]
  node_settings["System settings<br/>[config.yml]"]
end

node_user(("Server administrator"))
node_docker["Docker"]

node_user -->|"chooses services"| node_menu
node_menu -.->|"routes commands"| node_router
node_router -.->|"manages containers"| node_container_manager
node_container_manager -.->|"uses Docker operations"| node_docker_manager
node_docker_manager -.->|"operates"| node_docker
node_service_scripts -.->|"uses definitions"| node_compose_definitions
node_container_manager -.->|"installs services"| node_service_catalog
node_user -->|"requests programs"| node_program_installer
node_program_installer -.->|"offers programs"| node_other_tools
node_list_generator -->|"reads settings"| node_settings
node_proxy_generator -->|"reads settings"| node_settings


class node_menu,node_router,node_utilities toneBlue
class node_service_catalog,node_service_scripts,node_compose_definitions,node_container_manager,node_docker_manager toneAmber
class node_program_installer,node_other_tools,node_firewall,node_backup,node_user toneMint
class node_config_loader,node_list_generator,node_proxy_generator,node_settings toneRose
class node_docker toneIndigo

Un gestionnaire en ligne de commande pour installer et configurer des services auto-hébergés. Le parcours documenté part du menu, choisit un service ou un programme, puis délègue les conteneurs, le proxy et la configuration à des utilitaires Shell et Python.

Composants
18
Connexions
11
Liens appuyés par le code
4/11
Version texte du diagramme
  • setup.sh → src/menu.sh
  • src/menu.sh → Configuration et sélection
  • Configuration et sélection → Installation du conteneur
Suivre un parcours dans le code

Partez de l’appel à main_setup_menu, puis inspectez le service choisi dans containers avant de l’exécuter. Le menu distribue les actions; le service choisi détermine les changements réels.

7. Dossier technique

Établi à partir du code au commit 6e1e193 (209 fichiers). Chaque élément vient d’une correspondance de motif dans le code: ouvrez le fichier lié avant de vous y fier.

7.1. Couches et modules

Les dossiers sont classés par couche selon leur nom, de l’interface utilisateur jusqu’à l’accès aux données. Comme le classement repose sur les noms seulement, le diagramme ne dit rien des appels entre couches.

Mermaid Vue en couches
flowchart TB
  subgraph L_interface["Points d’entrée et API"]
    direction TB
    interface_0["containers/code-server<br/>1 fichier"]
  end
  subgraph L_application["Services applicatifs"]
    direction TB
    application_0["docs/scripts<br/>1 fichier"]
  end
  subgraph L_domain["Domaine et règles métier"]
    direction TB
    domain_0["containers/cloudtorrent<br/>1 fichier"]
  end
  subgraph L_infrastructure["Données et infrastructure"]
    direction TB
    infrastructure_0["containers/htpcdownloadbox<br/>1 fichier"]
  end
  subgraph L_core["Source principale"]
    direction TB
    core_0["src<br/>12 fichiers"]
    core_1["(root)<br/>3 fichiers"]
    core_2["containers/n8n<br/>2 fichiers"]
    core_3["containers/airsonic<br/>1 fichier"]
    core_more["+87"]
  end
  subgraph L_tests["Tests"]
    direction TB
    tests_0["tests<br/>3 fichiers"]
  end
  subgraph L_hosting["Build, CI et hébergement"]
    direction TB
    hosting_0["containers<br/>95 fichiers"]
    hosting_1[".github<br/>7 fichiers"]
  end
  L_interface ~~~ L_application
  L_application ~~~ L_domain
  L_domain ~~~ L_infrastructure
  L_infrastructure ~~~ L_core
  L_core ~~~ L_tests
  L_core ~~~ L_hosting
Modules et couche principale
ModuleCoucheFichiersTypesExtensions
srcSource principale122.sh .py
(root)Source principale30.sh
containers/n8nSource principale20.sh
containers/airsonicSource principale10.sh
containers/ansiblesemaphoreSource principale10.sh
containers/bitwardenSource principale10.sh
containers/bookstackSource principale10.sh
containers/calibreSource principale10.sh
containers/cheveretoSource principale10.sh
containers/cloudtorrentDomaine et règles métier10.sh
containers/code-serverPoints d’entrée et API10.sh
containers/couchpotatoSource principale10.sh
containers/cyberchefSource principale10.sh
containers/dailynotesSource principale10.sh

81 modules plus petits ne sont pas affichés.

7.2. Modèle C4

Du contexte du système aux déclarations du code. Chaque niveau conserve les limites des sources disponibles.

UML 1 · Contexte du système
1 · Contexte du système

La vue C4 la plus large : qui utilise le projet et sur quels systèmes et stockages externes il s’appuie. Rendu avec uml-mcp.

Source PlantUML
@startuml
!include <C4/C4_Context>
LAYOUT_LEFT_RIGHT()
System(SYS, "another-install-script", "another-install-script propose un menu shell pour choisir des opérati…")
@enduml
UML 2 · Conteneurs
2 · Conteneurs

Un niveau plus près : les parties qui s’exécutent séparément dans le projet, leur langage principal et le chemin des appels entre elles. Rendu avec uml-mcp.

Source PlantUML
@startuml
!include <C4/C4_Container>
LAYOUT_LEFT_RIGHT()
System_Boundary(SYS, "another-install-script") {
  Container(C0, "airsonic", "Docker")
  Container(C1, "ansible-semaphore_db", "Docker")
  Container(C2, "bookstack", "Docker")
  Container(C3, "bookstack_db", "Docker")
  Container(C4, "calibre", "Docker")
  Container(C5, "chevereto_db", "Docker")
  Container(C6, "chevereto", "Docker")
  Container(C7, "code-server", "Docker")
}
@enduml
UML 3 · Composants et couches
3 · Composants et couches

Modules regroupés par couche du code. Les limites indiquent l’organisation, sans affirmer une isolation à l’exécution ni des appels. Rendu avec uml-mcp.

Source PlantUML
@startuml
!include <C4/C4_Component>
LAYOUT_TOP_DOWN()
System_Boundary(SYS, "another-install-script") {
Boundary(L0, "Points d’entrée et API", "layer") {
Component(M0_0, "containers/code-server", ".sh", "1 fichiers")
}
Boundary(L1, "Services applicatifs", "layer") {
Component(M1_0, "docs/scripts", ".sh, .bash", "3 fichiers")
}
Boundary(L2, "Domaine et règles métier", "layer") {
Component(M2_0, "containers/cloudtorrent", ".sh", "1 fichiers")
}
Boundary(L3, "Données et infrastructure", "layer") {
Component(M3_0, "containers/htpcdownloadbox", ".sh", "1 fichiers")
}
Boundary(L4, "Source principale", "layer") {
Component(M4_0, "src", ".sh, Python", "12 fichiers")
Component(M4_1, "(root)", ".sh", "3 fichiers")
Component(M4_2, "containers/n8n", ".sh", "2 fichiers")
Component(M4_3, "containers/airsonic", ".sh", "1 fichiers")
Component(M4_4, "containers/ansiblesemaphore", ".sh", "1 fichiers")
Component(M4_5, "containers/bitwarden", ".sh", "1 fichiers")
Component(M4_6, "containers/bookstack", ".sh", "1 fichiers")
Component(M4_7, "containers/calibre", ".sh", "1 fichiers")
Component(M4_more, "+83 modules", "", "")
}
Boundary(L5, "Tests", "layer") {
Component(M5_0, "docs", ".sh", "19 fichiers")
Component(M5_1, "tests", ".sh", "3 fichiers")
}
Boundary(L6, "Build, CI et hébergement", "layer") {
Component(M6_0, "containers", ".yml, Dockerfile", "95 fichiers")
Component(M6_1, ".github", ".md, CODEOWNERS", "7 fichiers")
Component(M6_2, "docs", ".yaml, Makefile", "2 fichiers")
}
}
@enduml
UML 4 · Code
4 · Code

Déclarations, champs et méthodes sélectionnés, regroupés par fichier source. Aucun héritage ni appel n’est déduit. Rendu avec uml-mcp.

Source PlantUML
@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
top to bottom direction
hide empty members
package "another-install-script" {
package "src/containers_list.py" as F0 {
class "GeneratorAIS" as T0_0 {
  read_yml()
  generate_containers_list()
  write_containers_list_text()
}
}
package "src/nginx_reverse_proxy.py" as F1 {
class "ReverseProxy" as T1_0 {
  read_yml()
  generate_nginx_conf()
  generate_server_block()
}
}
}
@enduml

7.3. Flux de données

Les appels du diagramme GitDiagram, dans l’ordre où on les rencontre depuis les points d’entrée. GitDiagram produit ce graphe par IA; les chemins de fichiers cités ont été comparés à l’arbre du dépôt.

Mermaid Diagramme de séquence
sequenceDiagram
  autonumber
  participant P0 as Service installers
  participant P1 as Compose definitions
  participant P2 as Service list generator
  participant P3 as System settings
  participant P4 as Proxy config generator
  participant P5 as Server administrator
  participant P6 as CLI menu
  participant P7 as Program installer
  participant P8 as Command router
  participant P9 as Other programs
  participant P10 as Container manager
  participant P11 as Docker operations
  participant P12 as Service catalog
  participant P13 as Docker
  P0--)P1: uses definitions
  P2->>P3: reads settings
  P4->>P3: reads settings
  P5->>P6: chooses services
  P5->>P7: requests programs
  P6--)P8: routes commands
  P7--)P9: offers programs
  P8--)P10: manages containers
  P10--)P11: uses Docker operations
  P10--)P12: installs services
  P11--)P13: operates
Étapes en texte
  1. Service installers vers Compose definitions uses definitions
  2. Service list generator vers System settings reads settings
  3. Proxy config generator vers System settings reads settings
  4. Server administrator vers CLI menu chooses services
  5. Server administrator vers Program installer requests programs
  6. CLI menu vers Command router routes commands
  7. Program installer vers Other programs offers programs
  8. Command router vers Container manager manages containers
  9. Container manager vers Docker operations uses Docker operations
  10. Container manager vers Service catalog installs services
  11. Docker operations vers Docker operates

7.4. Logique métier

Une fois écartés le code d’interface et les services et entités ci-dessus, ces classes ont le plus de méthodes.

GeneratorAIS Source principale, 3 méthodes
read_yml, generate_containers_list, write_containers_list_text
ReverseProxy Source principale, 3 méthodes
read_yml, generate_nginx_conf, generate_server_block

7.5. Base de données et persistance

Conteneurs de données

mariadb linuxserver/mariadb mariadb postgres:16 mysql:8.1 mysql:8.1 mongo:7.0 postgres:latest

7.6. Pipeline CI/CD

Aucun pipeline CI/CD dans le dépôt, en dehors de Travis CI. Le code se construit et se lance à la main, comme décrit plus haut.

7.7. Déploiement

Mermaid Schéma de déploiement
flowchart LR
  repo[("Dépôt GitHub")]
  ci_Travis_CI[["Travis CI"]]
  image["Image Docker<br/>FROM alpine:edge"]
  subgraph compose["Docker Compose"]
    svc_airsonic["airsonic"]
    svc_ansible_semaphore_db["ansible-semaphore_db"]
    svc_bookstack["bookstack"]
    svc_bookstack_db["bookstack_db"]
    svc_calibre["calibre"]
    svc_chevereto_db["chevereto_db"]
    svc_chevereto["chevereto"]
    svc_code_server["code-server"]
    svc_more["+8"]
  end
  repo --> ci_Travis_CI
  repo -->|"docker build"| image
  image -->|"docker compose up"| compose
UML Déploiement
Déploiement

Le nœud extérieur est l’endroit où le code s’exécute. Chaque image de base pointe vers ce qu’elle construit, les flèches pleines mènent aux bases de données et les pointillées aux services externes. Rendu avec uml-mcp.

Source PlantUML
@startuml
skinparam backgroundColor transparent
skinparam shadowing false
skinparam roundCorner 10
skinparam defaultFontName Arial
skinparam defaultFontSize 13
skinparam ArrowColor #4e6070
skinparam ArrowFontColor #3d4f5f
skinparam titleFontSize 14
skinparam actorBorderColor #006a62
skinparam actorBackgroundColor #e9f3f4
skinparam usecaseBorderColor #006a62
skinparam usecaseBackgroundColor #e9f3f4
skinparam componentBorderColor #006a62
skinparam componentBackgroundColor #e9f3f4
skinparam interfaceBorderColor #006a62
skinparam interfaceBackgroundColor #ffffff
skinparam nodeBorderColor #4e6070
skinparam nodeBackgroundColor #f4f8fb
skinparam databaseBorderColor #006a62
skinparam databaseBackgroundColor #ffffff
skinparam cloudBorderColor #4e6070
skinparam cloudBackgroundColor #f0f5fa
skinparam artifactBorderColor #006a62
skinparam artifactBackgroundColor #ffffff
skinparam rectangleBorderColor #b0c2d3
skinparam activityBorderColor #006a62
skinparam activityBackgroundColor #e9f3f4
skinparam partitionBorderColor #b0c2d3
skinparam stereotypeCBackgroundColor #ffffff
node "Docker Compose" as H {
  node "airsonic" as N0 <<container>>
  node "ansible-semaphore_db" as N1 <<container>>
  node "bookstack" as N2 <<container>>
  node "bookstack_db" as N3 <<container>>
  node "calibre" as N4 <<container>>
  node "chevereto_db" as N5 <<container>>
  node "chevereto" as N6 <<container>>
  node "code-server" as N7 <<container>>
  node "couchpotato" as N8 <<container>>
  node "cyberchef" as N9 <<container>>
}
artifact "FROM alpine:edge" as IMG0
IMG0 ..> N0 : construit
artifact "FROM golang:1.21-alpine" as IMG1
IMG1 ..> N0 : construit
artifact "FROM alpine:latest" as IMG2
IMG2 ..> N0 : construit
@enduml

Où il s’exécute

Services Compose

airsonic ansible-semaphore_db bookstack bookstack_db calibre chevereto_db chevereto code-server couchpotato cyberchef dailynotes dashmachine draw.io duplicati emby firefly_iii_app

Images Docker de base

alpine:edge golang:1.21-alpine alpine:latest node:20.7-alpine ubuntu:22.04 alpine:latest

7.8. Supervision

Ce que le code consigne, mesure et expose pour savoir s’il fonctionne.

Vérifications de santé des conteneurs

7.9. Sécurité

Chaîne d’approvisionnement

7.10. Tests automatisés

Fichiers de test
3
Fichiers source
109
Tests unitaires
3

Couverture de code

Aucun rapport chiffré de couverture dans les sources analysées.

Où sont les tests

tests 3

Rien trouvé pour: Interface publique, Interface privée, Services, Entités, Intégrations externes, Stack et dépendances.

8. Déploiement et exploitation

Les ports, le stockage et les relations de démarrage ci-dessous viennent de la configuration du dépôt. depends_on indique l’ordre de démarrage, pas la disponibilité du service.

9. Types et structure des fichiers

2 types déclarés, dont 2 dans l’aperçu des relations de base.

Diagramme des types
classDiagram
direction TB
class t9c1d5cd3c00c["GeneratorAIS"] {
  __init__()
  read_yml()
  generate_containers_list()
  write_containers_list_text()
}
class t51dcacef3aad["ReverseProxy"] {
  read_yml()
  generate_nginx_conf()
  generate_server_block()
}
class bb0976d8612e0["object"] {
  <<unresolved_base>>
}
bb0976d8612e0 <|-- t9c1d5cd3c00c

Les bases non résolues restent identifiées; les signatures complètes ne sont pas reconstruites.

10. Référence

203 / 203 fichiers admissibles lus (291 dans l’arbre); 0 trop volumineux, 0 échec de lecture et 1 diagnostic de syntaxe.

Ce que couvre l’analyse

Les dossiers connus de dépendances et de compilation, les fichiers d’identifiants et les binaires sont exclus. La collecte couvre les README, les manifestes reconnus et les fichiers source pris en charge.

Les statistiques Linguist couvrent l’ensemble du dépôt et peuvent inclure d’autres langages.

12. Fichiers à lire 3

13. Glossaire

Dépôt

Les fichiers source, la configuration et l’historique versionné d’un projet.

README

Le document d’entrée du dépôt, qui présente généralement son rôle et son installation.

Dépendance

Une bibliothèque, un outil ou un service nécessaire à la compilation ou à l’exécution d’un composant.

Conteneur

Un environnement de processus isolé créé à partir d’une image. Les données persistantes nécessitent un stockage hors de son système de fichiers temporaire.

Port publié

Un port de l’hôte associé au port d’un service dans un conteneur. Sa publication peut rendre le service accessible hors du réseau des conteneurs.

Interface en ligne de commande

Une interface textuelle où les commandes et arguments choisissent les opérations. Les codes de retour permettent aux scripts de détecter un succès ou un échec.

14. Références

  1. antoinebou12. (2026, 5 novembre). another-install-script. [Software repository] github.com.
  2. antoinebou12. (2026, 5 novembre). another-install-script: README. [Repository documentation] github.com.
  3. antoinebou12. (2026, 5 novembre). setup.sh. [Source file] github.com.
  4. antoinebou12. (2026, 5 novembre). src/menu.sh. [Source file] github.com.
  5. antoinebou12. (2026, 5 novembre). config.yml. [Source file] github.com.
  6. Boucher, A. (2024, 1 janvier). MediaBoxDockerCompose. [Project article] antoineboucher.info.
  7. Boucher, A. (2026, 23 octobre). another-install-script : Un menu d’installation pour le homelab. [Project article] antoineboucher.info.

Les sources sans date de publication indiquent la date de leur dernière vérification, le 5 novembre 2026. Les liens des fichiers conservent la révision inspectée lorsqu’elle est disponible.