Ressources de projet
Rattachez des dépôts GitHub ou des répertoires locaux à un projet pour que les exécutions suivantes disposent d'un contexte de travail stable.
Les ressources d'un projet indiquent aux agents quel code utilise cet ensemble de travail et où s'exécuter. Les ressources restent rattachées au projet : inutile de recoller les URL de dépôts ou les chemins locaux dans chaque tâche.
Deux types de ressources sont pris en charge aujourd'hui :
| Ressource | Idéal pour | Où ont lieu les exécutions |
|---|---|---|
| Dépôt GitHub | Du code partagé par l'équipe, avec des checkouts gérés par le runtime | Un répertoire de travail géré par le runtime |
| Répertoire local | Un checkout existant, un très gros dépôt, ou lorsque vous voulez inspecter directement les modifications locales | Le répertoire d'origine, sur un ordinateur précis |
Comment les ressources entrent dans une exécution
Lorsqu'un agent traite une tâche du projet, Multica ajoute le nom du projet, sa description et la liste des ressources au contexte de l'exécution, et écrit .multica/project/resources.json dans le répertoire de travail.
La liste des dépôts rattachés à l'espace de travail est toujours incluse dans le contexte de l'exécution. Les dépôts rattachés au projet précisent en plus le code et la ref par défaut qu'utilise cet ensemble de travail.
Un répertoire local ne s'applique qu'au daemon auquel il est lié. Lorsque le daemon chargé d'une exécution dispose d'un répertoire local correspondant, l'agent travaille directement dans ce répertoire ; les autres ordinateurs continuent d'utiliser les dépôts GitHub du projet ou les dépôts de l'espace de travail.
Ajouter un dépôt GitHub
Ouvrez le projet et choisissez « Ajouter une ressource » sous Ressources. Sélectionnez un dépôt déjà rattaché à l'espace de travail, ou collez une URL Git. Les dépôts de l'espace de travail se gèrent dans Paramètres → Code ; une fois GitHub connecté, la même page propose Choisir depuis GitHub pour importer les dépôts auxquels la GitHub App a accès.
Les dépôts ne se limitent pas à GitHub : toute URL Git accessible par le runtime fonctionne comme ressource de dépôt. Une instance Multica auto-hébergée peut aussi connecter des instances Forgejo, Gitea ou GitLab auto-hébergées dans Paramètres → Code ; voir Fournisseurs Git auto-hébergés.
Lors de la création d'un projet, vous pouvez aussi choisir des dépôts directement sous Dépôts. Un même projet peut rattacher plusieurs dépôts GitHub.
La ref d'une ressource définit la branche, le tag ou le commit que les checkouts suivants utilisent par défaut. default_branch_hint donne seulement à l'agent une indication sur la branche par défaut et n'impose pas de changement de branche.
Ajouter un répertoire local
L'interface d'ajout d'un répertoire local n'existe que dans l'application de bureau, car les navigateurs ne peuvent pas sélectionner de dossiers sur votre ordinateur.
Réservez cette option aux cas particuliers ; ne la choisissez pas par commodité. local_directory existe pour les personnes qui n'ont pas d'autre choix, typiquement un projet de jeu dont le checkout pèse des dizaines de gigaoctets et qu'il est impossible de recloner à chaque exécution.
Si votre répertoire est un dépôt git ordinaire que vous pouvez cloner, utilisez plutôt github_repo : il utilise le mode worktree par défaut, et les exécutions sur un même dépôt peuvent avoir lieu simultanément, sans limite de nombre. Un local_directory traite une exécution à la fois par défaut ; si le répertoire est un dépôt git, vous pouvez activer le mode worktree pour retrouver le parallélisme (voir Comment les exécutions partagent le répertoire). En cas de doute, comparez d'abord les deux types de ressources en haut de la page.
Assurez-vous que le daemon local de l'application de bureau est en ligne.
Ouvrez les Ressources du projet, ou l'onglet Répertoire local de la boîte de dialogue de création de projet. Le même choix y est disponible avant même que le projet existe.
Choisissez « Ajouter un répertoire local », puis sélectionnez le dossier à utiliser.
Choisissez comment les exécutions doivent l'utiliser : Direct ou Parallèle, voir Comment les exécutions partagent le répertoire. L'application de bureau présélectionne Parallèle lorsque le dossier est un dépôt git que le runtime de cette machine peut isoler, et Direct sinon. Modifiez ce choix sur place, ou plus tard depuis Ressources avec le crayon à côté du répertoire.
La présélection ne s'applique qu'au répertoire que vous rattachez maintenant. Un répertoire rattaché auparavant conserve le mode avec lequel il a été enregistré : une configuration existante n'est jamais modifiée à votre insu.
Le répertoire doit être un chemin absolu, doit déjà exister et doit être accessible en lecture et en écriture par le daemon actuel. Les chemins suivants sont refusés : les racines système et les racines de lecteur (/, C:\), les répertoires personnels eux-mêmes et leurs répertoires parents (comme /Users, /home, /root), ainsi que les répertoires système comme /etc, /var, /tmp, /usr et /opt. Si le chemin choisi est un lien symbolique, il est d'abord résolu en son chemin réel, puis validé à nouveau selon les mêmes règles ; le verrou de sérialisation s'applique lui aussi au chemin réel.
Chaque projet peut rattacher au plus un répertoire local par daemon. Les différents ordinateurs d'une équipe peuvent chacun rattacher leur propre répertoire pour le même projet.
En mode in_place (par défaut), un répertoire local n'est pas un environnement isolé : l'agent voit et modifie directement votre branche actuelle et vos fichiers non commités, et Multica ne change pas automatiquement de branche, ne fait ni stash, ni commit, ni push, et n'ouvre pas de PR. Le mode worktree fonctionne autrement, voir Comment les exécutions partagent le répertoire ci-dessous.
Comment les exécutions partagent le répertoire
Un répertoire local dispose de deux modes d'exécution, définis par ressource avec execution_mode. L'application de bureau les nomme Direct et Parallèle ; l'API, le CLI et le reste de cette page utilisent les identifiants.
L'agent travaille directement dans votre répertoire, et les exécutions ont lieu une à la fois. Lorsque deux exécutions utilisent le même répertoire réel, la seconde passe en waiting_local_directory et reprend une fois que la première a libéré le répertoire. Deux chemins qui mènent au même répertoire via des liens symboliques différents sont sérialisés de la même manière.
L'attente ne modifie pas le répertoire. Une exécution en attente peut être annulée ; sinon, elle attend que le répertoire devienne disponible.
Un simple répertoire non git ne peut utiliser que ce mode : le mode worktree est réservé aux dépôts git.
Ce qui est écrit pendant une exécution
Au-delà des modifications de code apportées par l'agent, le runtime peut aussi écrire dans le répertoire les fichiers d'instructions dont a besoin l'outil de codage IA utilisé, ainsi que .multica/project/resources.json. Ajoutez-les à .gitignore si vous ne voulez pas les versionner.
Multica ne supprime jamais un répertoire local rattaché lors du nettoyage des environnements d'exécution. Les modifications que l'agent apporte au répertoire sont de même nature que celles d'un outil de codage IA que vous lanceriez vous-même dans votre terminal, et demandent la même relecture.
Gérer les ressources avec le CLI
# Rattacher un dépôt lors de la création d'un projet
multica project create \
--title "Agent UX" \
--repo https://github.com/multica-ai/multica
# Lister et ajouter des ressources
multica project resource list <project-id>
multica project resource add <project-id> \
--type github_repo \
--url https://github.com/multica-ai/multica \
--ref main
# Rattacher un répertoire local sur un daemon précis
multica project resource add <project-id> \
--type local_directory \
--local-path /absolute/path/to/repo \
--daemon-id <daemon-id>
# Rattacher un dépôt git local et laisser les exécutions tourner simultanément, chacune dans son propre worktree
multica project resource add <project-id> \
--type local_directory \
--local-path /absolute/path/to/repo \
--daemon-id <daemon-id> \
--execution-mode worktree
# Faire passer un répertoire local existant d'un mode à l'autre
multica project resource update <project-id> <resource-id> --execution-mode worktree
multica project resource update <project-id> <resource-id> --execution-mode in_place
# Retirer une ressource
multica project resource remove <project-id> <resource-id>Les modifications de ressources s'appliquent aux exécutions créées ensuite ; elles ne réécrivent pas les enregistrements des exécutions déjà terminées.
Étapes suivantes
- Projets — découvrez le contexte, l'avancement et le responsable d'un projet.
- Daemon et runtimes — découvrez quel ordinateur prend en charge une exécution.
- Exécutions — consultez les états d'exécution comme
waiting_local_directory.